Re: [PATCH v5 2/3] arm64/cpufeature: Store elf_hwcaps as a bitmap rather than unsigned long

From: Mark Brown <broonie@kernel.org>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Szabolcs Nagy <szabolcs.nagy@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5 2/3] arm64/cpufeature: Store elf_hwcaps as a bitmap rather than unsigned long
Date: Thu, 7 Jul 2022 12:52:37 +0100	[thread overview]
Message-ID: <YsbJBbKvIdEL33Mz@sirena.org.uk> (raw)
In-Reply-To: <YsbFlqxpMJ+tv90k@arm.com>

[-- Attachment #1.1: Type: text/plain, Size: 1016 bytes --]

On Thu, Jul 07, 2022 at 12:37:58PM +0100, Catalin Marinas wrote:
> On Thu, Jul 07, 2022 at 11:36:31AM +0100, Mark Brown wrote:

> > -#define MAX_CPU_FEATURES	64
> > +#define MAX_CPU_FEATURES	128

> Should this be (32 + 64)? I guess it's easier as you did since we have
> 128 bits in total, only that we reserved the top 32 in ELF_HWCAP.

We need to have the full 64 bits allocated for AT_HWCAP storage even if
nothing uses the top 32 so that we can return the elements in the array,
otherwise we need logic for fishing variably sized silces of bits out of
the bitmap which seems more trouble than it's worth.

> >  unsigned long cpu_get_elf_hwcap2(void)
> >  {
> > -	return upper_32_bits(elf_hwcap);
> > +	return elf_hwcap[1];
> >  }

> This is fine on the assumption that DECLARE_BITMAP is always an array of
> longs. I couldn't see any documentation on this but at least the
> set_bit() etc. API only works on 'long *' pointers.

If someone changes DECLARE_BITMAP() they're going to have to be very,
very careful.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel