arm64: cpufeature: Fix the sign of feature bits
authorSuzuki K Poulose <suzuki.poulose@arm.com>
Tue, 26 Jan 2016 10:58:14 +0000 (10:58 +0000)
committerCatalin Marinas <catalin.marinas@arm.com>
Thu, 25 Feb 2016 10:33:07 +0000 (10:33 +0000)
commit0710cfdb8db674df622cc1858e033c11d255af80
tree67c232728843f4d89379ec424e6dcb9f0a06aad0
parente53435031a541762223b03f5e6f0ebd98bdf3501
arm64: cpufeature: Fix the sign of feature bits

There is a confusion on whether the values of a feature are signed
or not in ARM. This is not clearly mentioned in the ARM ARM either.
We have dealt most of the bits as signed so far, and marked the
rest as unsigned explicitly. This fixed in ARM ARM and will be rolled
out soon.

Here is the criteria in a nutshell:

1) The fields, which are either signed or unsigned, use increasing
   numerical values to indicate an increase in functionality. Thus, if a value
   of 0x1 indicates the presence of some instructions, then the 0x2 value will
   indicate the presence of those instructions plus some additional instructions
   or functionality.

2) For ID field values where the value 0x0 defines that a feature is not present,
   the number is an unsigned value.

3) For some features where the feature was made optional or removed after the
   start of the definition of the architecture, the value 0x0 is used to
   indicate the presence of a feature, and 0xF indicates the absence of the
   feature. In these cases, the fields are, in effect, holding signed values.

So with these rules applied, we have only the following fields which are signed and
the rest are unsigned.

 a) ID_AA64PFR0_EL1: {FP, ASIMD}
 b) ID_AA64MMFR0_EL1: {TGran4K, TGran64K}
 c) ID_AA64DFR0_EL1: PMUVer (0xf - PMUv3 not implemented)
 d) ID_DFR0_EL1: PerfMon
 e) ID_MMFR0_EL1: {InnerShr, OuterShr}

Signed-off-by: Suzuki K. Poulose <suzuki.poulose@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
arch/arm64/kernel/cpufeature.c