[PATCH v6 13/37] arm64/sme: Basic enumeration support

[Mark Brown]

On Fri, Dec 10, 2021 at 10:41:18AM +0000, Catalin Marinas wrote:
> On Thu, Dec 09, 2021 at 07:28:16PM +0000, Mark Brown wrote:

> > > > +#define HWCAP2_SME_B16F32	(1 << 25)
> > > > +#define HWCAP2_SME_F32F32	(1 << 26)
> > > > +#define HWCAP2_SME_FA64		(1 << 27)
> > 
> > > At this pace we'll need HWCAP3 pretty soon (since we only allocated
> > > 32-bit in each). I wonder whether we could instead not bother at all and
> > > just provide user-space emulation for ID_AA64SMFR0_EL1.

> > I think so if people are willing to go along with just having userspace
> > check the ID register (IIRC access to it already does the right thing
> > but I need to confirm).  We'll also need to think about how we handle
> > any new SVE features, that's got a similar thing going on and is most of
> > the existing usage of HWCAP2.

> It would be good to get feedback from the libc people. IIRC the ifunc
> resolver relies currently on the HWCAP bits. Could this be adapted to
> use the MRS instruction? We'd still keep the main HWCAP2_SME but without
> the finer-grained bits.

> The other option is to start going into the upper 32-bit of the
> elf_hwcap. We tried to avoid this some time back when we were still
> having doubts about merging ILP32.

I'll leave things as they are just now to give more time for feedback.

> > > I'll comment here rather than the patch introducing has_feature_flag():
> > > an alternative would be to add a .field_width option and in
> > > feature_matches() use cpuid_feature_extract_field_width() directly. All

> > Sure, if people are happy with that - it's a more invasive change since
> > we don't currently set the widths, I wasn't clear if that was a case of
> > not needing it right now or a design decision.

> We didn't have a field_width since they were all 4 bits until SVE. If
> you don't want to touch all the entries in the array, we can say that a
> 0 value (i.e. not explicitly initialised) means default 4 and update it
> during init_cpu_features().

It's annoying to have to update everything but it feels more idiomatic
and less likely to cause surprises later on.
-------------- 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/20211210/f07ede7f/attachment.sig>