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

[Andy Shevchenko <andriy.shevchenko@intel.com>]

On Mon, Mar 02, 2026 at 10:13:52AM +0000, Rodrigo Alencar wrote:
> 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@gmail.com> wrote:
> > > > > > On Mon, Feb 23, 2026 at 12:37 PM Rodrigo Alencar
> > > > > > <455.rodrigo.alencar@gmail.com> 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@yandex.ru/  
> > > > 
> > > > 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@smile.fi.intel.com/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?

I do not understand why we have to stick with the scope of IIO and make an
unneeded churn and double effort. We have a code that you need. Yes, it
requires an additional change that adds a glue (exported) function. How is it
out of the scope? If we hurry up with that code to be added, it increases
the chances to get the rest in sooner.

-- 
With Best Regards,
Andy Shevchenko