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

Pre-existing issues:
- [High] Lifecycle mismatch: devm_* APIs used in component bind callback cause 
severe resource leaks, re-bind failures, and system hangs on unbind.
--

commit 55f99b0dc1074955624c3dfcd17a773dd54e5b91
Author: Hüseyin BIYIK <[email protected]>
Subject: drm/rockchip: rk3066_hdmi: convert to devm_drm_bridge_alloc() API

This commit converts the rk3066_hdmi driver to use the devm_drm_bridge_alloc()
API. This aligns the driver with the new standard for allocating DRM bridges
that was introduced during the initial bridge API conversion.

> diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c 
> b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
> index f28d6a883e099..05dbbcc6f7b03 100644
> --- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
> +++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
[ ... ]
> @@ -747,9 +745,10 @@ static int rk3066_hdmi_bind(struct device *dev, struct 
> device *master,
>       int irq;
>       int ret;
>  
> -     hdmi = devm_kzalloc(dev, sizeof(*hdmi), GFP_KERNEL);
> -     if (!hdmi)
> -             return -ENOMEM;
> +     hdmi = devm_drm_bridge_alloc(dev, struct rk3066_hdmi, bridge,
> +                                  &rk3066_hdmi_bridge_funcs);
> +     if (IS_ERR(hdmi))
> +             return PTR_ERR(hdmi);

[Severity: High]
This is a pre-existing issue, but is it safe to use device-managed APIs
like devm_drm_bridge_alloc() inside a component bind callback like
rk3066_hdmi_bind()?

Device-managed resources are tied to the platform device's probe and remove
lifecycle, not the component bind and unbind lifecycle. When
rk3066_hdmi_unbind() is called (e.g., during master deferred probe or driver
unload), the platform device isn't removed, so the devm allocations are not
released.

If the component is bound again, allocations will fail. For example,
devm_platform_ioremap_resource() will return -EBUSY because the memory
region is already claimed, completely breaking deferred probing.

Could this also cause a system hang on unbind? Since rk3066_hdmi_unbind()
calls clk_disable_unprepare() but the interrupt remains active via
devm_request_threaded_irq(), an HDMI hotplug event occurring after unbind
triggers rk3066_hdmi_hardirq(). Accessing unclocked registers there will
synchronously hang the system.

>  
>       hdmi->dev = dev;
>       hdmi->drm_dev = drm;

-- 
Sashiko AI review · 
https://sashiko.dev/#/patchset/[email protected]?part=1

Reply via email to