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

["Nuno Sá" <noname.nuno@gmail.com>]

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@gmail.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@kernel.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.

- Nuno Sá