Re: [PATCH v7 2/8] iio: core: add fixed point parsing with 64-bit parts

[Rodrigo Alencar]

On 26/03/02 11:33AM, Andy Shevchenko wrote:
> On Mon, Mar 02, 2026 at 09:19:42AM +0000, Rodrigo Alencar wrote:
> > On 26/03/02 10:27AM, Andy Shevchenko wrote:
> > > On Sun, Mar 01, 2026 at 12:23:40PM +0000, Jonathan Cameron wrote:
> > > > On Mon, 23 Feb 2026 12:41:45 +0200
> > > > Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote:
> > > > > On Mon, Feb 23, 2026 at 12:37 PM Rodrigo Alencar
> > > > > <455.rodrigo.alencar@xxxxxxxxx> wrote:
> > > > > > On 26/02/23 11:06AM, Andy Shevchenko wrote:  
> > > > > > > On Sun, Feb 22, 2026 at 05:29:12PM +0000, Jonathan Cameron wrote:  
> 
> ...
> 
> > > > > > > It all depends on the series from Dmitry Antipov.
> > > > > > > Can somebody help reviewing the patch 1 there?
> > > > > > > https://lore.kernel.org/linux-hardening/20260212125628.739276-1-dmantipov@xxxxxxxxx/  
> > > 
> > > FWIW, Andrew picked them up for Linux Next. Please, test!
> > 
> > The patch looks ok, but I am not seeing it solving my problem here.
> > Here is the v8:
> > https://lore.kernel.org/linux-hardening/aZXDSbyH8tWmTPPL@xxxxxxxxxxxxxxxxxx/T/#t
> > 
> > I would have to use simple_strtoull() and it would clamp the value at
> > ULLONG_MAX in case of overflow, but it would not say that an overflow
> > happened. Would that be fine? I understand that addressing the FIXME
> > in simple_strntoull() is not a subject of this patch.
> >  
> > > > > > can we push for the exposure of that function to kernel modules?
> > > > > > We have discussed that in v6, and I understand that:
> > > > > >
> > > > > > EXPORT_SYMBOL_FOR_MODULES(_parse_integer_limit, "industrialio");
> > > > > > in lib/kstrtox.c;
> > > > > >
> > > > > > #include "../../lib/kstrtox.h"
> > > > > > in drivers/iio/industrialio-core.c
> > > > > >
> > > > > > is not a good call...  
> > > > > 
> > > > > Yep, because it's a temporary band-aid. The proper solution is to have
> > > > > shared code provided by the lib/. So, the wrapper to parse 64-bit out
> > > > > from the constant string literal should be part of the lib/ in the
> > > > > result.
> > > > > 
> > > > > > > When it's in, we can continue on this one. TL;DR: for me this is on hold.
> > > > > > > But if you see the need to have the driver being in IIO, please add a big
> > > > > > > fat FIXME to make sure we will get this all being sorted out in the
> > > > > > > (nearest?) future.  
> > > > > >
> > > > > > I could add the FIXME into iio_safe_strntou64() doc header. It explains
> > > > > > the context:
> > > > > >  
> > > > > > > + * The implementation of this function is similar to _parse_integer_limit()
> > > > > > > + * available in lib/kstrtox.h, but that header/function is not available to be
> > > > > > > + * used in kernel modules. Hence, this implementation may need to change or
> > > > > > > + * removed to reuse a new suitable helper that is properly exposed.  
> > > > > 
> > > > > Up to Jonathan, I hope we can move the above mentioned series forward.
> > > > > Without that, as I pointed out, this one sounds to me suboptimal and
> > > > > unneeded double effort.
> > > > > 
> > > > I don't want to hold this series for another cycle, but we are still
> > > > fairly early in this one, so some focus on moving that forwards seems
> > > > sensible.  If we are running out of time, we can fallback to a loud
> > > > FIXME and a plan to move to the generic version in the library next cycle.
> > > > So let's set a rough deadline of rc5 and see how things are going then.
> > > 
> > > Taking into account the above, can we actually develop something
> > > based on that?  Or at least having a temporary solution for this
> > > cycle followed up by the better one for the next?
> > 
> > As mentioned above, I am not sure how consume what Andrew has over there.
> > It seems address lib/ internal stuff. The interfaces are still the same.
> 
> I think it will be third time I'm repeating that this needs a wrapper in the
> lib/. Just add the one (like with safe_strtoull() naming schema) with properly
> formed prototype that returns an error and the result in different variables
> 
> int safe_strtoull(..., *result)
> {
> 	...
> }
> EXPORT_SYMBOL_GPL(safe_strtoull);
> 
> (Also some test cases have to be added.)

I really understood that I would need to use Andrew's work as is, but
in fact, you encouraging me to add what we need on top of it.

Assuming that this would increase the scope of this patch series, I suppose
that would need to be included in a separate one.
can we just not export simple_strntoull() from lib/vsprintf.c? I mean,
addressing its FIXME and changing its prototype?

-- 
Kind regards,

Rodrigo Alencar