Re: [PATCH 1/5] iio: humidity: hts221: report available values via read_avail()
Jonathan Cameron <[email protected]>
| Newsgroups | dev.linux.lists.linux-kernel-mentees,org.kernel.vger.linux-iio,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <20260812060414.427f7616@jic23-huawei> |
On Wed, 12 Aug 2026 08:22:48 +0800 Adinata Tan <[email protected]> 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.