Re: [PATCH RFC v2 0/4] Add E notation support to kstrtodec64() and IIO sysfs writes

[Jonathan Cameron]

On Tue, 13 Oct 2026 10:36:43 -0300
Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@xxxxxxxxxx> 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