Re: [PATCH v10 54/69] drm/rockchip: rk3066_hdmi: Advertise HDMI 1.4 capabilities

Thank you for your contribution! Sashiko AI review found 1 potential issue(=
s) to consider:

Pre-existing issues:
- [High] Using devm_ functions inside a component bind callback causes reso=
urce leaks and permanent re-bind failures.
--

--- Patch [54]: [PATCH v10 54/69] drm/rockchip: rk3066_hdmi: Advertise HDMI=
 1.4 capabilities ---
commit ec81435b2b3f978e3738f994975d9efc7aae982d
Author: Cristian Ciocaltea <[email protected]>
drm/rockchip: rk3066_hdmi: Advertise HDMI 1.4 capabilities

This patch configures the RK3066 HDMI TX bridge to advertise HDMI 1.4
capabilities. This enables the DRM core to properly filter out modes
that exceed the 340 MHz TMDS limit.

> diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c b/drivers/gpu/drm/roc=
kchip/rk3066_hdmi.c
> index f28d6a883e099..f748700b0ba6c 100644
> --- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
> +++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c

[ ... ]

> @@ -712,6 +713,7 @@ rk3066_hdmi_register(struct drm_device *drm, struct r=
k3066_hdmi *hdmi)
>  	hdmi->bridge.type =3D DRM_MODE_CONNECTOR_HDMIA;
>  	hdmi->bridge.vendor =3D "Rockchip";
>  	hdmi->bridge.product =3D "RK3066 HDMI";
> +	hdmi->bridge.supported_hdmi_ver =3D HDMI_VERSION_1_4;

[Severity: High]
This is a pre-existing issue, but I noticed a potential problem in how
resources are managed in this file during component initialization.

Does the use of devm_ functions inside the component bind callback
rk3066_hdmi_bind() cause resource leaks and permanent re-bind failures?

If rk3066_hdmi_bind() or a subsequent component's bind() returns an error
(such as -EPROBE_DEFER from devm_clk_get() or rk3066_hdmi_register()), the
DRM master driver's probe will fail. However, the resources allocated via
devm_kzalloc() and devm_platform_ioremap_resource() in rk3066_hdmi_bind()
are tied to the subcomponent's platform device, which isn't unbound during
this failure.

This means the resources are not freed. On the next probe attempt,
rk3066_hdmi_bind() will execute again and devm_platform_ioremap_resource()
will fail with -EBUSY because the memory region is already exclusively held
by the previous un-freed allocation. This appears to permanently break the
display driver until a system reboot or manual unbind.

Should these allocations be moved to the platform probe callback instead,
or explicitly managed so they can be properly freed in rk3066_hdmi_unbind()?

> =20
>  	hdmi->bridge.ddc =3D rk3066_hdmi_i2c_adapter(hdmi);
>  	if (IS_ERR(hdmi->bridge.ddc))

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260731-dw-hdmi-qp=
[email protected]?part=3D54