Re: [PATCH v5 9/9] arm64: dts: renesas: Add LVDS overlay for RZ/G3L SMARC EVK with ITE6263

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] drm: rz-du: rzg3l_lvds: pm runtime usage counter leak on error paths
- [Low] dts: build failure due to unresolved du and lvds node references
--

commit 7ca002208d8868213743e7114cf32df2e06ea2b6
Author: Biju Das <biju.das.jz@bp.renesas.com>

arm64: dts: renesas: Add LVDS overlay for RZ/G3L SMARC EVK with ITE6263

Add a Device Tree overlay (r9a08g046l48-smarc-lvds-ite6263.dtso) for the
RZ/G3L (R9A08G046) SMARC EVK board to support LVDS-to-HDMI output via the
ITE 6263 HDMI transmitter.

> diff --git a/arch/arm64/boot/dts/renesas/Makefile b/arch/arm64/boot/dts/renesas/Makefile
> index 8c6a448907151..3cecc40204e90 100644
> --- a/arch/arm64/boot/dts/renesas/Makefile
> +++ b/arch/arm64/boot/dts/renesas/Makefile
[ ... ]
> @@ -190,6 +190,9 @@ dtb-$(CONFIG_ARCH_R9A08G046) += r9a08g046l48-smarc.dtb
>  dtb-$(CONFIG_ARCH_R9A08G046) += r9a08g046l48-smarc-dsi-adv7535.dtbo
>  r9a08g046l48-smarc-dsi-adv7535-dtbs := r9a08g046l48-smarc.dtb r9a08g046l48-smarc-dsi-adv7535.dtbo
>  dtb-$(CONFIG_ARCH_R9A08G046) += r9a08g046l48-smarc-dsi-adv7535.dtb
> +dtb-$(CONFIG_ARCH_R9A08G046) += r9a08g046l48-smarc-lvds-ite6263.dtbo
> +r9a08g046l48-smarc-lvds-ite6263-dtbs := r9a08g046l48-smarc.dtb r9a08g046l48-smarc-lvds-ite6263.dtbo
> +dtb-$(CONFIG_ARCH_R9A08G046) += r9a08g046l48-smarc-lvds-ite6263.dtb

[Severity: Low]
Does this rule cause a build failure? 

When attempting to merge the composite DTB here, fdtoverlay will fail to
resolve the &du and &lvds targets because they are missing from the base
device tree.

This results in an FDT_ERR_NOTFOUND error.

> diff --git a/arch/arm64/boot/dts/renesas/r9a08g046l48-smarc-lvds-ite6263.dtso b/arch/arm64/boot/dts/renesas/r9a08g046l48-smarc-lvds-ite6263.dtso
> new file mode 100644
> index 0000000000000..3c64db8d22e9e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/r9a08g046l48-smarc-lvds-ite6263.dtso
[ ... ]
> +&du {
> +	status = "okay";
> +};

[Severity: Low]
Is the du label defined in the base device tree (r9a08g046.dtsi or board
dts)?

Referencing this undefined label here will cause an fdtoverlay resolution
failure.

[ ... ]
> +&lvds {
> +	status = "okay";
> +
> +	ports {
> +		#address-cells = <1>;

[Severity: Low]
Similarly, is the lvds label defined in the base device tree? 

This missing label will also cause an fdtoverlay resolution failure.


Also, reviewing the DRM driver in drivers/gpu/drm/renesas/rz-du/rzg3l_lvds.c:

drivers/gpu/drm/renesas/rz-du/rzg3l_lvds.c:rzg3l_lvds_atomic_enable() {
    ...
	if (WARN_ON(pm_runtime_get_sync(lvds->dev) < 0))
		return;
    ...
}

[Severity: High]
Does this error path leak the PM usage counter? 

pm_runtime_get_sync() increments the device's PM usage counter even if it
returns an error (< 0).

Returning early here without dropping the reference (e.g. via
pm_runtime_put_noidle()) leaves the counter permanently incremented, which
can prevent the power domain from suspending.

drivers/gpu/drm/renesas/rz-du/rzg3l_lvds.c:rzg3l_lvds_atomic_enable() {
    ...
	bridge_state = drm_atomic_get_new_bridge_state(state, bridge);
	if (WARN_ON(!bridge_state))
		return;
    ...
}

[Severity: High]
Does this early return also leak the PM usage counter? 

If drm_atomic_get_new_bridge_state() returns NULL, the function hits the
WARN_ON and returns without calling pm_runtime_put_sync() to decrement the
usage counter acquired earlier.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261001094041.135697-1-biju.das.jz@bp.renesas.com?part=9