From: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
To: linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: jic23@kernel.org, Jonathan.Cameron@huawei.com,
nuno.sa@analog.com, andy@kernel.org, dlechner@baylibre.com,
marcelo.schmitt1@gmail.com
Subject: [RFC PATCH v1 0/9] iio: Expand IIO event interface for real-world unit handling
Date: Sun, 18 Jan 2026 15:18:36 -0300 [thread overview]
Message-ID: <cover.1768759292.git.marcelo.schmitt1@gmail.com> (raw)
This patch set adjusts and complements the IIO event ABI docs making them
coherent with the fact that not all threshold value attributes had a _raw/_input
indicator set in their names. In addition that, the latter patches on this
series update the IIO event infrastructure to actually enable drivers to provide
_input threshold value attributes.
I'm actually proposing this set just for the sake of solving the event ABI
naming inconsistency. I recall the event ABI was a bit puzzling to understand
when I was having a closer look at that a while ago [1].
[1]: https://lore.kernel.org/linux-iio/cover.1703013352.git.marcelo.schmitt1@gmail.com/
Also, I'm doing this set entirely on my spare time and just because I wanted
to have the ABI naming inconsistency fixed. This is also a late reply to [2].
[2]: https://lore.kernel.org/linux-iio/20251109164312.781de64c@jic23-huawei/
I've tested this with ad7091r8 driver and result is:
Before event extension (current IIO teting branch):
root@localhost:~# ls /sys/bus/iio/devices/iio:device0/events
in_voltage0_thresh_either_hysteresis in_voltage4_thresh_either_hysteresis
in_voltage0_thresh_falling_en in_voltage4_thresh_falling_en
in_voltage0_thresh_falling_value in_voltage4_thresh_falling_value
in_voltage0_thresh_rising_en in_voltage4_thresh_rising_en
in_voltage0_thresh_rising_value in_voltage4_thresh_rising_value
in_voltage1_thresh_either_hysteresis in_voltage5_thresh_either_hysteresis
in_voltage1_thresh_falling_en in_voltage5_thresh_falling_en
in_voltage1_thresh_falling_value in_voltage5_thresh_falling_value
in_voltage1_thresh_rising_en in_voltage5_thresh_rising_en
in_voltage1_thresh_rising_value in_voltage5_thresh_rising_value
in_voltage2_thresh_either_hysteresis in_voltage6_thresh_either_hysteresis
in_voltage2_thresh_falling_en in_voltage6_thresh_falling_en
in_voltage2_thresh_falling_value in_voltage6_thresh_falling_value
in_voltage2_thresh_rising_en in_voltage6_thresh_rising_en
in_voltage2_thresh_rising_value in_voltage6_thresh_rising_value
in_voltage3_thresh_either_hysteresis in_voltage7_thresh_either_hysteresis
in_voltage3_thresh_falling_en in_voltage7_thresh_falling_en
in_voltage3_thresh_falling_value in_voltage7_thresh_falling_value
in_voltage3_thresh_rising_en in_voltage7_thresh_rising_en
in_voltage3_thresh_rising_value in_voltage7_thresh_rising_value
After event extension:
root@localhost:~# ls /sys/bus/iio/devices/iio:device0/events
in_voltage0_raw_thresh_either_hysteresis in_voltage4_raw_thresh_either_hysteresis
in_voltage0_raw_thresh_falling_value in_voltage4_raw_thresh_falling_value
in_voltage0_raw_thresh_rising_value in_voltage4_raw_thresh_rising_value
in_voltage0_thresh_falling_en in_voltage4_thresh_falling_en
in_voltage0_thresh_rising_en in_voltage4_thresh_rising_en
in_voltage1_raw_thresh_either_hysteresis in_voltage5_raw_thresh_either_hysteresis
in_voltage1_raw_thresh_falling_value in_voltage5_raw_thresh_falling_value
in_voltage1_raw_thresh_rising_value in_voltage5_raw_thresh_rising_value
in_voltage1_thresh_falling_en in_voltage5_thresh_falling_en
in_voltage1_thresh_rising_en in_voltage5_thresh_rising_en
in_voltage2_raw_thresh_either_hysteresis in_voltage6_raw_thresh_either_hysteresis
in_voltage2_raw_thresh_falling_value in_voltage6_raw_thresh_falling_value
in_voltage2_raw_thresh_rising_value in_voltage6_raw_thresh_rising_value
in_voltage2_thresh_falling_en in_voltage6_thresh_falling_en
in_voltage2_thresh_rising_en in_voltage6_thresh_rising_en
in_voltage3_raw_thresh_either_hysteresis in_voltage7_raw_thresh_either_hysteresis
in_voltage3_raw_thresh_falling_value in_voltage7_raw_thresh_falling_value
in_voltage3_raw_thresh_rising_value in_voltage7_raw_thresh_rising_value
in_voltage3_thresh_falling_en in_voltage7_thresh_falling_en
in_voltage3_thresh_rising_en in_voltage7_thresh_rising_en
The difference is the '_raw' element in thresh_(rising|falling|either) attributes.
Why posting it as an RFC?
1) ABI changes a sensitive topic.
2) There are 77 drivers that will go through collateral evolution with the event
interface update. A 77+ patch set is probably not a good idea? I recall the
claim_direct stuff was split into 2 or more patch sets. This might need a
similar approach (if accepted).
3) My coccinelle semantic patch does a nice job in updating the vast majority
of the drivers but, it produces diffs longer than needed. E.g.
@@ -844,7 +844,8 @@ static int adxl313_read_event_value(stru
enum iio_event_type type,
enum iio_event_direction dir,
enum iio_event_info info,
- int *val, int *val2)
+ enum iio_event_unit unit, int *val,
+ int *val2)
could be
@@ -844,6 +844,7 @@ static int adxl313_read_event_value(struct iio_dev *indio_dev,
enum iio_event_type type,
enum iio_event_direction dir,
enum iio_event_info info,
+ enum iio_event_unit unit,
int *val, int *val2)
I'll try to figure out how to make it generate smaller diffs, or do the changes
by hand if needed.
One more thing is this doesn't need to take test bot time as this breaks kernel
build without the patches to the individual drivers.
With best regards,
Marcelo
Marcelo Schmitt (9):
iio: ABI: Drop unused in_energy_input
iio: ABI: Accurately describe in_distance_input
iio: ABI: Accurately describe in_illuminance[Y]_input
iio: ABI: Slight readability improve for event threshold value doc
iio: ABI: Update event threshold value documentation
iio: ABI: Adjust event threshold enable desc to unitless thresh values
iio: Expand IIO event interface for real-world unit handling
iio: dummy: iio_simple_dummy: Update to event unit expanded interface
iio: adc: ad7091r-base: Update to event unit expanded interface
Documentation/ABI/testing/sysfs-bus-iio | 29 +++++++++----
drivers/iio/adc/ad7091r-base.c | 7 ++-
drivers/iio/dummy/iio_simple_dummy.h | 6 ++-
drivers/iio/dummy/iio_simple_dummy_events.c | 2 +
drivers/iio/industrialio-event.c | 47 +++++++++++++++------
include/linux/iio/iio.h | 8 +++-
include/uapi/linux/iio/types.h | 5 +++
7 files changed, 77 insertions(+), 27 deletions(-)
base-commit: c30e80d68a7afb334fde7147ee0106f25dd58d3a
--
2.51.0
next reply other threads:[~2026-01-18 18:16 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-18 18:18 Marcelo Schmitt [this message]
2026-01-18 18:18 ` [RFC PATCH v1 1/9] iio: ABI: Drop unused in_energy_input Marcelo Schmitt
2026-01-31 18:51 ` Jonathan Cameron
2026-01-18 18:20 ` [RFC PATCH v1 2/9] iio: ABI: Accurately describe in_distance_input Marcelo Schmitt
2026-01-18 19:46 ` David Lechner
2026-01-21 2:49 ` Marcelo Schmitt
2026-01-31 18:52 ` Jonathan Cameron
2026-01-18 18:20 ` [RFC PATCH v1 3/9] iio: ABI: Accurately describe in_illuminance[Y]_input Marcelo Schmitt
2026-01-18 18:20 ` [RFC PATCH v1 4/9] iio: ABI: Slight readability improve for event threshold value doc Marcelo Schmitt
2026-01-18 18:21 ` [RFC PATCH v1 5/9] iio: ABI: Update event threshold value documentation Marcelo Schmitt
2026-01-18 18:21 ` [RFC PATCH v1 6/9] iio: ABI: Adjust event threshold enable desc to unitless thresh values Marcelo Schmitt
2026-01-18 18:21 ` [RFC PATCH v1 7/9] iio: Expand IIO event interface for real-world unit handling Marcelo Schmitt
2026-01-18 20:10 ` David Lechner
2026-01-31 18:55 ` Jonathan Cameron
2026-01-18 18:22 ` [RFC PATCH v1 8/9] iio: dummy: iio_simple_dummy: Update to event unit expanded interface Marcelo Schmitt
2026-01-18 18:22 ` [RFC PATCH v1 9/9] iio: adc: ad7091r-base: " Marcelo Schmitt
2026-01-18 20:33 ` [RFC PATCH v1 0/9] iio: Expand IIO event interface for real-world unit handling David Lechner
2026-01-21 2:40 ` Marcelo Schmitt
2026-01-21 9:33 ` Nuno Sá
2026-01-21 17:43 ` David Lechner
2026-01-31 18:48 ` Jonathan Cameron
2026-02-02 10:21 ` Nuno Sá
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=cover.1768759292.git.marcelo.schmitt1@gmail.com \
--to=marcelo.schmitt1@gmail.com \
--cc=Jonathan.Cameron@huawei.com \
--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=nuno.sa@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