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 76019C433EF for ; Thu, 21 Apr 2022 14:18:11 +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=uoFbVTGe+mIrG1Tm641keDPp+9qdbYhWCjXDOcqBmes=; b=q9+SeVXmVy2Zk0 9rQ65ILtRiQPrPpJZldeyOwxgGdpqjuLDfbYaDi8yYIf+t9Skim4Ic1x/CWHPTnW2ZP43p6L/0e/x 0TnZVzDpqt1fKXAhtjuvjQ1zuzvdd6kSGzgOgtAOFa7aWda64S6wOx8U5r3ZJuJaoLFyNPuO264My z3bjFN8WlGgxqNv/5+BY64QSQ9BwWMXR6kRVSfmD/Px7ffYEP/A2duV3wKG3RCnTQxfjdnygmmpek e5vvThfZjveMonQ1/zR49GT7vnNWlcKS497flm4MeXHeYi4U41BaYbQXTDn+cOsKtDmJpvSltB1EW KihTxDjts28ueJgjwqow==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nhXcI-00DjSX-TR; Thu, 21 Apr 2022 14:17:06 +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 1nhXcE-00DjRK-Qy for linux-arm-kernel@lists.infradead.org; Thu, 21 Apr 2022 14:17:04 +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 7FC591515; Thu, 21 Apr 2022 07:16:55 -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 976ED3F73B; Thu, 21 Apr 2022 07:16:54 -0700 (PDT) Date: Thu, 21 Apr 2022 15:16:52 +0100 From: Mark Rutland To: Mark Brown Cc: Catalin Marinas , Will Deacon , Marc Zyngier , Suzuki K Poulose , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v4 4/8] arm64: Add sysreg header generation scripting Message-ID: References: <20220419104329.188489-1-broonie@kernel.org> <20220419104329.188489-5-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-20220421_071703_009127_D0107433 X-CRM114-Status: GOOD ( 35.09 ) 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 Thu, Apr 21, 2022 at 02:00:17PM +0100, Mark Brown wrote: > On Thu, Apr 21, 2022 at 10:47:42AM +0100, Mark Rutland wrote: > > On Tue, Apr 19, 2022 at 11:43:25AM +0100, Mark Brown wrote: > > > > | #define ID_AA64ISAR0_EL1_RNDR ARM64_SYSREG_BITMASK(63, 60) > > > | #define ID_AA64ISAR0_EL1_RNDR_MASK ARM64_SYSREG_BITMASK(63, 60) > > > I think this got missed when s/ARM64_SYSREG_BITMASK()/GENMASK_ULL()/ happened. > > Yes. > > > > | #define ID_AA64ISAR0_EL1_RNDR_SHIFT 60 > > > | #define ID_AA64ISAR0_EL1_RNDR_WIDTH 4 > > > | #define ID_AA64ISAR0_EL1_RNDR_NI ULL(0b0000) > > > | #define ID_AA64ISAR0_EL1_RNDR_IMP ULL(0b0001) > > > Just to check, was there a reason for going for ULL() and GENMASK_ULL() rather > > than UL() and GENMASK()? > > > We generally use UL() today, since we treat `unsigned long` as the native > > register size. > > That's not been updated from what you originally had had I think it was? The version in my arm64/sysreg-scripting branch doesn't use either UL() or ULL(), and its example has: | #define ID_AA64ISAR1_EL1_I8MM BITMASK(55, 52) | #define ID_AA64ISAR1_EL1_I8MM_SHIFT 52 | #define ID_AA64ISAR1_EL1_I8MM_WIDTH 4 | #define ID_AA64ISAR1_EL1_I8MM_NI 0b0000 | #define ID_AA64ISAR1_EL1_I8MM_SUPPORTED 0b0001 > , I think I'd just been under the impression that there was a good > reason for it that wasn't apparent to me. FWIW, I have no strong opinion either way, so I'm happy for that to stay as ULL and GENMASK_ULL(); I just wanted to check if there was a rationale I'd missed. > > > The script requires that all bits in the register be specified and that > > > there be no overlapping fields. This helps the script spot errors in the > > > input but means that the few registers which change layout at runtime > > > depending on things like virtualisation settings will need some manual > > > handling. No actual register conversions are done here but a header for > > > the register data with some documention of the format is provided. > > > It would be good to see an example of how we'd handle one of those, in case > > that means we need to play around with naming or structure of the definitions a > > bit. > > My thinking here was that we might not want to handle those registers > through the automated stuff at all. I haven't yet come up with > something that seems tasteful and viable for them, if I had a firm idea > for what that should look like I'd probably have implemented it. Sure, and I'm not expecting that we automate all of that, just that we have an idea of how the manual bits would work with the automatic bits. If the odd cases looks simple enough, we might be able to get away with a couple of small additions to the scripting. For example, for ESR_EL{1,2,3} today we define ESR_ELx_field definitions rather than duplicate ESR_EL1_field / ESR_EL2_field / ESR_EL3_field definitions. If the scripting has a mechanism to handle that, then that might be good enough for the other odd cases. For example, I think we could do something like: # Define a set of fields without a specific register encoding, using the # name `ESR_ELx` SysregFields ESR_ELx Res0 63:37 Field 36:32 ISS2 Field 31:26 EC Field 25 IL Field 24:0 ISS EndSysregFields # This could instead be SysregEncoding Sysreg ESR_EL1 3 0 5 2 0 Comment "See ESR_ELx for fields" # Don't create any field definitions for this reg, and don't # bother with the associated sanity checks NoFields EndSysreg Sysreg ESR_EL2 3 4 5 2 0 Comment "See ESR_ELx for fields" NoFields EndSysreg Sysreg ESR_EL12 3 5 5 2 0 Comment "See ESR_ELx for fields" NoFields EndSysreg ... and the `SysregFields` `NoFields`, and `Comment` mechanisms might be good enough to cover the other odd cases we have (e.g. aliased GIC registers, or different "views" for the same register). Does that make sense, or have I misunderstood the point you were making? Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel