linux-kernel - Re: [PATCH] iio: core: Use datasheet name as fallback for label

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: <CAGb2v676eOkPOc33+FMX6k9562gn34+MR15t-iucLjd0qQKs7Q@mail.gmail.com>
Date: Tue, 28 Oct 2025 22:36:35 +0800
From: Chen-Yu Tsai <wens@...nel.org>
To: Nuno Sá <noname.nuno@...il.com>, 
	Jonathan Cameron <jic23@...nel.org>
Cc: Andy Shevchenko <andriy.shevchenko@...el.com>, David Lechner <dlechner@...libre.com>, 
	Nuno Sá <nuno.sa@...log.com>, 
	Andy Shevchenko <andy@...nel.org>, linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] iio: core: Use datasheet name as fallback for label

On Tue, Oct 28, 2025 at 5:22 PM Nuno Sá <noname.nuno@...il.com> wrote:
>
> On Tue, 2025-10-28 at 10:04 +0200, Andy Shevchenko wrote:
> > On Mon, Oct 27, 2025 at 02:43:27PM +0000, Jonathan Cameron wrote:
> > > On Mon, 27 Oct 2025 20:42:09 +0800
> > > Chen-Yu Tsai <wens@...nel.org> wrote:
> > >
> > > > Some IIO drivers do not provide labels or extended names for their
> > > > channels. However they may provide datasheet names. axp20x-adc is
> > > > one such example.
> > > >
> > > > Use the datasheet name as a fallback for the channel label. This mainly
> > > > benefits iio-hwmon by letting the produced hwmon sensors have more
> > > > meaningful names rather than in_voltageX.
> > >
> > > I definitely don't want to have different behaviour for in kernel requests
> > > and for people reading the _label attributes.
> > > https://elixir.bootlin.com/linux/v6.18-rc2/source/drivers/iio/industrialio-core.c#L1232
> > > would need modifying to allow for the sysfs attributes to be created.
> > >
> > > In general I'm not sure I want to do this.  Datasheet names can be
> > > exceptionally
> > > obscure which is why we've kept them hidden from userspace.  At least dts
> > > writers
> > > tend to have those names on their circuit diagrams and tend to have
> > > datasheet access.
> > >
> > > Let's see if anyone else has feedback on this suggestion over next week or
> > > so.
> >
> > This is an ABI change without
>
> Indeed...
>
> > 1) proper documentation;
> > 2) backward compatibility (i.e. there is no knob to opt-out the change, or
> > make
> > it opt-in).
> >
> > In this form is definitely NAK.
> >
> > If you wish something like this, better to have a separate attribute. But the
> > problem maybe also that the same component (or 100% compatible one) made by
> > different vendors and have different datasheet names. This means that the new
> > attribute may still be ambiguous. Hence I see a little sense to have it,
> > rather
> > better to have these links / names to be put in DT schema. At least there we
> > have different vendors and compatibility mappings.
>
> I mean, we already have labels for channels so this all looks like a bit of
> overlap to me (though I see the temptation of going this way). For
> extended_names, there was a reason why it came as a fallback for .label() [1].
> For this, I'm not really convinced for now. There is also at least one driver
> already exporting the .datasheet_name as a label [2] so maybe we should do that
> instead (again, I understand that doing it like this we only need to change one
> place...)? Otherwise we should clean up those and that should definitely be part
> of the series (if we even consider this).

Thanks for the pointers. In my case I think either solution works.

The axp20x-adc driver currently provides _no_ labels. Would adding labels
now be considered backward incompatible?


Thanks
ChenYu

> [1]: https://lore.kernel.org/linux-iio/20210618123005.49867-1-paul@crapouillou.net/
> [2]: https://elixir.bootlin.com/linux/v6.18-rc2/source/drivers/iio/adc/xilinx-ams.c#L539
>
> - Nuno Sá