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/rcar-du: dsi: Support DSC in the pipeline Date: Sat, 16 May 2026 09:29:58 +1000 Message-ID: In-Reply-To: <20260515-rcar-du-dsc-v3-4-164157820498@ideasonboard.com> References: <20260515-rcar-du-dsc-v3-0-164157820498@ideasonboard.com> <20260515-rcar-du-dsc-v3-4-164157820498@ideasonboard.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Patch Review This patch handles the pipeline topology change where the CRTC code calls `= rcar_mipi_dsi_pclk_enable()` on whatever bridge is first in the chain =E2= =80=94 which is now the DSC bridge rather than the DSI bridge. The `rcar_mipi_dsi_resolve_bridge()` approach of comparing `bridge->funcs` = pointers is pragmatic. The forward declaration of `rcar_mipi_dsi_bridge_ops= ` is necessary and correctly placed. ```c +static struct drm_bridge * +rcar_mipi_dsi_resolve_bridge(struct drm_bridge *bridge) +{ + if (bridge->funcs !=3D &rcar_mipi_dsi_bridge_ops) + bridge =3D bridge->next_bridge; + + if (!bridge || bridge->funcs !=3D &rcar_mipi_dsi_bridge_ops) + return NULL; + + return bridge; +} ``` One consideration: this function is in `rcar_mipi_dsi.c` but it needs to un= derstand the DSC bridge's topology (specifically, that DSC's `next_bridge` = points to the DSI). This works because `next_bridge` is a standard drm_brid= ge field, so no DSC-specific knowledge is actually needed beyond "skip one = bridge if it's not ours." The comment explaining the logic is appropriate a= nd helpful. The `WARN_ON(!bridge)` in both callers is a reasonable choice =E2=80=94 thi= s situation indicates broken DT data, which shouldn't occur in a correctly = configured system. No issues. --- Generated by Claude Code Patch Reviewer