Claude review: drm/amd: fix force_yuv420/422_output being ignored

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

Patch Review

**Correctness concern:** The original code gated `force_yuv420_output` on `drm_mode_is_420_also()` and `force_yuv422_output` on `DRM_COLOR_FORMAT_YCBCR422`. These guards existed to prevent forcing a pixel encoding the display genuinely cannot accept. Removing them means:

```c
else if (aconnector && aconnector->force_yuv420_output)
    timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
```

This will now force YCbCr 4:2:0 even for modes that are not 420-capable at all (not just "420_also" but completely 420-incompatible). This could cause a black screen or signal errors on displays that truly don't support 4:2:0 for a given mode.

The commit message frames this as "the flag becomes ineffective" when the display doesn't advertise the capability, but the `force_` prefix in the debugfs attribute does suggest "force regardless." Still, this is a user-facing behavior change that removes safety checks. It would be better to either:
1. Gate on `edid_overridden` (only bypass the check when an override is active), or
2. Add a warning log when forcing an unadvertised encoding so users can diagnose issues.

**Interaction with Patch 2:** This patch is listed as fixing issues with EDID overrides, but it unconditionally changes behavior for all displays, not just those with overrides. This seems like an overly broad change for the stated problem.

---
Generated by Claude Code Patch Reviewer