[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <855dbb91-db37-4178-bd0b-511994d3aef7@sirena.org.uk>
Date: Mon, 16 Dec 2024 13:23:55 +0000
From: Mark Brown <broonie@...nel.org>
To: Mark Rutland <mark.rutland@....com>
Cc: Marc Zyngier <maz@...nel.org>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>, Peter Collingbourne <pcc@...gle.com>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
stable@...r.kernel.org
Subject: Re: [PATCH] arm64/sme: Move storage of reg_smidr to
__cpuinfo_store_cpu()
On Mon, Dec 16, 2024 at 12:44:14PM +0000, Mark Rutland wrote:
> ... didn't matter either way, and using '&boot_cpu_data' was intended to
> make it clear that the features were based on the boot CPU's info, even
> if you just grepped for that and didn't see the surrounding context.
Right, that was my best guess as to what was supposed to be going on
but it wasn't super clear. The code could use some more comments.
> I think the real fix here is to move the reading back into
> __cpuinfo_store_cpu(), but to have an explicit check that SME has been
> disabled on the commandline, with a comment explaining that this is a
> bodge for broken FW which traps the SME ID regs.
That should be doable.
There's a few other similar ID registers (eg, we already read GMID_EL1
and MPAMIDR_EL1) make me a bit nervous that we might need to generalise
it a bit, but we can deal with that if it comes up. Even for SME the
disable was added speculatively, the factors that made this come up for
SVE are less likely to be an issue with SME.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists