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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 18907C433F5 for ; Tue, 3 May 2022 12:59:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=BemxKOkjUxAj7tprIM3IhkDIK197yu6z6+3LGAQNOj4=; b=aFSkCZZ7IE4eRE 62/GxrIPWoECF+gcYfVpOhpxqKxJIo08esM2jtZ/LXmrUaPjmN9laVPk6yWQoSxMGf+5lR41Xpsva c9lRtbokT6S+kfQftxRYogCXzNYsdwboYjoCx8cN5F6FVFVA99vspAV3IbNTruno4G6JSGZpiyuB9 8gWU1XJ5qGP/3i8tJ48Fli1d2n4bTMx/AJGfP9XDJ6ypuLB3PBXb3Mk5nLp6G/ZAzrjmoEiHDfgOk bQUswJ3IrTTT2zVuWVBXDd4OQ0t/ahhtkkH7mtmQsx8ehWmhwF30gVH4qS8fCrWMR+HcwcQ8azISX 8FGTyv8dvCdD/3jYlX+g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nls6h-005wTn-JR; Tue, 03 May 2022 12:58:23 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nls6e-005wSe-Js for linux-arm-kernel@lists.infradead.org; Tue, 03 May 2022 12:58:22 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id F407A1042; Tue, 3 May 2022 05:58:18 -0700 (PDT) Received: from lakrids (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0FB023F774; Tue, 3 May 2022 05:58:17 -0700 (PDT) Date: Tue, 3 May 2022 13:58:09 +0100 From: Mark Rutland To: Catalin Marinas Cc: Mark Brown , Will Deacon , Marc Zyngier , Suzuki K Poulose , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v5 00/12] arm64: Automatic system register definition generation Message-ID: References: <20220426181704.2583494-1-broonie@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220503_055820_737751_88296A2A X-CRM114-Status: GOOD ( 24.94 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, May 03, 2022 at 12:28:50PM +0100, Catalin Marinas wrote: > On Tue, Apr 26, 2022 at 07:16:52PM +0100, Mark Brown wrote: > > This patch series introduces a > > script which describes registers and the fields within them in a format > > that is easy to cross reference with the architecture reference manual > > and uses them to generate the constants we use in a standard format: > > > > | #define REG_ID_AA64ISAR0_EL1 S3_0_C0_C6_0 > > | #define SYS_ID_AA64ISAR0_EL1 sys_reg(3, 0, 0, 6, 0) > > | #define SYS_ID_AA64ISAR0_EL1_Op0 3 > > | #define SYS_ID_AA64ISAR0_EL1_Op1 0 > > | #define SYS_ID_AA64ISAR0_EL1_CRn 0 > > | #define SYS_ID_AA64ISAR0_EL1_CRm 6 > > | #define SYS_ID_AA64ISAR0_EL1_Op2 0 > > > > | #define ID_AA64ISAR0_EL1_RNDR GENMASK(63, 60) > > | #define ID_AA64ISAR0_EL1_RNDR_MASK GENMASK(63, 60) > > | #define ID_AA64ISAR0_EL1_RNDR_SHIFT 60 > > | #define ID_AA64ISAR0_EL1_RNDR_WIDTH 4 > > | #define ID_AA64ISAR0_EL1_RNDR_NI UL(0b0000) > > | #define ID_AA64ISAR0_EL1_RNDR_IMP UL(0b0001) > > I like the automatic generation of the register fields, I think it's > less prone to errors and it gives us consistent notation, so it would be > nice to have this in mainline. > > I'm not convinced that we need the RES[01]_msb_lsb definitions, I'd > rather have a RES[01] with all the UL(x) or'ed in. FWIW, the scripting does define the combined RES[01] definitions with all constituent bits or'd in. It just happens to define those in terms of the individual RES[01]_msb_lsb definitions. I had originally added the RES[01]_msb_lsb definitions purely so I could reuse the define_field() logic, and I agree that we don't really need the constituent portions to be defined individually (but I'm happy either way). I believe it's easy to remove the individual field definitions by having the Res0 and Res1 block handlers not call define_field(), and add add to the res[01] vars directly, e.g. | /^Res1/ && (block == "Sysreg" || block == "SysregFields") { | expect_fields(2) | parse_bitdef(reg, "RES1", $2) | | res1 = res1 " | GENMASK(" msb ", " lsb ")" | | next | } > > Rather than attempting to convert every register at once the current > > series converts a few sample registers to provide some concrete examples > > but allow for easier updating during review of the file format and the > > script. Handling a register at a time should also make review less > > taxing so it seems like a sensible approach in general. > > So apart from RES definitions (but happy to hear an argument), I'm fine > with the patches. If you think they are ready, we could queue the > infrastructure for 5.19 and add some of the register definitions at -rc1 > to avoid conflicts (the more conversions the better). FWIW, that sounds good to me! Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel