lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <cover.1768759292.git.marcelo.schmitt1@gmail.com>
Date: Sun, 18 Jan 2026 15:18:36 -0300
From: Marcelo Schmitt <marcelo.schmitt1@...il.com>
To: linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Cc: jic23@...nel.org, Jonathan.Cameron@...wei.com, nuno.sa@...log.com,
	andy@...nel.org, dlechner@...libre.com, marcelo.schmitt1@...il.com
Subject: [RFC PATCH v1 0/9] iio: Expand IIO event interface for real-world
 unit handling

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@...alhost:~# 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@...alhost:~# 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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