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@xxxxxxxxxxxx> 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á