Claude review: drm/rockchip: cdn-dp: Add multiple bridges to support PHY port selection

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

Patch Review

This is the largest and most complex patch in the series.

**Bug: `prev_port` used uninitialized**
In `cdn_dp_bridge_edid_read()`:
```c
struct cdn_dp_port *prev_port;
...
if (dp->bridge_count > 1 && !port->phy_enabled) {
    for (i = 0; i < dp->bridge_count; i++) {
        if (dp->bridge_list[i] != dp_bridge && dp->bridge_list[i]->enabled)
            goto get_cache;
        if (dp->port[i]->phy_enabled)
            prev_port = dp->port[i];
    }

    /* Switch to current port */
    if (prev_port) {
        ret = cdn_dp_switch_port(dp, prev_port, port);
```
`prev_port` is never initialized to `NULL`. If no port has `phy_enabled` set, `prev_port` contains stack garbage, and the `if (prev_port)` check passes with a random non-zero value, leading to a crash in `cdn_dp_switch_port()`. **Fix: initialize `prev_port = NULL`.**

**Issue: `cdn_dp_switch_port` sets `dp->active = true` from EDID context**
```c
static int cdn_dp_switch_port(struct cdn_dp_device *dp, ...)
{
    if (dp->active)
        return 0;
    ...
    dp->active = true;
    dp->lanes = port->lanes;
```
This function is called from `cdn_dp_bridge_edid_read()`, which is a detect/probe path. Setting `dp->active = true` during EDID read means the subsequent `cdn_dp_enable()` call from `cdn_dp_bridge_atomic_enable()` will return early (`if (dp->active) return 0`), potentially skipping important initialization that normally happens during `cdn_dp_enable()` (firmware init, clock enable). This seems like it could leave the driver in an inconsistent state.

**Issue: `cdn_dp_connected_port` logic change breaks non-bridge path**
```c
for (i = 0; i < dp->ports; i++) {
    port = dp->port[i];
    lanes[i] = cdn_dp_get_port_lanes(port);
    if (!dp->next_bridge_valid)
        return port;
}
```
In the old code, the function returned the first port with non-zero lanes. Now with `!dp->next_bridge_valid`, it returns the first port **unconditionally** (even if `lanes[i]` is 0). This is a regression for the extcon path — a port with zero lanes would now be returned as "connected". Should be:
```c
    if (!dp->next_bridge_valid && lanes[i])
        return port;
```

**Issue: `bridge_count` vs `ports` inconsistency**
The `next_bridge_valid` path in `cdn_dp_connected_port()` iterates with `dp->bridge_count`:
```c
for (i = 0; i < dp->bridge_count; i++) {
    if (lanes[i])
        return dp->port[i];
}
```
But `lanes[]` was populated over `dp->ports` iterations. If `bridge_count != ports`, some `lanes[]` entries could be uninitialized or we could access `dp->port[i]` out of bounds.

**Issue: `cdn_dp_bridge_detect` not updated for multi-bridge**
The `cdn_dp_bridge_detect()` function still only checks `dp->connected`, but the per-bridge `dp_bridge->connected` flag is only checked in `cdn_dp_bridge_mode_valid()`. The detect callback should probably also consider the per-bridge connected state, otherwise all bridges report the same connection status.

**Design: EDID caching**
The EDID caching design (`edid_cache[MAX_PHY]`) is reasonable for the port-switching scenario. The `drm_edid_dup()`/`drm_edid_free()` calls appear correctly paired.

**Good: `devm_drm_bridge_alloc` usage**
Moving from a single bridge embedded in `cdn_dp_device` to dynamically allocated `cdn_dp_bridge` structs is the right structural change.

**Cleanup needed in unbind:**
```c
for (i = 0; i < dp->bridge_count; i++) {
    encoder = &dp->bridge_list[i]->encoder.encoder;
    encoder->funcs->destroy(encoder);
    drm_bridge_put(dp->next_bridge_list[i]);
}
```
`drm_bridge_put(dp->next_bridge_list[i])` could be called with NULL if `next_bridge_list[i]` wasn't populated (e.g., extcon path where `bridge_count = 1` but `next_bridge_valid = false`). Should check for NULL before calling `drm_bridge_put()`.

---

**Summary:** The series has the right architectural direction but patch 5 has several correctness issues that need fixing before merge, most critically the uninitialized `prev_port` and the `cdn_dp_connected_port` logic regression. Patch 4 also has a real bug in the probe filter condition.

---
Generated by Claude Code Patch Reviewer