[PATCH v5 0/3] arm64: Start allocating upper bits of AT_HWCAP2

[Mark Brown]

Currently for arm64 we expose hwcaps to userspace using the low 32 bits
of AT_HWCAP and AT_HWCAP2. Due to the ever expanding capabilties of the
architecture we have now allocated all the available bits in this scheme
so we need to expand, either using the higher bits or adding a new
AT_HWCAP3. Discussions suggest that the favoured approach for now is to
start allocating the upper bits of AT_HWCAP2.

The final patch starts allocating from the upper bits of AT_HWCAP2,
reporting the presence of FEAT_EBF16, this will conflict with my series
converting ID_AA64ISAR1_EL1 to be generated. I've got a version based on
top of that which I can send if that's convenient.

v5:
 - Correct bit ranges for glibc reservation.
v4:
 - Document status of upper bits in AT_HWCAP.
 - Instead of creating AT_HWCAP3 just convert elf_hwcap to a bitmask and
   start allocating the upper bits of AT_HWCAP2.
v3:
 - Expand comment on CPU_FEATURES_PER_HWCAP.
v2:
 - Rebase onto v5.19-rc3.

Mark Brown (3):
  arm64/hwcap: Document allocation of upper bits of AT_HWCAP
  arm64/cpufeature: Store elf_hwcaps as a bitmap rather than unsigned
    long
  arm64/hwcap: Support FEAT_EBF16

 Documentation/arm64/elf_hwcaps.rst  |  4 ++++
 arch/arm64/include/asm/cpufeature.h |  2 +-
 arch/arm64/include/asm/hwcap.h      |  3 ++-
 arch/arm64/include/uapi/asm/hwcap.h |  4 ++++
 arch/arm64/kernel/cpufeature.c      | 13 ++++++-------
 arch/arm64/kernel/cpuinfo.c         |  1 +
 6 files changed, 18 insertions(+), 9 deletions(-)


base-commit: a111daf0c53ae91e71fd2bfe7497862d14132e3e
-- 
2.30.2