[PATCH v4 8/8] arm64/sysreg: Generate definitions for SCTLR_EL1

[Mark Brown]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20220422/21ab0d59/attachment.sig>