[RFC PATCH v1 0/9] iio: Expand IIO event interface for real-world unit handling

[RFC PATCH v1 0/9] iio: Expand IIO event interface for real-world unit handling

[Marcelo Schmitt]

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

[RFC PATCH v1 1/9] iio: ABI: Drop unused in_energy_input

[Marcelo Schmitt]

No IIO driver declares a channel of type IIO_ENERGY with info_mask
containing IIO_CHAN_INFO_PROCESSED. Thus, in_energy_input has never been
seen in user space.

Fixes: 72c66644673a ("iio: core: Introduce ENERGY channel type")
Signed-off-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
---
Added a fix tag though not sure it's needed/desired since it might not be worth
to backport documentation?

 Documentation/ABI/testing/sysfs-bus-iio | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index 5f87dcee78f7..aec39b8e3345 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -1601,7 +1601,6 @@ Description:
 		For a list of available output power modes read
 		in_accel_power_mode_available.
 
-What:		/sys/.../iio:deviceX/in_energy_input
 What:		/sys/.../iio:deviceX/in_energy_raw
 What:		/sys/.../iio:deviceX/in_energyY_active_raw
 What:		/sys/.../iio:deviceX/in_energyY_reactive_raw
-- 
2.51.0

Re: [RFC PATCH v1 1/9] iio: ABI: Drop unused in_energy_input

[Jonathan Cameron]

On Sun, 18 Jan 2026 15:18:57 -0300
Marcelo Schmitt <marcelo.schmitt1@gmail.com> wrote:

> No IIO driver declares a channel of type IIO_ENERGY with info_mask
> containing IIO_CHAN_INFO_PROCESSED. Thus, in_energy_input has never been
> seen in user space.
> 
> Fixes: 72c66644673a ("iio: core: Introduce ENERGY channel type")

I don't think the fixes tag makes sense.  This is just tidy up of
unused ABI, because why document what doesn't exist?

> Signed-off-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
> ---
> Added a fix tag though not sure it's needed/desired since it might not be worth
> to backport documentation?
> 
>  Documentation/ABI/testing/sysfs-bus-iio | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
> index 5f87dcee78f7..aec39b8e3345 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -1601,7 +1601,6 @@ Description:
>  		For a list of available output power modes read
>  		in_accel_power_mode_available.
>  
> -What:		/sys/.../iio:deviceX/in_energy_input
>  What:		/sys/.../iio:deviceX/in_energy_raw
>  What:		/sys/.../iio:deviceX/in_energyY_active_raw
>  What:		/sys/.../iio:deviceX/in_energyY_reactive_raw

[RFC PATCH v1 2/9] iio: ABI: Accurately describe in_distance_input

[Marcelo Schmitt]

There is only one driver (drivers/iio/accel/mma9553.c) that declares a
channel of type IIO_DISTANCE with an info_mask containing
IIO_CHAN_INFO_PROCESSED. Though, mma9553.c provides distance in meters (as
would be expected for the _input interface). Split in_distance_raw and
in_distance_input ABI documentation to provide accurate description for the
in_distance_input interface.

Fixes: 7cf78db585b1 ("iio: Add ABI documentation for illuminance raw and scale values in light")
Signed-off-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
---
Added a fix tag though not sure it's needed/desired since it might not be worth
to backport documentation?

 Documentation/ABI/testing/sysfs-bus-iio | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index aec39b8e3345..27251b65ea0e 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -1613,6 +1613,13 @@ Description:
 		user). Units after application of scale are Joules.
 
 What:		/sys/.../iio:deviceX/in_distance_input
+KernelVersion:	4.0
+Contact:	linux-iio@vger.kernel.org
+Description:
+		This attribute is used to read the measured distance (in meters)
+		to an object or the distance covered by the user since the last
+		reboot while activated.
+
 What:		/sys/.../iio:deviceX/in_distance_raw
 KernelVersion:	4.0
 Contact:	linux-iio@vger.kernel.org
-- 
2.51.0

Re: [RFC PATCH v1 2/9] iio: ABI: Accurately describe in_distance_input

[David Lechner]

