Re: [PATCH 1/5] iio: humidity: hts221: report available values via read_avail()
From: Jonathan Cameron
Date: Wed Aug 12 2026 - 01:05:17 EST
On Wed, 12 Aug 2026 08:22:48 +0800
Adinata Tan <adinatatan99@xxxxxxxxx> wrote:
> Hi Jonathan,
>
> Thanks for the feedback. I have checked with what Sachiko is saying is correct.
> The custom attribute was in_humidity_oversampling_ratio_available while
> the current on is in_humidityrelative_oversampling_ratio_available because in
> industrial_core.c only has [IIO_HUMIDITYRELATIVE] = "humidityrelative".
>
> For this humidity case in particular, would it be better to keep the legacy
> implementation while adding the new read_avail()?
To me it seems vanishingly unlikely there is any code out there jumping
through the hoops to read the wrong ABI element to figure out a possible
value to write to in_humidityrelative_oversampling_ratio
So I think this is in the category of ABI that we can change as long
as no one notices. For IIO I will also generally take ABI fixes on
basis we actually want to know if anyone is using the broken ABI
(and they very rarely are!)
>
> The other case declaration will remain changed.
>
> > > Replace the custom oversampling_ratio_available sysfs attributes with
> > > the standard IIO read_avail() callback. This lets the IIO core create
> > > and format *_available attributes and exposes the lists to
> > > in-kernel consumers.
> >
> > Sashiko points out that there is an ABI change in here as oddly
> > the driver uses
> > in_humidity_oversampling_ratio_available rather than
> > in_humidityrelative_oversampling_ratio_available
> >
> > Which makes this an ABI fix. Therefore this should have a fixes
> > tag and be moved to the start of the set. Please check that logic
> > though as maybe I'm missing something.