Re: [PATCH v10 38/69] drm/rockchip: dw_hdmi_qp: Use dw_hdmi_qp_hpd_notify() for HPD reports

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

Pre-existing issues:
- [High] Resource leak and permanent driver re-bind failure due to componen=
t-level devm_ usage in bind().
--

--- Patch [38]: [PATCH v10 38/69] drm/rockchip: dw_hdmi_qp: Use dw_hdmi_qp_=
hpd_notify() for HPD reports ---
commit 494b956223c364f53e596d5709d4eefbf8153439
Author: Cristian Ciocaltea <[email protected]>

drm/rockchip: dw_hdmi_qp: Use dw_hdmi_qp_hpd_notify() for HPD reports
   =20
This commit updates the driver to notify only the affected connector instea=
d of
polling all of them, and ensures .detect_ctx() runs on reconnect to recover=
 SCDC
state.

> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c b/drivers/gpu=
/drm/rockchip/dw_hdmi_qp-rockchip.c
> index 253da2162ce6f..bbdd47d4f3817 100644
> --- a/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c

[ ... ]

drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c:dw_hdmi_qp_rockchip_bind() {
    ...
	ret =3D devm_request_threaded_irq(dev, hdmi->hpd_irq,
					cfg->ctrl_ops->hardirq_callback,
					cfg->ctrl_ops->irq_callback,
					IRQF_NO_AUTOEN, "dw-hdmi-qp-hpd",
					hdmi);
    ...
}

[Severity: High]
This is a pre-existing issue, but does using devm_request_threaded_irq() in
bind() tied to the component device cause a resource leak on unbind?

Since the component device itself isn't destroyed during unbind, the IRQ is
never freed. When the DRM master is re-bound, could this cause the driver to
permanently fail initialization because requesting the same IRQ returns -EB=
USY?

Prior to the commit "drm/rockchip: dw_hdmi_qp: Control the HPD IRQ line via
the bridge HPD ops" removing the IRQF_SHARED flag, would this have succeeded
but registered a second handler with a dangling dev_id pointer, leading to a
use-after-free when the interrupt fired?

A similar issue appears in the bridge helper:

drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c:dw_hdmi_qp_bind() {
    ...
	ret =3D devm_request_threaded_irq(dev, plat_data->main_irq,
					dw_hdmi_qp_main_hardirq, NULL,
					IRQF_SHARED, dev_name(dev), hdmi);
    ...
}

[Severity: High]
This is a pre-existing issue, but does this also leak the main IRQ and the
bridge allocation across unbind/rebind cycles for the same reason?

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