[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260207165938.59d6895f@jic23-huawei>
Date: Sat, 7 Feb 2026 16:59:38 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Nuno Sá <noname.nuno@...il.com>
Cc: 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, 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, 03 Feb 2026 10:04:01 +0000
Nuno Sá <noname.nuno@...il.com> wrote:
> 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.
When we say overflow, I assume we just get the wrong value? If so
then I doubt anyone ever noticed it. Worth tidying up as a useability
improvement but not sure it's worth back porting.
Jonathan
>
> - Nuno Sá
> > before this assignment.
> >
Powered by blists - more mailing lists