From: Jonathan Cameron <jic23@kernel.org>
To: Rodrigo Alencar via B4 Relay
<devnull+rodrigo.alencar.analog.com@kernel.org>
Cc: rodrigo.alencar@analog.com, linux-kernel@vger.kernel.org,
linux-iio@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
David Lechner <dlechner@baylibre.com>,
Andy Shevchenko <andy@kernel.org>
Subject: Re: [PATCH RFC v2 0/4] Add E notation support to kstrtodec64() and IIO sysfs writes
Date: Sat, 17 Oct 2026 23:50:32 +0100 [thread overview]
Message-ID: <20261017235032.693e9eca@jic23-hlaptop> (raw)
In-Reply-To: <20261013-e-notation-v2-0-d4adb5e193fc@analog.com>
On Tue, 13 Oct 2026 10:36:43 -0300
Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
> This series lets kstrtoudec64() and kstrtodec64() accept numbers in E
> notation (scientific notation), such as "2.7e9", "1.5E-3" or "1e+16".
> It then moves the IIO core fixed-point parser over to kstrtodec64(), so
> every IIO channel attribute written through iio_write_channel_info()
> accepts that format as well.
>
> There are two main motivations:
>
> 1. Shell usage of sysfs attributes
>
> Some IIO devices take values that are long to type and easy to get
> wrong in plain decimal. A frequency synthesizer or DDS might be
> programmed in the GHz range, and a scale might be a tiny fraction.
> With this series one can write:
>
> echo 2.7e9 > out_altvoltage0_frequency
> echo 1.5e-6 > in_voltage0_scale
>
> instead of counting zeros in "2700000000" or "0.0000015". It also
> works with shell tools that print in E notation by default, such as
> printf's %g conversion ("printf '%g' 2700000000" prints "2.7e+09")
> and awk, whose default output format ("%.6g") prints
> non-integral values like 1234567.5 as "1.23457e+06".
>
> 2. Userspace software that formats numbers automatically
>
> Many languages and libraries switch to E notation when converting
> floating point numbers to strings, without the caller asking for it:
>
> - Python: str() and repr() of a float use E notation for exponents
> below -4 or from 16 up, e.g. str(0.00001) == '1e-05' and
> str(1e16) == '1e+16'. Writing such a value straight to an attribute
> with open(...).write(str(value)) currently fails with -EINVAL.
> The same applies to NumPy scalars and to f-strings with the 'g'
> format spec (f"{2.7e9:g}" == '2.7e+09').
> - JavaScript/Node.js: Number.prototype.toString() uses E notation
> for magnitudes from 1e21 up or below 1e-6, e.g. String(1e-7)
> gives '1e-7'.
> - C/C++ applications and bindings that use printf("%g") or
> std::to_chars() with general formatting, as well as MATLAB/Octave
> and other numeric environments that print in a "short" form.
>
> Today these values have to be reformatted by the application, or are
> rejected by the kernel without warning. Accepting E notation in the
> kernel makes the IIO sysfs ABI more robust to this common
> behaviour.
FWIW reason for the feature looks sensible to me. Thanks for laying
out all this detail.
Jonathan
prev parent reply other threads:[~2026-10-17 22:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 13:36 Rodrigo Alencar via B4 Relay
2026-10-13 13:36 ` [PATCH RFC v2 1/4] lib: kstrtox: support E notation in kstrtoudec64() and kstrtodec64() Rodrigo Alencar via B4 Relay
2026-10-13 18:48 ` Andy Shevchenko
2026-10-13 13:36 ` [PATCH RFC v2 2/4] lib: test-kstrtox: add E notation tests for kstrto[u]dec64() Rodrigo Alencar via B4 Relay
2026-10-13 18:49 ` Andy Shevchenko
2026-10-13 13:36 ` [PATCH RFC v2 3/4] iio: core: use kstrtodec64() to parse fixed-point values Rodrigo Alencar via B4 Relay
2026-10-13 19:08 ` Andy Shevchenko
2026-10-14 10:46 ` Rodrigo Alencar
2026-10-13 13:36 ` [PATCH RFC v2 4/4] iio: test: add kunit tests for channel info writes Rodrigo Alencar via B4 Relay
2026-10-13 19:10 ` Andy Shevchenko
2026-10-17 22:55 ` Jonathan Cameron
2026-10-17 22:50 ` Jonathan Cameron [this message]
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=20261017235032.693e9eca@jic23-hlaptop \
--to=jic23@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=andy@kernel.org \
--cc=devnull+rodrigo.alencar.analog.com@kernel.org \
--cc=dlechner@baylibre.com \
--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®