Re: [PATCH v2 1/6] dt-bindings: hwmon: add binding for adi,adt7470

Luiz Angelo Daros de Luca <[email protected]>
Newsgroups org.kernel.vger.linux-hwmon,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel,org.kernel.vger.linux-pwm
Message-ID <CAJq09z7z13hO33xpfQNYc=eHec3yN3H2yVy=oqXhuvhRZhvX3g@mail.gmail.com>
Hi Uwe,

> On Fri, Jul 17, 2026 at 05:59:14PM -0300, Luiz Angelo Daros de Luca wrote:
> > +  "#pwm-cells":
> > +    const: 2
> > +    description: |
> > +      Number of cells in a PWM specifier.
> > +      - The first cell is the PWM channel (0 to 3).
> > +      - The second cell is the PWM period in nanoseconds.
>
> Please use #pwm-cells = <3> and $ref: pwm.yaml#

Thanks for the review. I already switched to #pwm-cells = <3> for
the next version, so that part is settled.

Regarding $ref: /schemas/pwm/pwm.yaml#, it doesn't quite work here.
When I added it and ran
dt_binding_check, it started rejecting the example node:

hwmon@2f (adi,adt7470): $nodename:0: 'hwmon@2f' does not match
'^pwm(@.*|-([0-9]|[1-9][0-9]+))?$'

It turns out pwm.yaml also constrains $nodename as part of the
allOf, so referencing it forces the node name into the pwm@...
pattern. That's not right for this device: the ADT7470 is primarily a
hwmon chip (10 temperature inputs, 4 fan/PWM outputs), and the PWM
channels are just one of the interfaces it exposes, so hwmon@2f is
the correct node name here, not pwm@2f.

So, for the next version, I'm declaring #pwm-cells and
#thermal-sensor-cells directly in the binding instead of pulling in
pwm.yaml via $ref, and pointing to pwm.yaml only in the description
for context:

"#pwm-cells":
const: 3
description:
See Documentation/devicetree/bindings/pwm/pwm.yaml for the
generic PWM binding description.

Let me know if you'd rather see this handled differently (e.g. keeping
the $ref and accepting the pwm@ node name), but I think keeping the
node name aligned with the device's primary function is the more
correct approach.

Regards,

Luiz
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.