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: Add new general DRM property "color format" Date: Mon, 25 May 2026 17:26:08 +1000 Message-ID: In-Reply-To: <20260523-color-format-v16-3-24340c5e4732@collabora.com> References: <20260523-color-format-v16-0-24340c5e4732@collabora.com> <20260523-color-format-v16-3-24340c5e4732@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 This is the core of the series. A few observations: **Observation:** `hdmi_colorformats` and `dp_colorformats` (lines 971=E2=80= =93981 in the mbox) are currently identical bitmasks. This is fine =E2=80= =94 they serve as separate validation sets for future divergence =E2=80=94 = but it does mean the validation in `drm_connector_attach_color_format_prope= rty` is currently a no-op for both HDMI and DP since both allow all four fo= rmats. **Minor:** The `switch` in `drm_connector_attach_color_format_property` at = line 1075 has no `default:` case, meaning connector types other than HDMI/D= P silently skip connector-type-specific validation. That's actually fine = =E2=80=94 not all connectors need per-type restrictions =E2=80=94 but a bri= ef comment noting the intentional fall-through for other connector types wo= uld improve clarity. **Observation on the enum naming:** Using `drm_hdmi_connector_get_output_fo= rmat_name()` (line 1116) for the property enum labels means the name string= s come from a function originally scoped for HDMI. This works because the f= ormat names are protocol-independent ("RGB", "YUV 4:4:4", etc.), but it's a= slightly surprising code path. --- Generated by Claude Code Patch Reviewer