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: <5e3bf0d87ae1b539d134edefee67d3e3ef3b46cb.camel@gmail.com>
Date: Tue, 28 Oct 2025 09:22:36 +0000
From: Nuno Sá <noname.nuno@...il.com>
To: Andy Shevchenko <andriy.shevchenko@...el.com>, Jonathan Cameron
	 <jic23@...nel.org>
Cc: Chen-Yu Tsai <wens@...nel.org>, 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, 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).


[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á