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: Create drm_output_color_format enum Date: Fri, 27 Feb 2026 15:17:07 +1000 Message-ID: In-Reply-To: <20260224-drm-rework-color-formats-v1-0-bebc76604ada@kernel.org> References: <20260224-drm-rework-color-formats-v1-0-bebc76604ada@kernel.org> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Overall Series Review Subject: drm: Create drm_output_color_format enum Author: Maxime Ripard Patches: 24 Reviewed: 2026-02-27T15:17:07.561361 --- This is a well-structured cleanup series by Maxime Ripard that introduces a proper `enum drm_output_color_format` to replace the ad-hoc `DRM_COLOR_FORMAT_*` bitmask defines, and additionally replaces the (mis)use of `enum hdmi_colorspace` in the DRM HDMI connector state and helpers. The approach is sound: define an enum for individual format values, use `BIT(enum_value)` for bitmasks, and keep backward-compatible `#define` aliases during the transition (removed in patch 13). The series is logically ordered: introduce the enum, convert all users, remove old defines, then consolidate HDMI helpers. **Key concern**: The `supported_formats` field documentation in both `drm_connector.h` and `drm_bridge.h` still references `@hdmi_colorspace` after patch 14 and must be updated. Additionally, the 422/444 enum ordering differs between `hdmi_colorspace` (YUV422=1, YUV444=2) and `drm_output_color_format` (YCBCR444=1, YCBCR422=2), which is a silent ABI change in the `supported_formats` bitmask. The conversion appears complete for all in-tree users so this is safe, but it should be explicitly called out. **Commit message quality**: Patches 2-12 all share an identical boilerplate commit message with three typos ("different" should be "difference", "done is such a way than" should be "done in such a way that", "transitition" should be "transition"). These should be fixed. Overall: the series looks correct and is a worthwhile cleanup. A few documentation and cosmetic issues should be addressed before merging. --- --- Generated by Claude Code Patch Reviewer