On 1/18/26 12:20 PM, Marcelo Schmitt wrote:
> There is only one driver (drivers/iio/accel/mma9553.c) that declares a
> channel of type IIO_DISTANCE with an info_mask containing
> IIO_CHAN_INFO_PROCESSED. Though, mma9553.c provides distance in meters (as
> would be expected for the _input interface). Split in_distance_raw and
> in_distance_input ABI documentation to provide accurate description for the
> in_distance_input interface.
> 
> Fixes: 7cf78db585b1 ("iio: Add ABI documentation for illuminance raw and scale values in light")
> Signed-off-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
> ---
> Added a fix tag though not sure it's needed/desired since it might not be worth
> to backport documentation?
> 
>  Documentation/ABI/testing/sysfs-bus-iio | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
> index aec39b8e3345..27251b65ea0e 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -1613,6 +1613,13 @@ Description:
>  		user). Units after application of scale are Joules.
>  
>  What:		/sys/.../iio:deviceX/in_distance_input
> +KernelVersion:	4.0
> +Contact:	linux-iio@vger.kernel.org
> +Description:
> +		This attribute is used to read the measured distance (in meters)
> +		to an object or the distance covered by the user since the last
> +		reboot while activated.
> +
>  What:		/sys/.../iio:deviceX/in_distance_raw
>  KernelVersion:	4.0
>  Contact:	linux-iio@vger.kernel.org

I'm not sure it is worth splitting these up since the documentation is
just repeated except for the bit about scale. And it is common knowledge
that scale only applies to raw and not input.

Also, looks like raw and input are swapped. raw it the one with scale
so the sentence about scale should be with the raw attribute.

Re: [RFC PATCH v1 2/9] iio: ABI: Accurately describe in_distance_input

[Marcelo Schmitt]

On 01/18, David Lechner wrote:
> On 1/18/26 12:20 PM, Marcelo Schmitt wrote:
> > There is only one driver (drivers/iio/accel/mma9553.c) that declares a
> > channel of type IIO_DISTANCE with an info_mask containing
> > IIO_CHAN_INFO_PROCESSED. Though, mma9553.c provides distance in meters (as
> > would be expected for the _input interface). Split in_distance_raw and
> > in_distance_input ABI documentation to provide accurate description for the
> > in_distance_input interface.
> > 
> > Fixes: 7cf78db585b1 ("iio: Add ABI documentation for illuminance raw and scale values in light")
> > Signed-off-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
> > ---
> > Added a fix tag though not sure it's needed/desired since it might not be worth
> > to backport documentation?
> > 
> >  Documentation/ABI/testing/sysfs-bus-iio | 7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
> > index aec39b8e3345..27251b65ea0e 100644
> > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > @@ -1613,6 +1613,13 @@ Description:
> >  		user). Units after application of scale are Joules.
> >  
> >  What:		/sys/.../iio:deviceX/in_distance_input
> > +KernelVersion:	4.0
> > +Contact:	linux-iio@vger.kernel.org
> > +Description:
> > +		This attribute is used to read the measured distance (in meters)
> > +		to an object or the distance covered by the user since the last
> > +		reboot while activated.
> > +
> >  What:		/sys/.../iio:deviceX/in_distance_raw
> >  KernelVersion:	4.0
> >  Contact:	linux-iio@vger.kernel.org
> 
> I'm not sure it is worth splitting these up since the documentation is
> just repeated except for the bit about scale. And it is common knowledge
> that scale only applies to raw and not input.

It's common knowledge to us who are familiar with IIO. For anyone else, it might
not be. Plus, it is tecnically incorrect to have _raw and _input together like
they were before.

> 
> Also, looks like raw and input are swapped. raw it the one with scale
> so the sentence about scale should be with the raw attribute.

Hmm, have I messed up with the patches? Their final look in my local tree is:

What:		/sys/.../iio:deviceX/in_distance_input
KernelVersion:	4.0
Contact:	linux-iio@vger.kernel.org
Description:
		This attribute is used to read the measured distance (in meters)
		to an object or the distance covered by the user since the last
		reboot while activated.

What:		/sys/.../iio:deviceX/in_distance_raw
KernelVersion:	4.0
Contact:	linux-iio@vger.kernel.org
Description:
		This attribute is used to read the measured distance to an object
		or the distance covered by the user since the last reboot while
		activated. Units after application of scale are meters.

Re: [RFC PATCH v1 2/9] iio: ABI: Accurately describe in_distance_input

[Jonathan Cameron]

On Tue, 20 Jan 2026 23:49:11 -0300
Marcelo Schmitt <marcelo.schmitt1@gmail.com> wrote:

