Re: [PATCH v2 3/6] arm64: HWCAP: encapsulate elf_hwcap
From: Dave P Martin <Dave.Martin@arm.com>
Date: 2019-02-21 18:45:32
On Thu, Feb 21, 2019 at 12:20:54PM +0000, Andrew Murray wrote:
The introduction of AT_HWCAP2 introduced accessors which ensure that hwcap features are set and tested appropriately. Let's now mandate access to elf_hwcap via these accessors by making elf_hwcap static within cpufeature.c.
Since elf_hwcap now survives and retains a compatible encoding for HWCAP_foo, I'm wondering whether it would be simpler to drop this patch. Although this will help push people to use the new helpers, the need to do that seems reduced now. People falling off the end of the hwcaps will discover that there is no HWCAP_foo for the feature they want, only HWCAP2_foo (but no elf_hwcap2 to look for it in), or KERNEL_HWCAP_foo (which should get them thinking). What do you think? [...]
quoted hunk ↗ jump to hunk
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c index 6a477a3..d57a179 100644 --- a/arch/arm64/kernel/cpufeature.c +++ b/arch/arm64/kernel/cpufeature.c@@ -35,8 +35,7 @@ #include <asm/traps.h> #include <asm/virt.h> -unsigned long elf_hwcap __read_mostly; -EXPORT_SYMBOL_GPL(elf_hwcap); +static unsigned long elf_hwcap __read_mostly; #ifdef CONFIG_COMPAT #define COMPAT_ELF_HWCAP_DEFAULT\@@ -1909,6 +1908,30 @@ bool this_cpu_has_cap(unsigned int n) return false; } +void cpu_set_feature(unsigned int num) +{ +WARN_ON(num >= MAX_CPU_FEATURES); +elf_hwcap |= BIT(num); +} +EXPORT_SYMBOL_GPL(cpu_set_feature); + +bool cpu_have_feature(unsigned int num) +{ +WARN_ON(num >= MAX_CPU_FEATURES); +return elf_hwcap & BIT(num); +} +EXPORT_SYMBOL_GPL(cpu_have_feature); + +unsigned long cpu_get_elf_hwcap(void) +{ +return lower_32_bits(elf_hwcap); +} + +unsigned long cpu_get_elf_hwcap2(void) +{ +return upper_32_bits(elf_hwcap); +} +
Similarly, pushing all this out of line to enable elf_hwcap to be hidden may be more effort than it is really worth (?) Cheers ---Dave IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel