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
next prev parent 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®