From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm/rockchip: dw_hdmi_qp: Do not send HPD events for all connectors Date: Wed, 25 Mar 2026 07:36:47 +1000 Message-ID: In-Reply-To: <20260323-dw-hdmi-qp-scramb-v4-4-1d99df84883e@collabora.com> References: <20260323-dw-hdmi-qp-scramb-v4-0-1d99df84883e@collabora.com> <20260323-dw-hdmi-qp-scramb-v4-4-1d99df84883e@collabora.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Patch Review **Overall: Clean and straightforward.** - **IRQ registration moved after connector init:** The `devm_request_thread= ed_irq` is moved to after `drm_bridge_connector_init` and `drm_connector_at= tach_encoder`, which is correct =E2=80=94 HPD interrupts could fire immedia= tely and the handler needs `hdmi->connector` to be valid. - **`hdmi->connector` set from `drm_bridge_connector_init`:** This is the b= ridge connector, not a user-allocated connector. Its lifetime is managed by= DRM core, so storing it in `hdmi->connector` is fine as long as the driver= doesn't outlive the DRM device. - **Race on `hdmi->connector` in `dw_hdmi_qp_rk3588_hpd_work`:** The work f= unction uses `hdmi->connector` (line 254) which is set during bind. Since t= he IRQ is now registered after connector init, this is safe. However, durin= g unbind, if the work is still pending, it could access a freed connector. = There's no `cancel_delayed_work_sync` in the unbind path for `hpd_work` =E2= =80=94 but this may be handled by `devm_request_threaded_irq` cleanup preve= nting new work from being scheduled, and the existing unbind sequence. Wort= h verifying that the unbind path is safe. - **Minor: variable rename `irq` =E2=86=92 `hpd_irq`:** Clean change to avo= id confusion with other IRQs. --- Generated by Claude Code Patch Reviewer