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: ensure blend mode supported if pixel format with alpha exposed Date: Wed, 27 May 2026 14:23:00 +1000 Message-ID: In-Reply-To: <20260526181700.25310-3-leandro.ribeiro@collabora.com> References: <20260526181700.25310-1-leandro.ribeiro@collabora.com> <20260526181700.25310-3-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 **Potential NULL pointer dereference.** In `validate_blend_mode_for_alpha_f= ormats()`: ```c for (i =3D 0; i < plane->format_count; i++) { fmt =3D drm_format_info(plane->format_types[i]); if (fmt->has_alpha) { ``` `drm_format_info()` can return NULL for unknown formats (it only does a `WA= RN_ON(!info)` internally, then returns NULL). If a buggy driver registers a= n unknown fourcc, this validation function =E2=80=94 which exists precisely= to catch driver bugs =E2=80=94 would hit a NULL dereference on `fmt->has_a= lpha`. This should have a NULL check: ```c fmt =3D drm_format_info(plane->format_types[i]); if (fmt && fmt->has_alpha) { ``` In practice this is unlikely to trigger since any driver with an unknown fo= rmat would already be very broken, but a validation function should be defe= nsive. **Otherwise the logic is correct.** The early return when `blend_mode_prope= rty` is set avoids unnecessary iteration. The `break` after the first warni= ng avoids spamming the log. The placement in `drm_mode_config_validate()` i= n the existing `drm_for_each_plane` loop is efficient. **Minor style nit:** The WARN format string is split across lines: ```c WARN(1, "[PLANE:%d:%s] pixel format with alpha exposed but " "blend mode not setup", plane->base.id, plane->name); ``` "not setup" should be "not set up" (two words =E2=80=94 "setup" is a noun, = "set up" is the verb/participle form). Very minor. --- Generated by Claude Code Patch Reviewer