public inbox for linux-iio@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: David Lechner <dlechner@baylibre.com>
Cc: "Nuno Sá" <noname.nuno@gmail.com>,
	"Marcelo Schmitt" <marcelo.schmitt1@gmail.com>,
	linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jonathan.Cameron@huawei.com, nuno.sa@analog.com, andy@kernel.org
Subject: Re: [RFC PATCH v1 0/9] iio: Expand IIO event interface for real-world unit handling
Date: Sat, 31 Jan 2026 18:48:11 +0000	[thread overview]
Message-ID: <20260131184811.1e86ffa0@jic23-huawei> (raw)
In-Reply-To: <95b13260-0564-445d-bff7-b3b54fa15005@baylibre.com>

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

  reply	other threads:[~2026-01-31 18:48 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-18 18:18 [RFC PATCH v1 0/9] iio: Expand IIO event interface for real-world unit handling Marcelo Schmitt
2026-01-18 18:18 ` [RFC PATCH v1 1/9] iio: ABI: Drop unused in_energy_input Marcelo Schmitt
2026-01-31 18:51   ` Jonathan Cameron
2026-01-18 18:20 ` [RFC PATCH v1 2/9] iio: ABI: Accurately describe in_distance_input Marcelo Schmitt
2026-01-18 19:46   ` David Lechner
2026-01-21  2:49     ` Marcelo Schmitt
2026-01-31 18:52       ` Jonathan Cameron
2026-01-18 18:20 ` [RFC PATCH v1 3/9] iio: ABI: Accurately describe in_illuminance[Y]_input Marcelo Schmitt
2026-01-18 18:20 ` [RFC PATCH v1 4/9] iio: ABI: Slight readability improve for event threshold value doc Marcelo Schmitt
2026-01-18 18:21 ` [RFC PATCH v1 5/9] iio: ABI: Update event threshold value documentation Marcelo Schmitt
2026-01-18 18:21 ` [RFC PATCH v1 6/9] iio: ABI: Adjust event threshold enable desc to unitless thresh values Marcelo Schmitt
2026-01-18 18:21 ` [RFC PATCH v1 7/9] iio: Expand IIO event interface for real-world unit handling Marcelo Schmitt
2026-01-18 20:10   ` David Lechner
2026-01-31 18:55   ` Jonathan Cameron
2026-01-18 18:22 ` [RFC PATCH v1 8/9] iio: dummy: iio_simple_dummy: Update to event unit expanded interface Marcelo Schmitt
2026-01-18 18:22 ` [RFC PATCH v1 9/9] iio: adc: ad7091r-base: " Marcelo Schmitt
2026-01-18 20:33 ` [RFC PATCH v1 0/9] iio: Expand IIO event interface for real-world unit handling David Lechner
2026-01-21  2:40   ` Marcelo Schmitt
2026-01-21  9:33   ` Nuno Sá
2026-01-21 17:43     ` David Lechner
2026-01-31 18:48       ` Jonathan Cameron [this message]
2026-02-02 10:21         ` Nuno Sá

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260131184811.1e86ffa0@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=andy@kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo.schmitt1@gmail.com \
    --cc=noname.nuno@gmail.com \
    --cc=nuno.sa@analog.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox