Phandles

Phandles

[Kyle Bonnici]

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");


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

Regards
Kyle

Re: Phandles

[Herve Codina]

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.

      };

      node2 {
          pwms = <&pwm0 1 20>;

          Here 2 arguments. The node referenced by &pwm0 must indicated the
          number of argument to provide. I.e it must have a #pwm-cells$
          property set.

          According to your example, this property must be #pwm-cells= <2>;
          

      };

      node3 {
          pwms = <1 &pwm0 1 20 PWM_POLARITY_NORMAL>;

          Here also, '1', the first cell, is not a phandle.
      };
  };

  Case 2:

  / {
      foobar {
          pwms = <1 2 3 4 5>;

          Random values. Error detected by DTC.

      };
  };

  Case 3:

  / {
      zephyr,user {
          pwms = <1  20 1>;
    
          Here also the phandle is missing.
      };
  };


If you want to use Nexus node on top of that, you can have a look at the
following example:
  https://elixir.bootlin.com/linux/v7.0-rc7/source/Documentation/devicetree/bindings/pwm/pwm-nexus-node.yaml

In the example, you will find the consumer, the nexus node and the pwm
providers.

Not sure to have fully understood your issue but I hope my comments help.

Best regards,
Hervé

Re: Phandles

[Kyle Bonnici]

> 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. 

This is not the case in zephyr. Any property that is a specifier property must implement a binding and follow these rules 
https://docs.zephyrproject.org/latest/build/dts/bindings-syntax.html#specifier-space and validation is the responsibility go Zephyr's build system.

The same applies for all the other examples I have here https://github.com/zephyrproject-rtos/zephyr/issues/107066 

Given that these nodes do not implement any binding then no type should be inferred.

In addition AFAIK the devicetree specification does not say anything about these specific property names (unlike `interrupts` and  `interrupts-extended)` 

Hence it is my option that the compiler should be agnostic of the binding system used and not make any assumptions about bindings used.

> 
>      };
> 
>      node2 {
>          pwms = <&pwm0 1 20>;
> 
>          Here 2 arguments. The node referenced by &pwm0 must indicated the
>          number of argument to provide. I.e it must have a #pwm-cells$
>          property set.
> 
>          According to your example, this property must be #pwm-cells= <2>;
> 
> 
>      };
> 
>      node3 {
>          pwms = <1 &pwm0 1 20 PWM_POLARITY_NORMAL>;
> 
>          Here also, '1', the first cell, is not a phandle.
>      };
>  };
> 
>  Case 2:
> 
>  / {
>      foobar {
>          pwms = <1 2 3 4 5>;
> 
>          Random values. Error detected by DTC.
> 
>      };
>  };
> 
>  Case 3:
> 
>  / {
>      zephyr,user {
>          pwms = <1  20 1>;

This is yet another example see where zephyr want to allow any inference based on the value and not the property name.
see https://github.com/zephyrproject-rtos/zephyr/pull/107127 (https://docs.zephyrproject.org/latest/build/dts/zephyr-user-node.html) 

i.e .          
pwms = ‘foobar”; // should be a string
pwms = <10>; // should be a number or U32
And so on.


> 
>          Here also the phandle is missing.
>      };
>  };
> 
> 
> If you want to use Nexus node on top of that, you can have a look at the
> following example:
>  https://elixir.bootlin.com/linux/v7.0-rc7/source/Documentation/devicetree/bindings/pwm/pwm-nexus-node.yaml
> 
> In the example, you will find the consumer, the nexus node and the pwm
> providers.
> 
> Not sure to have fully understood your issue but I hope my comments help.
> 
> Best regards,
> Hervé

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é

Re: Phandles

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 6263 bytes --]

On Sun, Apr 12, 2026 at 01:51:35PM +0000, Kyle Bonnici 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.
> 
> This is not the case in zephyr. Any property that is a specifier
> property must implement a binding and follow these rules
> https://docs.zephyrproject.org/latest/build/dts/bindings-syntax.html#specifier-space
> and validation is the responsibility go Zephyr's build system.

I'm not quite sure what you're saying here.  Are you saying that
Zephyr is using the same property name as an existing binding, but in
a different way from that binding?

That's a terrible idea, whether or not it's technically against any
spec,

Also, Zephyr shouldn't be making choices about how the device tree is
encoded.  The device tree describes *hardware* (real or virtual) not
how the hardware is used by a particular OS.

> The same applies for all the other examples I have here
> https://github.com/zephyrproject-rtos/zephyr/issues/107066
> 
> Given that these nodes do not implement any binding then no type should be inferred.
> 
> In addition AFAIK the devicetree specification does not say anything
> about these specific property names (unlike `interrupts` and
> `interrupts-extended)`
> 
> Hence it is my option that the compiler should be agnostic of the
> binding system used and not make any assumptions about bindings
> used.
> 
> > 
> >      };
> > 
> >      node2 {
> >          pwms = <&pwm0 1 20>;
> > 
> >          Here 2 arguments. The node referenced by &pwm0 must indicated the
> >          number of argument to provide. I.e it must have a #pwm-cells$
> >          property set.
> > 
> >          According to your example, this property must be #pwm-cells= <2>;
> > 
> > 
> >      };
> > 
> >      node3 {
> >          pwms = <1 &pwm0 1 20 PWM_POLARITY_NORMAL>;
> > 
> >          Here also, '1', the first cell, is not a phandle.
> >      };
> >  };
> > 
> >  Case 2:
> > 
> >  / {
> >      foobar {
> >          pwms = <1 2 3 4 5>;
> > 
> >          Random values. Error detected by DTC.
> > 
> >      };
> >  };
> > 
> >  Case 3:
> > 
> >  / {
> >      zephyr,user {
> >          pwms = <1  20 1>;
> 
> This is yet another example see where zephyr want to allow any inference based on the value and not the property name.
> see https://github.com/zephyrproject-rtos/zephyr/pull/107127 (https://docs.zephyrproject.org/latest/build/dts/zephyr-user-node.html) 
> 
> i.e .          
> pwms = ‘foobar”; // should be a string
> pwms = <10>; // should be a number or U32
> And so on.
> 
> 
> > 
> >          Here also the phandle is missing.
> >      };
> >  };
> > 
> > 
> > If you want to use Nexus node on top of that, you can have a look at the
> > following example:
> >  https://elixir.bootlin.com/linux/v7.0-rc7/source/Documentation/devicetree/bindings/pwm/pwm-nexus-node.yaml
> > 
> > In the example, you will find the consumer, the nexus node and the pwm
> > providers.
> > 
> > Not sure to have fully understood your issue but I hope my comments help.
> > 
> > Best regards,
> > Hervé
> 
> 

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Phandles

[Kyle Bonnici]

> On 13 Apr 2026, at 04:12, David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> On Sun, Apr 12, 2026 at 01:51:35PM +0000, Kyle Bonnici 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.
>> 
>> This is not the case in zephyr. Any property that is a specifier
>> property must implement a binding and follow these rules
>> https://docs.zephyrproject.org/latest/build/dts/bindings-syntax.html#specifier-space
>> and validation is the responsibility go Zephyr's build system.
> 
> I'm not quite sure what you're saying here.  Are you saying that
> Zephyr is using the same property name as an existing binding, but in
> a different way from that binding?

What I am saying is that as far I can see from the zephyr documentation and code 
Implementation it is possible to defined a binding pwms and have the specifier be foobar
Similarly a user can define a binding using the property name pwms and assign any type.

> 
> That's a terrible idea, whether or not it's technically against any
> spec,

I have no opinion if this a tribal idea or not, and hope to get some feedback from the Zephyr community
 on this as well.

> Also, Zephyr shouldn't be making choices about how the device tree is
> encoded.  The device tree describes *hardware* (real or virtual) not
> how the hardware is used by a particular OS.

Not sure I follow how Zephyr is making choices on how devicetree is encoded. 
If you are referring the the difference in the binding system, again the spec does not
go in detail on the format of a binding file it self.

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 documantion I have seen 
So far unless this is zephyr directions as well.

Possible solutions:
- Add “clocks”, “cooling_device”, “dmas”, “hwlocks”, “io_channels”, “iommus”, “mboxes”, “msi_parent”
  “mux_controls”, “phys”, “power_domains”, “pwms”, “resets”, “sound_dai” and “thermal_sensors” to
Section 2.3 of the spec and document the expected type and expected specifier the same way it is done 
For “interrupts_extended”.
    - Zephyr will then have to follow and documents the above properties and makes the space specifiers 
       static
- Allow the freedom of the above properties to be used in any way in different systems as currently suggested 
By the current spec. In such case the validation should be move from the DTC to the dt-validate

> 
>> The same applies for all the other examples I have here
>> https://github.com/zephyrproject-rtos/zephyr/issues/107066
>> 
>> Given that these nodes do not implement any binding then no type should be inferred.
>> 
>> In addition AFAIK the devicetree specification does not say anything
>> about these specific property names (unlike `interrupts` and
>> `interrupts-extended)`
>> 
>> Hence it is my option that the compiler should be agnostic of the
>> binding system used and not make any assumptions about bindings
>> used.
>> 
>>> 
>>>     };
>>> 
>>>     node2 {
>>>         pwms = <&pwm0 1 20>;
>>> 
>>>         Here 2 arguments. The node referenced by &pwm0 must indicated the
>>>         number of argument to provide. I.e it must have a #pwm-cells$
>>>         property set.
>>> 
>>>         According to your example, this property must be #pwm-cells= <2>;
>>> 
>>> 
>>>     };
>>> 
>>>     node3 {
>>>         pwms = <1 &pwm0 1 20 PWM_POLARITY_NORMAL>;
>>> 
>>>         Here also, '1', the first cell, is not a phandle.
>>>     };
>>> };
>>> 
>>> Case 2:
>>> 
>>> / {
>>>     foobar {
>>>         pwms = <1 2 3 4 5>;
>>> 
>>>         Random values. Error detected by DTC.
>>> 
>>>     };
>>> };
>>> 
>>> Case 3:
>>> 
>>> / {
>>>     zephyr,user {
>>>         pwms = <1  20 1>;
>> 
>> This is yet another example see where zephyr want to allow any inference based on the value and not the property name.
>> see https://github.com/zephyrproject-rtos/zephyr/pull/107127 (https://docs.zephyrproject.org/latest/build/dts/zephyr-user-node.html) 
>> 
>> i.e .          
>> pwms = ‘foobar”; // should be a string
>> pwms = <10>; // should be a number or U32
>> And so on.
>> 
>> 
>>> 
>>>         Here also the phandle is missing.
>>>     };
>>> };
>>> 
>>> 
>>> If you want to use Nexus node on top of that, you can have a look at the
>>> following example:
>>> https://elixir.bootlin.com/linux/v7.0-rc7/source/Documentation/devicetree/bindings/pwm/pwm-nexus-node.yaml
>>> 
>>> In the example, you will find the consumer, the nexus node and the pwm
>>> providers.
>>> 
>>> Not sure to have fully understood your issue but I hope my comments help.
>>> 
>>> Best regards,
>>> Hervé
>> 
>> 
> 
> -- 
> David Gibson (he or they) | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au | minimalist, thank you, not the other way
> | around.
> http://www.ozlabs.org/~dgibson