From: Marc Zyngier <maz@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Thomas Gleixner <tglx@kernel.org>,
Ben Horgan <ben.horgan@arm.com>,
Daniel Lezcano <daniel.lezcano@linaro.org>
Subject: Re: [PATCH v2 0/5] arm64: arch_timer: Improve errata handling
Date: Sun, 26 Jul 2026 13:43:14 +0100 [thread overview]
Message-ID: <87tsplq5ul.wl-maz@kernel.org> (raw)
In-Reply-To: <amH-vUEL-SUjfa-5@willie-the-truck>
On Thu, 23 Jul 2026 12:45:01 +0100,
Will Deacon <will@kernel.org> wrote:
>
> Hi Marc,
>
> Sorry it took me so long to look at this.
No worries, thanks for having given it a look.
[...]
>
> I think this series is a definite improvement on the existing (broken)
> code, but there are two things that jump out at me with the new code:
>
> 1. If somebody uses maxcpus= on perfectly working hardware, they will
> run with the overhead of the workaround. I fear this will be
> unpopular (and I sympathise!)... I suppose we could wait for people
> to scream and then add something like a cmdline option to pinky
> promise that the late CPUs are not affected by any timer errata (we
> could presumably refuse to bring them online if they are?).
I've now added such a command-line option, forcing the counter errata
management to be disabled from boot, with a loud warning being
produced if we spot that we should have applied something.
>
> 2. It's a bit grotty that you have to maintain your own mask to track
> which CPUs have booted once. I'd have thought this information should
> exist already, although none of the existing masks I could find do
> quite what you need. One alternative would be to iterate our per-cpu
> 'cpu_data' variable or perhaps you could even use the driver's
> existing 'arch_timer_evt' variable?
Sure, that's easy enough, just slower. Not that it should matter much.
I'll post an updated series once I've retested the various
configurations.
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
prev parent reply other threads:[~2026-07-26 12:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-08 9:41 [PATCH v2 0/5] arm64: arch_timer: Improve errata handling Marc Zyngier
2026-05-08 9:41 ` [PATCH v2 1/5] clocksource/drivers/arm_arch_timer: Add a static key indicating the need for a runtime workaround Marc Zyngier
2026-05-08 9:42 ` [PATCH v2 2/5] clocksource/drivers/arm_arch_timer: Convert counter accessors to a static key alternative Marc Zyngier
2026-05-08 9:42 ` [PATCH v2 3/5] clocksource/drivers/arm_arch_timer: Drop the arch_counter_get_cnt{p,v}ct_stable() accessors Marc Zyngier
2026-05-08 9:42 ` [PATCH v2 4/5] clocksource/drivers/arm_arch_timer: Expose a direct accessor for the virtual counter Marc Zyngier
2026-05-08 9:42 ` [PATCH v2 5/5] arm64: Convert __delay_cycles() to arch_timer_read_vcounter() Marc Zyngier
2026-05-26 18:44 ` Catalin Marinas
2026-07-23 11:45 ` [PATCH v2 0/5] arm64: arch_timer: Improve errata handling Will Deacon
2026-07-26 12:43 ` Marc Zyngier [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tsplq5ul.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=ben.horgan@arm.com \
--cc=catalin.marinas@arm.com \
--cc=daniel.lezcano@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=tglx@kernel.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.