Re: [PATCH v11 3/3] arm64: dts: rockchip: Add eDP node for RK3576

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Missing dt-binding documentation and driver support for 'rockchip,rk3576-edp' compatible string.
- [Medium] Device tree schema violation and unmanaged clock due to incorrect clock-names mapping.
--

commit e47ec8c7e8e01e5a72a889c3a37a5a2d40321b07
Author: Damon Ding <damon.ding@rock-chips.com>

arm64: dts: rockchip: Add eDP node for RK3576
    
Add full device tree definition for the integrated eDP controller
on RK3576, following the existing RK3588 hardware layout.

> diff --git a/arch/arm64/boot/dts/rockchip/rk3576.dtsi b/arch/arm64/boot/dts/rockchip/rk3576.dtsi
> index 28175d8200d57..733449cb88b15 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3576.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3576.dtsi
[ ... ]
> @@ -1496,6 +1496,34 @@ hdmi_out: port@1 {
>  			};
>  		};
>  
> +		edp: edp@27dc0000 {
> +			compatible = "rockchip,rk3576-edp";

[Severity: Medium]
Will this trigger a schema validation error during make dtbs_check?

The new compatible string is declared here without a fallback string like
"rockchip,rk3588-edp". If this string is not documented in the device tree
bindings (rockchip,analogix-dp.yaml) and lacks a match in the Rockchip Analogix
DP driver, the driver might not probe successfully. 

Should a fallback compatible be provided if the hardware is fully compatible,
or do the binding and driver need to be updated alongside this patch?

> +			reg = <0x0 0x27dc0000 0x0 0x1000>;
> +			clocks = <&cru CLK_EDP0_24M>, <&cru PCLK_EDP0>, <&cru HCLK_VO0_ROOT>;
> +			clock-names = "dp", "pclk", "hclk";

[Severity: Medium]
Does naming this third clock "hclk" violate the device tree schema and
prevent the driver from managing it?

The dt-binding schema for rockchip,analogix-dp.yaml explicitly restricts the
third clock name to "grf". The eDP driver attempts to fetch the third clock
using devm_clk_get_optional(dev, "grf"). 

With the name set to "hclk" here, will the driver silently fail to find it,
causing the HCLK_VO0_ROOT clock to be ignored and left unprepared?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260605022305.3058853-1-damon.ding@rock-chips.com?part=3