[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <92feb0bc-18b9-438a-9567-a9059a8cb9dd@sirena.org.uk>
Date: Thu, 7 Aug 2025 18:57:26 +0100
From: Mark Brown <broonie@...nel.org>
To: Palmer Dabbelt <palmer@...belt.com>
Cc: Marc Zyngier <maz@...nel.org>,
Catalin Marinas <catalin.marinas@....com>,
Mark Rutland <mark.rutland@....com>, Will Deacon <will@...nel.org>,
oliver.upton@...ux.dev, james.morse@....com, cohuck@...hat.com,
anshuman.khandual@....com, palmerdabbelt@...a.com,
lpieralisi@...nel.org, kevin.brodsky@....com,
scott@...amperecomputing.com, james.clark@...aro.org,
yeoreum.yun@....com, joey.gouly@....com, huangxiaojia2@...wei.com,
yebin10@...wei.com, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64: Expose CPUECTLR{,2}_EL1 via sysfs
On Thu, Aug 07, 2025 at 10:26:29AM -0700, Palmer Dabbelt wrote:
> On Thu, 07 Aug 2025 01:08:26 PDT (-0700), Marc Zyngier wrote:
> > For a start, these encodings fall into the IMPDEF range. They won't
> > exist on non-ARM implementations.
> OK, and that's because it says "Provides additional IMPLEMENTATION DEFINED
> configuration and control options for the processor." at the start of the
> manual page? Sorry, I'm kind of new to trying to read the Arm specs -- I
> thought just the meaning of the values was changing, but I probably just
> didn't read enough specs.
Yes, pretty much and also because this is in a range of registers
reserved for use by the specific implementation. See DDI0487 (the ARM)
version L.a sections D23.3.2 and D24.2.162 which specify the
IMPLEMENTATION DEFINED system register range, and the definition of the
term IMPLEMENTATION DEFINED in the glossary of DDI0487. If you see a
small upper case term like that in a spec related to the architecture
then it'll have a specific architectural defintion.
> That said, part of the reason I just sent this as-is is because I was sort
> of expecting the answer to be "no" here. No big deal if that's the case, we
> can figure out some other way to solve the problem. Happy to throw some
> time in to making some more generic flavor of this, though...
It's something that does come up, working out a way to make use of the
tuning in the IMPDEF registers in a way that generic software can safely
and sensibly make use of is rather non-trivial though.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists