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

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

Patch Review

**Overall: Looks good.** The locking pattern (internal `drm_modeset_acquire_ctx` with EDEADLK retry when no external ctx is provided) follows established DRM conventions.

One concern:

- **Return type mixing:** `drm_bridge_detect_ctx()` returns `int`, which can be either a `drm_connector_status` enum value or a negative error code. The fallback path at line 282 calls `bridge->funcs->detect()` which returns `enum drm_connector_status`. This works because the enum values are small non-negative integers, but it's worth documenting this mixing more explicitly. The docstring mentions it can return `-EDEADLK` only when `@ctx is set`, but the internal ctx path silently maps errors to `connector_status_unknown` (line 274-275), which could mask real errors. Consider at least a `dev_warn` or `drm_dbg` when a negative return is swallowed.

- **connection_mutex locking:** The function locks `connection_mutex` in the internal-ctx path (line 263). This is correct for the bridge-connector use case, but the docstring for `detect_ctx` in `drm_bridge.h` says `connection_mutex will always be locked` — this is only true when called from bridge-connector, not when called directly with `ctx = NULL` from other paths (like `drm_bridge_connector_get_modes_edid` which passes `NULL`). Actually, looking at the code again, the NULL-ctx path *does* lock it (line 263-264), so the guarantee holds. Good.

---
Generated by Claude Code Patch Reviewer