Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Component bind callback incorrectly uses devm_* allocations tied to the platform device, leading to resource leaks and -EBUSY errors on re-bind. -- commit a9c58c506cb77b47eb22437fb1825e8599bab1dc Author: Cristian Ciocaltea <[email protected]> drm/rockchip: dw_hdmi_qp: Add missing newlines in dev_err_probe() messages This commit adds missing trailing newlines to a couple of dev_err_probe() calls in dw_hdmi_qp_rockchip_bind(). > diff --git a/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c > b/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c > index 42f2627e1a052..df0e2bb1eedc6 100644 > --- a/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c > +++ b/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c > @@ -681,12 +681,12 @@ static int dw_hdmi_qp_rockchip_bind(struct device *dev, > struct device *master, > drm_encoder_helper_add(encoder, > &dw_hdmi_qp_rockchip_encoder_helper_funcs); > ret = drmm_encoder_init(drm, encoder, NULL, DRM_MODE_ENCODER_TMDS, > NULL); > if (ret) > - return dev_err_probe(hdmi->dev, ret, "Failed to init encoder"); > + return dev_err_probe(hdmi->dev, ret, "Failed to init > encoder\n"); > > hdmi->hdmi = dw_hdmi_qp_bind(pdev, encoder, &plat_data); > if (IS_ERR(hdmi->hdmi)) > return dev_err_probe(hdmi->dev, PTR_ERR(hdmi->hdmi), > - "Failed to bind dw-hdmi-qp"); > + "Failed to bind dw-hdmi-qp\n"); > > connector = drm_bridge_connector_init(drm, encoder); > if (IS_ERR(connector)) [Severity: High] This is a pre-existing issue, but looking at dw_hdmi_qp_rockchip_bind(), several resource allocations are made against the component's platform device (dev or hdmi->dev) rather than the DRM aggregate device (master): ret = devm_clk_bulk_get_all_enabled(dev, &clks); ... hdmi->frl_enable_gpio = devm_gpiod_get_optional(dev, "frl-enable", ...); ... ret = devm_request_threaded_irq(dev, hdmi->hpd_irq, ...); If dw_hdmi_qp_bind() or drm_bridge_connector_init() fails and returns an error (such as -EPROBE_DEFER), the component framework aborts the bind. Because these devm_ allocations are tied to the platform device and not the DRM aggregate device, they are not cleaned up upon bind failure. When the master DRM device later retries binding, will devm_request_threaded_irq() fail with -EBUSY since the IRQ and other resources remain claimed from the previous attempt? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=33
