From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933933AbbKSKDV (ORCPT ); Thu, 19 Nov 2015 05:03:21 -0500 Received: from eu-smtp-delivery-143.mimecast.com ([146.101.78.143]:51121 "EHLO eu-smtp-delivery-143.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757950AbbKSKDS convert rfc822-to-8bit (ORCPT ); Thu, 19 Nov 2015 05:03:18 -0500 Subject: Re: [PATCH 2/5] arm64: cpufeature: Track unsigned fields To: AKASHI Takahiro , linux-arm-kernel@lists.infradead.org References: <1447866238-22970-1-git-send-email-suzuki.poulose@arm.com> <1447866540-23207-1-git-send-email-suzuki.poulose@arm.com> <1447866540-23207-2-git-send-email-suzuki.poulose@arm.com> <564D56CA.60502@linaro.org> Cc: catalin.marinas@arm.com, will.deacon@arm.com, mark.rutland@arm.com, ard.biesheuvel@linaro.org, linux-kernel@vger.kernel.org From: "Suzuki K. Poulose" Message-ID: <564D9E61.8010802@arm.com> Date: Thu, 19 Nov 2015 10:03:13 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <564D56CA.60502@linaro.org> X-OriginalArrivalTime: 19 Nov 2015 10:03:13.0825 (UTC) FILETIME=[80F06910:01D122B1] X-MC-Unique: DlWOHKp5SYyi9k4wf3Ai5A-1 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 19/11/15 04:57, AKASHI Takahiro wrote: > Hi > > From my curiosity, > can you please clarify your criteria regarding which fields of a register should be signed or unsigned? > I guessed that the fields marked with FTR_LOWER_SAFE or FTR_HIGHER_SAFE could be unsigned, > but it seems to be not always true looking at your patch. > Anyhow, for example, ... >> - ARM64_FTR_BITS(FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_PARANGE_SHIFT, 4, 0), >> + U_ARM64_FTR_BITS(FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_PARANGE_SHIFT, 4, 0), >> ARM64_FTR_END, >> }; > > BigEnd, bits[11:8], is 0b0000 for "No mixed-endian support", and 0b0001 for > "Mixed-endian support". But can any other value be possible? If not, why signed? > If there are some hidden (or undocumented) specifications, as Ard mentioned, that's fine. > Please ignore my comments. There are no hidden specifications, but just that they are undocumented. To be precise, the criteria I selected was based on the meaning of their values. 1) If value represents something which cannot be negative and hence should be treated as unsigned. e.g, number of break points ID_AA64DFR0:BRPs. 2) If the individual values are mapped to some other values which cannot be negative, but have LOWER_SAFE/HIGHER_SAFE relation. e.g, CTR_EL0:WRG - Log2 of the write granule size. ID_AA64MMFR0:PARANGE - Supported PA Size Thanks Suzuki