From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755754AbbIYLiR (ORCPT ); Fri, 25 Sep 2015 07:38:17 -0400 Received: from eu-smtp-delivery-143.mimecast.com ([146.101.78.143]:56841 "EHLO eu-smtp-delivery-143.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753466AbbIYLiO convert rfc822-to-8bit (ORCPT ); Fri, 25 Sep 2015 07:38:14 -0400 Date: Fri, 25 Sep 2015 12:38:10 +0100 From: Dave Martin To: "Suzuki K. Poulose" Cc: linux-arm-kernel@lists.infradead.org, Mark.Rutland@arm.com, ard.biesheuvel@linaro.org, aph@redhat.com, Catalin.Marinas@arm.com, Will.Deacon@arm.com, linux-kernel@vger.kernel.org, edward.nevill@linaro.org, andre.przywara@arm.com, marc.zyngier@arm.com Subject: Re: [PATCH 07/22] arm64: Keep track of CPU feature registers Message-ID: <20150925113808.GL6281@e103592.cambridge.arm.com> References: <1442413280-31885-1-git-send-email-suzuki.poulose@arm.com> <1442413280-31885-8-git-send-email-suzuki.poulose@arm.com> MIME-Version: 1.0 In-Reply-To: <1442413280-31885-8-git-send-email-suzuki.poulose@arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-OriginalArrivalTime: 25 Sep 2015 11:38:10.0573 (UTC) FILETIME=[A7BEEBD0:01D0F786] X-MC-Unique: dcKCn978Rm2X-Dc92OGy1A-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: 8BIT Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 16, 2015 at 03:21:05PM +0100, Suzuki K. Poulose wrote: > From: "Suzuki K. Poulose" > > This patch adds an infrastructure to keep track of the CPU feature > registers on the system. For each register, the infrastructure keeps > track of the system wide safe value of the feature bits. Also, tracks > the which fields of a register should be matched strictly across all > the CPUs on the system for the SANITY check infrastructure. > > The feature bits are classified as one of SCALAR_MIN, SCALAR_MAX and DISCRETE > depending on the implication of the possible values. This information > is used to decide the safe value for a feature. > > SCALAR_MIN - The smaller value is safer > SCALAR_MAX - The bigger value is safer > DISCRETE - We can't decide between the two, so a predefined safe_value is used. Can documentation of the meanings of these be added somewhere in the relevant header or in Documentation? Cheers ---Dave [...]