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: Wed, 27 May 2026 14:23:00 +1000
Message-ID: <review-patch1-20260526181700.25310-2-leandro.ribeiro@collabora.com>
In-Reply-To: <20260526181700.25310-2-leandro.ribeiro@collabora.com>
References: <20260526181700.25310-1-leandro.ribeiro@collabora.com> <20260526181700.25310-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

**Looks good.** The change is straightforward and correct.

The WARN_ON condition change from requiring `BIT(DRM_MODE_BLEND_PREMULTI)` =
to just rejecting `supported_modes =3D=3D 0` is the right relaxation =E2=80=
=94 it still catches invalid bits via the `supported_modes & ~valid_mode_ma=
sk` check while removing only the PREMULTI mandate.

The default mode fallback logic is well-ordered:

```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;
```

PREMULTI first preserves compatibility with existing userspace that assumes=
 premultiplied alpha. COVERAGE second matches the target hardware use case.=
 PIXEL_NONE as the final fallback is the only remaining valid option given =
the earlier validation.

The doc update accurately describes the new behavior. No issues.

---
Generated by Claude Code Patch Reviewer