Claude review: drm/blend: size zpos array to active planes instead of total

[Claude Code Review Bot <claude-review@example.com>]

Overall Series Review

Subject: drm/blend: size zpos array to active planes instead of total
Author: Gustavo Piaz Da Silva <gustavopiazdasilva2102@gmail.com>
Patches: 2
Reviewed: 2026-05-05T09:43:21.243447

---

This is a single-patch series that reduces the allocation size of a temporary array in `drm_atomic_helper_crtc_normalize_zpos()` from `num_total_plane` (all planes on the device) to `hweight32(crtc_state->plane_mask)` (only the active planes on the given CRTC).

The change is **correct**. The `drm_for_each_plane_mask()` loop iterates exactly over the bits set in `plane_mask`, so `hweight32(plane_mask)` gives the precise count of array entries that will be populated. The original allocation was safe but conservatively oversized.

That said, the practical benefit is minimal. A typical device might have 3-8 total planes, and each array entry is a single pointer (8 bytes on 64-bit). The savings are on the order of a handful of bytes per CRTC atomic commit — not meaningful "memory pressure." The real value is arguably in making the code more self-documenting: the allocation size now directly reflects the iteration count.

**One potential issue worth flagging:** `plane_mask` is `u32` (confirmed at `include/drm/drm_crtc.h:195`), so `hweight32()` is type-correct today. However, if `plane_mask` were ever widened (e.g., to `u64` for devices with >32 planes), the `hweight32()` call would silently truncate and produce an undersized allocation, causing an out-of-bounds write at line 492:

```c
states[n++] = plane_state;
```

This is not a bug today, but it is a latent fragility the original code didn't have. Using `hweight_long()` or adding a `BUILD_BUG_ON(sizeof(crtc_state->plane_mask) > sizeof(u32))` would harden against that future scenario.

---

---
Generated by Claude Code Patch Reviewer