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

[Mark Rutland]

On Fri, Apr 22, 2022 at 01:14:51PM +0100, Mark Brown wrote:
> 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.

FWIW, I'm perfectly happy with adding those bits explicitly in the
`INIT_SCTLR_EL*` definitions. The key thing I wanted is that as a
policy, `<regname>_RES1` is purely the architecturally RES1 bits.

Thanks,
Mark.