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

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260131184811.1e86ffa0@jic23-huawei>
Date: Sat, 31 Jan 2026 18:48:11 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: David Lechner <dlechner@...libre.com>
Cc: Nuno Sá <noname.nuno@...il.com>, Marcelo Schmitt
 <marcelo.schmitt1@...il.com>, linux-iio@...r.kernel.org,
 linux-kernel@...r.kernel.org, Jonathan.Cameron@...wei.com,
 nuno.sa@...log.com, andy@...nel.org
Subject: Re: [RFC PATCH v1 0/9] iio: Expand IIO event interface for
 real-world unit handling

On Wed, 21 Jan 2026 11:43:03 -0600
David Lechner <dlechner@...libre.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