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 17CF8C71136 for ; Fri, 13 Jun 2025 15:16: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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=GwabUI6DvdhgKh+dzkXaFdsF529vQvlQqkz71nla3H4=; b=jZ6ZDKDcdjOXZR 4OmKXC/RuEkzqe4AimeyNwbQphWXuDhw5FGe/19SmWqb97KuJ1MqQ+LSxSrCVnjiblmD1XhFfJbiy jWTLZR7hcKZHJUfwY60iK6cX8Xwfh6ylWFlMFR7JUAyDOEYNBqATTqKW8K2DNe5dvDAz2EbGpZ0UC KPxDG+XGvakAum8CmXQyg5n0fd5X8EFkVJEdYiVUMB+5F1QOBmSnVThTspJwEUxaY3JX/M5V3kT5Q U0+XfeKJpJlZvydRf6Nqq4u3fD/mfYv50Ev215SdgfGW4K8jteZZXk+U6qRZqRq6mpZ6/15uzRJYO 9eVXK50DAiqQX8vLz3xg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1uQ68q-0000000Gq8X-1iWf; Fri, 13 Jun 2025 15:16:28 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1uQ4s5-0000000Ga5a-2OQn; Fri, 13 Jun 2025 13:55:06 +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 771B8FEC; Fri, 13 Jun 2025 06:54:42 -0700 (PDT) Received: from [10.57.28.131] (unknown [10.57.28.131]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3A0C03F59E; Fri, 13 Jun 2025 06:54:52 -0700 (PDT) Message-ID: <1437fe89-341b-4b57-b1fa-a0395081e941@arm.com> Date: Fri, 13 Jun 2025 14:54:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 01/20] bitfield: introduce HWORD_UPDATE bitfield macros To: Nicolas Frattaroli , Yury Norov , Rasmus Villemoes , Jaehoon Chung , Ulf Hansson , Heiko Stuebner , Shreeya Patel , Mauro Carvalho Chehab , Sandy Huang , Andy Yan , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Vinod Koul , Kishon Vijay Abraham I , Nicolas Frattaroli , Liam Girdwood , Mark Brown , Jaroslav Kysela , Takashi Iwai , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Maxime Coquelin , Alexandre Torgue , Shawn Lin , Lorenzo Pieralisi , =?UTF-8?Q?Krzysztof_Wilczy=C5=84ski?= , Manivannan Sadhasivam , Rob Herring , Bjorn Helgaas , Chanwoo Choi , MyungJoo Ham , Kyungmin Park , Qin Jian , Michael Turquette , Stephen Boyd , Nathan Chancellor , Nick Desaulniers , Bill Wendling , Justin Stitt Cc: linux-pm@vger.kernel.org, netdev@vger.kernel.org, llvm@lists.linux.dev, linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-clk@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-sound@vger.kernel.org, linux-pci@vger.kernel.org, linux-phy@lists.infradead.org, kernel@collabora.com, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org References: <20250612-byeword-update-v1-0-f4afb8f6313f@collabora.com> <20250612-byeword-update-v1-1-f4afb8f6313f@collabora.com> From: Robin Murphy Content-Language: en-GB In-Reply-To: <20250612-byeword-update-v1-1-f4afb8f6313f@collabora.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250613_065505_716770_DDD59E13 X-CRM114-Status: GOOD ( 26.98 ) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org On 2025-06-12 7:56 pm, Nicolas Frattaroli wrote: > Hardware of various vendors, but very notably Rockchip, often uses > 32-bit registers where the upper 16-bit half of the register is a > write-enable mask for the lower half. > > This type of hardware setup allows for more granular concurrent register > write access. > > Over the years, many drivers have hand-rolled their own version of this > macro, usually without any checks, often called something like > HIWORD_UPDATE or FIELD_PREP_HIWORD, commonly with slightly different > semantics between them. > > Clearly there is a demand for such a macro, and thus the demand should > be satisfied in a common header file. > > Add two macros: HWORD_UPDATE, and HWORD_UPDATE_CONST. The latter is a > version that can be used in initializers, like FIELD_PREP_CONST. The > macro names are chosen to not clash with any potential other macros that > drivers may already have implemented themselves, while retaining a > familiar name. Nit: while from one angle it indeed looks similar, from another it's even more opaque and less meaningful than what we have already. Personally I cannot help but see "hword" as "halfword", so logically if we want 32+32-bit or 8+8-bit variants in future those would be WORD_UPDATE() and BYTE_UPDATE(), right? ;) It's also confounded by "update" not actually having any obvious meaning at this level without all the implicit usage context. FWIW my suggestion would be FIELD_PREP_WM_U16, such that the reader instantly sees "FIELD_PREP with some additional semantics", even if they then need to glance at the kerneldoc for clarification that WM stands for writemask (or maybe WE for write-enable if people prefer). Plus it then leaves room to easily support different sizes (and potentially even bonkers upside-down Ux_WM variants?!) without any bother if we need to. Thanks, Robin. > Signed-off-by: Nicolas Frattaroli > --- > include/linux/bitfield.h | 47 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 47 insertions(+) > > diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h > index 6d9a53db54b66c0833973c880444bd289d9667b1..b90d88db7405f95b78cdd6f3426263086bab5aa6 100644 > --- a/include/linux/bitfield.h > +++ b/include/linux/bitfield.h > @@ -8,6 +8,7 @@ > #define _LINUX_BITFIELD_H > > #include > +#include > #include > #include > > @@ -142,6 +143,52 @@ > (((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask)) \ > ) > > +/** > + * HWORD_UPDATE() - prepare a bitfield element with a mask in the upper half > + * @_mask: shifted mask defining the field's length and position > + * @_val: value to put in the field > + * > + * HWORD_UPDATE() masks and shifts up the value, as well as bitwise ORs the > + * result with the mask shifted up by 16. > + * > + * This is useful for a common design of hardware registers where the upper > + * 16-bit half of a 32-bit register is used as a write-enable mask. In such a > + * register, a bit in the lower half is only updated if the corresponding bit > + * in the upper half is high. > + */ > +#define HWORD_UPDATE(_mask, _val) \ > + ({ \ > + __BF_FIELD_CHECK(_mask, ((u16) 0U), _val, \ > + "HWORD_UPDATE: "); \ > + (((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask)) | \ > + ((_mask) << 16); \ > + }) > + > +/** > + * HWORD_UPDATE_CONST() - prepare a constant bitfield element with a mask in > + * the upper half > + * @_mask: shifted mask defining the field's length and position > + * @_val: value to put in the field > + * > + * HWORD_UPDATE_CONST() masks and shifts up the value, as well as bitwise ORs > + * the result with the mask shifted up by 16. > + * > + * This is useful for a common design of hardware registers where the upper > + * 16-bit half of a 32-bit register is used as a write-enable mask. In such a > + * register, a bit in the lower half is only updated if the corresponding bit > + * in the upper half is high. > + * > + * Unlike HWORD_UPDATE(), this is a constant expression and can therefore > + * be used in initializers. Error checking is less comfortable for this > + * version. > + */ > +#define HWORD_UPDATE_CONST(_mask, _val) \ > + ( \ > + FIELD_PREP_CONST(_mask, _val) | \ > + (BUILD_BUG_ON_ZERO(const_true((u64) (_mask) > U16_MAX)) + \ > + ((_mask) << 16)) \ > + ) > + > /** > * FIELD_GET() - extract a bitfield element > * @_mask: shifted mask defining the field's length and position > _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip