From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm/radeon/rs780: prevent division by zero in refresh rate calculation Date: Tue, 05 May 2026 10:36:35 +1000 Message-ID: In-Reply-To: <20260430104626.16230-1-evg28bur@yandex.ru> References: <20260430104626.16230-1-evg28bur@yandex.ru> <20260430104626.16230-1-evg28bur@yandex.ru> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Patch Review **Correctness of the fix in `rs780_get_pm_mode_parameters()`:** The fallbac= k to 60Hz when `drm_mode_vrefresh()` returns 0 is sensible and consistent w= ith the existing default at line 59: ```c /* defaults */ pi->refresh_rate =3D 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 =E2=80=94 The `WARN_ON` in `rs780_program_at()` is unnecessary an= d arguably wrong.** With the fix in `rs780_get_pm_mode_parameters()`, `refr= esh_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. Mor= e 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 n= ext line. It doesn't actually *protect* against anything =E2=80=94 it just = adds a warning before the crash. If the intent is belt-and-suspenders, a `W= ARN_ON` with a return would be needed: ```c if (WARN_ON(pi->refresh_rate =3D=3D 0)) return; ``` But even that is over-engineering given the fix in the getter. I'd recommen= d dropping the `WARN_ON` entirely to keep the patch minimal and focused. **Issue 2 =E2=80=94 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()` =E2=80=94 it does not= validate `mode->clock` directly. The commit message should match what the = code actually does. **Issue 3 =E2=80=94 `Cc: stable` / routing concern.** The patch is addresse= d `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 k= ernel workflow is to get the fix merged in mainline first (via the drm/rade= on maintainers), and then request stable backport with a `Cc: stable@vger.k= ernel.org` tag. Sending directly to stable is not the usual process and wil= l likely be rejected. This should go through the `amd-gfx` / `dri-devel` ma= intainer flow first. **Issue 4 =E2=80=94 The `Reported-by` / `Closes` tags reference a kbuild bo= t report, but the commit message says "Found by Linux Verification Center (= linuxtesting.org) with SVACE."** These are two different tools/reporters. I= f 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 i= s fine. **Summary:** The core fix (fallback to 60Hz on zero return from `drm_mode_v= refresh()`) is correct and appropriate. The `WARN_ON` should be dropped or = converted to a `WARN_ON` + early return. The commit message needs to accura= tely describe what was done, and the submission routing needs to follow the= normal mainline-first workflow. --- Generated by Claude Code Patch Reviewer