[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