> On 01/18, David Lechner wrote:
> > On 1/18/26 12:20 PM, Marcelo Schmitt wrote:  
> > > There is only one driver (drivers/iio/accel/mma9553.c) that declares a
> > > channel of type IIO_DISTANCE with an info_mask containing
> > > IIO_CHAN_INFO_PROCESSED. Though, mma9553.c provides distance in meters (as
> > > would be expected for the _input interface). Split in_distance_raw and
> > > in_distance_input ABI documentation to provide accurate description for the
> > > in_distance_input interface.
> > > 
> > > Fixes: 7cf78db585b1 ("iio: Add ABI documentation for illuminance raw and scale values in light")
> > > Signed-off-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
> > > ---
> > > Added a fix tag though not sure it's needed/desired since it might not be worth
> > > to backport documentation?
> > > 
> > >  Documentation/ABI/testing/sysfs-bus-iio | 7 +++++++
> > >  1 file changed, 7 insertions(+)
> > > 
> > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
> > > index aec39b8e3345..27251b65ea0e 100644
> > > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > > @@ -1613,6 +1613,13 @@ Description:
> > >  		user). Units after application of scale are Joules.
> > >  
> > >  What:		/sys/.../iio:deviceX/in_distance_input
> > > +KernelVersion:	4.0
> > > +Contact:	linux-iio@vger.kernel.org
> > > +Description:
> > > +		This attribute is used to read the measured distance (in meters)
> > > +		to an object or the distance covered by the user since the last
> > > +		reboot while activated.
> > > +
> > >  What:		/sys/.../iio:deviceX/in_distance_raw
> > >  KernelVersion:	4.0
> > >  Contact:	linux-iio@vger.kernel.org  
> > 
> > I'm not sure it is worth splitting these up since the documentation is
> > just repeated except for the bit about scale. And it is common knowledge
> > that scale only applies to raw and not input.  
> 
> It's common knowledge to us who are familiar with IIO. For anyone else, it might
> not be. Plus, it is tecnically incorrect to have _raw and _input together like
> they were before.
If it's caused confusion. I think it's worth splitting them.
If the repeated text becomes too large, we can use a cross reference.

J
> 
> > 
> > Also, looks like raw and input are swapped. raw it the one with scale
> > so the sentence about scale should be with the raw attribute.  
> 
> Hmm, have I messed up with the patches? Their final look in my local tree is:
> 
> What:		/sys/.../iio:deviceX/in_distance_input
> KernelVersion:	4.0
> Contact:	linux-iio@vger.kernel.org
> Description:
> 		This attribute is used to read the measured distance (in meters)
> 		to an object or the distance covered by the user since the last
> 		reboot while activated.
> 
> What:		/sys/.../iio:deviceX/in_distance_raw
> KernelVersion:	4.0
> Contact:	linux-iio@vger.kernel.org
> Description:
> 		This attribute is used to read the measured distance to an object
> 		or the distance covered by the user since the last reboot while
> 		activated. Units after application of scale are meters.

[RFC PATCH v1 3/9] iio: ABI: Accurately describe in_illuminance[Y]_input

[Marcelo Schmitt]

The drivers that provide channels of type IIO_LIGHT with info masks
containing IIO_CHAN_INFO_PROCESSED provide values in lux through their
in_illuminance[Y]_input attribute. A few drivers provide both
in_illuminance[Y]_raw and in_illuminance[Y]_input and those also provide
values in lux through in_illuminance[Y]_input (as one would expect from
_input interfaces). The documentation, though, was previously describing
in_illuminance[Y]_input attributes as if they would only provide values in
lux after the application of offset and scale. Adjust the docs to provide
accurate description for IIO channel in_illuminance[Y]_input interface.

Signed-off-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
---
 Documentation/ABI/testing/sysfs-bus-iio | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index 27251b65ea0e..9fb12f7a639d 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -1652,8 +1652,13 @@ Description:
 		application of scale and offset are meters.
 
 What:		/sys/.../iio:deviceX/in_illuminance_input
-What:		/sys/.../iio:deviceX/in_illuminance_raw
 What:		/sys/.../iio:deviceX/in_illuminanceY_input
