public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


             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