From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 132173A9D8E for ; Fri, 8 May 2026 09:42:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778233331; cv=none; b=jXndDsNHhPx27BLDI98uDo5RW0yCpOn0KfYD+rZiCc0LOmnYsBWiBNqhTWnEf9APqljJU6s2O+06WYlyxK2VQ9rlT4E25fm/+3VvcP4f/quHpb5XAMLZTMaanGynKaRfzzH9SbAURIkiO9YSeg2OHxyZWk1A9vRT79d8UywfoX4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778233331; c=relaxed/simple; bh=8nT2QL41qh0YTYDMx9toL1jPyGWMqS0ony+FQLtS8nQ=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=Rk7zFx1BPgOtwBr13P49s8a23NlrsUZY5X65UQVvjhG3SVao2ERJAp7doUDrF/n8bZS7f/ezHmtvYzZpq6wmT/JKMvk6YcQZ680h3iEfoRxtERn2nWDU//PEVjjK+hem/DPmJw8jBUDqDxKjKuCsRAsWR5NumqT67BYj9s5/e5o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XcgpXcpP; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="XcgpXcpP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B8E0DC2BCB8; Fri, 8 May 2026 09:42:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778233330; bh=8nT2QL41qh0YTYDMx9toL1jPyGWMqS0ony+FQLtS8nQ=; h=From:To:Cc:Subject:Date:From; b=XcgpXcpPX5aeSI3/qV2Ym8owffrov2WvneHX/k1RFUq6nvOoBUyuuOb6ewwjRd9c9 PVM7KGv9qcb5NPjJEGKcZU6AK7FozBUQKZgySc+CvLXZs1gdQdGx0g04jNuAwGvkS1 AJFjVEWjHWFk4iksqNdJvBo/JNimYsshM5vH2qz7qEdgPLAIwZwgqyFq4cl/EmzyNe fGhfV4uUrAxZlZPJryo1sZHOpPLwPwdAxJzgSe8AJExaNrqu2KS8EnSFE4X/izSKa3 CC3lWJSRJTgQiN9Rdo0xH1o83PblbsSxTw7GJB43Lp73ufYpoqXG4dOMTSbOnf9DOp AG1/cZmNrKGOg== Received: from sofa.misterjones.org ([185.219.108.64] helo=valley-girl.lan) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wLHii-00000000HJz-233y; Fri, 08 May 2026 09:42:08 +0000 From: Marc Zyngier To: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Cc: Catalin Marinas , Will Deacon , Mark Rutland , Thomas Gleixner , Ben Horgan , Daniel Lezcano Subject: [PATCH v2 0/5] arm64: arch_timer: Improve errata handling Date: Fri, 8 May 2026 10:41:58 +0100 Message-ID: <20260508094203.2913880-1-maz@kernel.org> X-Mailer: git-send-email 2.47.3 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com, tglx@kernel.org, ben.horgan@arm.com, daniel.lezcano@linaro.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false This is the second version of this series addressing a couple of embarrassing bugs in the prolific arm64 timer errata handling department. Nothing changed since v1, which didn't get much traction, so this is only a rebase. Time is hard. Timers are harder. As a consequence, we have plenty of broken counter/timer implementations in the wild, and an infrastructure to deal with them. However, what we have today suffers from a number of issues: - if, on an heterogeneous system, affected CPUs are secondaries, we do record their broken state but don't correct anything - we always play games with preemption in order to access per-CPU state, irrespective of the presence of broken CPUs I hear someone saying "just use a static key to enable the errata and be done with it". Good call, except that we need to do that from a CPUHP callback, and that's deadlock central. We can't do it later, because this could affect the CPU before the workaround is enabled. However, not everything is lost if we turn the logic on its head: - always start with the mitigations enabled, even if we don't know of any affected CPU - once all CPUs have been seen once, and that we still haven't enabled any workaround, disable the mitigations globally. With that, a normal kernel boot with all CPUs will quickly switch to no mitigation on decent HW. If you're booting with CPUs disabled, this will only kick in once you have booted them all. Patches on top of 7.1-rc2. Marc Zyngier (5): clocksource/drivers/arm_arch_timer: Add a static key indicating the need for a runtime workaround clocksource/drivers/arm_arch_timer: Convert counter accessors to a static key alternative clocksource/drivers/arm_arch_timer: Drop the arch_counter_get_cnt{p,v}ct_stable() accessors clocksource/drivers/arm_arch_timer: Expose a direct accessor for the virtual counter arm64: Convert __delay_cycles() to arch_timer_read_vcounter() arch/arm64/lib/delay.c | 5 +- drivers/clocksource/arm_arch_timer.c | 99 +++++++++++++++++----------- include/clocksource/arm_arch_timer.h | 1 + 3 files changed, 64 insertions(+), 41 deletions(-) -- 2.47.3