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 F2EC1C433EF for ; Wed, 25 May 2022 09:08:38 +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=Dnm0VoAEGlMp+A2Wd63/YdUY0drznl56jRZkiSC/7u8=; b=xmTcSovdfg1dM5 ghOWRLPWM/iU7NUIKxrPDkvdFYcqw92UghZutcWsG80rgucFwicw8hGIzI6aV0lUAFg9t8cc86+t8 Zra4zi00eMPevPcRZw5L8c4Rksf4Up4vkG6Qipxrwn4+p3DHWIpznN2b6kFRGUoYFQOZzhIPvabao knd6GinHFWSeDDIMHmyObftuHWExSuF0S5xekEzl0rDob5ZFHeoTP5Nmsl2nzGY3Tnxhqj2J+yfXO qGl7Bq7Lo1YPXZCJmcJgoEt8YXnhpV8cFD8MO6FG6QOA857eX7wVk0REte0F4rLwADERGjTZQd7il Z2AkDqLKQozUeF0mCf/Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ntmzD-00AWsT-UK; Wed, 25 May 2022 09:07:24 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ntmzA-00AWqI-FN for linux-arm-kernel@lists.infradead.org; Wed, 25 May 2022 09:07:21 +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 C8BE1618CA; Wed, 25 May 2022 09:07:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D360C34118; Wed, 25 May 2022 09:07:18 +0000 (UTC) Date: Wed, 25 May 2022 10:07:14 +0100 From: Catalin Marinas To: Mark Rutland Cc: Mark Brown , Will Deacon , Marc Zyngier , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH RFC] arm64/sysregs: Align field names in ID_AA64DFR0_EL1 with architecture Message-ID: References: <20220518145750.251387-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-20220525_020720_589243_2CE9DDB0 X-CRM114-Status: GOOD ( 23.36 ) 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 Wed, May 25, 2022 at 09:46:13AM +0100, Mark Rutland wrote: > On Wed, May 18, 2022 at 03:57:50PM +0100, Mark Brown wrote: > > The naming scheme the architecture uses for the fields in ID_AA64DFR0_EL1 > > does not align well with kernel conventions, using as it does a lot of > > MixedCase in various arrangements. In preparation for automatically > > generating the defines for this register rename the defines used to match > > what is in the architecture. > > > > Signed-off-by: Mark Brown > > --- > > > > I am not entirely convinced if the best approach here is to deviate from > > the kernel naming convention as this does or to follow the architecture > > as we've decided in other cases, I don't really mind but would like some > > feedback before going ahead and sorting out the remaining issues with > > this register. > > It's unfortunate the architecture itself doesn't follow a consistent pattern. > :/ > > I don't personally have strong feelings here. I'm happy with either: > > (a) Matching the case to the architectural names, even if that means some > fields are MixedCase, as with this patch > > (b) Always using ALLCAPS for ID reg field definitions. > > Catalin/Marc/Will, any preference? I don't have a preference either. We have some limited mixed case places but mostly with a single 'n'. As we go for the automatic generation of these macros, it makes some sense to keep them aligned with the architecture. My only worry with (a) is the diffstat and potential conflicts. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel