[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c4efbcda461cdfd58c7a7ab8b8c29c5f47fbda01.camel@gmail.com>
Date: Tue, 03 Feb 2026 10:04:01 +0000
From: Nuno Sá <noname.nuno@...il.com>
To: Rodrigo Alencar <455.rodrigo.alencar@...il.com>,
rodrigo.alencar@...log.com, linux-kernel@...r.kernel.org,
linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
linux-doc@...r.kernel.org
Cc: Jonathan Cameron <jic23@...nel.org>, David Lechner
<dlechner@...libre.com>, Andy Shevchenko <andy@...nel.org>, Lars-Peter
Clausen <lars@...afoo.de>, Michael Hennerich
<Michael.Hennerich@...log.com>, Rob Herring <robh@...nel.org>, Krzysztof
Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH v6 2/8] iio: core: add fixed point parsing with 64-bit
parts
On Tue, 2026-02-03 at 09:26 +0000, Rodrigo Alencar wrote:
> On 26/02/02 09:57AM, Nuno Sá wrote:
> > On Fri, 2026-01-30 at 10:06 +0000, Rodrigo Alencar via B4 Relay wrote:
> > > From: Rodrigo Alencar <rodrigo.alencar@...log.com>
> > >
> > > Add iio_str_to_fixpoint64() function that leverages simple_strtoull()
> > > to parse numbers from a string.
> > > A helper function __iio_str_to_fixpoint64() replaces
> > > __iio_str_to_fixpoint() implementation, extending its usage for
> > > 64-bit fixed-point parsing.
>
> ...
>
> > > /**
> > > * __iio_str_to_fixpoint() - Parse a fixed-point number from a string
> > > * @str: The string to parse
> > > @@ -895,63 +1026,43 @@ static ssize_t iio_read_channel_info_avail(struct device *dev,
> > > static int __iio_str_to_fixpoint(const char *str, int fract_mult,
> > > int *integer, int *fract, bool scale_db)
> > > {
> > > - int i = 0, f = 0;
> > > - bool integer_part = true, negative = false;
> > > + s64 integer64, fract64;
> > > + int ret;
> > >
> > > - if (fract_mult == 0) {
> > > - *fract = 0;
> > > + ret = __iio_str_to_fixpoint64(str, fract_mult, &integer64, &fract64,
> > > + scale_db);
> > > + if (ret)
> > > + return ret;
> >
> > I know it feels tempting to do the above while adding the 64bit variant. But isn't the
> > overflow safety also an issue on the 32bit variant? IMO, we should first have a patch
> > adding the overflow safety with a Fixes tag and then add 64bit support.
>
> I think handling 64-bit support after taclking the overflow issue
> would require changes on top of previous ones, which might get a messy
> commit history, no? Mostly because the 64-bit variant of the function
> is being used inside the 32-bit one. Also, the added auxiliary function
> that implements the overflow check parses u64, which allowed for the
> removal of the while loop in the __iio_str_to_fixpoint() implementation.
Typically we do fixes before because we might want to backport them and we just want to backport the
fix (so not the 64bit support). But we never really had any known issues with the current API
(AFAIK) so it might be ok as-is. Will defer to Jonathan.
- Nuno Sá
> before this assignment.
>
Powered by blists - more mailing lists