Re: [PATCH v2 1/2] arm64: dts: renesas: r9a09g057: Add PCIe nodes

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The pcie1 node incorrectly re-uses the exact same clocks and resets properties as pcie0, causing a hardware resource conflict.
- [Medium] The `renesas,sysc` property passes an argument to a phandle, but the target `sys` node lacks a `#cells` property.
--

--- Patch [1]: [PATCH v2 1/2] arm64: dts: renesas: r9a09g057: Add PCIe nodes ---
commit 146b102b21fdb6341d75564293e25310c00c5056
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

arm64: dts: renesas: r9a09g057: Add PCIe nodes
    
Add PCIe nodes to Renesas RZ/V2H(P) ("R9A09G057") SoC DTSI.

> diff --git a/arch/arm64/boot/dts/renesas/r9a09g057.dtsi b/arch/arm64/boot/dts/renesas/r9a09g057.dtsi
> index 9581af58024ed..f3199c32423e5 100644
> --- a/arch/arm64/boot/dts/renesas/r9a09g057.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r9a09g057.dtsi
> @@ -1024,6 +1024,146 @@ rsci9: serial@12803000 {
[ ... ]
> +		pcie0: pcie@13400000 {
> +			compatible = "renesas,r9a09g057-pcie";
[ ... ]
> +			#size-cells = <2>;
> +			num-lanes = <2>;
> +			renesas,sysc = <&sys 0>;
                        ^^^^

[Severity: Medium]
Does the target sys node have a #sysc-cells property defined?

If the driver relies on standard of_parse_phandle_with_args() to read the
controller ID (0), the parsing will fail at runtime because the target
node lacks #sysc-cells. If the driver uses of_parse_phandle(), the
argument is simply ignored.

> +			status = "disabled";
> +
> +			pcie_port0: pcie@0,0 {
[ ... ]
> +		pcie1: pcie@13410000 {
> +			compatible = "renesas,r9a09g057-pcie";
[ ... ]
> +			interrupt-map = <0 0 0 1 &pcie1 0 0 0 0>, /* INTA */
> +					<0 0 0 2 &pcie1 0 0 0 1>, /* INTB */
> +					<0 0 0 3 &pcie1 0 0 0 2>, /* INTC */
> +					<0 0 0 4 &pcie1 0 0 0 3>; /* INTD */
> +			clocks = <&cpg CPG_MOD 0xc4>, <&cpg CPG_MOD 0xc5>;
> +			clock-names = "aclk", "pmu";
> +			resets = <&cpg 0xb2>;
                        ^^^^

[Severity: High]
Are these the correct clocks and resets for pcie1?

The pcie1 node re-uses the exact same indices (0xc4, 0xc5, and 0xb2) as
pcie0. The CPG driver (drivers/clk/renesas/r9a09g057-cpg.c) explicitly maps
these to pcie_0_aclk, pcie_0_clk_pmu, and PCIE_0_ARESETN.

Probing pcie1 will request the exact same exclusive reset and clock lines as
pcie0. This will cause the pcie1 probe to fail with -EBUSY due to exclusive
reset acquisition. Alternatively, if the reset is handled as shared, asserting
the reset during pcie1 initialization will unexpectedly reset the active
pcie0 hardware, dropping any attached devices.

> +			reset-names = "aresetn";
> +			power-domains = <&cpg>;
> +			device_type = "pci";
> +			#address-cells = <3>;
> +			#size-cells = <2>;
> +			num-lanes = <2>;
> +			renesas,sysc = <&sys 1>;
                        ^^^^

[Severity: Medium]
Does the target sys node have a #sysc-cells property defined?

Similar to pcie0, if the target node lacks #sysc-cells, parsing this
property with of_parse_phandle_with_args() will fail at runtime.

> +			status = "disabled";

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