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 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.)

-- 
With Best Regards,
Andy Shevchenko