Re: [PATCH v2 3/5] arm64: dts: renesas: r9a09g087: Add VSPD and FCPVD nodes

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Missing strictly required 'resets' property in vspd and fcpvd nodes prevents driver probing.
- [Low] Undeclared clock macro `R9A09G087_LCDC_CLKD` causes dtc compilation failure.
- [Low] Undocumented compatibles 'renesas,r9a09g087-fcpvd' and 'renesas,r9a09g087-vsp2' trigger cascading schema validation failures.
--

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

arm64: dts: renesas: r9a09g087: Add VSPD and FCPVD nodes
    
Add VSPD and FCPVD nodes to RZ/N2H SoC DTSI.

> diff --git a/arch/arm64/boot/dts/renesas/r9a09g087.dtsi b/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
> index f697e9698ed39..cb2eabe3242e0 100644
> --- a/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
> @@ -1271,6 +1271,28 @@ sdhi1_vqmmc: vqmmc-regulator {
>  				status = "disabled";
>  			};
>  		};
> +
> +		fcpvd: fcp@920d0000 {
> +			compatible = "renesas,r9a09g087-fcpvd", "renesas,fcpv";

[Severity: Low]
Are these new compatible strings documented in the bindings?

If renesas,r9a09g087-fcpvd is missing from the renesas,fcp.yaml schema,
dtbs_check might fall back to default rules (such as enforcing a single item
for clocks) and trigger cascading validation failures for the rest of this
node.

> +			reg = <0 0x920d0000 0 0x10000>;

[Severity: High]
Does this hardware block require a resets property to function?

The device tree binding schemas strictly require a resets property for fcpv.
Without it, driver initialization might fail or be unable to reset the hardware.

> +			clocks = <&cpg CPG_CORE R9A09G087_CLK_PCLKAH>,
> +				 <&cpg CPG_MOD 1204>,
> +				 <&cpg CPG_CORE R9A09G087_LCDC_CLKD>;

[Severity: Low]
Could this cause a compilation failure when building the device tree?

The R9A09G087_LCDC_CLKD macro does not appear to be defined in the clock
bindings header or elsewhere in the kernel tree. This usually results in a dtc
undeclared identifier error during compilation.

> +			clock-names = "aclk", "pclk", "vclk";
> +			power-domains = <&cpg>;
> +		};
> +
> +		vspd: vsp@920e0000 {
> +			compatible = "renesas,r9a09g087-vsp2", "renesas,r9a07g044-vsp2";

[Severity: Low]
Is renesas,r9a09g087-vsp2 documented in the renesas,vsp1.yaml schema?

Like the fcpvd node, an undocumented compatible string here might cause
dtbs_check validation failures.

> +			reg = <0 0x920e0000 0 0x8000>;
> +			interrupts = <GIC_SPI 780 IRQ_TYPE_LEVEL_HIGH>;

[Severity: High]
Will the vsp1 driver fail to probe here?

Looking at drivers/media/platform/renesas/vsp1/vsp1_drv.c, vsp1_probe() calls
devm_reset_control_get_shared() unconditionally. This will return -ENOENT if
the resets property is omitted from the device tree node. 

Does this node need a resets property to prevent the probe from aborting?

> +			clocks = <&cpg CPG_CORE R9A09G087_CLK_PCLKAH>,
> +				 <&cpg CPG_MOD 1204>,
> +				 <&cpg CPG_CORE R9A09G087_LCDC_CLKD>;

[Severity: Low]
Will this also fail to compile due to the undeclared R9A09G087_LCDC_CLKD
identifier?

> +			clock-names = "aclk", "pclk", "vclk";
> +			power-domains = <&cpg>;
> +			renesas,fcp = <&fcpvd>;
> +		};

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