From mboxrd@z Thu Jan  1 00:00:00 1970
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: drm/bridge: display-connector: trigger initial HPD event for DP
Date: Sat, 16 May 2026 11:28:16 +1000
Message-ID: <review-patch2-20260513-dp-connector-hpd-v2-2-42f757bfcbf9@oss.qualcomm.com>
In-Reply-To: <20260513-dp-connector-hpd-v2-2-42f757bfcbf9@oss.qualcomm.com>
References: <20260513-dp-connector-hpd-v2-0-42f757bfcbf9@oss.qualcomm.com> <20260513-dp-connector-hpd-v2-2-42f757bfcbf9@oss.qualcomm.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

**Purpose:** After enabling HPD, schedule a work item to send the current c=
able status for DP connectors, so that cables plugged before boot are detec=
ted.

**Analysis:**

The work_struct approach is the correct design. Calling `drm_bridge_hpd_not=
ify()` directly from `hpd_enable` would deadlock on `bridge->hpd_mutex`. Th=
e deferred work runs in system workqueue context where the mutex is not hel=
d:

```c
static void display_connector_hpd_work(struct work_struct *work)
{
	struct display_connector *conn =3D container_of(work, struct display_conne=
ctor, hpd_work);
	struct drm_bridge *bridge =3D &conn->bridge;
	drm_bridge_hpd_notify(bridge, display_connector_detect(bridge));
}
```

`display_connector_detect()` calls `gpiod_get_value_cansleep()`, which is f=
ine from workqueue context (can sleep).

The ordering in `hpd_disable` is correct =E2=80=94 cancel the work before d=
isabling the IRQ:

```c
if (conn->bridge.type =3D=3D DRM_MODE_CONNECTOR_DisplayPort)
	cancel_work_sync(&conn->hpd_work);
disable_irq(conn->hpd_irq);
```

`cancel_work_sync` ensures the work has either completed or been cancelled =
before proceeding, preventing a use-after-disable scenario.

The conditional `INIT_WORK` in probe:

```c
if (conn->hpd_irq >=3D 0 && type =3D=3D DRM_MODE_CONNECTOR_DisplayPort)
	INIT_WORK(&conn->hpd_work, display_connector_hpd_work);
```

is consistent with the conditional usage in `hpd_enable`/`hpd_disable` =E2=
=80=94 both check `conn->bridge.type =3D=3D DRM_MODE_CONNECTOR_DisplayPort`.

**Minor concern =E2=80=94 teardown safety:** `display_connector_remove()` d=
oes not call `cancel_work_sync()`. This relies on the DRM framework calling=
 `drm_bridge_hpd_disable()` (which calls `hpd_disable` =E2=86=92 `cancel_wo=
rk_sync`) before the bridge is removed. This is the expected teardown order=
 and is how other bridge drivers work, so it's acceptable. Adding a defensi=
ve cancel in `remove()` would be difficult anyway since the work is only in=
itialized for DP connectors.

**Commit message typos:**

```
Note, thia issue only affects drivers which set OP_HPD but not OP_DETECT
```
"thia" =E2=86=92 "this"

```
The HPD pin state is equalc to the display plugged state.
```
"equalc" =E2=86=92 "equal"

**No functional issues found. Two trivial typos in the commit message.**

---
Generated by Claude Code Patch Reviewer