Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Component bind function leaks devm resources and creates use-after-free conditions with IRQ and workqueue. -- commit 44b7706481ee59b636405417779ad4e2c3cd6fc8 Author: Cristian Ciocaltea <[email protected]> drm/rockchip: dw_hdmi_qp: Mask RK3576 HPD IRQ in io_init Start with HPD masked, matching RK3588, so the bridge framework controls when interrupts are armed via hpd_enable(). > diff --git a/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c > b/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c > index dff4002331546..bcfa6646546eb 100644 > --- a/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c > +++ b/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c > @@ -432,7 +432,7 @@ static void dw_hdmi_qp_rk3576_io_init(struct > rockchip_hdmi_qp *hdmi) > > regmap_write(hdmi->vo_regmap, RK3576_VO0_GRF_SOC_CON14, val); > > - val = FIELD_PREP_WM16(RK3576_HDMI_HPD_INT_MSK, 0); > + val = FIELD_PREP_WM16(RK3576_HDMI_HPD_INT_MSK, 1); > regmap_write(hdmi->regmap, RK3576_IOC_MISC_CON0, val); > } [Severity: High] This isn't a bug introduced by this patch, but there is a pre-existing issue in the component bind function: drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c:dw_hdmi_qp_rockchip_bind() { [ ... ] hdmi = drmm_kzalloc(drm, sizeof(*hdmi), GFP_KERNEL); [ ... ] ret = devm_request_threaded_irq(dev, irq, cfg->ctrl_ops->hardirq_callback, cfg->ctrl_ops->irq_callback, IRQF_SHARED, "dw-hdmi-qp-hpd", hdmi); [ ... ] } Does this code create a use-after-free condition on unbind? The hdmi context is allocated with drmm_kzalloc(), which ties its lifetime to the DRM master device. However, the IRQ is requested using devm_request_threaded_irq() on the component device. When the DRM master is unbound, the hdmi context is freed, but since the component device remains, the IRQ is not freed. If the IRQ triggers after unbind, will it access the freed hdmi structure? Additionally, if the driver unbinds and rebinds without being completely removed, will the devm_* allocations leak and cause devm_request_threaded_irq() to return -EBUSY, permanently breaking the driver? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=36
