From: Catalin Marinas <catalin.marinas@arm.com> To: Alexander Kuleshov <kuleshovmail@gmail.com> Cc: Will Deacon <will.deacon@arm.com>, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 1/3] arm64/cpufeature.h: Add macros for a cpu features testing Date: Fri, 4 Sep 2015 12:25:56 +0100 [thread overview] Message-ID: <20150904112555.GB17253@e104818-lin.cambridge.arm.com> (raw) In-Reply-To: <1441303911-9421-1-git-send-email-kuleshovmail@gmail.com> On Fri, Sep 04, 2015 at 12:11:51AM +0600, Alexander Kuleshov wrote: > --- a/arch/arm64/include/asm/cpufeature.h > +++ b/arch/arm64/include/asm/cpufeature.h > @@ -28,7 +28,50 @@ > > #define ARM64_NCAPS 4 > > +/* > + * ID_AA64ISAR0_EL1 AES, bits [7:4] > + */ > +#define ID_AA64ISAR0_EL1_AES_MASK 4 > +#define ID_AA64ISAR0_EL1_AES(feature) \ > + (((feature >> ID_AA64ISAR0_EL1_AES_MASK) & 0xf) & 1UL) This looks more like a shift than a mask. I don't think it's worth defining another macro for the shift. > +#define ID_AA64ISAR0_EL1_PMULL(feature) \ > + (((feature >> ID_AA64ISAR0_EL1_AES_MASK) & 0xf) & 2UL) I'm not against some clean-up here but I think you break the original logic. AES and PMULL are not exclusive, the latter implies the former but the way you check here is just individual bits. These id fields are meant to be treated as 4-bit signed values, so if AES means >= 1, PMULL means >= 2. We have a cpuid_feature_extract_field() (in linux-next and about to go in 4.3-rc1), so use this one for extracting the signed 4-bit field. -- Catalin
WARNING: multiple messages have this Message-ID (diff)
From: catalin.marinas@arm.com (Catalin Marinas) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 1/3] arm64/cpufeature.h: Add macros for a cpu features testing Date: Fri, 4 Sep 2015 12:25:56 +0100 [thread overview] Message-ID: <20150904112555.GB17253@e104818-lin.cambridge.arm.com> (raw) In-Reply-To: <1441303911-9421-1-git-send-email-kuleshovmail@gmail.com> On Fri, Sep 04, 2015 at 12:11:51AM +0600, Alexander Kuleshov wrote: > --- a/arch/arm64/include/asm/cpufeature.h > +++ b/arch/arm64/include/asm/cpufeature.h > @@ -28,7 +28,50 @@ > > #define ARM64_NCAPS 4 > > +/* > + * ID_AA64ISAR0_EL1 AES, bits [7:4] > + */ > +#define ID_AA64ISAR0_EL1_AES_MASK 4 > +#define ID_AA64ISAR0_EL1_AES(feature) \ > + (((feature >> ID_AA64ISAR0_EL1_AES_MASK) & 0xf) & 1UL) This looks more like a shift than a mask. I don't think it's worth defining another macro for the shift. > +#define ID_AA64ISAR0_EL1_PMULL(feature) \ > + (((feature >> ID_AA64ISAR0_EL1_AES_MASK) & 0xf) & 2UL) I'm not against some clean-up here but I think you break the original logic. AES and PMULL are not exclusive, the latter implies the former but the way you check here is just individual bits. These id fields are meant to be treated as 4-bit signed values, so if AES means >= 1, PMULL means >= 2. We have a cpuid_feature_extract_field() (in linux-next and about to go in 4.3-rc1), so use this one for extracting the signed 4-bit field. -- Catalin
next prev parent reply other threads:[~2015-09-04 11:26 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-09-03 18:11 [PATCH 1/3] arm64/cpufeature.h: Add macros for a cpu features testing Alexander Kuleshov 2015-09-03 18:11 ` Alexander Kuleshov 2015-09-03 18:12 ` [PATCH 2/3] arm64/setup: Use ID_AA64ISAR0_EL1_.* macros Alexander Kuleshov 2015-09-03 18:12 ` Alexander Kuleshov 2015-09-04 11:26 ` Catalin Marinas 2015-09-04 11:26 ` Catalin Marinas 2016-11-07 16:30 ` Suzuki K Poulose 2016-11-07 16:30 ` Suzuki K Poulose 2015-09-03 18:12 ` [PATCH 3/3] arm64/fpsimd: Use ID_AA64PFR0_EL1_.* macros Alexander Kuleshov 2015-09-03 18:12 ` Alexander Kuleshov 2016-11-07 16:31 ` Suzuki K Poulose 2016-11-07 16:31 ` Suzuki K Poulose 2015-09-04 11:25 ` Catalin Marinas [this message] 2015-09-04 11:25 ` [PATCH 1/3] arm64/cpufeature.h: Add macros for a cpu features testing Catalin Marinas 2015-09-04 12:00 ` Suzuki K. Poulose 2015-09-04 12:00 ` Suzuki K. Poulose 2015-09-04 12:19 ` Alexander Kuleshov 2015-09-04 12:19 ` Alexander Kuleshov 2015-09-16 14:48 ` Suzuki K. Poulose 2015-09-16 14:48 ` Suzuki K. Poulose
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20150904112555.GB17253@e104818-lin.cambridge.arm.com \ --to=catalin.marinas@arm.com \ --cc=kuleshovmail@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.