From mboxrd@z Thu Jan  1 00:00:00 1970
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: drm/display: hdmi: Use drm_output_color_format instead of hdmi_colorspace
Date: Fri, 27 Feb 2026 15:17:10 +1000
Message-ID: <review-patch14-20260224-drm-rework-color-formats-v1-14-bebc76604ada@kernel.org>
In-Reply-To: <20260224-drm-rework-color-formats-v1-14-bebc76604ada@kernel.org>
References: <20260224-drm-rework-color-formats-v1-0-bebc76604ada@kernel.org> <20260224-drm-rework-color-formats-v1-14-bebc76604ada@kernel.org>
X-Mailer: Claude Code Patch Reviewer
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0

Patch Review

This is the most substantive patch. It changes `drm_connector_hdmi_state.output_format` from `enum hdmi_colorspace` to `enum drm_output_color_format` and updates all related code.

**Issue 1 - Missing documentation updates**: The `supported_formats` field documentation is not updated in either header:
- `drm_connector.h:1882`: Still says "Bitmask of @hdmi_colorspace"
- `drm_bridge.h:1191`: Still says "Bitmask of @hdmi_colorspace listing supported output formats"

Both should be updated to reference `@drm_output_color_format`.

**Issue 2 - Silent bitmask semantics change**: The `supported_formats` bitmask changes semantics because the enum orderings differ:
- `hdmi_colorspace`: RGB=0, YUV422=1, YUV444=2, YUV420=3
- `drm_output_color_format`: RGB444=0, YCBCR444=1, YCBCR422=2, YCBCR420=3

So `BIT(HDMI_COLORSPACE_YUV422)` = BIT(1) = 2, but `BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422)` = BIT(2) = 4. The 422 and 444 bit positions are swapped. This is safe as long as the conversion is complete (which it appears to be), but it should be explicitly noted in the commit message to alert reviewers.

**Issue 3 - Header include**: The patch adds `#include <drm/drm_connector.h>` to `drm_hdmi_helper.h`. This is a significant include -- `drm_connector.h` is a very large header. Consider whether a forward declaration would suffice, or whether the enum could be defined in a smaller header.

**Positive**: The `output_color_format_to_hdmi_colorspace()` conversion function is well-written with proper `default` + `fallthrough` handling:
```c
default:
    drm_warn(connector->dev, "Unsupported output color format. Defaulting to RGB.");
    fallthrough;
case DRM_OUTPUT_COLOR_FORMAT_RGB444:
    return HDMI_COLORSPACE_RGB;
```

**Positive**: The test updates are thorough and mechanical, covering all the KUnit test infrastructure consistently.

**Minor**: The `drm_hdmi_connector_get_output_format_name()` function declaration is moved in `drm_connector.h` to after the enum definition, which is correct since it now depends on the enum type.

---
Generated by Claude Code Patch Reviewer