Claude review: drm/bridge: Add detect_ctx hook and drm_bridge_detect_ctx() helper

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

Patch Review

This is the core infrastructure patch. Key observations:

**Return type change:** `drm_bridge_detect_ctx()` returns `int` rather than `enum drm_connector_status`, allowing `-EDEADLK` to propagate. This is a reasonable approach since connector status values are positive. The `WARN_ON(ret < 0)` fallback at the end catches unexpected negative returns:

```c
out:
	if (WARN_ON(ret < 0))
		ret = connector_status_unknown;

	return ret;
```

This is good defensive coding. However, note that when `ctx != NULL` and `ret == -EDEADLK`, the function returns early (correct), but for any *other* negative return from `detect_ctx` with a caller-provided ctx, it falls through to the `WARN_ON` and converts to `connector_status_unknown`. That seems intentional and fine.

**Locking in the NULL-ctx path:** When `ctx` is NULL, the function acquires `connection_mutex` internally. This matches what the DRM core does for the connector `.detect_ctx` path. The EDEADLK retry loop is correctly structured.

**Delegation from drm_bridge_detect():** The existing `drm_bridge_detect()` now simply delegates to `drm_bridge_detect_ctx(bridge, connector, NULL)`. This means old callers that only set `.detect` go through an extra function call but the behavior is preserved since `!bridge->funcs->detect_ctx` returns `bridge->funcs->detect(bridge, connector)` directly.

**One subtlety:** When `ctx` is NULL and `detect_ctx` is implemented, the helper acquires `connection_mutex` internally. But when going through the old `drm_bridge_detect()` → `drm_bridge_detect_ctx(NULL)` path for a bridge that only has `.detect`, no locking is acquired — which matches the previous behavior. Good.

**Documentation** is clear and correctly describes the precedence rules (`detect_ctx` over `detect`).

**No issues found.**

---

---
Generated by Claude Code Patch Reviewer