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 the key enabling patch. Moving the lookup from probe to attach breaks the devlink chicken-and-egg problem described in the commit message.

The implementation looks correct. The new code in `dw_hdmi_bridge_attach()`:

```c
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 -EPROBE_DEFER;

struct drm_bridge *next_bridge __free(drm_bridge_put) =
    of_drm_find_and_get_bridge(remote);

return drm_bridge_attach(encoder, next_bridge, bridge, flags);
```

**Potential issue:** If `of_drm_find_and_get_bridge()` returns NULL (bridge not yet registered), `next_bridge` will be NULL and `drm_bridge_attach()` will be called with a NULL bridge, returning `-EINVAL`. The old `dw_hdmi_parse_dt()` returned `-EPROBE_DEFER` in this case. Consider adding a NULL check on `next_bridge` and returning `-EPROBE_DEFER` to maintain the probe deferral behavior. Without this, the attach would fail hard instead of deferring.

**Semantic change:** The old code returned `-ENODEV` when the remote node was missing in DT; the new code returns `-EPROBE_DEFER`. Since the WARN_ON in patch 5 guards the `!output_port` case, and if `output_port` is set but there's no remote in DT, `-EPROBE_DEFER` may not be the right error — the node might simply not exist. However, with the overlay fixup in patch 7, this becomes a timing issue, so `-EPROBE_DEFER` is arguably more appropriate.

---
Generated by Claude Code Patch Reviewer