From nobody Mon Feb 9 17:23:24 2026 Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com [209.85.216.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0146130F541 for ; Sat, 3 Jan 2026 15:24:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.52 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767453878; cv=none; b=QOE5uKeuQF0GNPcdaAGAQZZ5XjWzEaK6wvSqsffIWYkI4iR5N8a6dX97KwDhW+cz9smAoBcftW0K0kG8Cv8mbAOqXXwQNYFL4NJd7CG1+Vyw1GoItfu+U95+dVr/bSyoGi+HRmw4J2qYUP7O7wVgKuGUkccJu7XH9cWbVsJ5LRU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767453878; c=relaxed/simple; bh=lerh5EnUg1JN1+T9TQ7JGXjzP1VBU6OTyUVU6U9a5lc=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=ux9BC6MW5bi4i8SH5T3jbg3CdnZm3lR14OegLEb5jXhJamb08VpngWGM097ryLxe5CIlsmd9NpYZ51wk3S8Ag/C4ZEOIGsT1+VQ+uyH7q1Yvj/0LcTVR6Tdxo0rWdMthVDYdP1P/1nIo8Gf7hOzmBNTjQSnYjzfpvigIVVXG1E4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=baUsal5h; arc=none smtp.client-ip=209.85.216.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="baUsal5h" Received: by mail-pj1-f52.google.com with SMTP id 98e67ed59e1d1-34c71f462d2so13569852a91.0 for ; Sat, 03 Jan 2026 07:24:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767453876; x=1768058676; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=N9tqN72DnRW3gbfss4TAn1MPl/pI0d3sx5WMZWESXiU=; b=baUsal5hsBy/2twCB/J+qUlYpV9Gjlbl06RonL4S9565MRW+p4A+iJDeQZ+AY7vDtP ToW7sKM7+zQzgUJ0Lh5zoSrocW27+qtaV/JNp6h9uNK/Lp+MZhhkHfBWHZvTBKJWRsYK m3HQ1gNTreW0YdqyFHoh/3ZPtuOv9PhzRlz71Hr5sSh4XVmKFdPHABfV6wPZkN4E1obC 6betHwytjsj1EjOcKEc3Tkq9XwZK8844wA/gvCH/LzCSDQPp5wSjWrXgXpr34JJsiVGn cKLpR9RgguM1MSssnE74rXxKLCARW/uILDJfi/3ppn4AllqpU8dt1rolG7uvGTs6Pf+E K93g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767453876; x=1768058676; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=N9tqN72DnRW3gbfss4TAn1MPl/pI0d3sx5WMZWESXiU=; b=Aouow7g/xpl5qFaN0Ile/z51z+aejYH429uikGN9mPAsLU1LkEFT4o5edIrZMS9Msl 1runKYZC5XVo3CLfljLJyZmkYBWen9omAqrw77MuXshQkjIB49c0H2S/MVl4xorDNdSr Ruw9kHz0WhkAHCVlAyZ85HRu5PM4Y6duITPq+mfSYWSfrr/zFkgMxAL69xmnz+FDCoSM drGfR2Tg/W7KVclAFfnH1utBbpUIN1lgeUkJl9Q6cOohGOeBjL1WyigXYxGTx9U0uWqx dpByThQhkoT1XIlYp6K1djr1wwRvzxSoTUQlm9LTPuG8zu16s2PTbA7kG1X5XMrrNdjv JGig== X-Forwarded-Encrypted: i=1; AJvYcCVkrjBUqkQeOZiYX45pLLL8AQi93X9l+OunqbwNk9zdURJFD6ndsrHocKbLwoBQeYNuNC/UUkKd8eDY8Aw=@vger.kernel.org X-Gm-Message-State: AOJu0Yx8VlhKJjmNwLa8bTEzFPEIEPC4LqXIOpZLiHf8YdPJLsd03FvJ yl72S/UIZfb1ctbheYOF3sz1m69yrgcORW6DPR+C1TYWZHKFwI5KzenY X-Gm-Gg: AY/fxX4vBHrEGQppTHm4AXdjKsJVDTmKShk2RvfraYYSGQr+WiF/4Sj2/JWq88WoftP E18Ms3wSKSyHTzVtBSU0pR2yJCnIXjKWdNlG7pRon8Cx6a1NpBNny0bTCtck0VEGbaIqbEDuLNU BziIwKOp//4V9Rm4Uh1bcUB47xXdS9IlsD444hY1MrQAinAufBuDCgda/WnE5SfN9A5P//KiSWa yURuS2idz66dBBLbqI8ict2wZ1IY4HCcaJUYLrH+C5V1cK5mme/1NvlBC0KXGiwCHewKCHCZxSF S/Nx+erqZFYb7y+2AVUSul9EjzhyruZjWxIo6nlJCSxR+jCCAENxfbWrF2x5L8jgpCu/W3U45wn TBufkvqQNAnWDAcpmD0bJ7Jbw4pKvLGDVPVmiU9y8iu1QC+tDCfeKWdysTdRq9ER2JGyropLrEf WSJo+0c7tQQ4klr2aRojPiDT4Z8N0Qv/t8I0Ro0aMaQtpMEzgFj5Lzb4cYmN98Mp0KgIDCDQVnv JI= X-Google-Smtp-Source: AGHT+IHlInhhJ3xFCCOgA3SiqoyGe4GrNPNHAy5HiMlXuyqZ/J0ImxaOeRtEIO78Zh6IdYlfYS5myw== X-Received: by 2002:a17:90b:54c8:b0:340:b908:9665 with SMTP id 98e67ed59e1d1-34e921ed466mr39711928a91.37.1767453876082; Sat, 03 Jan 2026 07:24:36 -0800 (PST) Received: from localhost.localdomain (123-48-16-240.area55c.commufa.jp. [123.48.16.240]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-34f4770a256sm2107802a91.12.2026.01.03.07.24.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 03 Jan 2026 07:24:35 -0800 (PST) From: Naohiko Shimizu To: pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu Cc: alex@ghiti.fr, anup@brainfault.org, atish.patra@linux.dev, daniel.lezcano@linaro.org, tglx@linutronix.de, nick.hu@sifive.com, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, kvm-riscv@lists.infradead.org, Naohiko Shimizu Subject: [PATCH v2 3/3] riscv: suspend: Fix stimecmp update hazard on RV32 Date: Sun, 4 Jan 2026 00:24:00 +0900 Message-Id: <20260103152400.552-4-naohiko.shimizu@gmail.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260103152400.552-1-naohiko.shimizu@gmail.com> References: <20260103152400.552-1-naohiko.shimizu@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Signed-off-by: Naohiko Shimizu riscv: fix timer register update hazard on RV32 On RV32, updating the 64-bit stimecmp (or vstimecmp) CSR requires two separate 32-bit writes. A race condition exists if the timer triggers during these two writes. The RISC-V Privileged Specification (e.g., Section 3.2.1 for mtimecmp) recommends a specific 3-step sequence to avoid spurious interrupts when updating 64-bit comparison registers on 32-bit systems: 1. Set the low-order bits (stimecmp) to all ones (ULONG_MAX). 2. Set the high-order bits (stimecmph) to the desired value. 3. Set the low-order bits (stimecmp) to the desired value. Current implementation writes the LSB first without ensuring a future value, which may lead to a transient state where the 64-bit comparison is incorrectly evaluated as "expired" by the hardware. This results in spurious timer interrupts. This patch adopts the spec-recommended 3-step sequence to ensure the intermediate 64-bit state is never smaller than the current time. --- arch/riscv/kernel/suspend.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/riscv/kernel/suspend.c b/arch/riscv/kernel/suspend.c index 24b3f57d467f..aff93090c4ef 100644 --- a/arch/riscv/kernel/suspend.c +++ b/arch/riscv/kernel/suspend.c @@ -51,10 +51,11 @@ void suspend_restore_csrs(struct suspend_context *conte= xt) =20 #ifdef CONFIG_MMU if (riscv_has_extension_unlikely(RISCV_ISA_EXT_SSTC)) { - csr_write(CSR_STIMECMP, context->stimecmp); #if __riscv_xlen < 64 + csr_write(CSR_STIMECMP, ULONG_MAX); csr_write(CSR_STIMECMPH, context->stimecmph); #endif + csr_write(CSR_STIMECMP, context->stimecmp); } =20 csr_write(CSR_SATP, context->satp); --=20 2.39.5