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/drm_blend: allow blend mode property without PREMULTI
Date: Tue, 05 May 2026 08:17:26 +1000
Message-ID: <review-patch1-20260504140630.68707-2-leandro.ribeiro@collabora.com>
In-Reply-To: <20260504140630.68707-2-leandro.ribeiro@collabora.com>
References: <20260504140630.68707-1-leandro.ribeiro@collabora.com> <20260504140630.68707-2-leandro.ribeiro@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

**Verdict: Looks good, minor nit.**

The core change is clean and well-motivated. The WARN_ON condition is simpl=
ified to only reject invalid bits, and a fallback default selection is adde=
d:

```c
if (supported_modes & BIT(DRM_MODE_BLEND_PREMULTI))
    default_mode =3D DRM_MODE_BLEND_PREMULTI;
else if (supported_modes & BIT(DRM_MODE_BLEND_COVERAGE))
    default_mode =3D DRM_MODE_BLEND_COVERAGE;
else
    default_mode =3D DRM_MODE_BLEND_PIXEL_NONE;
```

This fallback order is reasonable =E2=80=94 PREMULTI first (backward compat=
), then COVERAGE, then PIXEL_NONE.

**Minor nit:** There is no check that `supported_modes !=3D 0`. Passing zer=
o would create a property with zero enum values and set `default_mode =3D D=
RM_MODE_BLEND_PIXEL_NONE` (which isn't even in the enum list). The old WARN=
_ON would have caught this since `BIT(DRM_MODE_BLEND_PREMULTI) =3D=3D 0` ev=
aluates true. Consider adding `!supported_modes` to the WARN_ON:

```c
if (WARN_ON(!supported_modes || (supported_modes & ~valid_mode_mask)))
    return -EINVAL;
```

**Documentation update is good** =E2=80=94 the `@supported_modes` doc now a=
ccurately reflects the new behavior.

---
Generated by Claude Code Patch Reviewer