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

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

[Chen-Yu Tsai]

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.

Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
---
 drivers/iio/industrialio-core.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 88c3d585a1bd..d410ea2e7963 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -749,6 +749,9 @@ ssize_t do_iio_read_channel_label(struct iio_dev *indio_dev,
 	if (c->extend_name)
 		return sysfs_emit(buf, "%s\n", c->extend_name);
 
+	if (c->datasheet_name)
+		return sysfs_emit(buf, "%s\n", c->datasheet_name);
+
 	return -EINVAL;
 }
 
-- 
2.47.3

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

[Jonathan Cameron]

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.

Thanks,

Jonathan

> 
> Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
> ---
>  drivers/iio/industrialio-core.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 88c3d585a1bd..d410ea2e7963 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -749,6 +749,9 @@ ssize_t do_iio_read_channel_label(struct iio_dev *indio_dev,
>  	if (c->extend_name)
>  		return sysfs_emit(buf, "%s\n", c->extend_name);
>  
> +	if (c->datasheet_name)
> +		return sysfs_emit(buf, "%s\n", c->datasheet_name);
> +
>  	return -EINVAL;
>  }
>  

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

[Andy Shevchenko]

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
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.

-- 
With Best Regards,
Andy Shevchenko

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

[Nuno Sá]

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).


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

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

[Chen-Yu Tsai]

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?


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á

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

[Andy Shevchenko]

On Tue, Oct 28, 2025 at 10:36:35PM +0800, Chen-Yu Tsai wrote:
> On Tue, Oct 28, 2025 at 5:22 PM Nuno Sá <noname.nuno@gmail.com> wrote:

...

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

It can be considered forward-incompatible :-)

This kind of discussions happen in IIO in the past and probably still will in
the future. Namely "What should be unique (enough?) string to recognise chip
(platform?)?"

So, you see, we need to answer first "What do we want to recognise?
The platform or the chip?" Then decide what uniquiness will be enough.

-- 
With Best Regards,
Andy Shevchenko

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

[Nuno Sá]

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á

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

[Jonathan Cameron]

On Tue, 28 Oct 2025 15:17:24 +0000
Nuno Sá <noname.nuno@gmail.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@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.

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