From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 28B43C47247 for ; Tue, 5 May 2020 12:12:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 038EB206A4 for ; Tue, 5 May 2020 12:12:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588680769; bh=lRSSmIip0z2BoR+RQ+3hQQVFRY5K07HxlK441PUvO4w=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=Dbx6qw3nDMeDTnyOXdFBdMLbrDOn0mL8w9JbjHhm+/5gxi/n05na7mYJkUb7L6c/q +E9MjPAmm747WG/eJ6WNFSOPuGSMhZyrw8QZx6gH19X6mg1QP/qJLllFYJrPan0jVr AX6Df0Xisj5SneDngJvBEghVbH60X9fYkY8ADaI0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728972AbgEEMMr (ORCPT ); Tue, 5 May 2020 08:12:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:37404 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728957AbgEEMMp (ORCPT ); Tue, 5 May 2020 08:12:45 -0400 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3463E206A4; Tue, 5 May 2020 12:12:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588680764; bh=lRSSmIip0z2BoR+RQ+3hQQVFRY5K07HxlK441PUvO4w=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Vvd6pPIdmUOLnPSSOEbgshPimjHlXn8Jb0pT005eaNVQM/O1gReGl7Hz3fjulp0N9 2HhwCwhWBvnLs/L1MlRsx2W3CcZZ2qWetwd9To2K5swDT65NzY4tKUWS8kpBYA19l4 +ZuM12CP6wKprD2xtAJnC4YlWJo3Av3GWnxT/Gmo= Date: Tue, 5 May 2020 13:12:39 +0100 From: Will Deacon To: Mark Rutland Cc: Anshuman Khandual , linux-arm-kernel@lists.infradead.org, Catalin Marinas , Marc Zyngier , James Morse , Suzuki K Poulose , kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org Subject: Re: [PATCH V3 04/16] arm64/cpufeature: Introduce ID_PFR2 CPU register Message-ID: <20200505121239.GI19710@willie-the-truck> References: <1588426445-24344-1-git-send-email-anshuman.khandual@arm.com> <1588426445-24344-5-git-send-email-anshuman.khandual@arm.com> <20200505111241.GF19710@willie-the-truck> <20200505111607.GA82823@C02TD0UTHF1T.local> <20200505112718.GH19710@willie-the-truck> <20200505115054.GC82823@C02TD0UTHF1T.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200505115054.GC82823@C02TD0UTHF1T.local> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 05, 2020 at 12:50:54PM +0100, Mark Rutland wrote: > On Tue, May 05, 2020 at 12:27:19PM +0100, Will Deacon wrote: > > On Tue, May 05, 2020 at 12:16:07PM +0100, Mark Rutland wrote: > > > On Tue, May 05, 2020 at 12:12:41PM +0100, Will Deacon wrote: > > > > On Sat, May 02, 2020 at 07:03:53PM +0530, Anshuman Khandual wrote: > > > > > diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h > > > > > index e5317a6367b6..c977449e02db 100644 > > > > > --- a/arch/arm64/include/asm/sysreg.h > > > > > +++ b/arch/arm64/include/asm/sysreg.h > > > > > @@ -153,6 +153,7 @@ > > > > > #define SYS_MVFR0_EL1 sys_reg(3, 0, 0, 3, 0) > > > > > #define SYS_MVFR1_EL1 sys_reg(3, 0, 0, 3, 1) > > > > > #define SYS_MVFR2_EL1 sys_reg(3, 0, 0, 3, 2) > > > > > +#define SYS_ID_PFR2_EL1 sys_reg(3, 0, 0, 3, 4) > > > > > > > > nit: but please group these defines by name rather than encoding. > > > > > > So far we've *always* grouped these by encoding in this file, so can we > > > keep things that way for now? Otherwise we're inconsistent with both > > > schemes. > > > > Hmm, but it's really hard to read sorted that way and we'll end up with > > duplicate definitions like we had for some of the field offsets already. > > I appreciate that, and don't disagree that the current scheme is not > obvious. > > I just want to ensure that we don't make things less consistent, and if > we're going to change the scheme in order to make that easier, it should > be a separate patch. There'll be other changes like MMFR4_EL1, and we > should probably add a comment as to what the policy is either way (e.g. > if we're just grouping at the top level, or if that should be sorted > too). Ok, I added a comment below. Will --->8 commit be7ab6a6cdb0a6d7b10883094c2adf96f5d4e1e8 Author: Will Deacon Date: Tue May 5 13:08:02 2020 +0100 arm64: cpufeature: Group indexed system register definitions by name Some system registers contain an index in the name (e.g. ID_MMFR_EL1) and, while this index often follows the register encoding, newer additions to the architecture are necessarily tacked on the end. Sorting these registers by encoding therefore becomes a bit of a mess. Group the indexed system register definitions by name so that it's easier to read and will hopefully reduce the chance of us accidentally introducing duplicate definitions in the future. Signed-off-by: Will Deacon diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h index 2dd3f4ca9780..194684301df0 100644 --- a/arch/arm64/include/asm/sysreg.h +++ b/arch/arm64/include/asm/sysreg.h @@ -105,6 +105,10 @@ #define SYS_DC_CSW sys_insn(1, 0, 7, 10, 2) #define SYS_DC_CISW sys_insn(1, 0, 7, 14, 2) +/* + * System registers, organised loosely by encoding but grouped together + * where the architected name contains an index. e.g. ID_MMFR_EL1. + */ #define SYS_OSDTRRX_EL1 sys_reg(2, 0, 0, 0, 2) #define SYS_MDCCINT_EL1 sys_reg(2, 0, 0, 2, 0) #define SYS_MDSCR_EL1 sys_reg(2, 0, 0, 2, 2) @@ -140,6 +144,7 @@ #define SYS_ID_MMFR1_EL1 sys_reg(3, 0, 0, 1, 5) #define SYS_ID_MMFR2_EL1 sys_reg(3, 0, 0, 1, 6) #define SYS_ID_MMFR3_EL1 sys_reg(3, 0, 0, 1, 7) +#define SYS_ID_MMFR4_EL1 sys_reg(3, 0, 0, 2, 6) #define SYS_ID_ISAR0_EL1 sys_reg(3, 0, 0, 2, 0) #define SYS_ID_ISAR1_EL1 sys_reg(3, 0, 0, 2, 1) @@ -147,7 +152,6 @@ #define SYS_ID_ISAR3_EL1 sys_reg(3, 0, 0, 2, 3) #define SYS_ID_ISAR4_EL1 sys_reg(3, 0, 0, 2, 4) #define SYS_ID_ISAR5_EL1 sys_reg(3, 0, 0, 2, 5) -#define SYS_ID_MMFR4_EL1 sys_reg(3, 0, 0, 2, 6) #define SYS_ID_ISAR6_EL1 sys_reg(3, 0, 0, 2, 7) #define SYS_MVFR0_EL1 sys_reg(3, 0, 0, 3, 0) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 09FDFC47258 for ; Tue, 5 May 2020 12:12:50 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 8647F206A4 for ; Tue, 5 May 2020 12:12:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="Vvd6pPId" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8647F206A4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 2B1064B2CF; Tue, 5 May 2020 08:12:49 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@kernel.org Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xs2nMNQSKNwp; Tue, 5 May 2020 08:12:48 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id F0CB44B2FF; Tue, 5 May 2020 08:12:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 118DE4B2CF for ; Tue, 5 May 2020 08:12:47 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbnEKdkWVC3G for ; Tue, 5 May 2020 08:12:45 -0400 (EDT) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id B2DF74B2BF for ; Tue, 5 May 2020 08:12:45 -0400 (EDT) Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3463E206A4; Tue, 5 May 2020 12:12:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588680764; bh=lRSSmIip0z2BoR+RQ+3hQQVFRY5K07HxlK441PUvO4w=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Vvd6pPIdmUOLnPSSOEbgshPimjHlXn8Jb0pT005eaNVQM/O1gReGl7Hz3fjulp0N9 2HhwCwhWBvnLs/L1MlRsx2W3CcZZ2qWetwd9To2K5swDT65NzY4tKUWS8kpBYA19l4 +ZuM12CP6wKprD2xtAJnC4YlWJo3Av3GWnxT/Gmo= Date: Tue, 5 May 2020 13:12:39 +0100 From: Will Deacon To: Mark Rutland Subject: Re: [PATCH V3 04/16] arm64/cpufeature: Introduce ID_PFR2 CPU register Message-ID: <20200505121239.GI19710@willie-the-truck> References: <1588426445-24344-1-git-send-email-anshuman.khandual@arm.com> <1588426445-24344-5-git-send-email-anshuman.khandual@arm.com> <20200505111241.GF19710@willie-the-truck> <20200505111607.GA82823@C02TD0UTHF1T.local> <20200505112718.GH19710@willie-the-truck> <20200505115054.GC82823@C02TD0UTHF1T.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200505115054.GC82823@C02TD0UTHF1T.local> User-Agent: Mutt/1.10.1 (2018-07-13) Cc: Catalin Marinas , Anshuman Khandual , linux-kernel@vger.kernel.org, Marc Zyngier , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Tue, May 05, 2020 at 12:50:54PM +0100, Mark Rutland wrote: > On Tue, May 05, 2020 at 12:27:19PM +0100, Will Deacon wrote: > > On Tue, May 05, 2020 at 12:16:07PM +0100, Mark Rutland wrote: > > > On Tue, May 05, 2020 at 12:12:41PM +0100, Will Deacon wrote: > > > > On Sat, May 02, 2020 at 07:03:53PM +0530, Anshuman Khandual wrote: > > > > > diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h > > > > > index e5317a6367b6..c977449e02db 100644 > > > > > --- a/arch/arm64/include/asm/sysreg.h > > > > > +++ b/arch/arm64/include/asm/sysreg.h > > > > > @@ -153,6 +153,7 @@ > > > > > #define SYS_MVFR0_EL1 sys_reg(3, 0, 0, 3, 0) > > > > > #define SYS_MVFR1_EL1 sys_reg(3, 0, 0, 3, 1) > > > > > #define SYS_MVFR2_EL1 sys_reg(3, 0, 0, 3, 2) > > > > > +#define SYS_ID_PFR2_EL1 sys_reg(3, 0, 0, 3, 4) > > > > > > > > nit: but please group these defines by name rather than encoding. > > > > > > So far we've *always* grouped these by encoding in this file, so can we > > > keep things that way for now? Otherwise we're inconsistent with both > > > schemes. > > > > Hmm, but it's really hard to read sorted that way and we'll end up with > > duplicate definitions like we had for some of the field offsets already. > > I appreciate that, and don't disagree that the current scheme is not > obvious. > > I just want to ensure that we don't make things less consistent, and if > we're going to change the scheme in order to make that easier, it should > be a separate patch. There'll be other changes like MMFR4_EL1, and we > should probably add a comment as to what the policy is either way (e.g. > if we're just grouping at the top level, or if that should be sorted > too). Ok, I added a comment below. Will --->8 commit be7ab6a6cdb0a6d7b10883094c2adf96f5d4e1e8 Author: Will Deacon Date: Tue May 5 13:08:02 2020 +0100 arm64: cpufeature: Group indexed system register definitions by name Some system registers contain an index in the name (e.g. ID_MMFR_EL1) and, while this index often follows the register encoding, newer additions to the architecture are necessarily tacked on the end. Sorting these registers by encoding therefore becomes a bit of a mess. Group the indexed system register definitions by name so that it's easier to read and will hopefully reduce the chance of us accidentally introducing duplicate definitions in the future. Signed-off-by: Will Deacon diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h index 2dd3f4ca9780..194684301df0 100644 --- a/arch/arm64/include/asm/sysreg.h +++ b/arch/arm64/include/asm/sysreg.h @@ -105,6 +105,10 @@ #define SYS_DC_CSW sys_insn(1, 0, 7, 10, 2) #define SYS_DC_CISW sys_insn(1, 0, 7, 14, 2) +/* + * System registers, organised loosely by encoding but grouped together + * where the architected name contains an index. e.g. ID_MMFR_EL1. + */ #define SYS_OSDTRRX_EL1 sys_reg(2, 0, 0, 0, 2) #define SYS_MDCCINT_EL1 sys_reg(2, 0, 0, 2, 0) #define SYS_MDSCR_EL1 sys_reg(2, 0, 0, 2, 2) @@ -140,6 +144,7 @@ #define SYS_ID_MMFR1_EL1 sys_reg(3, 0, 0, 1, 5) #define SYS_ID_MMFR2_EL1 sys_reg(3, 0, 0, 1, 6) #define SYS_ID_MMFR3_EL1 sys_reg(3, 0, 0, 1, 7) +#define SYS_ID_MMFR4_EL1 sys_reg(3, 0, 0, 2, 6) #define SYS_ID_ISAR0_EL1 sys_reg(3, 0, 0, 2, 0) #define SYS_ID_ISAR1_EL1 sys_reg(3, 0, 0, 2, 1) @@ -147,7 +152,6 @@ #define SYS_ID_ISAR3_EL1 sys_reg(3, 0, 0, 2, 3) #define SYS_ID_ISAR4_EL1 sys_reg(3, 0, 0, 2, 4) #define SYS_ID_ISAR5_EL1 sys_reg(3, 0, 0, 2, 5) -#define SYS_ID_MMFR4_EL1 sys_reg(3, 0, 0, 2, 6) #define SYS_ID_ISAR6_EL1 sys_reg(3, 0, 0, 2, 7) #define SYS_MVFR0_EL1 sys_reg(3, 0, 0, 3, 0) _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2704CC47259 for ; Tue, 5 May 2020 12:12:50 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DD85D20735 for ; Tue, 5 May 2020 12:12:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="hzuF47jF"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="Vvd6pPId" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DD85D20735 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=4aQwUB9XZ6N/XRZaCJ2RpERBKjVxgZYrnkTvkvniA24=; b=hzuF47jFejQLF6 hjmLcQKl9f42mlEbagEMaDpHcSG6IFit/MuZP137pwdLebKgCaw/xCNPPbWISXWNreAKStdmSkvqc vjWK/7rcoQoHjnTSLy9jPSs+yMWYC0NXjWOqLXa06KzEBnLoHXBIhetbvQliAcD1KwnASMHXHdO8H mdB6Qa9ZPPiidaJB4BvCxVvkmeFdnEXcIxZl/3V2HNggotQPryifHdQQAXL+k75DmPfeKQ1P34Lv7 lO9QSslJtMPyNPYIFKOmKQNnTgPwP70bsRDtCwt9MSRLwVC8Cz5/TZDrgsAJbmcRrfXvye5a/krG8 yhPYTEk4iPxrF+TDzLhQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jVwRM-0005KA-Pr; Tue, 05 May 2020 12:12:48 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jVwRJ-0005JJ-By for linux-arm-kernel@lists.infradead.org; Tue, 05 May 2020 12:12:46 +0000 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3463E206A4; Tue, 5 May 2020 12:12:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588680764; bh=lRSSmIip0z2BoR+RQ+3hQQVFRY5K07HxlK441PUvO4w=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Vvd6pPIdmUOLnPSSOEbgshPimjHlXn8Jb0pT005eaNVQM/O1gReGl7Hz3fjulp0N9 2HhwCwhWBvnLs/L1MlRsx2W3CcZZ2qWetwd9To2K5swDT65NzY4tKUWS8kpBYA19l4 +ZuM12CP6wKprD2xtAJnC4YlWJo3Av3GWnxT/Gmo= Date: Tue, 5 May 2020 13:12:39 +0100 From: Will Deacon To: Mark Rutland Subject: Re: [PATCH V3 04/16] arm64/cpufeature: Introduce ID_PFR2 CPU register Message-ID: <20200505121239.GI19710@willie-the-truck> References: <1588426445-24344-1-git-send-email-anshuman.khandual@arm.com> <1588426445-24344-5-git-send-email-anshuman.khandual@arm.com> <20200505111241.GF19710@willie-the-truck> <20200505111607.GA82823@C02TD0UTHF1T.local> <20200505112718.GH19710@willie-the-truck> <20200505115054.GC82823@C02TD0UTHF1T.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200505115054.GC82823@C02TD0UTHF1T.local> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200505_051245_448172_FCC27FA7 X-CRM114-Status: GOOD ( 18.45 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Suzuki K Poulose , Catalin Marinas , Anshuman Khandual , linux-kernel@vger.kernel.org, James Morse , Marc Zyngier , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, May 05, 2020 at 12:50:54PM +0100, Mark Rutland wrote: > On Tue, May 05, 2020 at 12:27:19PM +0100, Will Deacon wrote: > > On Tue, May 05, 2020 at 12:16:07PM +0100, Mark Rutland wrote: > > > On Tue, May 05, 2020 at 12:12:41PM +0100, Will Deacon wrote: > > > > On Sat, May 02, 2020 at 07:03:53PM +0530, Anshuman Khandual wrote: > > > > > diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h > > > > > index e5317a6367b6..c977449e02db 100644 > > > > > --- a/arch/arm64/include/asm/sysreg.h > > > > > +++ b/arch/arm64/include/asm/sysreg.h > > > > > @@ -153,6 +153,7 @@ > > > > > #define SYS_MVFR0_EL1 sys_reg(3, 0, 0, 3, 0) > > > > > #define SYS_MVFR1_EL1 sys_reg(3, 0, 0, 3, 1) > > > > > #define SYS_MVFR2_EL1 sys_reg(3, 0, 0, 3, 2) > > > > > +#define SYS_ID_PFR2_EL1 sys_reg(3, 0, 0, 3, 4) > > > > > > > > nit: but please group these defines by name rather than encoding. > > > > > > So far we've *always* grouped these by encoding in this file, so can we > > > keep things that way for now? Otherwise we're inconsistent with both > > > schemes. > > > > Hmm, but it's really hard to read sorted that way and we'll end up with > > duplicate definitions like we had for some of the field offsets already. > > I appreciate that, and don't disagree that the current scheme is not > obvious. > > I just want to ensure that we don't make things less consistent, and if > we're going to change the scheme in order to make that easier, it should > be a separate patch. There'll be other changes like MMFR4_EL1, and we > should probably add a comment as to what the policy is either way (e.g. > if we're just grouping at the top level, or if that should be sorted > too). Ok, I added a comment below. Will --->8 commit be7ab6a6cdb0a6d7b10883094c2adf96f5d4e1e8 Author: Will Deacon Date: Tue May 5 13:08:02 2020 +0100 arm64: cpufeature: Group indexed system register definitions by name Some system registers contain an index in the name (e.g. ID_MMFR_EL1) and, while this index often follows the register encoding, newer additions to the architecture are necessarily tacked on the end. Sorting these registers by encoding therefore becomes a bit of a mess. Group the indexed system register definitions by name so that it's easier to read and will hopefully reduce the chance of us accidentally introducing duplicate definitions in the future. Signed-off-by: Will Deacon diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h index 2dd3f4ca9780..194684301df0 100644 --- a/arch/arm64/include/asm/sysreg.h +++ b/arch/arm64/include/asm/sysreg.h @@ -105,6 +105,10 @@ #define SYS_DC_CSW sys_insn(1, 0, 7, 10, 2) #define SYS_DC_CISW sys_insn(1, 0, 7, 14, 2) +/* + * System registers, organised loosely by encoding but grouped together + * where the architected name contains an index. e.g. ID_MMFR_EL1. + */ #define SYS_OSDTRRX_EL1 sys_reg(2, 0, 0, 0, 2) #define SYS_MDCCINT_EL1 sys_reg(2, 0, 0, 2, 0) #define SYS_MDSCR_EL1 sys_reg(2, 0, 0, 2, 2) @@ -140,6 +144,7 @@ #define SYS_ID_MMFR1_EL1 sys_reg(3, 0, 0, 1, 5) #define SYS_ID_MMFR2_EL1 sys_reg(3, 0, 0, 1, 6) #define SYS_ID_MMFR3_EL1 sys_reg(3, 0, 0, 1, 7) +#define SYS_ID_MMFR4_EL1 sys_reg(3, 0, 0, 2, 6) #define SYS_ID_ISAR0_EL1 sys_reg(3, 0, 0, 2, 0) #define SYS_ID_ISAR1_EL1 sys_reg(3, 0, 0, 2, 1) @@ -147,7 +152,6 @@ #define SYS_ID_ISAR3_EL1 sys_reg(3, 0, 0, 2, 3) #define SYS_ID_ISAR4_EL1 sys_reg(3, 0, 0, 2, 4) #define SYS_ID_ISAR5_EL1 sys_reg(3, 0, 0, 2, 5) -#define SYS_ID_MMFR4_EL1 sys_reg(3, 0, 0, 2, 6) #define SYS_ID_ISAR6_EL1 sys_reg(3, 0, 0, 2, 7) #define SYS_MVFR0_EL1 sys_reg(3, 0, 0, 3, 0) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel