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/display: hdmi-state-helper: Act on color format DRM property Date: Wed, 25 Mar 2026 06:44:27 +1000 Message-ID: In-Reply-To: <20260324-color-format-v11-6-605559af4fb4@collabora.com> References: <20260324-color-format-v11-0-605559af4fb4@collabora.com> <20260324-color-format-v11-6-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 1. **Dead code in switch:** The `DRM_CONNECTOR_COLOR_FORMAT_AUTO` case insi= de the `if (conn_state->color_format !=3D DRM_CONNECTOR_COLOR_FORMAT_AUTO)`= block can never be reached normally, which is why there's a `drm_warn` + `= fallthrough`. This is defensive coding, but the pattern is unusual =E2=80= =94 the `drm_warn` will fire if the enum values are somehow corrupted: ```c + if (conn_state->color_format !=3D DRM_CONNECTOR_COLOR_FORMAT_AUTO) { + switch (conn_state->color_format) { + case DRM_CONNECTOR_COLOR_FORMAT_AUTO: + drm_warn(connector->dev, "AUTO format in non-AUTO path.\n"); + fallthrough; ``` This is fine for defensive programming but adds visual noise. 2. The non-auto path calls `hdmi_compute_format_bpc` directly with the requ= ested format and returns. For AUTO, it tries RGB then falls back to YCbCr42= 0. This matches the documented behavior. Correct. --- Generated by Claude Code Patch Reviewer