From: Mark Brown <broonie@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 8/8] arm64/sysreg: Generate definitions for SCTLR_EL1
Date: Fri, 22 Apr 2022 13:14:51 +0100 [thread overview]
Message-ID: <YmKcO9MLbgNTfvpl@sirena.org.uk> (raw)
In-Reply-To: <YmEsZ/Ec1KubN045@FVFF77S0Q05N>
[-- Attachment #1.1: Type: text/plain, Size: 1299 bytes --]
On Thu, Apr 21, 2022 at 11:05:27AM +0100, Mark Rutland wrote:
> On Tue, Apr 19, 2022 at 11:43:29AM +0100, Mark Brown wrote:
> > Several fields which are defined in the current revision of DDI0487 but
> > which are not yet used by the kernel are left as RES1 in order to ensure
> > that the SCTLR_EL1_RES1 mask used for early initialisation of SCTLR_EL1 is
> > not changed. These are LSMAOE, nTLSMD, EIS, TSCXT and EOS.
> I think that going forward we'll hit similar issues when adding new fields, so
> we probably want to distinguish "architecturally RESx" and "The kernel wants to
> treat these as RESx".
> I suspect we should add those fields to the scripting, but (manually) add a
> definition to a header with both the architectural RES1 bits and the bits we're
> treating as RES1 even though they're now been allocated a purpose.
> I'm not sure how to name that clearly, though.
I think I'd come to a similar conclusion but as you say the naming is
annoying and in cases like these ones there's so few users and they're
oring in other bits so it might be more sensible to just or in these now
defined RES1 bits in the user, skipping out on the naming question
entirely - in this case the usage is in INIT_SCTLR_EL2_MMU_*. Looking
at it again now I'm inclined to go that way for this one.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-04-22 12:16 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-19 10:43 [PATCH v4 0/8] arm64: Automatic system register definition generation Mark Brown
2022-04-19 10:43 ` [PATCH v4 1/8] arm64/mte: Move shift from definition of TCF0 enumeration values Mark Brown
2022-04-21 9:33 ` Mark Rutland
2022-04-19 10:43 ` [PATCH v4 2/8] arm64/sysreg: Standardise ID_AA64ISAR0_EL1 macro names Mark Brown
2022-04-21 9:35 ` Mark Rutland
2022-04-19 10:43 ` [PATCH v4 3/8] arm64/sysreg: Rename SCTLR_EL1_NTWE/TWI to SCTLR_EL1_nTWE/TWI Mark Brown
2022-04-21 9:36 ` Mark Rutland
2022-04-19 10:43 ` [PATCH v4 4/8] arm64: Add sysreg header generation scripting Mark Brown
2022-04-21 9:47 ` Mark Rutland
2022-04-21 13:00 ` Mark Brown
2022-04-21 14:16 ` Mark Rutland
2022-04-21 14:50 ` Mark Brown
2022-04-21 15:35 ` Mark Rutland
2022-04-21 15:46 ` Mark Brown
2022-04-19 10:43 ` [PATCH v4 5/8] arm64/sysreg: Enable automatic generation of system register definitions Mark Brown
2022-04-21 9:52 ` Mark Rutland
2022-04-19 10:43 ` [PATCH v4 6/8] arm64/sysreg: Generate definitions for ID_AA64ISAR0_EL1 Mark Brown
2022-04-21 9:58 ` Mark Rutland
2022-04-19 10:43 ` [PATCH v4 7/8] arm64/sysreg: Generate definitions for TTBRn_EL1 Mark Brown
2022-04-21 9:59 ` Mark Rutland
2022-04-19 10:43 ` [PATCH v4 8/8] arm64/sysreg: Generate definitions for SCTLR_EL1 Mark Brown
2022-04-21 10:05 ` Mark Rutland
2022-04-22 12:14 ` Mark Brown [this message]
2022-04-22 13:42 ` Mark Rutland
2022-04-22 13:50 ` Mark Brown
2022-04-21 10:15 ` [PATCH v4 0/8] arm64: Automatic system register definition generation Mark Rutland
2022-04-21 15:14 ` Mark Brown
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=YmKcO9MLbgNTfvpl@sirena.org.uk \
--to=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=suzuki.poulose@arm.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).