Claude review: drm/rockchip: dw_hdmi_qp: Restrict HPD event to the affected connector

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

Switches from `drm_helper_hpd_irq_event()` (polls all connectors) to `drm_connector_helper_hpd_irq_event()` (targets a specific connector). Adds `struct drm_connector *connector` to `rockchip_hdmi_qp` to track the relevant connector.

```c
-	if (drm) {
-		changed = drm_helper_hpd_irq_event(drm);
+	if (hdmi->connector) {
+		changed = drm_connector_helper_hpd_irq_event(hdmi->connector);
```

The `hdmi->connector` is set in `bind()` (after patch 9 ensures the connector is fully initialized) and cleared in `unbind()`. The NULL check before use in the HPD work and resume path is correct.

The `connector = NULL` in unbind runs after `cancel_delayed_work_sync(&hdmi->hpd_work)`, so no racing work item will see a stale pointer.

Has R-b from Heiko. **No issues.**

---

## SUMMARY

The series is well-organized and at v5 has addressed most review feedback. The only substantive point I'd raise:

1. **Patch 5:** The `hdmi->scramb_enabled = false` on the failure path in `dw_hdmi_qp_enable_scramb()` should use `WRITE_ONCE` for consistency with the `READ_ONCE` in the scramb_work, even though it's not a live race at that point.

2. **Patch 5:** Consider documenting the locking assumption that protects `curr_conn` from concurrent access between `detect_ctx` (which reads it) and `atomic_disable` (which clears it). The connection_mutex should serialize these, but an explicit comment would help future readers.

These are minor nits; the series looks good for merge.

---
Generated by Claude Code Patch Reviewer