[boot-wrapper PATCH 2/2] aarch64: Enable use of SME by EL2 and below

Mark Rutland mark.rutland at arm.com
Wed Feb 2 02:30:52 PST 2022


On Tue, Feb 01, 2022 at 06:22:59PM +0000, Mark Brown wrote:
> On Tue, Feb 01, 2022 at 06:16:58PM +0000, Mark Rutland wrote:
> > On Tue, Feb 01, 2022 at 05:21:32PM +0000, broonie at kernel.org wrote:
> 
> > > +#define ID_AA64SMFR0_EL1		s3_0_c0_c4_5
> > > +#define ID_AA64SMFR0_EL1_FA64		(1UL << 63)
> 
> > For consistency with the other ID fields, I'm going to make this:
> 
> >    #define ID_AA64SMFR0_EL1_FA64		BIT(63)
> 
> > In future I'd like to split the remaining definitions using shifted bits into
> > separate <register>_<field> and <register>_<field>_<value> definitions (or
> > something of that rought shape) so that field boundaries are always explicit,
> > but those can stay as-is for now.
> 
> Sure.  I was quite confused about the idioms for the use of BIT() in
> this header since it's used for for example both ID registers and SCR
> but things like the various SPSR and CPTR defines use shifts, it'd
> probably be good to just use BIT() throughout.

I generally agree, and sorry that this is a bit of a mess at present!

I'd held off converting everything to BIT() because I had planned to convert
multi-bit fields at the same time with some helper macros that I've dropped for
now to clearly separate the concept of a field of bits from the values that
field may contain.

For example, CURRENTEL_EL2 is (1 << 2), and shouldn't be converted to BIT(2),
because it is a 2-bit value 0b10 in the field bits[3:2].

That said, I'd be happy to convert all the true single-bit fields to BIT() now.

Thanks,
Mark.



More information about the linux-arm-kernel mailing list