From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1162825AbbKTNhH (ORCPT ); Fri, 20 Nov 2015 08:37:07 -0500 Received: from eu-smtp-delivery-143.mimecast.com ([146.101.78.143]:49970 "EHLO eu-smtp-delivery-143.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161920AbbKTNhF convert rfc822-to-8bit (ORCPT ); Fri, 20 Nov 2015 08:37:05 -0500 Subject: Re: [PATCH 2/5] arm64: cpufeature: Track unsigned fields To: Catalin Marinas 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> <564D9E61.8010802@arm.com> <20151119184533.GB10823@e104818-lin.cambridge.arm.com> Cc: AKASHI Takahiro , linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, ard.biesheuvel@linaro.org From: "Suzuki K. Poulose" Message-ID: <564F21FC.1030306@arm.com> Date: Fri, 20 Nov 2015 13:37:00 +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: <20151119184533.GB10823@e104818-lin.cambridge.arm.com> X-OriginalArrivalTime: 20 Nov 2015 13:37:01.0362 (UTC) FILETIME=[8928F920:01D12398] X-MC-Unique: p1Dm2IgsQwqFl_apR1e6SA-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 18:45, Catalin Marinas wrote: > On Thu, Nov 19, 2015 at 10:03:13AM +0000, Suzuki K. Poulose wrote: >> On 19/11/15 04:57, AKASHI Takahiro wrote: > a) A precise value (number of breakpoint registers) or a value from > which you derive some precise value. You mentioned these above > > b) Fields defining the presence of a feature (1, 2, 3). These would > always be positive since the absence of such feature would mean a > value of 0 > > c) Fields defining the absence of a feature by setting 0xf. These are > usually fields that were initial RAZ and turned to -1. I don't expect > such field be greater than 0, nor smaller than -1. > > So I think we can treat (a) and (b) as unsigned permanently. Agreed. > We could treat (c) as unsigned as well with a value of 0xf though I'm not sure > how it matches your LOWER/HIGHER_SAFE definitions. I think we should treat (c) as signed, as we never know what could change, given that meaning of (0xf - implies unsupported) < meaning of (0 - supported). Treating them unsigned could break the LOWER/HIGHER_SAFE definitions and makes the safe value selection ugly. Cheers Suzuki