From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sender4-op-o12.zoho.com (sender4-op-o12.zoho.com [136.143.188.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8FF942E426F for ; Mon, 16 Jun 2025 12:29:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=136.143.188.12 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750076964; cv=pass; b=EIHH9ZKfsogRQz58qN/d1EMCunDQmJEK1WzGpzC403Mev+amN3XGn3huAimdB0X0d8vk9jSpH0QfoUJXBiJV0+JLnMhJfng2bgp2XsvycP9iPdiMJm/Z4J52BR/8CxS9J8m5mK8bbYRhpftWqayUFbDJnuTyedWouvfCFeGIkz8= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750076964; c=relaxed/simple; bh=D1nrTM3OWHNa73fOHQSyszn7QncKX5gjfoZAZmCJOV4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=nMM6Bn3Wd2n9NI9VwHaJO5KwpOO7FNHwt7wEQFvD8PR0hARORI2jltLFHHa9mZQNYhRS8bmNVFlR6OvaKpTP+T4Mz1+78g+EgY+QJLcYL4nhL1uylr1JKisIOpXldEHZzJD4jlOyMJ/et6Oc2JjgFI79SiONtUf8EjFkAerunqg= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (1024-bit key) header.d=collabora.com header.i=nicolas.frattaroli@collabora.com header.b=VTK5V0/V; arc=pass smtp.client-ip=136.143.188.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=collabora.com header.i=nicolas.frattaroli@collabora.com header.b="VTK5V0/V" ARC-Seal: i=1; a=rsa-sha256; t=1750076894; cv=none; d=zohomail.com; s=zohoarc; b=Kn8MGUt3qBaOkBsleWMs/iI7evtX+3Ii+lWmXB8xOO8yonT/tDL4OfelfnPrGyP69Xa6GXt64PMxsM5vBn5YsaN0I5GeJUR7YvPCpzogaDpzyN7GW1fehBmHRRYpAHqyTyzXBh1S8/TsCf+p6V2AaB6zIxcJ7XJ+dTVZeTb4YRc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1750076894; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=lS5jmrsM1AStlE4Oaeas/EKugjJN944zsH8rQcQ3FAk=; b=gZpW6CMh7kONQtxIuB9S8BJSCJKsvjeGsHGDKmIuXDXZlzskn5bJwbdnpsUcmAghdjwm7D9LGAU4Rel8QeQKW1q+5kRysuw841yRbvXfifnWduhN2bYLxbuLNXEh2MTtxoVgPSUuojnwR8DpXHHIQwqbIosI/MoGhZqfAJbm5mE= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=collabora.com; spf=pass smtp.mailfrom=nicolas.frattaroli@collabora.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1750076894; s=zohomail; d=collabora.com; i=nicolas.frattaroli@collabora.com; h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-ID:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Reply-To; bh=lS5jmrsM1AStlE4Oaeas/EKugjJN944zsH8rQcQ3FAk=; b=VTK5V0/Vh8vG0ADUhZJqoWC8GNkp9+Edtt7f54cvlzORP0TBC3O3iXDcIRVP1bPg diBzmzi3jUJX7MfK81EwTr1m9SPAyKZNsnywz/gVppbbf7/4KM7BIphS3UCg/GYBOZD MzraVGJabGmAR/4cao207oI0XAYOJPvc3s7lJ85s= Received: by mx.zohomail.com with SMTPS id 1750076891122319.76650013837536; Mon, 16 Jun 2025 05:28:11 -0700 (PDT) From: Nicolas Frattaroli To: Robin Murphy , Yury Norov , Jakub Kicinski , Jani Nikula Cc: 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 , Paolo Abeni , Maxime Coquelin , Alexandre Torgue , Shawn Lin , Lorenzo Pieralisi , Krzysztof =?UTF-8?B?V2lsY3p5xYRza2k=?= , 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 , 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 Subject: Re: [PATCH 01/20] bitfield: introduce HWORD_UPDATE bitfield macros Date: Mon, 16 Jun 2025 14:27:55 +0200 Message-ID: <3361713.44csPzL39Z@workhorse> In-Reply-To: References: <20250612-byeword-update-v1-0-f4afb8f6313f@collabora.com> <1437fe89-341b-4b57-b1fa-a0395081e941@arm.com> Precedence: bulk X-Mailing-List: llvm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Hello, On Friday, 13 June 2025 16:52:28 Central European Summer Time Yury Norov wrote: > On Fri, Jun 13, 2025 at 02:54:50PM +0100, Robin Murphy wrote: > > 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. > > I like the idea. Maybe even shorter: FIELD_PREP_WM16()? > I do think FIELD_PREP_WM16() is a good name. If everyone is okay with this as a name, I will use it in v2 of the series. And by "everyone" I really mean everyone should get their hot takes in before the end of the week, as I intend to send out a v2 on either Friday or the start of next week to keep the ball rolling, but I don't want to reroll a 20 patch series with a trillion recipients more than is absolutely necessary. To that end, I'd also like to get some other naming choices clarified. As I gathered, these two macros should best be placed in its own header. Is include/linux/hw_bitfield.h a cromulent choice, or should we go with include/linux/hw_bits.h? Furthermore, should it be FIELD_PREP_WM16_CONST or FIELD_PREP_CONST_WM16? I'm personally partial to the former. And finally, is it okay if I leave out refactoring Intel's _MASKED_FIELD() or should I see if I can at least replace its implementation while I'm at it? For less opinionated changes, I'll also change all the `U` literal suffixes to `UL` wherever I've added them. As I understand it, it doesn't really make a difference in these instances, but `UL` is more prevalent in the kernel. Kind regards, Nicolas Frattaroli