Re: [PATCH 2/2] dt-bindings: timer: pit: add PIT node example for s32g2/3 platforms

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] Incorrect Interrupt Cells Representation in DT Example
- [Low] Non-Generic Device Tree Node Name
- [Low] Example Scope Confusion and Structural Redundancy
--

commit 0c9d62d6961d94621407fcbe8691b419e9baf7f8
Author: Khristine Andreea Barbulescu <khristineandreea.barbulescu@oss.nxp.com>

dt-bindings: timer: pit: add PIT node example for s32g2/3 platforms

This commit adds a devicetree binding example for the PIT timer
as used on nxp s32g2 and s32g3 platforms.

> diff --git a/Documentation/devicetree/bindings/timer/fsl,vf610-pit.yaml b/Documentation/devicetree/bindings/timer/fsl,vf610-pit.yaml
> --- a/Documentation/devicetree/bindings/timer/fsl,vf610-pit.yaml
> +++ b/Documentation/devicetree/bindings/timer/fsl,vf610-pit.yaml
[ ... ]
> @@ -57,3 +57,11 @@ examples:
>          clocks = <&clks VF610_CLK_PIT>;
>          clock-names = "pit";
>      };
> +
> +    pit@40188000 {

This isn't a bug, but the devicetree specification mandates generic node
names reflecting the function of the device. Should this be named
timer@40188000 instead of pit@40188000?

> +        compatible = "nxp,s32g2-pit";
> +        reg = <0x40188000 0x3000>;
> +        interrupts = <53 IRQ_TYPE_LEVEL_HIGH>;

Since the nxp s32g2 platform is an arm64 soc using the arm generic interrupt
controller (gicv3), doesn't it require a 3-cell interrupt specifier (such as
<GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>)?

Will this 2-cell representation cause dtc compilation errors or misrepresent
the physical hardware routing for users copying the example?

> +        clocks = <&clks 61>;
> +        clock-names = "pit";
> +    };

This isn't a bug, but adding this to the exact same yaml list item as the
existing vf610 timer example causes the schema compiler to interpret them as
existing simultaneously within the same root device tree. 

Since they share the exact same property structure, is a separate example
for this platform strictly necessary, or could it just cause structural
redundancy and bloat the schema?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260514070605.996462-1-khristineandreea.barbulescu@oss.nxp.com?part=2