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

[Andy Shevchenko]

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!

> > > 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?

-- 
With Best Regards,
Andy Shevchenko