From: Krzysztof Kozlowski <krzk@kernel.org>
To: Huan He <hehuan1@eswincomputing.com>
Cc: linux@roeck-us.net, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, p.zabel@pengutronix.de,
linux-hwmon@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, ningyu@eswincomputing.com,
linmin@eswincomputing.com, pinkesh.vaghela@einfochips.com,
luyulin@eswincomputing.com
Subject: Re: [PATCH v4 1/2] dt-bindings: hwmon: Add Eswin EIC7700 PVT sensor
Date: Wed, 13 May 2026 21:03:27 +0200 [thread overview]
Message-ID: <d525673f-4b7e-43c3-af6e-39b679036914@kernel.org> (raw)
In-Reply-To: <4339b90a.6169.19e1b798c90.Coremail.hehuan1@eswincomputing.com>
On 12/05/2026 11:16, Huan He wrote:
> Hi Krzysztof,
>
> Thank you very much for your detailed review. We appreciate the feedback.
>
>> On Thu, Apr 30, 2026 at 02:44:44PM +0800, hehuan1@eswincomputing.com wrote:
>>> +
>>> + label:
>>> + enum:
>>> + - pvt0
>>> + - pvt1
>>
>> No, label is user-visible name. Can be whatever user decides.
>>
>> Please read writing bindings - instance IDs are not allowed.
>
> Thanks for the clarification.
> I am planning to update the next revision as follows. Would this be
> acceptable?
From DT ABI point of view, that would be fine, but as Guenter pointed
out - it is not correct for hwmon.
>
> YAML:
> - label:
> - enum:
> - - pvt0
> - - pvt1
> + label: true
>
> required:
> - compatible
> - reg
> - clocks
> - interrupts
> - - label
>
> Driver:
> static int eic7700_pvt_create_hwmon(struct pvt_hwmon *pvt)
> {
> - struct device *dev = pvt->dev;
> - struct device_node *np = dev->of_node;
> - const char *node_label;
> - int type;
> - const char *names[2] = {"soc_pvt", "ddr_pvt"};
> -
> - if (of_property_read_string(np, "label", &node_label)) {
> - dev_err(dev, "Missing 'label' property in DTS node\n");
> - return -EINVAL;
> - }
> -
> - if (strcmp(node_label, "pvt0") == 0) {
> - type = 0;
> - } else if (strcmp(node_label, "pvt1") == 0) {
> - type = 1;
> - } else {
> - dev_err(pvt->dev, "Unsupported label: %s\n", node_label);
> - return -EINVAL;
> - }
> + const char *name = "pvt";
> +
> + of_property_read_string(pvt->dev->of_node, "label", &name);
>
> - pvt->hwmon = devm_hwmon_device_register_with_info(pvt->dev, names[type],
> + pvt->hwmon = devm_hwmon_device_register_with_info(pvt->dev, name,
> pvt, &pvt_hwmon_info,
> NULL);
>
>>
>>> +
>>> + resets:
>>> + maxItems: 1
>>> +
>>> + '#thermal-sensor-cells':
>>> + const: 0
>>> +
>>> +required:
>>> + - compatible
>>> + - reg
>>> + - clocks
>>> + - interrupts
>>> + - label
>>> + - resets
>>> +
>>> +unevaluatedProperties: false
>>> +
>>> +examples:
>>> + - |
>>> + pvt@50b00000 {
>>
>>
>> Node names should be generic. See also an explanation and list of
>> examples (not exhaustive) in DT specification:
>> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
>> If you cannot find a name matching your device, please check in kernel
>> sources for similar cases or you can grow the spec (via pull request to
>> DT spec repo).
>
> I will update the example node name from "pvt@..." to the generic
> "sensor@...". Is this acceptable?
Yes, assuming this is some sort of sensor.
Best regards,
Krzysztof
next prev parent reply other threads:[~2026-05-13 19:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-30 6:41 [PATCH v4 0/2] Add driver support for ESWIN EIC7700 PVT controller hehuan1
2026-04-30 6:44 ` [PATCH v4 1/2] dt-bindings: hwmon: Add Eswin EIC7700 PVT sensor hehuan1
2026-04-30 7:00 ` sashiko-bot
2026-05-12 9:14 ` Huan He
2026-05-03 12:03 ` Krzysztof Kozlowski
2026-05-12 9:16 ` Huan He
2026-05-12 14:26 ` Guenter Roeck
2026-05-13 7:03 ` Huan He
2026-05-13 19:03 ` Krzysztof Kozlowski [this message]
2026-04-30 6:45 ` [PATCH v4 2/2] hwmon: Add Eswin EIC7700 PVT sensor driver hehuan1
2026-04-30 8:08 ` sashiko-bot
2026-05-12 9:45 ` Huan He
2026-05-12 9:51 ` Huan He
2026-04-30 20:24 ` [PATCH v4 0/2] Add driver support for ESWIN EIC7700 PVT controller Guenter Roeck
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=d525673f-4b7e-43c3-af6e-39b679036914@kernel.org \
--to=krzk@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=hehuan1@eswincomputing.com \
--cc=krzk+dt@kernel.org \
--cc=linmin@eswincomputing.com \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=luyulin@eswincomputing.com \
--cc=ningyu@eswincomputing.com \
--cc=p.zabel@pengutronix.de \
--cc=pinkesh.vaghela@einfochips.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.