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

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

Patch Review

**Purpose:** Prevent the HPD IRQ from firing before the DRM connector is fully set up by using `IRQF_NO_AUTOEN` and controlling enablement via `hpd_enable`/`hpd_disable` bridge callbacks.

**Analysis:**

The change is straightforward and correct. Adding `IRQF_NO_AUTOEN` to `devm_request_threaded_irq()`:

```c
IRQF_TRIGGER_RISING |
IRQF_TRIGGER_FALLING |
IRQF_NO_AUTOEN |
IRQF_ONESHOT,
```

ensures the IRQ starts disabled. The new callbacks:

```c
static void display_connector_hpd_enable(struct drm_bridge *bridge)
{
	struct display_connector *conn = to_display_connector(bridge);
	enable_irq(conn->hpd_irq);
}

static void display_connector_hpd_disable(struct drm_bridge *bridge)
{
	struct display_connector *conn = to_display_connector(bridge);
	disable_irq(conn->hpd_irq);
}
```

are only invoked when `DRM_BRIDGE_OP_HPD` is set in `bridge->ops`, which only happens when `conn->hpd_irq >= 0` (line 413-414), so `conn->hpd_irq` is always valid when these callbacks run.

The `enable_irq`/`disable_irq` are called under `bridge->hpd_mutex` (held by `drm_bridge_hpd_enable`/`drm_bridge_hpd_disable`). If a threaded IRQ fires immediately after `enable_irq()` and calls `drm_bridge_hpd_notify()`, that will block on the mutex in a separate thread context — no deadlock, just a brief wait. The callback `hpd_cb` is already set before `hpd_enable` is called (drm_bridge.c:1459-1460), so the notification will be properly delivered.

The Fixes tag referencing the original commit that introduced the driver is appropriate.

**No issues found.**

---

---
Generated by Claude Code Patch Reviewer