Claude review: drm/msm/disp/dpu: consider SSPP line width during mode valid

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

Patch Review

**The fix is incomplete for the non-3d_merge path.**

The patch only constrains the final `drm_mode_validate_size()` call, changing:
```c
2 * dpu_kms->catalog->caps->max_mixer_width
```
to:
```c
2 * min_t(u32, max_mixer_width, max_linewidth)
```

But earlier in the same function (around line 1598-1600), there is:
```c
if (!dpu_kms->catalog->caps->has_3d_merge &&
    mode->hdisplay > dpu_kms->catalog->caps->max_mixer_width)
    return MODE_BAD_HVALUE;
```

For targets *without* `has_3d_merge` where `max_linewidth < max_mixer_width` (e.g., sm6150 has no `has_3d_merge`, max_mixer_width=2560, max_linewidth=2160), this early check still allows modes up to 2560 wide, even though the SSPP can only handle 2160. Those modes would pass `mode_valid` and then presumably fail at `atomic_check`.

**This early check should also be clamped by `max_linewidth`**, something like:
```c
if (!dpu_kms->catalog->caps->has_3d_merge &&
    mode->hdisplay > min_t(u32, dpu_kms->catalog->caps->max_mixer_width,
                           dpu_kms->catalog->caps->max_linewidth))
    return MODE_BAD_HVALUE;
```

**Minor: the commit message could be more specific.** The message says "few targets have lesser SSPP line width" — it would be helpful to name the affected targets (sm6150, sm6125, sm6115, qcm2290, sm6375, etc.) and perhaps add a `Fixes:` tag if this addresses a regression or user-reported issue, or at least a `Cc: stable` if backport is desired.

**The code itself is otherwise correct:** `min_t(u32, ...)` is the right macro, the `max_width` variable is properly typed, and the comment update accurately describes the new logic.

---
Generated by Claude Code Patch Reviewer