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(-)
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
On 1/18/26 12:18 PM, Marcelo Schmitt wrote: > 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 generally like the idea. There were a number of times recently when adding events where we had to do complex calculation to convert to/from raw units for the event value because it needed to match the in_..._raw scaling. In these cases it would have been much more convenient to be able to use SI units for the event value while keeping raw+scale for the actual sensor value. > > 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 We can't be breaking ABI like this. There are some alternatives though. We could register duplicate attributes with both the old and the new name (or can we make the old name a symlink to the new?). Or we could add a 3rd option to the unit of IIO_EV_UNIT_NONE and use that on existing drivers so that they don't change the attribute name. > > 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. > Just throwing out an idea here without thinking about it too much... Instead of adding a new field/parameter for units, could we extend enum iio_event_info to add IIO_EV_INFO_VALUE_RAW and IIO_EV_INFO_VALUE_INPUT (and same for HYSTERESIS). Really, the units only make sense for these two info types anyway. This would work like my suggestion above that existing drivers would continue to use the old enum value, but we would encourage using the new enum values in new code. And it would eliminate the churn of having to touch every existing user. And if someone really wants to take advantage of the new naming for a driver with existing events, we could do the duplicate attribute thing I mentioned above still.
On Sun, 2026-01-18 at 14:33 -0600, David Lechner wrote: > On 1/18/26 12:18 PM, Marcelo Schmitt wrote: > > 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. > ... > > Just throwing out an idea here without thinking about it too much... > > Instead of adding a new field/parameter for units, could we extend > enum iio_event_info to add IIO_EV_INFO_VALUE_RAW and IIO_EV_INFO_VALUE_INPUT > (and same for HYSTERESIS). Really, the units only make sense for these > two info types anyway. > Makes sense to me. Or we can just document that the old value is _INPUT? Or just make it the same value in the enum. - Nuno Sá
On 1/21/26 3:33 AM, Nuno Sá wrote: > On Sun, 2026-01-18 at 14:33 -0600, David Lechner wrote: >> On 1/18/26 12:18 PM, Marcelo Schmitt wrote: >>> 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. >> > > ... > >> >> Just throwing out an idea here without thinking about it too much... >> >> Instead of adding a new field/parameter for units, could we extend >> enum iio_event_info to add IIO_EV_INFO_VALUE_RAW and IIO_EV_INFO_VALUE_INPUT >> (and same for HYSTERESIS). Really, the units only make sense for these >> two info types anyway. >> > > Makes sense to me. Or we can just document that the old value is _INPUT? Or just make > it the same value in the enum. > > - Nuno Sá I don't think that works since IIO_EV_INFO_VALUE could be _RAW or _INPUT depending on the driver. And another point was that this should also control the _raw or _input in the attribute name, and we can't change the existing attribute names.
On Wed, 21 Jan 2026 11:43:03 -0600 David Lechner <dlechner@baylibre.com> wrote: > On 1/21/26 3:33 AM, Nuno Sá wrote: > > On Sun, 2026-01-18 at 14:33 -0600, David Lechner wrote: > >> On 1/18/26 12:18 PM, Marcelo Schmitt wrote: > >>> 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. > >> > > > > ... > > > >> > >> Just throwing out an idea here without thinking about it too much... > >> > >> Instead of adding a new field/parameter for units, could we extend > >> enum iio_event_info to add IIO_EV_INFO_VALUE_RAW and IIO_EV_INFO_VALUE_INPUT > >> (and same for HYSTERESIS). Really, the units only make sense for these > >> two info types anyway. > >> > > > > Makes sense to me. Or we can just document that the old value is _INPUT? Or just make > > it the same value in the enum. > > > > - Nuno Sá > > I don't think that works since IIO_EV_INFO_VALUE could be _RAW or _INPUT > depending on the driver. And another point was that this should also > control the _raw or _input in the attribute name, and we can't change the > existing attribute names. > Fully agree with David here. To fix this up we need new ABI, with the old ABI remaining in place (including for new drivers) where the raw or processed nature of event values is derived from whether they have _raw or _input (and hopefully not the horrible case of both!) The new drivers keeping this bit is the only place I might be flexible if it is a real problem. I'd still strongly prefer devices to match the channel presentation for these but if there is a really tricky corner case for a particular part then 'maybe' we can relax it. Upshot is that it won't work with standard userspace code that is old. Not the first time we've had to add new ABI and keep the old (whilst telling people not to use it) The multiple buffers stuff is a good example. Jonathan
On Sat, 2026-01-31 at 18:48 +0000, Jonathan Cameron wrote: > On Wed, 21 Jan 2026 11:43:03 -0600 > David Lechner <dlechner@baylibre.com> wrote: > > > On 1/21/26 3:33 AM, Nuno Sá wrote: > > > On Sun, 2026-01-18 at 14:33 -0600, David Lechner wrote: > > > > On 1/18/26 12:18 PM, Marcelo Schmitt wrote: > > > > > 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. > > > > > > > > > > ... > > > > > > > > > > > Just throwing out an idea here without thinking about it too much... > > > > > > > > Instead of adding a new field/parameter for units, could we extend > > > > enum iio_event_info to add IIO_EV_INFO_VALUE_RAW and IIO_EV_INFO_VALUE_INPUT > > > > (and same for HYSTERESIS). Really, the units only make sense for these > > > > two info types anyway. > > > > > > > > > > Makes sense to me. Or we can just document that the old value is _INPUT? Or just make > > > it the same value in the enum. > > > > > > - Nuno Sá > > > > I don't think that works since IIO_EV_INFO_VALUE could be _RAW or _INPUT > > depending on the driver. And another point was that this should also > > control the _raw or _input in the attribute name, and we can't change the > > existing attribute names. > > > > Fully agree with David here. To fix this up we need new ABI, with > the old ABI remaining in place (including for new drivers) where the > raw or processed nature of event values is derived from whether they have > _raw or _input (and hopefully not the horrible case of both!) > > The new drivers keeping this bit is the only place I might be flexible > if it is a real problem. I'd still strongly prefer devices to match > the channel presentation for these but if there is a really tricky > corner case for a particular part then 'maybe' we can relax it. Upshot > is that it won't work with standard userspace code that is old. > > Not the first time we've had to add new ABI and keep the old > (whilst telling people not to use it) > The multiple buffers stuff is a good example. Sure, I was not suggesting to destroy ABI. Just a suggestion for the enum :) Yeah, I desperately need to find a proper multibuffer user for upstream. We do have some issues there... - Nuno Sá
On 01/18, David Lechner wrote: > On 1/18/26 12:18 PM, Marcelo Schmitt wrote: > > 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. > ... > > Just throwing out an idea here without thinking about it too much... > > Instead of adding a new field/parameter for units, could we extend > enum iio_event_info to add IIO_EV_INFO_VALUE_RAW and IIO_EV_INFO_VALUE_INPUT > (and same for HYSTERESIS). Makes sense. If no other idea comes up, I'll go with that for the next version. > Really, the units only make sense for these > two info types anyway. Ah good point. I was too hasty in thinking the _raw/_input distinction would apply to other event_info options. Will avoid affecting those. Thanks > > This would work like my suggestion above that existing drivers would continue > to use the old enum value, but we would encourage using the new enum values > in new code. And it would eliminate the churn of having to touch every existing > user. > > And if someone really wants to take advantage of the new naming for a driver > with existing events, we could do the duplicate attribute thing I mentioned > above still.
© 2016 - 2026 Red Hat, Inc.