This series fixes two MES queue-init reset paths that still clear
ring->wptr_cpu_addr with a plain 32-bit store even though the same
carrier is accessed with atomic64_set()/atomic64_read() and
support_64bit_ptrs is enabled.

This is not just a missing atomic annotation. The write pointer carrier
is used as a shared 64-bit value, so a plain *ring->wptr_cpu_addr = 0
only clears the low 32 bits. A later atomic64_read() can then observe
stale high 32 bits instead of a real zeroed reset state.

Use atomic64_set((atomic64_t *)ring->wptr_cpu_addr, 0) in both reset
paths so the full 64-bit MES wptr is cleared with the same access
family as the existing readers and writers.

This issue was first flagged by our static analysis tool while scanning
for 64-bit atomic write pointer carriers mixed with plain reset stores,
then manually audited on Linux v6.18.21.

It was further confirmed with a QEMU no-device stand-in that preserved
the same access contract: atomic64_set() write, plain low-32 reset, and
atomic64_read() readback. In that stand-in, a buggy reset turned
0x12345678abcdeff0 into 0x1234567800000000, while replacing the reset
with atomic64_set(..., 0) read back 0x0.

Build-tested by compiling mes_v11_0.o and mes_v12_0.o.

No AMDGPU hardware was available for end-to-end runtime testing.

Runyu Xiao (2):
  drm/amdgpu/mes11: fix queue init wptr reset
  drm/amdgpu/mes12: fix queue init wptr reset

 drivers/gpu/drm/amd/amdgpu/mes_v11_0.c | 2 +-
 drivers/gpu/drm/amd/amdgpu/mes_v12_0.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.34.1