[PATCH v2 1/2] arm64/cpufeature: Define hwcaps for 2025 dpISA features
Mark Brown
broonie at kernel.org
Tue May 19 09:03:58 PDT 2026
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.
-------------- 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/20260519/7835aaa5/attachment.sig>
More information about the linux-arm-kernel
mailing list