From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S968863AbdADSpw (ORCPT ); Wed, 4 Jan 2017 13:45:52 -0500 Received: from foss.arm.com ([217.140.101.70]:56418 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965205AbdADSpt (ORCPT ); Wed, 4 Jan 2017 13:45:49 -0500 From: Suzuki K Poulose To: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org, catalin.marinas@arm.com, will.deacon@arm.com, mark.rutland@arm.com, dave.martin@arm.com, aph@redhat.com, ryan.arnold@linaro.org, adhemerval.zanella@linaro.org, sid@reserved-bit.com, Suzuki K Poulose Subject: [PATCH v3 4/9] arm64: cpufeature: Document the rules of safe value for features Date: Wed, 4 Jan 2017 17:49:02 +0000 Message-Id: <1483552147-9605-5-git-send-email-suzuki.poulose@arm.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1483552147-9605-1-git-send-email-suzuki.poulose@arm.com> References: <1483552147-9605-1-git-send-email-suzuki.poulose@arm.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Document the rules for choosing the safe value for different types of features. Cc: Dave Martin Cc: Catalin Marinas Cc: Will Deacon Cc: Mark Rutland Signed-off-by: Suzuki K Poulose --- arch/arm64/include/asm/cpufeature.h | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h index b4989df..fb76c81 100644 --- a/arch/arm64/include/asm/cpufeature.h +++ b/arch/arm64/include/asm/cpufeature.h @@ -29,7 +29,21 @@ #include #include -/* CPU feature register tracking */ +/* + * CPU feature register tracking + * + * The safe value of a CPUID feature field is dependent on the implications + * of the values assigned to it by the architecture. Based on the relationship + * between the values, the features are classified into 3 types. + * + * a) LOWER_SAFE - The value 'n+1' indicates, value 'n' and some + * additional features. (where n >= 0). The smaller value (n) is + * considered safer in this case. + * b) HIGHER_SAFE - The value 'n+1' is safer than 'n' (for n>= 0). + * c) EXACT - If the values of the feature don't have any relationship, + * a predefined safe value is used. + */ + enum ftr_type { FTR_EXACT, /* Use a predefined safe value */ FTR_LOWER_SAFE, /* Smaller value is safe */ -- 2.7.4