From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: rodrigo.alencar@analog.com
Cc: linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Jonathan Cameron <jic23@kernel.org>,
David Lechner <dlechner@baylibre.com>,
Andy Shevchenko <andy@kernel.org>
Subject: Re: [PATCH v4 5/6] iio: core: use kstrtodec64() to parse fixed-point values
Date: Mon, 26 Oct 2026 16:54:13 +0200 [thread overview]
Message-ID: <at9plejNuVxO2V-A@ashevche-desk.local> (raw)
In-Reply-To: <20261026-e-notation-v4-5-a366a6d14d57@analog.com>
On Mon, Oct 26, 2026 at 08:54:09AM -0300, Rodrigo Alencar via B4 Relay wrote:
> Replace the open-coded __iio_str_to_fixpoint() parser with kstrtodec64(),
> so sysfs writes of fixed-point values also accept E notation.
>
> The fractional part only keeps the sign when the integer part is zero,
> as before. The dB suffix for scale attributes is now handled by a separate
> __iio_str_to_fixpoint_units() helper. It strips an optional trailing
> newline and the "dB" or " dB" suffix before parsing.
>
> When there is no fractional part (fract_mult == 0, or dec_scale == 0 for
> 64-bit values), try base-autodetecting kstrtoll() first so hexadecimal
> and octal input keeps its meaning ("010" is still 8). Fall back to
> kstrtodec64() on -EINVAL to accept E notation.
> As a side effect, inputs that used to be rejected for integer-only
> attributes are now accepted. An invalid octal number such as "08" is
> parsed as decimal 8, and a fractional value such as "1.5" is rounded
> to 2.
The main question here is: Do we want these side effects?
And follow up question is: Where is it going to be documented?
I consider this paragraph is very important for the users.
...
> + /*
> + * Keep hex/octal support for integers. E notation and decimal values
> + * result in -EINVAL from kstrtoll, due to unexpected termination on '.'
kstrtoll()
> + * or 'e'. It falls back to kstrtodec64 for decimal fixed-point numbers
> + * with zero scale.
> + */
> + ret = kstrtoll(str, 0, val);
> + if (ret == -EINVAL)
> + ret = kstrtodec64(str, 0, val);
return kstrtodec64(str, 0, val);
?
> + return ret;
...
> int iio_str_to_fixpoint(const char *str, int fract_mult,
> int *integer, int *fract)
> {
> - return __iio_str_to_fixpoint(str, fract_mult, integer, fract, false);
> + s64 dec64;
> + int ret;
> +
> + if (fract_mult) {
> + /* scale = ffs(fract_mult) = ffs(10^n) = ffs(2^n * 5^n) = n + 1 */
> + ret = kstrtodec64(str, ffs(fract_mult), &dec64);
> + if (ret)
> + return ret;
> +
> + dec64 = div_s64_rem(dec64, fract_mult * 10, fract);
> + /* only carry the sign in fract if the integer is zero */
> + if (dec64)
> + *fract = abs(*fract);
Should we actually switch to UB-free abs() implementation?
> + } else {
> + ret = iio_str_to_s64(str, &dec64);
> + if (ret)
> + return ret;
> +
> + *fract = 0;
> + }
> +
> + if (dec64 > INT_MAX || dec64 < INT_MIN)
> + return -ERANGE;
> +
> + *integer = dec64;
> +
> + return 0;
> }
...
> + if (scale_db)
> + ret = iio_str_to_fixpoint_units(buf, "dB", fract_mult,
> + &integer, &fract);
Can we actually make units to be the last argument? In this case we might join
two calls together, it also might be beneficial from code generation point of
view (as the units version calls the basic one at the end).
> + else
> + ret = iio_str_to_fixpoint(buf, fract_mult, &integer,
> + &fract);
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2026-10-26 14:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-26 11:54 [PATCH v4 0/6] Add E notation support to kstrtodec64() and IIO sysfs writes Rodrigo Alencar via B4 Relay
2026-10-26 11:54 ` [PATCH v4 1/6] lib: kstrtox: support E notation in kstrtoudec64() and kstrtodec64() Rodrigo Alencar via B4 Relay
2026-10-26 11:54 ` [PATCH v4 2/6] lib: kstrtox: round to nearest, ties to even in kstrto[u]dec64() Rodrigo Alencar via B4 Relay
2026-10-26 11:54 ` [PATCH v4 3/6] lib: test-kstrtox: add E notation tests for kstrto[u]dec64() Rodrigo Alencar via B4 Relay
2026-10-26 11:54 ` [PATCH v4 4/6] iio: test: rescale: compare scales against the precision of the output Rodrigo Alencar via B4 Relay
2026-10-26 14:40 ` Andy Shevchenko
2026-10-26 15:29 ` Rodrigo Alencar
2026-10-26 11:54 ` [PATCH v4 5/6] iio: core: use kstrtodec64() to parse fixed-point values Rodrigo Alencar via B4 Relay
2026-10-26 14:54 ` Andy Shevchenko [this message]
2026-10-26 15:53 ` Rodrigo Alencar
2026-10-26 11:54 ` [PATCH v4 6/6] iio: test: add kunit tests for channel info writes Rodrigo Alencar via B4 Relay
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=at9plejNuVxO2V-A@ashevche-desk.local \
--to=andriy.shevchenko@intel.com \
--cc=akpm@linux-foundation.org \
--cc=andy@kernel.org \
--cc=dlechner@baylibre.com \
--cc=jic23@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rodrigo.alencar@analog.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®