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/amdgpu: fix MES queue init wptr reset on atomic64 carriers Date: Thu, 04 Jun 2026 13:17:09 +1000 Message-ID: In-Reply-To: <20260602050354.2237095-1-runyu.xiao@seu.edu.cn> References: <20260602050354.2237095-1-runyu.xiao@seu.edu.cn> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Overall Series Review Subject: drm/amdgpu: fix MES queue init wptr reset on atomic64 carriers Author: Runyu Xiao Patches: 5 Reviewed: 2026-06-04T13:17:09.171124 --- **Series: drm/amdgpu: fix MES queue init wptr reset on atomic64 carriers (2= patches)** The premise of this series is that `*(ring->wptr_cpu_addr) =3D 0` only writ= es 32 bits because `wptr_cpu_addr` is typed as `u32 *`, while the normal re= ad/write paths use `atomic64_set()`/`atomic64_read()` which treat the same = memory as a 64-bit value. The claim that the plain store "only clears the l= ow 32 bits" is **correct** =E2=80=94 `wptr_cpu_addr` is `u32 *`, so `*wptr_= cpu_addr =3D 0` is a 32-bit store, leaving the upper 32 bits untouched. However, **the practical severity is questionable**. The write pointer (`ri= ng->wptr`) is a ring buffer offset. On a reset/suspend path, the ring is be= ing cleared entirely (`amdgpu_ring_clear_ring(ring)`), and the wptr value i= tself is typically well within 32-bit range for normal operation. The upper= 32 bits would only be non-zero after the ring has wrapped an extraordinary= number of times (past 4G entries). That said, the fix is trivially correct= =E2=80=94 using the same access width as the normal read/write paths is st= rictly better and removes a latent inconsistency. **The `rptr_cpu_addr` reset on the adjacent line has the same pattern** but= is not addressed. In `mes_v11_0` and `mes_v12_0`, `rptr_cpu_addr` is read = via `*ring->rptr_cpu_addr` (32-bit read in `ring_get_rptr`), so the 32-bit = store to rptr is at least consistent with its reader. The wptr case is diff= erent because its reader uses `atomic64_read()`. So the wptr fix is correct= ly scoped. **Verdict:** The fix is correct and consistent with the existing access pat= tern. Low practical risk but a real inconsistency. Appropriate for stable b= ackport if accepted. --- Generated by Claude Code Patch Reviewer