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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Missing required 'resets' property in VSP and FCP nodes causes DT binding violations and unconditional driver probe failure.
- [High] The device tree references an unregistered module clock `<&cpg CPG_MOD 1204>`.
- [Low] Undefined macro `R9A09G077_LCDC_CLKD` causes a fatal dtc compilation failure.
- [Low] Undocumented compatible strings used without updating the YAML bindings.
--

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

arm64: dts: renesas: r9a09g077: Add VSPD and FCPVD nodes

Add VSPD and FCPVD nodes to RZ/T2H SoC DTSI.

> diff --git a/arch/arm64/boot/dts/renesas/r9a09g077.dtsi b/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
> index 3761551c96472..29ecd0189ce72 100644
> --- a/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
> @@ -1268,6 +1268,28 @@ sdhi1_vqmmc: vqmmc-regulator {
>  				status = "disabled";
>  			};
>  		};
> +
> +		fcpvd: fcp@920d0000 {
> +			compatible = "renesas,r9a09g077-fcpvd", "renesas,fcpv";

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

It seems renesas,r9a09g077-fcpvd is not added to renesas,fcp.yaml. This could
cause dtbs_check to report unrecognized compatibles. Since it falls back
to generic renesas,fcpv constraints, it might enforce maxItems: 1 for clocks
and trigger further validation errors.

> +			reg = <0 0x920d0000 0 0x10000>;
> +			clocks = <&cpg CPG_CORE R9A09G077_CLK_PCLKAH>,
> +				 <&cpg CPG_MOD 1204>,

[Severity: High]
Is module clock 1204 registered in the clock driver?

Looking at drivers/clk/renesas/r9a09g077-cpg.c, 1204 doesn't appear to be
defined in the module clock array. This would cause the clock framework's
of_xlate function to return -ENOENT, preventing the PM domain from enabling
the clock and resulting in a fatal probe failure.

> +				 <&cpg CPG_CORE R9A09G077_LCDC_CLKD>;

[Severity: Low]
Is R9A09G077_LCDC_CLKD defined in the kernel tree?

It appears this macro isn't defined, which would leave the token unchanged by
the C preprocessor and cause a syntax error during device tree compilation.

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

[Severity: High]
Does this node need a resets property?

The device tree bindings for FCP require a resets property. Without it,
device initialization might be incomplete.

> +		};
> +
> +		vspd: vsp@920e0000 {
> +			compatible = "renesas,r9a09g077-vsp2", "renesas,r9a07g044-vsp2";

[Severity: Low]
Is the renesas,r9a09g077-vsp2 compatible string added to the bindings?

Without an update to renesas,vsp1.yaml, dtbs_check will report this as an
unrecognized compatible.

> +			reg = <0 0x920e0000 0 0x8000>;
> +			interrupts = <GIC_SPI 780 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&cpg CPG_CORE R9A09G077_CLK_PCLKAH>,
> +				 <&cpg CPG_MOD 1204>,

[Severity: High]
Would the unregistered CPG_MOD 1204 clock also cause probe failure for the
VSPD device here?

Similar to the fcpvd node, failing to acquire the clock will abort the probe.

> +				 <&cpg CPG_CORE R9A09G077_LCDC_CLKD>;

[Severity: Low]
Could this undefined macro break dtc compilation here as well?

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

[Severity: High]
Does the vsp1 driver require a resets property to successfully probe?

Looking at drivers/media/platform/renesas/vsp1/vsp1_drv.c, vsp1_probe() calls
devm_reset_control_get_shared() without the optional flag. Because the resets
property is omitted here, this might return -ENOENT and immediately abort the
probe via dev_err_probe().

> +			renesas,fcp = <&fcpvd>;
> +		};
>  	};
>  
>  	stmmac_axi_setup: stmmac-axi-config {

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