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 0580BC433EF for ; Tue, 3 May 2022 11:30:21 +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=iSkIRs0TZtBN6rQPofvVOzPhMsVKYJGAg0ssZp+2O8o=; b=u5e1L6jp+5i5QL N2TMQw4U4vQC/pG9We+7A/lDGd//gyBMDAac4TOuAYsuY7A40p4Q0K0WK0/Xu/xHKKece8h7fcAAH 7+IuFBSVWbYFnVMB+jFnJNt/g0eu54XQ3GRhCzQcdfRXeNSI7k5xpa51l6nSjFr5Pjk4cTcFn5WPQ ialqStYpOjh9tJUqkK4zE5OZ212PPkVaR+T5esnmpVK9Uec29/9pQBHYZXKEJs7OoiY8T6TcgN4Zo SdHM7LrKE2ek0tskhNZPvNsy/RrEgEhAK2umc7FLdQbyCeIrdge3+4Nn/qKVWzzA1KapxgmuN/61U NzIOfhzRaTNlWS43DMvw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nlqiC-005bKB-EM; Tue, 03 May 2022 11:29:00 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nlqi9-005bJZ-5m for linux-arm-kernel@lists.infradead.org; Tue, 03 May 2022 11:28:58 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C43E5615D1; Tue, 3 May 2022 11:28:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E6ED1C385A9; Tue, 3 May 2022 11:28:53 +0000 (UTC) Date: Tue, 3 May 2022 12:28:50 +0100 From: Catalin Marinas To: Mark Brown Cc: Will Deacon , Mark Rutland , 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: <20220426181704.2583494-1-broonie@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220503_042857_296014_36FE3509 X-CRM114-Status: GOOD ( 24.19 ) 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, 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. We want to avoid anyone making use of the RES1_x explicitly, though most likely we'd notice this during review. But these are some 'constants' that will keep changing even their macro name, not just the value (when one bit from the field gets used for something else). > At the moment this is only intended to express metadata from the > architecture, and does not handle policy imposed by the kernel, such as > values exposed to userspace or VMs. In future this could be extended to > express such information. This could also be extended to cover more > information such as the FTR_SIGNED/FTR_UNSIGNED distinction. We could indeed add signed info for the enum fields at some point. As for kernel possible like FTR_VISIBLE, not sure whether we should add them to the same sysreg file. My instinct is to keep it strictly about the architecture definitions, not kernel policy. > 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). -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel