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/mes11: fix queue init wptr reset Date: Thu, 04 Jun 2026 13:17:09 +1000 Message-ID: In-Reply-To: <20260602050354.2237095-2-runyu.xiao@seu.edu.cn> References: <20260602050354.2237095-1-runyu.xiao@seu.edu.cn> <20260602050354.2237095-2-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 Patch Review **The change:** ```c - *(ring->wptr_cpu_addr) =3D 0; + atomic64_set((atomic64_t *)ring->wptr_cpu_addr, 0); ``` At `mes_v11_0.c:1311`, in the reset/suspend path of `mes_v11_0_queue_init()= `. **Correctness:** The fix is correct. The normal writer `mes_v11_0_ring_set_= wptr()` (line 79) uses `atomic64_set((atomic64_t *)ring->wptr_cpu_addr, rin= g->wptr)`, and the reader `mes_v11_0_ring_get_wptr()` (line 97) uses `atomi= c64_read((atomic64_t *)ring->wptr_cpu_addr)`. Using `atomic64_set()` in the= reset path makes the reset consistent with these accessors. **Fixes tag:** `Fixes: d81d75c99936 ("drm/amdgpu/gfx11: enable kiq to map m= es ring")` =E2=80=94 this identifies when the queue_init code with the plai= n store was introduced, which seems reasonable. **Minor note:** The adjacent `*(ring->rptr_cpu_addr) =3D 0` is left as a 32= -bit store, but this is fine because `mes_v11_0_ring_get_rptr()` (line 89) = reads rptr via `return *ring->rptr_cpu_addr` =E2=80=94 also a 32-bit access= =E2=80=94 so the rptr path is internally consistent at 32 bits. **No issues with this patch.** --- Generated by Claude Code Patch Reviewer