From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm/rockchip: cdn-dp: Add multiple bridges to support PHY port selection Date: Thu, 05 Mar 2026 13:38:01 +1000 Message-ID: In-Reply-To: <20260304094152.92-8-kernel@airkyi.com> References: <20260304094152.92-1-kernel@airkyi.com> <20260304094152.92-8-kernel@airkyi.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review The most complex patch. Introduces `cdn_dp_bridge` wrapper, multi-bridge registration, port switching, HPD notification. **Bug: `prev_port` is 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]; } if (prev_port) { // <--- prev_port may be uninitialized! ``` If no port has `phy_enabled` set, `prev_port` is never assigned but is still checked. The compiler may or may not zero-initialize it. This must be initialized to `NULL`. **Issue (medium): `cdn_dp_connected_port()` has a logic issue with the extcon (non-next_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 extcon path (`!next_bridge_valid`), this returns the first port unconditionally regardless of whether it has lanes. The old code was: ```c lanes = cdn_dp_get_port_lanes(port); if (lanes) return port; ``` The new code removed the `lanes` check for the extcon path, so it returns the first port even if it has 0 lanes. This is a regression. **Issue (minor): `dp->active` check in `cdn_dp_switch_port()` is confusing:** ```c static int cdn_dp_switch_port(...) { if (dp->active) return 0; ``` Returning 0 (success) when `dp->active` is true seems wrong for a "switch port" operation. The caller expects to be able to switch, but if the DP is actively streaming, this silently does nothing. A return of `-EBUSY` or at least a log message would be more appropriate. **Issue (minor): In the HPD notify path, `bridge_list[i]->connected` is set but `dp->connected` is the main connection state.** The interaction between per-bridge `connected` and the global `dp->connected` is subtle and deserves a comment. --- Generated by Claude Code Patch Reviewer