Claude review: drm/bridge: dw-hdmi: move next_bridge lookup to attach time

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

Patch Review

This is a key patch that resolves the devlink chicken-egg problem. The moved logic looks correct:

```c
+	if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
+		struct device_node *remote __free(device_node) =
+			of_graph_get_remote_node(hdmi->dev->of_node,
+						 hdmi->plat_data->output_port, -1);
+		if (!remote)
+			return -ENODEV;
+
+		struct drm_bridge *next_bridge __free(drm_bridge_put) =
+			of_drm_find_and_get_bridge(remote);
+		if (!next_bridge)
+			return -EPROBE_DEFER;
+
+		return drm_bridge_attach(encoder, next_bridge, bridge, flags);
+	}
```

**Concern**: The `next_bridge` is declared with `__free(drm_bridge_put)`, which means `drm_bridge_put()` will be called when the variable goes out of scope (i.e., after `drm_bridge_attach()` returns). `drm_bridge_attach()` adds the bridge to the encoder's bridge chain via `list_add_tail`, which means the bridge chain holds a reference to it. The question is whether `drm_bridge_attach()` takes its own reference on the bridge.

Looking at the existing code at probe time, the original `dw_hdmi_parse_dt()` stored the result of `of_drm_find_and_get_bridge()` in `hdmi->bridge.next_bridge` and never put it. With the new code, `of_drm_find_and_get_bridge()` takes a reference, then `__free(drm_bridge_put)` drops it after attach. If `drm_bridge_attach()` takes its own reference internally (which is the case with the new refcounted bridge infrastructure), this should be fine. Given that this codebase has clearly moved to refcounted bridges (v6.17+), and `drm_bridge_attach()` does get a reference, this pattern should be correct.

No blocking issues.

---

---
Generated by Claude Code Patch Reviewer