Re: [PATCH v2 2/5] arm64: dts: renesas: r9a09g077: Add DU node

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Missing mandatory `resets` property in du, fcpvd, and vspd nodes
- [High] Unregistered CPG_MOD 1204 clock referenced in du, fcpvd, and vspd nodes
- [Medium] Incomplete device tree implementation without driver support or fallback compatible string for du node
- [Low] Undefined macro R9A09G077_LCDC_CLKD causes build failure
--

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

arm64: dts: renesas: r9a09g077: Add DU node

Add Display Unit (DU) node to SoC DTSI.

> diff --git a/arch/arm64/boot/dts/renesas/r9a09g077.dtsi b/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
> --- a/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
> @@ -1269,6 +1269,30 @@ sdhi1_vqmmc: vqmmc-regulator {
>  			};
>  		};
>  
> +		du: display@920c0000 {
> +			compatible = "renesas,r9a09g077-du";

[Severity: Medium]
Does this compatible string need a generic fallback? 

Without a fallback like "renesas,r9a09g057-du", and with no driver currently
matching "renesas,r9a09g077-du" in the tree, won't this regression prevent the
node from binding to a driver and cause a schema validation failure?

> +			reg = <0 0x920c0000 0 0x10000>;
> +			interrupts = <GIC_SPI 781 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&cpg CPG_CORE R9A09G077_CLK_PCLKAH>,
> +				 <&cpg CPG_MOD 1204>,

[Severity: High]
Is module clock ID 1204 registered in the r9a09g077_mod_clks array in
drivers/clk/renesas/r9a09g077-cpg.c? 

When the Renesas CPG-MSSR PM domain governor attempts to attach the du, fcpvd,
and vspd devices, won't of_clk_get_from_provider() fail and return -ENOENT
because the clock is missing? Could this regression prevent the devices from
being attached to the power domain?

> +				 <&cpg CPG_CORE R9A09G077_LCDC_CLKD>;

[Severity: Low]
Where is R9A09G077_LCDC_CLKD defined? 

Since it doesn't appear to be defined in the device tree bindings headers for
the du, fcpvd, and vspd nodes, won't this regression cause the device tree
compiler to fail with a syntax error and break the build?

[Severity: High]
Do the du, fcpvd, and vspd nodes also need a resets property? 

The DT bindings for the Renesas Display Unit, Frame Compression Processor,
and VSP Video Processing Engine mandate the resets property. Their respective
drivers call devm_reset_control_get_shared() without the _optional flag. 

Without it, won't reset_control_get() return -ENOENT and cause this regression
where the driver probes fail?

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

[ ... ]

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