Claude review: drm/radeon: Fix OOB read in MC register table init

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

Patch Review

**Problem analysis:** In `radeon_atom_init_mc_reg_table()`, the inner `for` loop at line 4029 iterates `i` starting from 0. When `pre_reg_data` has `DATA_EQU_PREV` set for the first entry (`i == 0`), the code accesses `mc_data[i - 1]` which underflows to `mc_data[-1]` — a clear out-of-bounds read.

**Fix analysis:** The patch adds:
```c
if (i == 0)
    continue;
```
at line 4035-4036, before the `mc_data[i - 1]` access. This is correct:

1. **`continue` targets the right loop.** The innermost enclosing loop is the `for (i = 0, j = 1; i < reg_table->last; i++)` at line 4029. The `continue` skips the copy for entry 0 and advances `i`, which is the desired behavior — leaving `mc_data[0]` uninitialized for this case is acceptable since `DATA_EQU_PREV` on the first entry is a malformed table condition with no meaningful "previous" value to copy.

2. **Exact match to the amdgpu fix.** The amdgpu equivalent at `amdgpu_atombios.c:1525-1526` uses the identical pattern (`if (i == 0) continue;`), so this is consistent across both drivers.

3. **No side effects on `j`.** The `j` index is only incremented in the `DATA_FROM_TABLE` branch, not the `DATA_EQU_PREV` branch, so skipping via `continue` doesn't desynchronize the data pointer.

4. **Fixes tag and stable tag are appropriate.** The Fixes tag points to the original commit that introduced this code path (`ae5b0abbb6f7`), and the `Cc: stable` is warranted since this is a real OOB read.

**Minor note:** The commit message mentions "Emulate a fix" — the wording is slightly odd ("apply the same fix as" would be more natural), but this is cosmetic and not worth a respin.

**Reviewed-by worthy.** No issues found.

---
Generated by Claude Code Patch Reviewer