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: <aXA8lq7JGZEF4ffa@debian-BULLSEYE-live-builder-AMD64>
Date: Tue, 20 Jan 2026 23:40:22 -0300
From: Marcelo Schmitt <marcelo.schmitt1@...il.com>
To: David Lechner <dlechner@...libre.com>
Cc: linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
	jic23@...nel.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 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.