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] [day] [month] [year] [list]

Message-ID: <20251102120746.48dfb71b@jic23-huawei>
Date: Sun, 2 Nov 2025 12:07:46 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Nuno Sá <noname.nuno@...il.com>
Cc: wens@...nel.org, 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, 28 Oct 2025 15:17:24 +0000
Nuno Sá <noname.nuno@...il.com> wrote:

> On Tue, 2025-10-28 at 22:36 +0800, Chen-Yu Tsai wrote:
> > 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?
> >   
> 
> Jonathan should know better but I'm not seeing any reason why you could not add
> .label support for axp20x-adc (exporting the .datasheet_name for the channels)
> instead of the current patch.

I'd prefer a per driver version of this as then the author can look for the
sorts of issues Andy raised.  Basically it boils down to are the datasheet
names convenient and human readable names that it makes sense to reuse
for a particular set of devices (if no label in DT is provided)?

So basically side step the insane by doing it where we can evaluate that
the names meet this criteria.

Jonathan

> 
> - Nuno Sá
>