Claude review: drm/radeon/rs780: prevent division by zero in refresh rate calculation

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

Patch Review

**Correctness of the fix in `rs780_get_pm_mode_parameters()`:** The fallback to 60Hz when `drm_mode_vrefresh()` returns 0 is sensible and consistent with the existing default at line 59:

```c
/* defaults */
pi->refresh_rate = 60;
```

The code already sets 60 as the default before the loop, so falling back to 60 when `drm_mode_vrefresh()` returns an unusable value is the right thing to do.

**Issue 1 — The `WARN_ON` in `rs780_program_at()` is unnecessary and arguably wrong.** With the fix in `rs780_get_pm_mode_parameters()`, `refresh_rate` should never be 0 when `rs780_program_at()` is reached. Adding a `WARN_ON` for a condition the code already prevents is defensive noise. More importantly, the `WARN_ON` fires but execution continues, so if somehow `refresh_rate` were 0, the division-by-zero would still happen on the very next line. It doesn't actually *protect* against anything — it just adds a warning before the crash. If the intent is belt-and-suspenders, a `WARN_ON` with a return would be needed:

```c
if (WARN_ON(pi->refresh_rate == 0))
    return;
```

But even that is over-engineering given the fix in the getter. I'd recommend dropping the `WARN_ON` entirely to keep the patch minimal and focused.

**Issue 2 — Commit message claims "mode clock validation" was added, but no clock check exists in the diff.** The commit message says "Fix by adding mode clock validation and fallback to default 60Hz." The actual fix just checks the return value of `drm_mode_vrefresh()` — it does not validate `mode->clock` directly. The commit message should match what the code actually does.

**Issue 3 — `Cc: stable` / routing concern.** The patch is addressed `To: stable@vger.kernel.org` and Greg KH, suggesting it's being submitted as a stable-only patch or a direct backport request. However, the normal kernel workflow is to get the fix merged in mainline first (via the drm/radeon maintainers), and then request stable backport with a `Cc: stable@vger.kernel.org` tag. Sending directly to stable is not the usual process and will likely be rejected. This should go through the `amd-gfx` / `dri-devel` maintainer flow first.

**Issue 4 — The `Reported-by` / `Closes` tags reference a kbuild bot report, but the commit message says "Found by Linux Verification Center (linuxtesting.org) with SVACE."** These are two different tools/reporters. If the bug was found by SVACE, the `Reported-by` should reflect that. If the kbuild bot independently reported it as well, that's fine as an additional tag, but the attribution is confusing as written.

**Minor style nit:** The added braces around the `if` block are correct per kernel coding style (multi-statement body requires braces), so that part is fine.

**Summary:** The core fix (fallback to 60Hz on zero return from `drm_mode_vrefresh()`) is correct and appropriate. The `WARN_ON` should be dropped or converted to a `WARN_ON` + early return. The commit message needs to accurately describe what was done, and the submission routing needs to follow the normal mainline-first workflow.

---
Generated by Claude Code Patch Reviewer