Re: Phandles

Re: Phandles

[Herve Codina]

Hi Kyle,

+Cc Kernel device-tree maintainers

On Sun, 12 Apr 2026 13:51:35 +0000
Kyle Bonnici <kylebonnici@hotmail.com> wrote:

> > On 12 Apr 2026, at 14:51, Herve Codina <herve.codina@bootlin.com> wrote:
> > 
> > Hi Kyle,
> > 
> > On Sat, 11 Apr 2026 18:33:33 +0000
> > Kyle Bonnici <kylebonnici@hotmail.com> wrote:
> >   
> >> Hi
> >> 
> >> I have been looking at the the code for the compiler and I am wondering which specifications marks the below properties MUST BE Nexus Properties hence the validation.
> >> 
> >> WARNING_PROPERTY_PHANDLE_CELLS(clocks, "clocks", "#clock-cells");
> >> WARNING_PROPERTY_PHANDLE_CELLS(cooling_device, "cooling-device", "#cooling-cells");
> >> WARNING_PROPERTY_PHANDLE_CELLS(dmas, "dmas", "#dma-cells");
> >> WARNING_PROPERTY_PHANDLE_CELLS(hwlocks, "hwlocks", "#hwlock-cells");
> >> WARNING_PROPERTY_PHANDLE_CELLS(interrupts_extended, "interrupts-extended", "#interrupt-cells");
> >> WARNING_PROPERTY_PHANDLE_CELLS(io_channels, "io-channels", "#io-channel-cells");
> >> WARNING_PROPERTY_PHANDLE_CELLS(iommus, "iommus", "#iommu-cells");
> >> WARNING_PROPERTY_PHANDLE_CELLS(mboxes, "mboxes", "#mbox-cells");
> >> WARNING_PROPERTY_PHANDLE_CELLS(msi_parent, "msi-parent", "#msi-cells", true);
> >> WARNING_PROPERTY_PHANDLE_CELLS(mux_controls, "mux-controls", "#mux-control-cells");
> >> WARNING_PROPERTY_PHANDLE_CELLS(phys, "phys", "#phy-cells");
> >> WARNING_PROPERTY_PHANDLE_CELLS(power_domains, "power-domains", "#power-domain-cells");
> >> WARNING_PROPERTY_PHANDLE_CELLS(pwms, "pwms", "#pwm-cells");
> >> WARNING_PROPERTY_PHANDLE_CELLS(resets, "resets", "#reset-cells");
> >> WARNING_PROPERTY_PHANDLE_CELLS(sound_dai, "sound-dai", "#sound-dai-cells");
> >> WARNING_PROPERTY_PHANDLE_CELLS(thermal_sensors, "thermal-sensors", "#thermal-sensor-cells");  
> > 
> > All of those properties are defined as phandles.
> > 
> > For instance, the 'pwms' property available in a node means the the node is
> > a pwm consumer. It must follow the pwm consumer binding [1] and so a phandle
> > is involved.
> > 
> > This phandle can have arguments and the number of argument is defined by the
> > #pwm-cells property set in the pwm provider node [2], [3].
> > 
> > [1] https://elixir.bootlin.com/zephyr/v4.4.0-rc3/source/dts/bindings/pwm/pwm-controller.yaml
> > [2] https://github.com/zephyrproject-rtos/zephyr/blob/main/dts/bindings/pwm/pwm-controller.yaml
> > [3] https://elixir.bootlin.com/linux/v7.0-rc7/source/Documentation/devicetree/bindings/pwm/pwm.yaml
> >   
> >> 
> >> 
> >> These can be found here: https://github.com/dgibson/dtc/blob/main/checks.c#L1498 this is relevant for https://github.com/zephyrproject-rtos/zephyr/issues/107066  
> > 
> > Examples provided in the zephyrproject issue link are, in my opinion, incorrect.
> > 
> >  Case 1:
> >  / {
> >      node1 {
> >           pwms = <1 &pwm0 1 20 PWM_POLARITY_NORMAL>;
> > 
> >           Here the first cell '1' is not a phandle.  
> 
> Here the compiler is making an assumption here that all `pwms` properties must be specifier properties and all use `pwm` specifier.

I think the purpose of 'select: true' is to have the binding always applied:
  https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/pwm/pwm-consumer.yaml#L15

If this is confirmed, DTC performs correct checks as this binding must always
be applied and so the 'pwms' property must be a phandle-array property.

Device-tree maintainers, can you confirm the purpose of 'select: true' set
in a DT binding ?

Best regards,
Hervé

Re: Phandles

[Kyle Bonnici]

> On 12 Apr 2026, at 17:40, Herve Codina <herve.codina@bootlin.com> wrote:
> 
> Hi Kyle,
> 
> +Cc Kernel device-tree maintainers
> 
> On Sun, 12 Apr 2026 13:51:35 +0000
> Kyle Bonnici <kylebonnici@hotmail.com> wrote:
> 
>>> On 12 Apr 2026, at 14:51, Herve Codina <herve.codina@bootlin.com> wrote:
>>> 
>>> Hi Kyle,
>>> 
>>> On Sat, 11 Apr 2026 18:33:33 +0000
>>> Kyle Bonnici <kylebonnici@hotmail.com> wrote:
>>> 
>>>> Hi
>>>> 
>>>> I have been looking at the the code for the compiler and I am wondering which specifications marks the below properties MUST BE Nexus Properties hence the validation.
>>>> 
>>>> WARNING_PROPERTY_PHANDLE_CELLS(clocks, "clocks", "#clock-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(cooling_device, "cooling-device", "#cooling-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(dmas, "dmas", "#dma-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(hwlocks, "hwlocks", "#hwlock-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(interrupts_extended, "interrupts-extended", "#interrupt-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(io_channels, "io-channels", "#io-channel-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(iommus, "iommus", "#iommu-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(mboxes, "mboxes", "#mbox-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(msi_parent, "msi-parent", "#msi-cells", true);
>>>> WARNING_PROPERTY_PHANDLE_CELLS(mux_controls, "mux-controls", "#mux-control-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(phys, "phys", "#phy-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(power_domains, "power-domains", "#power-domain-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(pwms, "pwms", "#pwm-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(resets, "resets", "#reset-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(sound_dai, "sound-dai", "#sound-dai-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(thermal_sensors, "thermal-sensors", "#thermal-sensor-cells");  
>>> 
>>> All of those properties are defined as phandles.
>>> 
>>> For instance, the 'pwms' property available in a node means the the node is
>>> a pwm consumer. It must follow the pwm consumer binding [1] and so a phandle
>>> is involved.
>>> 
>>> This phandle can have arguments and the number of argument is defined by the
>>> #pwm-cells property set in the pwm provider node [2], [3].
>>> 
>>> [1] https://elixir.bootlin.com/zephyr/v4.4.0-rc3/source/dts/bindings/pwm/pwm-controller.yaml
>>> [2] https://github.com/zephyrproject-rtos/zephyr/blob/main/dts/bindings/pwm/pwm-controller.yaml
>>> [3] https://elixir.bootlin.com/linux/v7.0-rc7/source/Documentation/devicetree/bindings/pwm/pwm.yaml
>>> 
>>>> 
>>>> 
>>>> These can be found here: https://github.com/dgibson/dtc/blob/main/checks.c#L1498 this is relevant for https://github.com/zephyrproject-rtos/zephyr/issues/107066  
>>> 
>>> Examples provided in the zephyrproject issue link are, in my opinion, incorrect.
>>> 
>>> Case 1:
>>> / {
>>>     node1 {
>>>          pwms = <1 &pwm0 1 20 PWM_POLARITY_NORMAL>;
>>> 
>>>          Here the first cell '1' is not a phandle.  
>> 
>> Here the compiler is making an assumption here that all `pwms` properties must be specifier properties and all use `pwm` specifier.
> 
> I think the purpose of 'select: true' is to have the binding always applied:
>  https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/pwm/pwm-consumer.yaml#L15
> 


I’m having trouble finding where the Devicetree Specification (v0.4) mandates that all binding systems must extend dt-schema. 
Since this requirement isn't explicitly in the spec, it follows that the WARNING_PROPERTY_PHANDLE_CELLS validation belongs in dt-validate rather than within dtc itself.


> If this is confirmed, DTC performs correct checks as this binding must always
> be applied and so the 'pwms' property must be a phandle-array property.
> 
> Device-tree maintainers, can you confirm the purpose of 'select: true' set
> in a DT binding ?
> 
> Best regards,
> Hervé

Re: Phandles

[Krzysztof Kozlowski]

On 12/04/2026 18:37, Kyle Bonnici wrote:
>>>> Case 1:
>>>> / {
>>>>     node1 {
>>>>          pwms = <1 &pwm0 1 20 PWM_POLARITY_NORMAL>;
>>>>
>>>>          Here the first cell '1' is not a phandle.  
>>>
>>> Here the compiler is making an assumption here that all `pwms` properties must be specifier properties and all use `pwm` specifier.
>>
>> I think the purpose of 'select: true' is to have the binding always applied:
>>  https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/pwm/pwm-consumer.yaml#L15
>>
> 
> 
> I’m having trouble finding where the Devicetree Specification (v0.4) mandates that all binding systems must extend dt-schema. 
> Since this requirement isn't explicitly in the spec, it follows that the WARNING_PROPERTY_PHANDLE_CELLS validation belongs in dt-validate rather than within dtc itself.


So you want to have a property with values not being phandle? The spec
defines that properties like "pwm" must contain "value of properties
with a phandle value type". Therefore what does '1' represents in your
example?

Best regards,
Krzysztof

Re: Phandles

[Kyle Bonnici]

> On 13 Apr 2026, at 08:37, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> 
> On 12/04/2026 18:37, Kyle Bonnici wrote:
>>>>> Case 1:
>>>>> / {
>>>>>    node1 {
>>>>>         pwms = <1 &pwm0 1 20 PWM_POLARITY_NORMAL>;
>>>>> 
>>>>>         Here the first cell '1' is not a phandle.  
>>>> 
>>>> Here the compiler is making an assumption here that all `pwms` properties must be specifier properties and all use `pwm` specifier.
>>> 
>>> I think the purpose of 'select: true' is to have the binding always applied:
>>> https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/pwm/pwm-consumer.yaml#L15
>>> 
>> 
>> 
>> I’m having trouble finding where the Devicetree Specification (v0.4) mandates that all binding systems must extend dt-schema. 
>> Since this requirement isn't explicitly in the spec, it follows that the WARNING_PROPERTY_PHANDLE_CELLS validation belongs in dt-validate rather than within dtc itself.
> 
> 
> So you want to have a property with values not being phandle? The spec
> defines that properties like "pwm" must contain "value of properties
> with a phandle value type". Therefore what does '1' represents in your
> example?

I am just building and maintaining an LSP to assists Zephyr and Linux developers alike and what is technically
allowed in Zephyr is not allowed in Linux. The issue here is that DTC is warning zephyr users about it. 
I also find my self in the wrong to enforce these types for Zephyr dts usage given all documentation I have seen 
so far. 

> 
> Best regards,
> Krzysztof

Re: Phandles

[Krzysztof Kozlowski]

On 13/04/2026 09:10, Kyle Bonnici wrote:
> 
> 
>> On 13 Apr 2026, at 08:37, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On 12/04/2026 18:37, Kyle Bonnici wrote:
>>>>>> Case 1:
>>>>>> / {
>>>>>>    node1 {
>>>>>>         pwms = <1 &pwm0 1 20 PWM_POLARITY_NORMAL>;
>>>>>>
>>>>>>         Here the first cell '1' is not a phandle.  
>>>>>
>>>>> Here the compiler is making an assumption here that all `pwms` properties must be specifier properties and all use `pwm` specifier.
>>>>
>>>> I think the purpose of 'select: true' is to have the binding always applied:
>>>> https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/pwm/pwm-consumer.yaml#L15
>>>>
>>>
>>>
>>> I’m having trouble finding where the Devicetree Specification (v0.4) mandates that all binding systems must extend dt-schema. 
>>> Since this requirement isn't explicitly in the spec, it follows that the WARNING_PROPERTY_PHANDLE_CELLS validation belongs in dt-validate rather than within dtc itself.
>>
>>
>> So you want to have a property with values not being phandle? The spec
>> defines that properties like "pwm" must contain "value of properties
>> with a phandle value type". Therefore what does '1' represents in your
>> example?
> 
> I am just building and maintaining an LSP to assists Zephyr and Linux developers alike and what is technically
> allowed in Zephyr is not allowed in Linux. The issue here is that DTC is warning zephyr users about it. 

Please wrap your email responses to mailing list style.

> I also find my self in the wrong to enforce these types for Zephyr dts usage given all documentation I have seen 
> so far. 

To repeat my question:
What does '1' stand for?

Best regards,
Krzysztof

Re: Phandles

[Kyle Bonnici]

> Please wrap your email responses to mailing list style.

Hope I got this part right in this email!

> To repeat my question:
> What does '1' stand for?

‘1' was just an random value to show the issue. Please note that 
this issue has more context. This can all be found tin the Zephyr issue 
https://github.com/zephyrproject-rtos/zephyr/issues/107066 
And also on the discord link.

To summarize, In zephyr the dts is pickled to a header file on
compile. Zephyr build system uses the bindings to determine types.
Any property with no type will not be pickled. 

`/zephyr,user` node is a convenience node that does not need a binding
And types are inferred from values not property names.

The reported issues:
- Zephyr is inferring a type but the DTC compiler is inferring another
type and reporting w waring about it in the build output
- Zephyr does not infer types for properties with no bindings, hence 
If any of mention properties are used and node has no binding for
that property name, zephyr will ignore this, but the DTC reports a
warning that contradics Zephyr's implementation.

Re: Phandles

[Krzysztof Kozlowski]

On 13/04/2026 10:40, Kyle Bonnici wrote:
> 
>> Please wrap your email responses to mailing list style.
> 
> Hope I got this part right in this email!
> 
>> To repeat my question:
>> What does '1' stand for?
> 
> ‘1' was just an random value to show the issue. Please note that 
> this issue has more context. This can all be found tin the Zephyr issue 

You cannot have random values. I quoted the DT spec.

> https://github.com/zephyrproject-rtos/zephyr/issues/107066 
> And also on the discord link.

Well, we don't use discord but IRC... but that github issue also uses
"pwms = <1 &pwm0 1 20 PWM_POLARITY_NORMAL>;"

So again - what is "1"?

I am asking because if you use incorrect value as phandle value, then
DTC warning is obviously expected and nothing to fix here.

> 
> To summarize, In zephyr the dts is pickled to a header file on
> compile. Zephyr build system uses the bindings to determine types.
> Any property with no type will not be pickled. 

I know, but this is not what you asked, right?

You asked why phandle has to be the first entry in phandle-value type? I
responded that DT spec makes it.

Now to determine that DTC is correct or not correct, we need to
understand what "1" means in this context - is it a valid phandle value?

> 
> `/zephyr,user` node is a convenience node that does not need a binding
> And types are inferred from values not property names.
> 
> The reported issues:
> - Zephyr is inferring a type but the DTC compiler is inferring another
> type and reporting w waring about it in the build output

Are you reporting bug in Zephyr or DTC?

> - Zephyr does not infer types for properties with no bindings, hence 
> If any of mention properties are used and node has no binding for
> that property name, zephyr will ignore this, but the DTC reports a
> warning that contradics Zephyr's implementation.

We discuss DTC here, yes? Whether it has or has not a bug? Please help
me to understand the topic. Why would we care about Zephyr's
implementation? It's Zephyr's problem and I am not a Zephyr developer. I
am not saying that it is not important, just saying that I am not the
audience to discuss it.

Best regards,
Krzysztof

Re: Phandles

[Kyle Bonnici]

> You cannot have random values. I quoted the DT spec.

Where in the DTS 0.4 spec are property names such as  pwms, clocks
 etc… mandated to be of format <phandle cell …>?

> Well, we don't use discord but IRC... but that github issue also uses
> "pwms = <1 &pwm0 1 20 PWM_POLARITY_NORMAL>;"
> 
> So again - what is "1"?
> 
> I am asking because if you use incorrect value as phandle value, then
> DTC warning is obviously expected and nothing to fix here.

The warning is only valid if ‘1’  is expected to be a phandle which is what I am
Arguing the spec does not mandate this.

> You asked why phandle has to be the first entry in phandle-value type? I
> responded that DT spec makes it.

Which section in DTS 0.4 spec?

> We discuss DTC here, yes? Whether it has or has not a bug? Please help
> me to understand the topic. Why would we care about Zephyr's
> implementation? It's Zephyr's problem and I am not a Zephyr developer. I
> am not saying that it is not important, just saying that I am not the
> audience to discuss it.

I am arguing that the DTC Spec 0.4 does NOT mandate any of these any of these
“cooling_device”, “dmas”, “hwlocks”, “io_channels”, “iommus”, “mboxes”, 
“msi_parent”, “mux_controls”, “phys”, “power_domains”, “pwms”, “resets”, 
“clocks”,  “sound_dai” and “thermal_sensors” 
must follow <phandle cell …>. 

This is only mandated by the dt-schema as far as I understand, that is a used by 
Linux, but not Zephyr and the DTC Making the assumption that this is true for 
all systems

Regards
Kyle

Re: Phandles

[Krzysztof Kozlowski]

On 13/04/2026 11:50, Kyle Bonnici wrote:
> 
>> You cannot have random values. I quoted the DT spec.
> 
> Where in the DTS 0.4 spec are property names such as  pwms, clocks
>  etc… mandated to be of format <phandle cell …>?

Ah, true, this is not expressed but DT spec defines types for only a few
cases.

> 
>> Well, we don't use discord but IRC... but that github issue also uses
>> "pwms = <1 &pwm0 1 20 PWM_POLARITY_NORMAL>;"
>>
>> So again - what is "1"?
>>
>> I am asking because if you use incorrect value as phandle value, then
>> DTC warning is obviously expected and nothing to fix here.
> 
> The warning is only valid if ‘1’  is expected to be a phandle which is what I am
> Arguing the spec does not mandate this.

The "&foo" used in the property defines that it is phandle, no?

> 
>> You asked why phandle has to be the first entry in phandle-value type? I
>> responded that DT spec makes it.
> 
> Which section in DTS 0.4 spec?

2.2.4.2. Property Values
"That number is used for the value of properties with a phandle value type.

The properties having phandle value must have proper, well, value :)

> 
>> We discuss DTC here, yes? Whether it has or has not a bug? Please help
>> me to understand the topic. Why would we care about Zephyr's
>> implementation? It's Zephyr's problem and I am not a Zephyr developer. I
>> am not saying that it is not important, just saying that I am not the
>> audience to discuss it.
> 
> I am arguing that the DTC Spec 0.4 does NOT mandate any of these any of these
> “cooling_device”, “dmas”, “hwlocks”, “io_channels”, “iommus”, “mboxes”, 
> “msi_parent”, “mux_controls”, “phys”, “power_domains”, “pwms”, “resets”, 
> “clocks”,  “sound_dai” and “thermal_sensors” 
> must follow <phandle cell …>. 
> 
> This is only mandated by the dt-schema as far as I understand, that is a used by 
> Linux, but not Zephyr and the DTC Making the assumption that this is true for 
> all systems

No, dtschema is irrelevant here and DTC was validating it since 2017, so
years before dtschema.

DT spec indeed does not mandate it as pwms, but replacing that check in
DTC with something only validating phandles would not solve your
problem. Your 'pwm' is a phandle-value type, because you use phandle
there, and still is has wrong value.

Best regards,
Krzysztof

Re: Phandles

[Kyle Bonnici]

> The "&foo" used in the property defines that it is phandle, no?

yes &foo is a phandle and must resolve to some node.

> 
>> 
>>> You asked why phandle has to be the first entry in phandle-value type? I
>>> responded that DT spec makes it.
>> 
>> Which section in DTS 0.4 spec?
> 
> 2.2.4.2. Property Values
> "That number is used for the value of properties with a phandle value type.
> 
> The properties having phandle value must have proper, well, value :)

For a property to have type <phandle> it must either be of that types as 
Defined dts spec 0.4 or a binding mandates that type.

> 
>> 
>>> We discuss DTC here, yes? Whether it has or has not a bug? Please help
>>> me to understand the topic. Why would we care about Zephyr's
>>> implementation? It's Zephyr's problem and I am not a Zephyr developer. I
>>> am not saying that it is not important, just saying that I am not the
>>> audience to discuss it.
>> 
>> I am arguing that the DTC Spec 0.4 does NOT mandate any of these any of these
>> “cooling_device”, “dmas”, “hwlocks”, “io_channels”, “iommus”, “mboxes”, 
>> “msi_parent”, “mux_controls”, “phys”, “power_domains”, “pwms”, “resets”, 
>> “clocks”,  “sound_dai” and “thermal_sensors” 
>> must follow <phandle cell …>. 
>> 
>> This is only mandated by the dt-schema as far as I understand, that is a used by 
>> Linux, but not Zephyr and the DTC Making the assumption that this is true for 
>> all systems
> 
> No, dtschema is irrelevant here and DTC was validating it since 2017, so
> years before dtschema.

My point it that the DTC is overreaching IMO and validating property using 
WARNING_PROPERTY_PHANDLE_CELLS that are not mandated by the 
DTS Spec 0.4. This is leaking warnings into Zephyr and can lead a user to 
believe, that Zephyr also interprets that property in the same way as the DTC

> 
> DT spec indeed does not mandate it as pwms, but replacing that check in
> DTC with something only validating phandles would not solve your
> problem. Your 'pwm' is a phandle-value type, because you use phandle
> there, and still is has wrong value.

Do not take my code in the example too critically, that is just code to show 
how to generate the warnings. 

My point has been that in zephyr non of these properties should generate 
Warnings generated by WARNING_PROPERTY_PHANDLE_CELLS 

Re: Phandles

[Rob Herring]

On Mon, Apr 13, 2026 at 4:50 AM Kyle Bonnici <kylebonnici@hotmail.com> wrote:
>
>
> > You cannot have random values. I quoted the DT spec.
>
> Where in the DTS 0.4 spec are property names such as  pwms, clocks
>  etc… mandated to be of format <phandle cell …>?

I would not read too much into what is defined in the spec vs. what is
defined in dtschema. It's a conscious decision that all these
properties are not in the spec. The goal is the whole spec or at least
any parts defining properties is just schemas and the spec is
generated from the schemas. That's the only way new properties will
get added to the spec (with a few exceptions). However, no one is
working on generating the spec from schemas.

> > Well, we don't use discord but IRC... but that github issue also uses
> > "pwms = <1 &pwm0 1 20 PWM_POLARITY_NORMAL>;"
> >
> > So again - what is "1"?
> >
> > I am asking because if you use incorrect value as phandle value, then
> > DTC warning is obviously expected and nothing to fix here.
>
> The warning is only valid if ‘1’  is expected to be a phandle which is what I am
> Arguing the spec does not mandate this.
>
> > You asked why phandle has to be the first entry in phandle-value type? I
> > responded that DT spec makes it.
>
> Which section in DTS 0.4 spec?

Doesn't matter. How would you ever parse the properties if that's not
the case. You have to have the phandle first to get the number of arg
cells to find the next phandle. I suppose you could define some other
convention, but it would have to be pretty much global like this
convention is. And this convention dates back to the GPIO binding
which dates back to at least 2005 if not the 1990s. And most of these
properties you list date back to well before Zephyr existed.

The spec, dtc and the dts format will let you do something like this:

foo = <0x12345678>, "bar", /bits/ 16 <0xabcd>;

You would have to be out of your mind to do something like that when
the format has zero type information.

Every warning in dtc can be disabled. So if they are a problem, turn them off.

Rob

Re: Phandles

[Kyle Bonnici]

> On 14 Apr 2026, at 17:24, Rob Herring <robh@kernel.org> wrote:
> 
> On Mon, Apr 13, 2026 at 4:50 AM Kyle Bonnici <kylebonnici@hotmail.com> wrote:
>> 
>> 
>>> You cannot have random values. I quoted the DT spec.
>> 
>> Where in the DTS 0.4 spec are property names such as  pwms, clocks
>> etc… mandated to be of format <phandle cell …>?
> 
> I would not read too much into what is defined in the spec vs. what is
> defined in dtschema. It's a conscious decision that all these
> properties are not in the spec. The goal is the whole spec or at least
> any parts defining properties is just schemas and the spec is
> generated from the schemas. That's the only way new properties will
> get added to the spec (with a few exceptions). However, no one is
> working on generating the spec from schemas.

If that is the intention, then IMO this needs to be documented in the spec at the
very least so that anyone using devicetree knows what rules are mandatory 
for that tool/system to comply and use common tools such as the DTC.

If this was documented in the spec I would be claiming zephyr has the bug for 
not following the schemas, but with the current status quo if I calmed in the 
zephyr issue that all properties named:
“cooling_device”, “dmas”, “hwlocks”, “io_channels”, “iommus”,
 “mboxes”, “msi_parent”, “mux_controls”, “phys”, “power_domains”, “pwms”, 
“resets”, “clocks”,  “sound_dai” and “thermal_sensors” MUST be of format
 <phandle cell …> and the phandle must implement <specifier>-cell. I would 
have no justification for my claim.

I have no issue with the rule book being clarified, but the spec cannot be 
ambiguous otherwise it is not a specification.


>>> Well, we don't use discord but IRC... but that github issue also uses
>>> "pwms = <1 &pwm0 1 20 PWM_POLARITY_NORMAL>;"
>>> 
>>> So again - what is "1"?
>>> 
>>> I am asking because if you use incorrect value as phandle value, then
>>> DTC warning is obviously expected and nothing to fix here.
>> 
>> The warning is only valid if ‘1’  is expected to be a phandle which is what I am
>> Arguing the spec does not mandate this.
>> 
>>> You asked why phandle has to be the first entry in phandle-value type? I
>>> responded that DT spec makes it.
>> 
>> Which section in DTS 0.4 spec?
> 
> Doesn't matter. How would you ever parse the properties if that's not
> the case. You have to have the phandle first to get the number of arg
> cells to find the next phandle. I suppose you could define some other
> convention, but it would have to be pretty much global like this
> convention is. And this convention dates back to the GPIO binding
> which dates back to at least 2005 if not the 1990s. And most of these
> properties you list date back to well before Zephyr existed.
> 
> The spec, dtc and the dts format will let you do something like this:
> 
> foo = <0x12345678>, "bar", /bits/ 16 <0xabcd>;
> 
> You would have to be out of your mind to do something like that when
> the format has zero type information.

By allowing it IMO with the public information on devicetree, the DTS spec 
is offloading the responsibility of this property to the bindings system.
Section 4.1.1 makes this split in responsibility very clear IMO. This is why
I am expressing that this is a bug in the DTC as without this discussion with 
All of you I cannot determine with certainty if the DTC is overstepping it’s
responsibilities or if zephyr did not follow the rules for these property names.

> Every warning in dtc can be disabled. So if they are a problem, turn them off.

That can be a temporary workaround if accepted upstream in zephyr, 
however I also see hardening the specification as more future proof.

Re: Phandles

[Krzysztof Kozlowski]

On 12/04/2026 17:40, Herve Codina wrote:
> Hi Kyle,
> 
> +Cc Kernel device-tree maintainers
> 
> On Sun, 12 Apr 2026 13:51:35 +0000
> Kyle Bonnici <kylebonnici@hotmail.com> wrote:
> 
>>> On 12 Apr 2026, at 14:51, Herve Codina <herve.codina@bootlin.com> wrote:
>>>
>>> Hi Kyle,
>>>
>>> On Sat, 11 Apr 2026 18:33:33 +0000
>>> Kyle Bonnici <kylebonnici@hotmail.com> wrote:
>>>   
>>>> Hi
>>>>
>>>> I have been looking at the the code for the compiler and I am wondering which specifications marks the below properties MUST BE Nexus Properties hence the validation.
>>>>
>>>> WARNING_PROPERTY_PHANDLE_CELLS(clocks, "clocks", "#clock-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(cooling_device, "cooling-device", "#cooling-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(dmas, "dmas", "#dma-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(hwlocks, "hwlocks", "#hwlock-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(interrupts_extended, "interrupts-extended", "#interrupt-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(io_channels, "io-channels", "#io-channel-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(iommus, "iommus", "#iommu-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(mboxes, "mboxes", "#mbox-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(msi_parent, "msi-parent", "#msi-cells", true);
>>>> WARNING_PROPERTY_PHANDLE_CELLS(mux_controls, "mux-controls", "#mux-control-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(phys, "phys", "#phy-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(power_domains, "power-domains", "#power-domain-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(pwms, "pwms", "#pwm-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(resets, "resets", "#reset-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(sound_dai, "sound-dai", "#sound-dai-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(thermal_sensors, "thermal-sensors", "#thermal-sensor-cells");  
>>>
>>> All of those properties are defined as phandles.
>>>
>>> For instance, the 'pwms' property available in a node means the the node is
>>> a pwm consumer. It must follow the pwm consumer binding [1] and so a phandle
>>> is involved.
>>>
>>> This phandle can have arguments and the number of argument is defined by the
>>> #pwm-cells property set in the pwm provider node [2], [3].
>>>
>>> [1] https://elixir.bootlin.com/zephyr/v4.4.0-rc3/source/dts/bindings/pwm/pwm-controller.yaml
>>> [2] https://github.com/zephyrproject-rtos/zephyr/blob/main/dts/bindings/pwm/pwm-controller.yaml
>>> [3] https://elixir.bootlin.com/linux/v7.0-rc7/source/Documentation/devicetree/bindings/pwm/pwm.yaml
>>>   
>>>>
>>>>
>>>> These can be found here: https://github.com/dgibson/dtc/blob/main/checks.c#L1498 this is relevant for https://github.com/zephyrproject-rtos/zephyr/issues/107066  
>>>
>>> Examples provided in the zephyrproject issue link are, in my opinion, incorrect.
>>>
>>>  Case 1:
>>>  / {
>>>      node1 {
>>>           pwms = <1 &pwm0 1 20 PWM_POLARITY_NORMAL>;
>>>
>>>           Here the first cell '1' is not a phandle.  
>>
>> Here the compiler is making an assumption here that all `pwms` properties must be specifier properties and all use `pwm` specifier.
> 
> I think the purpose of 'select: true' is to have the binding always applied:
>   https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/pwm/pwm-consumer.yaml#L15
> 
> If this is confirmed, DTC performs correct checks as this binding must always
> be applied and so the 'pwms' property must be a phandle-array property.
> 
> Device-tree maintainers, can you confirm the purpose of 'select: true' set
> in a DT binding ?

The quoted parts were mentioning Zephyr. Here you mentioned DTC, but ask
about "select: true", so dtschema. I don't get the context... dtschema
has nothing to do with DTC and Zephyr.

Best regards,
Krzysztof

Re: Phandles

[Herve Codina]

Hi Krzysztof

On Mon, 13 Apr 2026 08:33:49 +0200
Krzysztof Kozlowski <krzk@kernel.org> wrote:

> On 12/04/2026 17:40, Herve Codina wrote:
> > Hi Kyle,
> > 
> > +Cc Kernel device-tree maintainers
> > 
> > On Sun, 12 Apr 2026 13:51:35 +0000
> > Kyle Bonnici <kylebonnici@hotmail.com> wrote:
> >   
> >>> On 12 Apr 2026, at 14:51, Herve Codina <herve.codina@bootlin.com> wrote:
> >>>
> >>> Hi Kyle,
> >>>
> >>> On Sat, 11 Apr 2026 18:33:33 +0000
> >>> Kyle Bonnici <kylebonnici@hotmail.com> wrote:
> >>>     
> >>>> Hi
> >>>>
> >>>> I have been looking at the the code for the compiler and I am wondering which specifications marks the below properties MUST BE Nexus Properties hence the validation.
> >>>>
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(clocks, "clocks", "#clock-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(cooling_device, "cooling-device", "#cooling-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(dmas, "dmas", "#dma-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(hwlocks, "hwlocks", "#hwlock-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(interrupts_extended, "interrupts-extended", "#interrupt-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(io_channels, "io-channels", "#io-channel-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(iommus, "iommus", "#iommu-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(mboxes, "mboxes", "#mbox-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(msi_parent, "msi-parent", "#msi-cells", true);
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(mux_controls, "mux-controls", "#mux-control-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(phys, "phys", "#phy-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(power_domains, "power-domains", "#power-domain-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(pwms, "pwms", "#pwm-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(resets, "resets", "#reset-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(sound_dai, "sound-dai", "#sound-dai-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(thermal_sensors, "thermal-sensors", "#thermal-sensor-cells");    
> >>>
> >>> All of those properties are defined as phandles.
> >>>
> >>> For instance, the 'pwms' property available in a node means the the node is
> >>> a pwm consumer. It must follow the pwm consumer binding [1] and so a phandle
> >>> is involved.
> >>>
> >>> This phandle can have arguments and the number of argument is defined by the
> >>> #pwm-cells property set in the pwm provider node [2], [3].
> >>>
> >>> [1] https://elixir.bootlin.com/zephyr/v4.4.0-rc3/source/dts/bindings/pwm/pwm-controller.yaml
> >>> [2] https://github.com/zephyrproject-rtos/zephyr/blob/main/dts/bindings/pwm/pwm-controller.yaml
> >>> [3] https://elixir.bootlin.com/linux/v7.0-rc7/source/Documentation/devicetree/bindings/pwm/pwm.yaml
> >>>     
> >>>>
> >>>>
> >>>> These can be found here: https://github.com/dgibson/dtc/blob/main/checks.c#L1498 this is relevant for https://github.com/zephyrproject-rtos/zephyr/issues/107066    
> >>>
> >>> Examples provided in the zephyrproject issue link are, in my opinion, incorrect.
> >>>
> >>>  Case 1:
> >>>  / {
> >>>      node1 {
> >>>           pwms = <1 &pwm0 1 20 PWM_POLARITY_NORMAL>;
> >>>
> >>>           Here the first cell '1' is not a phandle.    
> >>
> >> Here the compiler is making an assumption here that all `pwms` properties must be specifier properties and all use `pwm` specifier.  
> > 
> > I think the purpose of 'select: true' is to have the binding always applied:
> >   https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/pwm/pwm-consumer.yaml#L15
> > 
> > If this is confirmed, DTC performs correct checks as this binding must always
> > be applied and so the 'pwms' property must be a phandle-array property.
> > 
> > Device-tree maintainers, can you confirm the purpose of 'select: true' set
> > in a DT binding ?  
> 
> The quoted parts were mentioning Zephyr. Here you mentioned DTC, but ask
> about "select: true", so dtschema. I don't get the context... dtschema
> has nothing to do with DTC and Zephyr.

I wanted be sure about checks done by DTC itself.

My feeling was that if a binding defined in dtschema has to be always applied
(i.e. select: true) it is a legit case to have DTC performing some checks
according to this binding.

Kyle seems to define the 'pwms' property to be something other than a phandle.
IMHO, this is wrong but the 'pwms' property is only defined in dtschema.

Best regards,
Hervé