+KernelVersion:	3.4
+Contact:	linux-iio@vger.kernel.org
+Description:
+		Illuminance measurement in lux.
+
+What:		/sys/.../iio:deviceX/in_illuminance_raw
 What:		/sys/.../iio:deviceX/in_illuminanceY_raw
 What:		/sys/.../iio:deviceX/in_illuminanceY_mean_raw
 What:		/sys/.../iio:deviceX/in_illuminance_ir_raw
-- 
2.51.0

[RFC PATCH v1 4/9] iio: ABI: Slight readability improve for event threshold value doc

[Marcelo Schmitt]

Add missing '_' to the attribute name pattern. While at it, add a word to
clarify the relation with the configuration enable attribute on specific
scenarios.

Signed-off-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
---
 Documentation/ABI/testing/sysfs-bus-iio | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index 9fb12f7a639d..20e93000a93e 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -1054,9 +1054,9 @@ Contact:	linux-iio@vger.kernel.org
 Description:
 		Specifies the value of threshold that the device is comparing
 		against for the events enabled by
-		<type>Y[_name]_thresh[_rising|falling]_en.
+		<type>Y[_name]_thresh[_rising|_falling]_en.
 
-		If separate attributes exist for the two directions, but
+		If separate enable attributes exist for the two directions, but
 		direction is not specified for this attribute, then a single
 		threshold value applies to both directions.
 
-- 
2.51.0

[RFC PATCH v1 5/9] iio: ABI: Update event threshold value documentation

[Marcelo Schmitt]

Complement the IIO event threshold value ABI description clarifying that
raw device units are assumed when the attribute has no _raw/_input element
in it's name.

Signed-off-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
---
 Documentation/ABI/testing/sysfs-bus-iio | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index 20e93000a93e..d746a5e09225 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -1062,7 +1062,9 @@ Description:
 
 		The raw or input element of the name indicates whether the
 		value is in raw device units or in processed units (as _raw
-		and _input do on sysfs direct channel read attributes).
+		and _input do on sysfs direct channel read attributes). If the
+		raw/input element of the name is absent, values are in raw
+		device units.
 
 What:		/sys/.../events/in_accel_scale
 What:		/sys/.../events/in_accel_peak_scale
-- 
2.51.0

[RFC PATCH v1 6/9] iio: ABI: Adjust event threshold enable desc to unitless thresh values

[Marcelo Schmitt]

Adjust the event threshold enable attribute description to cover the cases
where threshold value attributes don't contain a _raw/_input element in
their names.

Signed-off-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
---
 Documentation/ABI/testing/sysfs-bus-iio | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index d746a5e09225..fd296d8cf51a 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -906,9 +906,9 @@ Description:
 		(_rising|_falling) direction. If the direction is not specified,
 		then either the device will report an event which ever direction
 		a single threshold value is passed in (e.g.
-		<type>[Y][_name]_<raw|input>_thresh_value) or
-		<type>[Y][_name]_<raw|input>_thresh_rising_value and
-		<type>[Y][_name]_<raw|input>_thresh_falling_value may take
+		<type>[Y][_name][_raw|_input]_thresh_value) or
+		<type>[Y][_name][_raw|_input]_thresh_rising_value and
+		<type>[Y][_name][_raw|_input]_thresh_falling_value may take
 		different values, but the device can only enable both thresholds
 		or neither.
 
-- 
2.51.0

[RFC PATCH v1 7/9] iio: Expand IIO event interface for real-world unit handling

[Marcelo Schmitt]

The IIO event ABI documentation distinguishes between interfaces that
handle values in device-specific units (_raw) and event interfaces that
handle values in real-world units (e.g. meters, Joules, lux, etc).
However, the IIO event code infrastructure had never really implemented the
bits to distinguish between those two types of interfaces and had always
presumed events to handle raw device values.

For most current use cases, assuming events to handle values in device raw
units is reasonable because it often matches the type of the associated IIO
channel. There are a few cases where drivers provide events along side
channels with both _raw and _input interfaces, though. Also, when
real-world values can be mapped back to device configurations, it enables
drivers to provide event interfaces that are arguably easier to use.

Expand the IIO events support, enabling IIO drivers to provide event
interfaces that handle values in real-world units.

Signed-off-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
---
 drivers/iio/industrialio-event.c | 47 +++++++++++++++++++++++---------
 include/linux/iio/iio.h          |  8 ++++--
 include/uapi/linux/iio/types.h   |  5 ++++
 3 files changed, 45 insertions(+), 15 deletions(-)

