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/blend: size zpos array to active planes instead of total
Date: Tue, 05 May 2026 09:43:21 +1000
Message-ID: <review-patch1-20260501001301.7666-2-gustavopiazdasilva2102@gmail.com>
In-Reply-To: <20260501001301.7666-2-gustavopiazdasilva2102@gmail.com>
References: <20260501001301.7666-1-gustavopiazdasilva2102@gmail.com> <20260501001301.7666-2-gustavopiazdasilva2102@gmail.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

**Correctness:** The change is correct. Walking the function at `drm_blend.=
c:463-511`:

- `total_planes =3D hweight32(crtc_state->plane_mask)` =E2=80=94 counts exa=
ctly the bits set in the mask.
- `kmalloc_objs(*states, total_planes)` at line 477 =E2=80=94 allocates tha=
t many entries.
- `drm_for_each_plane_mask(plane, dev, crtc_state->plane_mask)` at line 485=
 =E2=80=94 iterates exactly over those same bits.
- `states[n++] =3D plane_state` at line 492 =E2=80=94 `n` will reach exactl=
y `total_planes` (assuming no early error exit), so no overrun.

The zero-planes edge case (`plane_mask =3D=3D 0`) is also fine: `kmalloc_ar=
ray(0, ...)` returns `ZERO_SIZE_PTR` (non-NULL), the loop body never execut=
es, `sort` and the for-loop with `n=3D0` are no-ops, and `kfree(ZERO_SIZE_P=
TR)` is valid.

**Suggested improvement:** Consider using `hweight_long()` or a type-matche=
d weight function instead of `hweight32()` to avoid a silent truncation bug=
 if `plane_mask` is ever widened beyond `u32`:

```c
-	int total_planes =3D hweight32(crtc_state->plane_mask);
+	int total_planes =3D hweight_long(crtc_state->plane_mask);
```

Or alternatively, add a static assertion:

```c
BUILD_BUG_ON(sizeof(crtc_state->plane_mask) !=3D sizeof(u32));
```

**Commit message:** The commit message is well written and clearly explains=
 both the problem and the solution. The claim about "reducing memory pressu=
re" is a bit strong for what amounts to saving a few pointers per atomic co=
mmit =E2=80=94 "tightens the allocation" or "avoids over-allocation" would =
be more proportionate.

**Verdict:** Correct, low-risk change. Worth applying, ideally with `hweigh=
t_long()` for future-proofing.

---
Generated by Claude Code Patch Reviewer