Claude review: drm/bridge: display-connector: trigger initial HPD event for DP

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

Patch Review

This patch adds a `work_struct` to schedule an initial HPD notification when `hpd_enable` is called for DP connectors. On `hpd_disable`, it cancels the work with `cancel_work_sync`.

**The use of a workqueue is appropriate** because `hpd_enable` is called under `bridge->hpd_mutex` (see `drm_bridge_hpd_enable()` in `drm_bridge.c`), and `drm_bridge_hpd_notify()` also takes `hpd_mutex`. Calling `drm_bridge_hpd_notify()` directly from `hpd_enable` would deadlock. The workqueue defers the notification outside the mutex.

**Observations:**

1. **`INIT_WORK` is conditional but callbacks are not.** The `INIT_WORK` call at line 661 is guarded by `conn->hpd_irq >= 0 && type == DRM_MODE_CONNECTOR_DisplayPort`, and the `schedule_work`/`cancel_work_sync` calls are guarded by `conn->bridge.type == DRM_MODE_CONNECTOR_DisplayPort`. This is consistent – DP connectors without HPD IRQ won't reach `hpd_enable` (since `DRM_BRIDGE_OP_HPD` won't be set), and non-DP connectors won't touch the work. However, if `INIT_WORK` is never called, the `work_struct` is zero-initialized (from `devm_drm_bridge_alloc` which uses `devm_kzalloc`), and `cancel_work_sync` on an uninitialized (zero) `work_struct` is technically undefined behavior. In practice, this path is unreachable for non-DP connectors because the `bridge.type` check guards it. Still, it would be slightly cleaner to always call `INIT_WORK` when `hpd_irq >= 0`, removing the type check from the init path, since the `schedule_work` is already guarded by the DP type check.

2. **Race between work and disable.** The ordering in `hpd_disable` is: `cancel_work_sync` first, then `disable_irq`. This is correct – it ensures the synthetic HPD work is cancelled before the IRQ is disabled. If the order were reversed, a pending work item could call `display_connector_detect` → `gpiod_get_value_cansleep` after the IRQ was disabled, which would be fine functionally but inconsistent.

3. **No cleanup on remove.** The `display_connector_remove` function doesn't call `cancel_work_sync`. This should be fine because `drm_bridge_hpd_disable` (and thus `hpd_disable`) is called during connector cleanup before bridge removal, so the work should already be cancelled. But it's worth considering whether there's a window where `hpd_enable` was called but `hpd_disable` was not before `remove`. Given the DRM lifecycle, this shouldn't happen.

4. **Minor typo in commit message:** "externall" should be "external".

Overall, this is a well-structured fix for a real problem. The series is correct and ready to merge with perhaps the typo fix in the commit message.

---
Generated by Claude Code Patch Reviewer