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/bridge: Act on the DRM color format property Date: Wed, 25 Mar 2026 06:44:26 +1000 Message-ID: In-Reply-To: <20260324-color-format-v11-4-605559af4fb4@collabora.com> References: <20260324-color-format-v11-0-605559af4fb4@collabora.com> <20260324-color-format-v11-4-605559af4fb4@collabora.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 Good approach. The `bus_format_is_color_fmt()` function is comprehensive in= its format mappings. 1. **HDMI format conversion switch is duplicated:** The `DRM_OUTPUT_COLOR_F= ORMAT_*` to `DRM_CONNECTOR_COLOR_FORMAT_*` conversion switch in `drm_atomic= _bridge_chain_select_bus_fmts` is a pattern repeated in patches 6, 8, and 9= . A shared inline helper would reduce maintenance burden. 2. **`out_free_bus_fmts` label placement:** The label is added but the orig= inal `kfree(out_bus_fmts)` is reused. If we reach the label from the HDMI `= default:` case with `ret =3D -EINVAL`, `out_bus_fmts` is freed and the erro= r is returned. This is correct. 3. **Debug log for non-HDMI uses raw enum int:** `"Non-HDMI bridge requests= format %d\n", fmt` =E2=80=94 could benefit from a name helper for readabil= ity in logs. --- Generated by Claude Code Patch Reviewer