[PATCH] drm/radeon/rs780: prevent division by zero in refresh rate calculation

[PATCH] drm/radeon/rs780: prevent division by zero in refresh rate calculation

[Evgenii Burenchev]

drm_mode_vrefresh() may return zero when mode clock is zero even if
htotal and vtotal are non-zero. Current code checks only htotal and
vtotal, allowing refresh_rate to become zero and subsequently causing
division by zero in rs780_program_at().

Fix by adding mode clock validation and fallback to default 60Hz in
rs780_get_pm_mode_parameters(). Add WARN_ON in rs780_program_at() to
catch such cases during development, ensuring safe fallback in all
scenarios.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202604300508.yXci8rey-lkp@intel.com/

Signed-off-by: Evgenii Burenchev <evg28bur@yandex.ru>
---
 drivers/gpu/drm/radeon/rs780_dpm.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/rs780_dpm.c b/drivers/gpu/drm/radeon/rs780_dpm.c
index 64bb4cafb8b5..8713f3fd6268 100644
--- a/drivers/gpu/drm/radeon/rs780_dpm.c
+++ b/drivers/gpu/drm/radeon/rs780_dpm.c
@@ -63,8 +63,11 @@ static void rs780_get_pm_mode_parameters(struct radeon_device *rdev)
 		if (crtc && crtc->enabled) {
 			radeon_crtc = to_radeon_crtc(crtc);
 			pi->crtc_id = radeon_crtc->crtc_id;
-			if (crtc->mode.htotal && crtc->mode.vtotal)
+			if (crtc->mode.htotal && crtc->mode.vtotal) {
 				pi->refresh_rate = drm_mode_vrefresh(&crtc->mode);
+				if (pi->refresh_rate == 0)
+					pi->refresh_rate = 60;
+			}
 			break;
 		}
 	}
@@ -363,6 +366,8 @@ static void rs780_program_at(struct radeon_device *rdev)
 {
 	struct igp_power_info *pi = rs780_get_pi(rdev);
 
+	WARN_ON(pi->refresh_rate == 0);
+
 	WREG32(FVTHROT_TARGET_REG, 30000000 / pi->refresh_rate);
 	WREG32(FVTHROT_CB1, 1000000 * 5 / pi->refresh_rate);
 	WREG32(FVTHROT_CB2, 1000000 * 10 / pi->refresh_rate);

base-commit: a5640267d6d35b89ebe6418da90a952a247215a5
-- 
2.43.0

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

[Claude Code Review Bot]

Overall Series Review

Subject: drm/radeon/rs780: prevent division by zero in refresh rate calculation
Author: Evgenii Burenchev <evg28bur@yandex.ru>
Patches: 1
Reviewed: 2026-05-05T10:36:35.430377

---

This is a single-patch fix for a potential division-by-zero in the radeon RS780 DPM (dynamic power management) code. The problem is real: `drm_mode_vrefresh()` can return 0 in several edge cases (overflow in `check_mul_overflow`, or `clock == 0` with non-zero htotal/vtotal, or very small clock values that round to 0 in `DIV_ROUND_CLOSEST_ULL`), and `rs780_program_at()` divides by `pi->refresh_rate` in five places. The fix is straightforward and low-risk. However, there are some issues with the patch.

**Verdict: Needs minor revision.**

---
Generated by Claude Code Patch Reviewer

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

[Claude Code Review Bot]

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