diff --git a/drivers/iio/industrialio-event.c b/drivers/iio/industrialio-event.c
index 06295cfc2da8..68bba21cae14 100644
--- a/drivers/iio/industrialio-event.c
+++ b/drivers/iio/industrialio-event.c
@@ -258,6 +258,11 @@ static const char * const iio_ev_info_text[] = {
 	[IIO_EV_INFO_RUNNING_COUNT] = "runningcount",
 };
 
+static const char * const iio_ev_unit_text[] = {
+	[IIO_EV_UNIT_RAW] = "raw",
+	[IIO_EV_UNIT_PROCESSED] = "input",
+};
+
 static enum iio_event_direction iio_ev_attr_dir(struct iio_dev_attr *attr)
 {
 	return attr->c->event_spec[attr->address & 0xffff].dir;
@@ -273,6 +278,11 @@ static enum iio_event_info iio_ev_attr_info(struct iio_dev_attr *attr)
 	return (attr->address >> 16) & 0xffff;
 }
 
+static enum iio_event_unit iio_ev_attr_unit(struct iio_dev_attr *attr)
+{
+	return attr->c->event_spec[attr->address & 0xffff].unit;
+}
+
 static ssize_t iio_ev_state_store(struct device *dev,
 				  struct device_attribute *attr,
 				  const char *buf,
@@ -332,7 +342,7 @@ static ssize_t iio_ev_value_show(struct device *dev,
 	ret = indio_dev->info->read_event_value(indio_dev,
 		this_attr->c, iio_ev_attr_type(this_attr),
 		iio_ev_attr_dir(this_attr), iio_ev_attr_info(this_attr),
-		&val, &val2);
+		iio_ev_attr_unit(this_attr), &val, &val2);
 	if (ret < 0)
 		return ret;
 	val_arr[0] = val;
@@ -359,7 +369,7 @@ static ssize_t iio_ev_value_store(struct device *dev,
 	ret = indio_dev->info->write_event_value(indio_dev,
 		this_attr->c, iio_ev_attr_type(this_attr),
 		iio_ev_attr_dir(this_attr), iio_ev_attr_info(this_attr),
-		val, val2);
+		iio_ev_attr_unit(this_attr), val, val2);
 	if (ret < 0)
 		return ret;
 
@@ -384,7 +394,8 @@ static ssize_t iio_ev_label_show(struct device *dev,
 static int iio_device_add_event(struct iio_dev *indio_dev,
 	const struct iio_chan_spec *chan, unsigned int spec_index,
 	enum iio_event_type type, enum iio_event_direction dir,
-	enum iio_shared_by shared_by, const unsigned long *mask)
+	enum iio_event_unit unit, enum iio_shared_by shared_by,
+	const unsigned long *mask)
 {
 	struct iio_dev_opaque *iio_dev_opaque = to_iio_dev_opaque(indio_dev);
 	ssize_t (*show)(struct device *dev, struct device_attribute *attr,
@@ -399,15 +410,23 @@ static int iio_device_add_event(struct iio_dev *indio_dev,
 	for_each_set_bit(i, mask, sizeof(*mask)*8) {
 		if (i >= ARRAY_SIZE(iio_ev_info_text))
 			return -EINVAL;
-		if (dir != IIO_EV_DIR_NONE)
-			postfix = kasprintf(GFP_KERNEL, "%s_%s_%s",
-					iio_ev_type_text[type],
-					iio_ev_dir_text[dir],
-					iio_ev_info_text[i]);
-		else
+		if (dir != IIO_EV_DIR_NONE) {
+			if (i == IIO_EV_INFO_ENABLE)
+				postfix = kasprintf(GFP_KERNEL, "%s_%s_%s",
+						iio_ev_type_text[type],
+						iio_ev_dir_text[dir],
+						iio_ev_info_text[i]);
+			else
+				postfix = kasprintf(GFP_KERNEL, "%s_%s_%s_%s",
+						iio_ev_unit_text[unit],
+						iio_ev_type_text[type],
+						iio_ev_dir_text[dir],
+						iio_ev_info_text[i]);
+		} else {
 			postfix = kasprintf(GFP_KERNEL, "%s_%s",
 					iio_ev_type_text[type],
 					iio_ev_info_text[i]);
+		}
 		if (postfix == NULL)
 			return -ENOMEM;
 
@@ -478,32 +497,34 @@ static int iio_device_add_event_sysfs(struct iio_dev *indio_dev,
 	int ret = 0, i, attrcount = 0;
 	enum iio_event_direction dir;
 	enum iio_event_type type;
+	enum iio_event_unit unit;
 
 	for (i = 0; i < chan->num_event_specs; i++) {
 		type = chan->event_spec[i].type;
 		dir = chan->event_spec[i].dir;
+		unit = chan->event_spec[i].unit;
 
-		ret = iio_device_add_event(indio_dev, chan, i, type, dir,
+		ret = iio_device_add_event(indio_dev, chan, i, type, dir, unit,
 			IIO_SEPARATE, &chan->event_spec[i].mask_separate);
 		if (ret < 0)
 			return ret;
 		attrcount += ret;
 
-		ret = iio_device_add_event(indio_dev, chan, i, type, dir,
+		ret = iio_device_add_event(indio_dev, chan, i, type, dir, unit,
 			IIO_SHARED_BY_TYPE,
 			&chan->event_spec[i].mask_shared_by_type);
 		if (ret < 0)
 			return ret;
 		attrcount += ret;
 
-		ret = iio_device_add_event(indio_dev, chan, i, type, dir,
+		ret = iio_device_add_event(indio_dev, chan, i, type, dir, unit,
 			IIO_SHARED_BY_DIR,
 			&chan->event_spec[i].mask_shared_by_dir);
 		if (ret < 0)
 			return ret;
 		attrcount += ret;
 
-		ret = iio_device_add_event(indio_dev, chan, i, type, dir,
+		ret = iio_device_add_event(indio_dev, chan, i, type, dir, unit,
 			IIO_SHARED_BY_ALL,
 			&chan->event_spec[i].mask_shared_by_all);
 		if (ret < 0)
diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
index 872ebdf0dd77..82d0a30e443f 100644
--- a/include/linux/iio/iio.h
+++ b/include/linux/iio/iio.h
@@ -156,6 +156,7 @@ typedef const struct iio_mount_matrix *
  * struct iio_event_spec - specification for a channel event
  * @type:		    Type of the event
  * @dir:		    Direction of the event
+ * @unit:		    Unit of the data to be handled (raw or processed).
  * @mask_separate:	    Bit mask of enum iio_event_info values. Attributes
  *			    set in this mask will be registered per channel.
  * @mask_shared_by_type:    Bit mask of enum iio_event_info values. Attributes
@@ -169,6 +170,7 @@ typedef const struct iio_mount_matrix *
 struct iio_event_spec {
 	enum iio_event_type type;
 	enum iio_event_direction dir;
+	enum iio_event_unit unit;
 	unsigned long mask_separate;
 	unsigned long mask_shared_by_type;
 	unsigned long mask_shared_by_dir;
@@ -522,13 +524,15 @@ struct iio_info {
 				const struct iio_chan_spec *chan,
 				enum iio_event_type type,
 				enum iio_event_direction dir,
-				enum iio_event_info info, int *val, int *val2);
+				enum iio_event_info info,
+				enum iio_event_unit unit, int *val, int *val2);
 
 	int (*write_event_value)(struct iio_dev *indio_dev,
 				 const struct iio_chan_spec *chan,
 				 enum iio_event_type type,
 				 enum iio_event_direction dir,
-				 enum iio_event_info info, int val, int val2);
+				 enum iio_event_info info,
+				 enum iio_event_unit unit, int val, int val2);
 
 	int (*read_event_label)(struct iio_dev *indio_dev,
 				struct iio_chan_spec const *chan,
diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
index 6d269b844271..4898444deb9e 100644
--- a/include/uapi/linux/iio/types.h
+++ b/include/uapi/linux/iio/types.h
@@ -137,4 +137,9 @@ enum iio_event_direction {
 	IIO_EV_DIR_FAULT_OPENWIRE,
 };
 
+enum iio_event_unit {
+	IIO_EV_UNIT_RAW,
+	IIO_EV_UNIT_PROCESSED,
+};
+
 #endif /* _UAPI_IIO_TYPES_H_ */
-- 
2.51.0

Re: [RFC PATCH v1 7/9] iio: Expand IIO event interface for real-world unit handling

[David Lechner]

On 1/18/26 12:21 PM, Marcelo Schmitt wrote:
> The IIO event ABI documentation distinguishes between interfaces that
> handle values in device-specific units (_raw) and event interfaces that
> handle values in real-world units (e.g. meters, Joules, lux, etc).
> However, the IIO event code infrastructure had never really implemented the
> bits to distinguish between those two types of interfaces and had always
> presumed events to handle raw device values.
> 
> For most current use cases, assuming events to handle values in device raw
> units is reasonable because it often matches the type of the associated IIO
> channel. There are a few cases where drivers provide events along side
> channels with both _raw and _input interfaces, though. Also, when
> real-world values can be mapped back to device configurations, it enables
> drivers to provide event interfaces that are arguably easier to use.
> 
> Expand the IIO events support, enabling IIO drivers to provide event
> interfaces that handle values in real-world units.
> 

...

> @@ -399,15 +410,23 @@ static int iio_device_add_event(struct iio_dev *indio_dev,
>  	for_each_set_bit(i, mask, sizeof(*mask)*8) {
>  		if (i >= ARRAY_SIZE(iio_ev_info_text))
>  			return -EINVAL;
> -		if (dir != IIO_EV_DIR_NONE)
> -			postfix = kasprintf(GFP_KERNEL, "%s_%s_%s",
> -					iio_ev_type_text[type],
> -					iio_ev_dir_text[dir],
> -					iio_ev_info_text[i]);
> -		else
> +		if (dir != IIO_EV_DIR_NONE) {
> +			if (i == IIO_EV_INFO_ENABLE)
> +				postfix = kasprintf(GFP_KERNEL, "%s_%s_%s",
> +						iio_ev_type_text[type],
> +						iio_ev_dir_text[dir],
> +						iio_ev_info_text[i]);
> +			else
> +				postfix = kasprintf(GFP_KERNEL, "%s_%s_%s_%s",
> +						iio_ev_unit_text[unit],
> +						iio_ev_type_text[type],
> +						iio_ev_dir_text[dir],
> +						iio_ev_info_text[i]);
> +		} else {

I think that the units only make sense on IIO_EV_INFO_VALUE and
IIO_EV_INFO_HYSTERESIS. Everything else has it's own unit, not just
IIO_EV_INFO_ENABLE.

>  			postfix = kasprintf(GFP_KERNEL, "%s_%s",
>  					iio_ev_type_text[type],
>  					iio_ev_info_text[i]);
> +		}
>  		if (postfix == NULL)
>  			return -ENOMEM;
>  

Re: [RFC PATCH v1 7/9] iio: Expand IIO event interface for real-world unit handling

[Jonathan Cameron]

On Sun, 18 Jan 2026 15:21:46 -0300
Marcelo Schmitt <marcelo.schmitt1@gmail.com> wrote:

> The IIO event ABI documentation distinguishes between interfaces that
> handle values in device-specific units (_raw) and event interfaces that
> handle values in real-world units (e.g. meters, Joules, lux, etc).
> However, the IIO event code infrastructure had never really implemented the
> bits to distinguish between those two types of interfaces and had always
> presumed events to handle raw device values.
> 
> For most current use cases, assuming events to handle values in device raw
> units is reasonable because it often matches the type of the associated IIO
> channel. There are a few cases where drivers provide events along side
> channels with both _raw and _input interfaces, though. Also, when
Can you list those cases. I thought we'd been keeping an eye out for that
but seems they slipped through!

> real-world values can be mapped back to device configurations, it enables
> drivers to provide event interfaces that are arguably easier to use.
> 
> Expand the IIO events support, enabling IIO drivers to provide event
> interfaces that handle values in real-world units.
> 
> Signed-off-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>

[RFC PATCH v1 8/9] iio: dummy: iio_simple_dummy: Update to event unit expanded interface

[Marcelo Schmitt]

The IIO events interface has been expanded with an additional parameter,
enabling drivers to handle values in real-world units for IIO event
configuration. Update to the expanded IIO event interface.

Signed-off-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
---
 drivers/iio/dummy/iio_simple_dummy.h        | 6 ++++--
 drivers/iio/dummy/iio_simple_dummy_events.c | 2 ++
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/dummy/iio_simple_dummy.h b/drivers/iio/dummy/iio_simple_dummy.h
index 8246f25dbad0..a1132781c0bc 100644
--- a/drivers/iio/dummy/iio_simple_dummy.h
+++ b/drivers/iio/dummy/iio_simple_dummy.h
@@ -66,14 +66,16 @@ int iio_simple_dummy_read_event_value(struct iio_dev *indio_dev,
 				      const struct iio_chan_spec *chan,
 				      enum iio_event_type type,
 				      enum iio_event_direction dir,
-				      enum iio_event_info info, int *val,
+				      enum iio_event_info info,
+				      enum iio_event_unit unit, int *val,
 				      int *val2);
 
 int iio_simple_dummy_write_event_value(struct iio_dev *indio_dev,
 				       const struct iio_chan_spec *chan,
 				       enum iio_event_type type,
 				       enum iio_event_direction dir,
-				       enum iio_event_info info, int val,
+				       enum iio_event_info info,
+				       enum iio_event_unit unit, int val,
 				       int val2);
 
 int iio_simple_dummy_events_register(struct iio_dev *indio_dev);
diff --git a/drivers/iio/dummy/iio_simple_dummy_events.c b/drivers/iio/dummy/iio_simple_dummy_events.c
index b51ec21b6309..9dfccc6439d4 100644
--- a/drivers/iio/dummy/iio_simple_dummy_events.c
+++ b/drivers/iio/dummy/iio_simple_dummy_events.c
@@ -120,6 +120,7 @@ int iio_simple_dummy_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)
 {
 	struct iio_dummy_state *st = iio_priv(indio_dev);
@@ -144,6 +145,7 @@ int iio_simple_dummy_write_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)
 {
 	struct iio_dummy_state *st = iio_priv(indio_dev);
-- 
2.51.0

[RFC PATCH v1 9/9] iio: adc: ad7091r-base: Update to event unit expanded interface

[Marcelo Schmitt]

The IIO events interface has been expanded with an additional parameter,
enabling drivers to handle values in real-world units for IIO event
configuration. Update to the expanded IIO event interface.

Signed-off-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
---
 drivers/iio/adc/ad7091r-base.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/adc/ad7091r-base.c b/drivers/iio/adc/ad7091r-base.c
index 647a7852dd8d..b3c6f6e5053d 100644
--- a/drivers/iio/adc/ad7091r-base.c
+++ b/drivers/iio/adc/ad7091r-base.c
@@ -27,6 +27,7 @@ const struct iio_event_spec ad7091r_events[] = {
 	{
 		.type = IIO_EV_TYPE_THRESH,
 		.dir = IIO_EV_DIR_FALLING,
+		.unit = IIO_EV_UNIT_RAW,
 		.mask_separate = BIT(IIO_EV_INFO_VALUE) |
 				 BIT(IIO_EV_INFO_ENABLE),
 	},
@@ -183,7 +184,8 @@ static int ad7091r_read_event_value(struct iio_dev *indio_dev,
 				    const struct iio_chan_spec *chan,
 				    enum iio_event_type type,
 				    enum iio_event_direction dir,
-				    enum iio_event_info info, int *val, int *val2)
+				    enum iio_event_info info,
+				    enum iio_event_unit unit, int *val, int *val2)
 {
 	struct ad7091r_state *st = iio_priv(indio_dev);
 	int ret;
@@ -224,7 +226,8 @@ static int ad7091r_write_event_value(struct iio_dev *indio_dev,
 				     const struct iio_chan_spec *chan,
 				     enum iio_event_type type,
 				     enum iio_event_direction dir,
-				     enum iio_event_info info, int val, int val2)
+				     enum iio_event_info info,
+				     enum iio_event_unit unit, int val, int val2)
 {
 	struct ad7091r_state *st = iio_priv(indio_dev);
 
-- 
2.51.0

Re: [RFC PATCH v1 0/9] iio: Expand IIO event interface for real-world unit handling

[David Lechner]

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.

Re: [RFC PATCH v1 0/9] iio: Expand IIO event interface for real-world unit handling

[Marcelo Schmitt]

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.

Re: [RFC PATCH v1 0/9] iio: Expand IIO event interface for real-world unit handling

[Nuno Sá]

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á

Re: [RFC PATCH v1 0/9] iio: Expand IIO event interface for real-world unit handling

[David Lechner]

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.

Re: [RFC PATCH v1 0/9] iio: Expand IIO event interface for real-world unit handling

[Jonathan Cameron]

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

Re: [RFC PATCH v1 0/9] iio: Expand IIO event interface for real-world unit handling

[Nuno Sá]

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á