From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759366AbdAIK7m (ORCPT ); Mon, 9 Jan 2017 05:59:42 -0500 Received: from foss.arm.com ([217.140.101.70]:50888 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759294AbdAIK70 (ORCPT ); Mon, 9 Jan 2017 05:59:26 -0500 Subject: Re: [PATCH v3 9/9] arm64: Documentation - Expose CPU feature registers To: Catalin Marinas References: <1483552147-9605-1-git-send-email-suzuki.poulose@arm.com> <1483552147-9605-10-git-send-email-suzuki.poulose@arm.com> <20170106121612.GA12863@e104818-lin.cambridge.arm.com> Cc: linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com, ryan.arnold@linaro.org, sid@reserved-bit.com, aph@redhat.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, adhemerval.zanella@linaro.org, dave.martin@arm.com From: Suzuki K Poulose Message-ID: <0701afb7-c337-4f82-3dd1-728bca160a44@arm.com> Date: Mon, 9 Jan 2017 10:59:23 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170106121612.GA12863@e104818-lin.cambridge.arm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/01/17 12:16, Catalin Marinas wrote: > On Wed, Jan 04, 2017 at 05:49:07PM +0000, Suzuki K. Poulose wrote: >> +The following rules are applied to the value returned by the >> +infrastructure: >> + >> + a) The value of an 'IMPLEMENTATION DEFINED' field is set to 0. >> + b) The value of a reserved field is populated with the reserved >> + value as defined by the architecture. >> + c) The value of a field marked as not 'visible', is set to indicate >> + the feature is missing (as defined by the architecture). >> + d) The value of a 'visible' field holds the system wide safe value >> + for the particular feature(except for MIDR_EL1, see section 4). >> + See Appendix I for more information on safe value. >> + >> +There are only a few registers visible to the userspace. See Section 4, >> +for the list of 'visible' registers. >> + >> +All others are emulated as having 'invisible' features. > > BTW, we don't have any statement about whether a visible field may > become invisible but I guess this wouldn't be a problem as long as the > feature is reported as missing. I'm thinking about currently RES0 fields > that are listed as visible but they may report something in the future > that we don't want exposed to user. At that point, we'll change the > field to "invisible" while reporting RES0 to user. I don't see an issue > with this, just I thought worth flagging. Thanks for raising that. In fact, we treat all the RES0 fields as invisible and strict for the moment. So, I think it is worth reflecting that in the documentation. As you mentioned, we could switch them as required based on the feature without any issues. I will fix this. > > Anyway: > > Reviewed-by: Catalin Marinas > Thanks for reviewing the entire series. I will resend the series with the tags and updates to this documentation and a couple of other patches. Suzuki