mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Lechner <dlechner@baylibre.com>
To: Flaviu Nistor <flaviu.nistor@gmail.com>,
	Andy Shevchenko <andy@kernel.org>
Cc: Jonathan Cameron <jic23@kernel.org>, Nuno Sa <nuno.sa@analog.com>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Rob Herring <robh@kernel.org>, Conor Dooley <conor+dt@kernel.org>,
	Daniel Baluta <daniel.baluta@nxp.com>,
	Antoniu Miclaus <antoniu.miclaus@analog.com>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-iio@vger.kernel.org
Subject: Re: [PATCH v2 2/2] iio: adc: ti-ads1015: Add support for label
Date: Thu, 3 Sep 2026 10:28:16 -0500	[thread overview]
Message-ID: <c7381f65-d895-4ee4-be24-695ca69a0337@baylibre.com> (raw)
In-Reply-To: <20260903151627.5011-1-flaviu.nistor@gmail.com>

On 9/3/26 10:16 AM, Flaviu Nistor wrote:
> On Thu, Sep 3, 2026 at 9:18 AM, Andy Shevchenko wrote:
>> On Wed, Sep 02, 2026 at 01:37:45PM -0500, David Lechner wrote:
>>> On 9/2/26 12:22 PM, Flaviu Nistor wrote:
>>
>> ...
>>
>>>> +		if (fwnode_property_present(node, "label")) {
>>>> +			ret = fwnode_property_read_string(node, "label", &label);
>>>> +			if (ret) {
>>>> +				dev_err(dev, "invalid label on %pfw\n", node);
>>>> +				return ret;
>>
>> 				return dev_err_probe(...);
>>
>>>> +			}
>>>> +			data->channel_data[channel].label = label;
>>>> +		} else {
>>>> +			data->channel_data[channel].label = "";
>>>
>>> I think the normal way to do this is to return -EINVAL on channels with no
>>> label rather than an empty string.
>>
>>
>> In this case the whole dance with property_present is not required.
>> (What you are saying sounds like label is mandatory property, but
>> how the old DT will work that have no such property?)
>>
> 
> I also consider that since label is not a mandatory property it should
> not return -EINVAL just be simply not being used in the device tree for
> that channel. Since the iio core exposes in sysfs the in_volatagex_label
> for all channels, there are 3 situations:
> 1. The channel is defined in the dts and has the optional label property
> assigned, in which case a string is returned in the console in user space.
> 2. The channel is defined in the dts but has no optional label property
> defined in the dts, in which case it an empty string "" (a default) is
> returned.
> 3. The channel is not defined in the dts (in_voltagex_label is still visible
> in the sysfs), and reading the label will cause "(null)\n" to be printed in
> the console (as indicated also by Sashiko boot), since the default "" value
> is not assigned during device_for_each_child_node_scoped(). I think this is
> not an issue since is just the way sysfs_emit() handles an NULL string.
> 
> My initial version (v1) handeled all 3 cases, for case 2 and 3, an empty string
> "" was printed out.
> 
> What would you prefer? Any further suggestions?

We should implement it like all of the other drivers that implement labels.
I did not see any that have an empty string, so we should not do that. The
sysfs attribute returns -EINVAL when read if there is not a label.

(I think my previous comment was ambiguous. I was not suggesting that we
return -EINVAL from probe.)

> 
> Best regards,
> Flaviu Nistor
> 
>>>> +		}
>>
>> -- 
>> With Best Regards,
>> Andy Shevchenko


  reply	other threads:[~2026-09-03 15:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02 17:22 [PATCH v2 1/2] dt-bindings: iio: adc: ti,ads1015: Add label property Flaviu Nistor
2026-09-02 17:22 ` [PATCH v2 2/2] iio: adc: ti-ads1015: Add support for label Flaviu Nistor
2026-09-02 18:37   ` David Lechner
2026-09-03  6:18     ` Andy Shevchenko
2026-09-03 15:16       ` Flaviu Nistor
2026-09-03 15:28         ` David Lechner [this message]
2026-09-03 19:03         ` Andy Shevchenko
2026-09-05  2:01           ` Jonathan Cameron
2026-09-02 18:31 ` [PATCH v2 1/2] dt-bindings: iio: adc: ti,ads1015: Add label property David Lechner
2026-09-03 15:19   ` Flaviu Nistor
2026-09-03 15:30     ` David Lechner
2026-09-05  1:56       ` Jonathan Cameron
2026-09-05  1:54 ` Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c7381f65-d895-4ee4-be24-695ca69a0337@baylibre.com \
    --to=dlechner@baylibre.com \
    --cc=andy@kernel.org \
    --cc=antoniu.miclaus@analog.com \
    --cc=conor+dt@kernel.org \
    --cc=daniel.baluta@nxp.com \
    --cc=devicetree@vger.kernel.org \
    --cc=flaviu.nistor@gmail.com \
    --cc=jic23@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nuno.sa@analog.com \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®