Claude review: drm/display: Increase DP_RECEIVER_CAP_SIZE from 15 to 16 bytes

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

Overall Series Review

Subject: drm/display: Increase DP_RECEIVER_CAP_SIZE from 15 to 16 bytes
Author: Khaled Almahallawy <khaled.almahallawy@intel.com>
Patches: 3
Reviewed: 2026-03-14T07:29:32.912351

---

This is a single-patch series (v2 is a rebase of v1) that fixes `DP_RECEIVER_CAP_SIZE` from 0xf (15 bytes) to 0x10 (16 bytes) to include the `DP_ADAPTER_CAP` register at DPCD address 0x00F. The change is well-motivated by the DP 2.1 spec and compliance test failures.

The fix is **correct and well-justified**. The DP spec clearly defines the Receiver Capability field as DPCD addresses 0x00000h through 0x0000Fh (inclusive), which is 16 bytes. The current value of 0xf (15) misses the last byte (`DP_ADAPTER_CAP`). Notably, AMD's DC driver already works around this by hardcoding `uint8_t dpcd_data[16]` with a comment referencing `DP_ADAPTER_CAP` (`link_dp_capability.c:1740-1743`), which independently confirms this was a known deficiency.

**Impact assessment**: `DP_RECEIVER_CAP_SIZE` is used extensively across the kernel — in struct field declarations (i915, nouveau, radeon, amdgpu, MSM, MediaTek, various bridges), local arrays, function signatures, and AUX read lengths. All of these will grow by 1 byte. This is benign:
- Local arrays and struct fields grow by 1 byte — no ABI concern for userspace.
- The nouveau `nvif_outp_dp_train_v0` struct embeds `dpcd[DP_RECEIVER_CAP_SIZE]`, but this is an internal kernel interface (not UAPI), so the size change is safe.
- `drm_dp_read_extended_dpcd_caps()` will also correctly read one additional byte from the 0x2200 range (through 0x220F), which is exactly what compliance test 4.2.2.2 requires.

**Risk**: Low. The extra byte read is harmless — all DP sinks must implement this register range per the spec.

---
Generated by Claude Code Patch Reviewer