Re: [PATCH 2/3] arm64: dts: renesas: r9a09g087: Add xSPI nodes

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The xSPI nodes provide incomplete clock and reset properties for the fallback compatible string (`renesas,r9a09g047-xspi`), which will cause schema validation errors.
- [Low] Mixed decimal and hexadecimal notation for reset indices in sibling nodes.
--

commit 7421051c9fdf7ba19830d3741837bab97e76f110
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

arm64: dts: renesas: r9a09g087: Add xSPI nodes

Add device tree nodes for the two xSPI (Expanded SPI) controllers
integrated into the RZ/N2H (R9A09G087) SoC.

> diff --git a/arch/arm64/boot/dts/renesas/r9a09g087.dtsi b/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
> index f697e9698ed39..e63a6b74d90b0 100644
> --- a/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r9a09g087.dtsi

[ ... ]

> @@ -1009,6 +1009,44 @@ mii_conv3: mii-conv@3 {
>  			};
>  		};
>  
> +		xspi0: spi@801c0000 {
> +			compatible = "renesas,r9a09g087-xspi", "renesas,r9a09g047-xspi";
> +			reg = <0 0x801c0000 0 0x1000>,
> +			      <0 0x40000000 0 0x10000000>;
> +			reg-names = "regs", "dirmap";
> +			interrupts = <GIC_SPI 654 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 655 IRQ_TYPE_LEVEL_HIGH>;
> +			interrupt-names = "pulse", "err_pulse";
> +			clocks = <&cpg CPG_MOD 4>,
> +				 <&cpg CPG_CORE R9A09G087_XSPI_CLK0>;
> +			clock-names = "ahb", "spi";
> +			resets = <&cpg 0x4>;
> +			reset-names = "hresetn";

[Severity: Medium]
Will this node pass schema validation for the r9a09g047-xspi fallback?

The YAML binding schema for renesas,r9a09g047-xspi requires four clocks (ahb,
axi, spi, spix2) and two resets (hresetn, aresetn), but only two clocks and
one reset are provided here.

Because device tree schema lists match positionally by index, providing spi
at index 1 of clock-names violates the schema that expects axi at that
position, which will cause dtbs_check to fail.

Additionally, should the primary compatible string renesas,r9a09g087-xspi be
documented in the bindings before adding it here?

> +			power-domains = <&cpg>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			status = "disabled";
> +		};
> +
> +		xspi1: spi@801c1000 {
> +			compatible = "renesas,r9a09g087-xspi", "renesas,r9a09g047-xspi";
> +			reg = <0 0x801c1000 0 0x1000>,
> +			      <0 0x50000000 0 0x10000000>;
> +			reg-names = "regs", "dirmap";
> +			interrupts = <GIC_SPI 656 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 657 IRQ_TYPE_LEVEL_HIGH>;
> +			interrupt-names = "pulse", "err_pulse";
> +			clocks = <&cpg CPG_MOD 5>,
> +				 <&cpg CPG_CORE R9A09G087_XSPI_CLK1>;
> +			clock-names = "ahb", "spi";
> +			resets = <&cpg 5>;

[Severity: Low]
This isn't a bug, but is it intentional to use decimal notation here
compared to hexadecimal notation for the reset index in the xspi0 node?

The xspi0 node uses <&cpg 0x4> while xspi1 uses <&cpg 5>. Should these use
a consistent notation base since they are identical adjacent hardware blocks?

> +			reset-names = "hresetn";
> +			power-domains = <&cpg>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			status = "disabled";
> +		};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260526204045.3481604-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=2