On Tue, May 19, 2026 at 04:24:35PM +0100, Will Deacon wrote: > On Mon, May 18, 2026 at 04:07:29PM +0100, Mark Brown wrote:
> > +HWCAP3_F16F32MM > > + Functionality implied by ID_AA64ISAR0_EL1.FHM == 0b0011 > > +HWCAP3_SVE_LUT6 > > + Functionality implied by ID_AA64ISAR2_EL1.LUT == 0b0010 and > > + ID_AA64PFR0_EL1.SVE == 0b0001. > I've queued this, but I'm curious why you've called out the > 'ID_AA64PFR0_EL1.SVE == 0b0001' part here and not for any of the other > SVE caps you're adding? It was mostly due to the possibility of ID_AA64ISAR2_EL1.LUT getting a new non-SVE value, now you mention it I should go back and add the same restriction for the others due to the use of ID_AA64ZFR0_EL1 for SME only systems. It's the implemented behaviour. > It's also formatted inconsistently from > pre-existing entries (such as HWCAP2_SVE_B16B16) which put the > ID_AA64PFR0_EL1.SVE part of the antecedent first. No real reason for that, there just weren't other examples on screen at the time I was editing this.
signature.asc
Description: PGP signature
