Claude review: drm/bridge: display-connector: don't autoenable HPD IRQ

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

Patch Review

This patch adds `IRQF_NO_AUTOEN` to the IRQ request flags and implements `hpd_enable`/`hpd_disable` callbacks that call `enable_irq()`/`disable_irq()`.

**Looks correct.** The `hpd_enable`/`hpd_disable` callbacks are the intended mechanism per the `drm_bridge_funcs` documentation: bridges that set `DRM_BRIDGE_OP_HPD` should implement these. Using `IRQF_NO_AUTOEN` prevents the IRQ from firing before the DRM connector is fully set up, which is the bug being fixed.

One minor observation:

- The `hpd_enable`/`hpd_disable` callbacks are unconditionally wired into `display_connector_bridge_funcs`, but `conn->hpd_irq` is only valid (>= 0) when an HPD GPIO with IRQ capability was found. If `hpd_irq` is `-EINVAL` (no HPD GPIO, or IRQ request failed), calling `enable_irq(-EINVAL)` / `disable_irq(-EINVAL)` would be invalid. However, in practice, the `hpd_enable` callback is only invoked by `drm_bridge_hpd_enable()` when `DRM_BRIDGE_OP_HPD` is set in `bridge->ops`, and `DRM_BRIDGE_OP_HPD` is only set when `conn->hpd_irq >= 0`. So this is safe by design, but adding a guard like:

```c
if (conn->hpd_irq < 0)
    return;
```

would be defensive and make the contract clearer. Not strictly necessary though.

**Fixes tag looks appropriate** – the original commit introduced the auto-enabled IRQ.

---
Generated by Claude Code Patch Reviewer