mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

      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®