From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Martin Subject: Re: [PATCH v3 2/7] arm64: HWCAP: add support for AT_HWCAP2 Date: Tue, 2 Apr 2019 15:58:31 +0100 Message-ID: <20190402145831.GI3567@e103592.cambridge.arm.com> References: <20190401104515.39775-1-andrew.murray@arm.com> <20190401104515.39775-3-andrew.murray@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20190401104515.39775-3-andrew.murray@arm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Andrew Murray Cc: Mark Rutland , libc-alpha@sourceware.org, Szabolcs Nagy , Catalin Marinas , Will Deacon , Phil Blundell , linux-api@vger.kernel.org, linux-arm-kernel@lists.infradead.org List-Id: linux-api@vger.kernel.org On Mon, Apr 01, 2019 at 11:45:10AM +0100, Andrew Murray wrote: > As we will exhaust the first 32 bits of AT_HWCAP let's start > exposing AT_HWCAP2 to userspace to give us up to 64 caps. > > Whilst it's possible to use the remaining 32 bits of AT_HWCAP, we > prefer to expand into AT_HWCAP2 in order to provide a consistent > view to userspace between ILP32 and LP64. However internal to the > kernel we prefer to continue to use the full space of elf_hwcap. > > To reduce complexity and allow for future expansion, we now > represent hwcaps in the kernel as ordinals and use a > KERNEL_HWCAP_ prefix. This allows us to support automatic feature > based module loading for all our hwcaps. > > We introduce cpu_set_feature to set hwcaps which compliments the Nit: maybe "complements"? (I've always been a bit fuzzy on the precise distinction, though.) > existing cpu_have_feature helper. These helpers allow us to clean > up existing direct uses of elf_hwcap and reduce any future effort > required to move beyond 64 caps. > > For convenience we also introduce cpu_{have,set}_named_feature which > makes use of the cpu_feature macro to allow providing a hwcap name > without a {KERNEL_}HWCAP_ prefix. > > Signed-off-by: Andrew Murray > --- > arch/arm64/crypto/aes-ce-ccm-glue.c | 2 +- > arch/arm64/crypto/aes-neonbs-glue.c | 2 +- > arch/arm64/crypto/chacha-neon-glue.c | 2 +- > arch/arm64/crypto/crct10dif-ce-glue.c | 4 +- > arch/arm64/crypto/ghash-ce-glue.c | 8 +-- > arch/arm64/crypto/nhpoly1305-neon-glue.c | 2 +- > arch/arm64/crypto/sha256-glue.c | 4 +- > arch/arm64/include/asm/cpufeature.h | 22 ++++---- > arch/arm64/include/asm/hwcap.h | 49 +++++++++++++++++- > arch/arm64/include/uapi/asm/hwcap.h | 2 +- > arch/arm64/kernel/cpufeature.c | 66 ++++++++++++------------ > arch/arm64/kernel/cpuinfo.c | 2 +- > arch/arm64/kernel/fpsimd.c | 4 +- > drivers/clocksource/arm_arch_timer.c | 8 +++ > 14 files changed, 117 insertions(+), 60 deletions(-) > [...] > diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h > index e505e1fbd2b9..f06e1da1d678 100644 > --- a/arch/arm64/include/asm/cpufeature.h > +++ b/arch/arm64/include/asm/cpufeature.h > @@ -14,15 +14,8 @@ > #include > #include > > -/* > - * In the arm64 world (as in the ARM world), elf_hwcap is used both internally > - * in the kernel and for user space to keep track of which optional features > - * are supported by the current system. So let's map feature 'x' to HWCAP_x. > - * Note that HWCAP_x constants are bit fields so we need to take the log. > - */ > - > -#define MAX_CPU_FEATURES (8 * sizeof(elf_hwcap)) > -#define cpu_feature(x) ilog2(HWCAP_ ## x) > +#define MAX_CPU_FEATURES 64 > +#define cpu_feature(x) (KERNEL_HWCAP_ ## x) Nit: do we need the () here? They may be defensive, but I'm not sure they're required. [...] > diff --git a/arch/arm64/include/asm/hwcap.h b/arch/arm64/include/asm/hwcap.h > index 400b80b49595..d21fe3314d90 100644 > --- a/arch/arm64/include/asm/hwcap.h > +++ b/arch/arm64/include/asm/hwcap.h > @@ -39,12 +39,59 @@ > #define COMPAT_HWCAP2_SHA2 (1 << 3) > #define COMPAT_HWCAP2_CRC32 (1 << 4) > > +/* > + * For userspace we represent hwcaps as a collection of HWCAP{,2}_x bitfields > + * as described in uapi/asm/hwcap.h. For the kernel we represent hwcaps as > + * natural numbers (in a single range of size MAX_CPU_FEATURES) defined here > + * with prefix KERNEL_HWCAP_ mapped to their HWCAP{,2}_x counterpart. > + * > + * Hwcaps should be set and tested within the kernel via the > + * cpu_{set,have}_named_feature(feature) where feature is the unique suffix > + * of KERNEL_HWCAP_{feature}. > + */ > +#define KERNEL_HWCAP_FP ilog2(HWCAP_FP) > +#define KERNEL_HWCAP_ASIMD ilog2(HWCAP_ASIMD) > +#define KERNEL_HWCAP_EVTSTRM ilog2(HWCAP_EVTSTRM) > +#define KERNEL_HWCAP_AES ilog2(HWCAP_AES) > +#define KERNEL_HWCAP_PMULL ilog2(HWCAP_PMULL) > +#define KERNEL_HWCAP_SHA1 ilog2(HWCAP_SHA1) > +#define KERNEL_HWCAP_SHA2 ilog2(HWCAP_SHA2) > +#define KERNEL_HWCAP_CRC32 ilog2(HWCAP_CRC32) > +#define KERNEL_HWCAP_ATOMICS ilog2(HWCAP_ATOMICS) > +#define KERNEL_HWCAP_FPHP ilog2(HWCAP_FPHP) > +#define KERNEL_HWCAP_ASIMDHP ilog2(HWCAP_ASIMDHP) > +#define KERNEL_HWCAP_CPUID ilog2(HWCAP_CPUID) > +#define KERNEL_HWCAP_ASIMDRDM ilog2(HWCAP_ASIMDRDM) > +#define KERNEL_HWCAP_JSCVT ilog2(HWCAP_JSCVT) > +#define KERNEL_HWCAP_FCMA ilog2(HWCAP_FCMA) > +#define KERNEL_HWCAP_LRCPC ilog2(HWCAP_LRCPC) > +#define KERNEL_HWCAP_DCPOP ilog2(HWCAP_DCPOP) > +#define KERNEL_HWCAP_SHA3 ilog2(HWCAP_SHA3) > +#define KERNEL_HWCAP_SM3 ilog2(HWCAP_SM3) > +#define KERNEL_HWCAP_SM4 ilog2(HWCAP_SM4) > +#define KERNEL_HWCAP_ASIMDDP ilog2(HWCAP_ASIMDDP) > +#define KERNEL_HWCAP_SHA512 ilog2(HWCAP_SHA512) > +#define KERNEL_HWCAP_SVE ilog2(HWCAP_SVE) > +#define KERNEL_HWCAP_ASIMDFHM ilog2(HWCAP_ASIMDFHM) > +#define KERNEL_HWCAP_DIT ilog2(HWCAP_DIT) > +#define KERNEL_HWCAP_USCAT ilog2(HWCAP_USCAT) > +#define KERNEL_HWCAP_ILRCPC ilog2(HWCAP_ILRCPC) > +#define KERNEL_HWCAP_FLAGM ilog2(HWCAP_FLAGM) > +#define KERNEL_HWCAP_SSBS ilog2(HWCAP_SSBS) > +#define KERNEL_HWCAP_SB ilog2(HWCAP_SB) > +#define KERNEL_HWCAP_PACA ilog2(HWCAP_PACA) > +#define KERNEL_HWCAP_PACG ilog2(HWCAP_PACG) > +#define KERNEL_HWCAP_DCPODP (ilog2(HWCAP2_DCPODP) + 32) Nit: can we wrap this so that the "+ 32" doesn't have to be spelled out each time? If we are splitting ths CVADP support from this patch, then dropping such a wrapper macro here (maybe with a comment) will serve as a placeholder for whichever patch wins the race for the first HWCAP2 flag. Say #define __khwcap2_feature(x) (ilog2(HWCAP2_ ## xx) + 32) (Optionally, we could also have __khwcap_feature() too so that everything looks nice and regular.) [...] > diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c > index aa4ec53281ce..6cc8aff83805 100644 > --- a/drivers/clocksource/arm_arch_timer.c > +++ b/drivers/clocksource/arm_arch_timer.c > @@ -833,7 +833,11 @@ static void arch_timer_evtstrm_enable(int divider) > cntkctl |= (divider << ARCH_TIMER_EVT_TRIGGER_SHIFT) > | ARCH_TIMER_VIRT_EVT_EN; > arch_timer_set_cntkctl(cntkctl); > +#ifdef CONFIG_ARM64 > + cpu_set_named_feature(EVTSTRM); > +#else > elf_hwcap |= HWCAP_EVTSTRM; > +#endif I wonder whether we can have a generic definition for this: #define cpu_set_named_feature(x) (elf_hwcap |= HWCAP_ ## x) seems a reasonable fallback when the arch doesn't provide its own version. Although we don't have many instances, it would still be nice to avoid ifdeffery creeping in. [...] We can probably pull the Documentation/arm64/elf_hwcaps.txt changes into this patch. It probably makes sense to pull the Documentation/arm64/elf_hwcaps.txt updates alongside this patch in the series (or even incorporate them into this patch, since they're not huge.) Other than that, looks reasonable to me. Cheers ---Dave From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E7F6EC10F00 for ; Tue, 2 Apr 2019 14:58:45 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B819A204EC for ; Tue, 2 Apr 2019 14:58:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="KV31BQIn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B819A204EC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=0c/6JcJTXqHyGWxbIpTF+qXgcoRXYiMchF+TeMAGk0s=; b=KV31BQIniVGa3c vHVKfSr1R2jJM3Yj1yOjo3ZgwSAPblh5rMAMSWJG7audaQNGeBJ2fYtBoK/TZewbqyBWM9v6xwB2z pqEkvLU7TO9lu+5GIyZRgdj6ko2mwjNl2ixoQxRUfZpzouKiWsAolvHrpV9/qN+yHTDkvTllWjDPe Tb8mB8vnX05rfC7P3/lOsRV3uizP36tGXhdCUTM2tp9T9YwEcIX9pfpRCY5xj2TnxSxL5IK+of3Ot ao6bq7zZDcVaqm+jeOR2cjATz62iOWuZTjbMi7HjUnn8jvwx7id1tH+Sr+klOpF7rYtP4GfW7o56o TjHTcgSzV2ajo1rNS7RA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hBKs4-0008Sa-21; Tue, 02 Apr 2019 14:58:40 +0000 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70] helo=foss.arm.com) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hBKrz-0008P3-U1 for linux-arm-kernel@lists.infradead.org; Tue, 02 Apr 2019 14:58:38 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C9672374; Tue, 2 Apr 2019 07:58:35 -0700 (PDT) Received: from e103592.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 290E13F721; Tue, 2 Apr 2019 07:58:34 -0700 (PDT) Date: Tue, 2 Apr 2019 15:58:31 +0100 From: Dave Martin To: Andrew Murray Subject: Re: [PATCH v3 2/7] arm64: HWCAP: add support for AT_HWCAP2 Message-ID: <20190402145831.GI3567@e103592.cambridge.arm.com> References: <20190401104515.39775-1-andrew.murray@arm.com> <20190401104515.39775-3-andrew.murray@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190401104515.39775-3-andrew.murray@arm.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190402_075835_991799_49CB78F9 X-CRM114-Status: GOOD ( 28.99 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , libc-alpha@sourceware.org, Szabolcs Nagy , Catalin Marinas , Will Deacon , Phil Blundell , linux-api@vger.kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Apr 01, 2019 at 11:45:10AM +0100, Andrew Murray wrote: > As we will exhaust the first 32 bits of AT_HWCAP let's start > exposing AT_HWCAP2 to userspace to give us up to 64 caps. > > Whilst it's possible to use the remaining 32 bits of AT_HWCAP, we > prefer to expand into AT_HWCAP2 in order to provide a consistent > view to userspace between ILP32 and LP64. However internal to the > kernel we prefer to continue to use the full space of elf_hwcap. > > To reduce complexity and allow for future expansion, we now > represent hwcaps in the kernel as ordinals and use a > KERNEL_HWCAP_ prefix. This allows us to support automatic feature > based module loading for all our hwcaps. > > We introduce cpu_set_feature to set hwcaps which compliments the Nit: maybe "complements"? (I've always been a bit fuzzy on the precise distinction, though.) > existing cpu_have_feature helper. These helpers allow us to clean > up existing direct uses of elf_hwcap and reduce any future effort > required to move beyond 64 caps. > > For convenience we also introduce cpu_{have,set}_named_feature which > makes use of the cpu_feature macro to allow providing a hwcap name > without a {KERNEL_}HWCAP_ prefix. > > Signed-off-by: Andrew Murray > --- > arch/arm64/crypto/aes-ce-ccm-glue.c | 2 +- > arch/arm64/crypto/aes-neonbs-glue.c | 2 +- > arch/arm64/crypto/chacha-neon-glue.c | 2 +- > arch/arm64/crypto/crct10dif-ce-glue.c | 4 +- > arch/arm64/crypto/ghash-ce-glue.c | 8 +-- > arch/arm64/crypto/nhpoly1305-neon-glue.c | 2 +- > arch/arm64/crypto/sha256-glue.c | 4 +- > arch/arm64/include/asm/cpufeature.h | 22 ++++---- > arch/arm64/include/asm/hwcap.h | 49 +++++++++++++++++- > arch/arm64/include/uapi/asm/hwcap.h | 2 +- > arch/arm64/kernel/cpufeature.c | 66 ++++++++++++------------ > arch/arm64/kernel/cpuinfo.c | 2 +- > arch/arm64/kernel/fpsimd.c | 4 +- > drivers/clocksource/arm_arch_timer.c | 8 +++ > 14 files changed, 117 insertions(+), 60 deletions(-) > [...] > diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h > index e505e1fbd2b9..f06e1da1d678 100644 > --- a/arch/arm64/include/asm/cpufeature.h > +++ b/arch/arm64/include/asm/cpufeature.h > @@ -14,15 +14,8 @@ > #include > #include > > -/* > - * In the arm64 world (as in the ARM world), elf_hwcap is used both internally > - * in the kernel and for user space to keep track of which optional features > - * are supported by the current system. So let's map feature 'x' to HWCAP_x. > - * Note that HWCAP_x constants are bit fields so we need to take the log. > - */ > - > -#define MAX_CPU_FEATURES (8 * sizeof(elf_hwcap)) > -#define cpu_feature(x) ilog2(HWCAP_ ## x) > +#define MAX_CPU_FEATURES 64 > +#define cpu_feature(x) (KERNEL_HWCAP_ ## x) Nit: do we need the () here? They may be defensive, but I'm not sure they're required. [...] > diff --git a/arch/arm64/include/asm/hwcap.h b/arch/arm64/include/asm/hwcap.h > index 400b80b49595..d21fe3314d90 100644 > --- a/arch/arm64/include/asm/hwcap.h > +++ b/arch/arm64/include/asm/hwcap.h > @@ -39,12 +39,59 @@ > #define COMPAT_HWCAP2_SHA2 (1 << 3) > #define COMPAT_HWCAP2_CRC32 (1 << 4) > > +/* > + * For userspace we represent hwcaps as a collection of HWCAP{,2}_x bitfields > + * as described in uapi/asm/hwcap.h. For the kernel we represent hwcaps as > + * natural numbers (in a single range of size MAX_CPU_FEATURES) defined here > + * with prefix KERNEL_HWCAP_ mapped to their HWCAP{,2}_x counterpart. > + * > + * Hwcaps should be set and tested within the kernel via the > + * cpu_{set,have}_named_feature(feature) where feature is the unique suffix > + * of KERNEL_HWCAP_{feature}. > + */ > +#define KERNEL_HWCAP_FP ilog2(HWCAP_FP) > +#define KERNEL_HWCAP_ASIMD ilog2(HWCAP_ASIMD) > +#define KERNEL_HWCAP_EVTSTRM ilog2(HWCAP_EVTSTRM) > +#define KERNEL_HWCAP_AES ilog2(HWCAP_AES) > +#define KERNEL_HWCAP_PMULL ilog2(HWCAP_PMULL) > +#define KERNEL_HWCAP_SHA1 ilog2(HWCAP_SHA1) > +#define KERNEL_HWCAP_SHA2 ilog2(HWCAP_SHA2) > +#define KERNEL_HWCAP_CRC32 ilog2(HWCAP_CRC32) > +#define KERNEL_HWCAP_ATOMICS ilog2(HWCAP_ATOMICS) > +#define KERNEL_HWCAP_FPHP ilog2(HWCAP_FPHP) > +#define KERNEL_HWCAP_ASIMDHP ilog2(HWCAP_ASIMDHP) > +#define KERNEL_HWCAP_CPUID ilog2(HWCAP_CPUID) > +#define KERNEL_HWCAP_ASIMDRDM ilog2(HWCAP_ASIMDRDM) > +#define KERNEL_HWCAP_JSCVT ilog2(HWCAP_JSCVT) > +#define KERNEL_HWCAP_FCMA ilog2(HWCAP_FCMA) > +#define KERNEL_HWCAP_LRCPC ilog2(HWCAP_LRCPC) > +#define KERNEL_HWCAP_DCPOP ilog2(HWCAP_DCPOP) > +#define KERNEL_HWCAP_SHA3 ilog2(HWCAP_SHA3) > +#define KERNEL_HWCAP_SM3 ilog2(HWCAP_SM3) > +#define KERNEL_HWCAP_SM4 ilog2(HWCAP_SM4) > +#define KERNEL_HWCAP_ASIMDDP ilog2(HWCAP_ASIMDDP) > +#define KERNEL_HWCAP_SHA512 ilog2(HWCAP_SHA512) > +#define KERNEL_HWCAP_SVE ilog2(HWCAP_SVE) > +#define KERNEL_HWCAP_ASIMDFHM ilog2(HWCAP_ASIMDFHM) > +#define KERNEL_HWCAP_DIT ilog2(HWCAP_DIT) > +#define KERNEL_HWCAP_USCAT ilog2(HWCAP_USCAT) > +#define KERNEL_HWCAP_ILRCPC ilog2(HWCAP_ILRCPC) > +#define KERNEL_HWCAP_FLAGM ilog2(HWCAP_FLAGM) > +#define KERNEL_HWCAP_SSBS ilog2(HWCAP_SSBS) > +#define KERNEL_HWCAP_SB ilog2(HWCAP_SB) > +#define KERNEL_HWCAP_PACA ilog2(HWCAP_PACA) > +#define KERNEL_HWCAP_PACG ilog2(HWCAP_PACG) > +#define KERNEL_HWCAP_DCPODP (ilog2(HWCAP2_DCPODP) + 32) Nit: can we wrap this so that the "+ 32" doesn't have to be spelled out each time? If we are splitting ths CVADP support from this patch, then dropping such a wrapper macro here (maybe with a comment) will serve as a placeholder for whichever patch wins the race for the first HWCAP2 flag. Say #define __khwcap2_feature(x) (ilog2(HWCAP2_ ## xx) + 32) (Optionally, we could also have __khwcap_feature() too so that everything looks nice and regular.) [...] > diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c > index aa4ec53281ce..6cc8aff83805 100644 > --- a/drivers/clocksource/arm_arch_timer.c > +++ b/drivers/clocksource/arm_arch_timer.c > @@ -833,7 +833,11 @@ static void arch_timer_evtstrm_enable(int divider) > cntkctl |= (divider << ARCH_TIMER_EVT_TRIGGER_SHIFT) > | ARCH_TIMER_VIRT_EVT_EN; > arch_timer_set_cntkctl(cntkctl); > +#ifdef CONFIG_ARM64 > + cpu_set_named_feature(EVTSTRM); > +#else > elf_hwcap |= HWCAP_EVTSTRM; > +#endif I wonder whether we can have a generic definition for this: #define cpu_set_named_feature(x) (elf_hwcap |= HWCAP_ ## x) seems a reasonable fallback when the arch doesn't provide its own version. Although we don't have many instances, it would still be nice to avoid ifdeffery creeping in. [...] We can probably pull the Documentation/arm64/elf_hwcaps.txt changes into this patch. It probably makes sense to pull the Documentation/arm64/elf_hwcaps.txt updates alongside this patch in the series (or even incorporate them into this patch, since they're not huge.) Other than that, looks reasonable to me. Cheers ---Dave _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel