Message-ID: <35d8c6372fb38f6d7e452c2e3b5a80327f20dae6@intel.com>
Date: Mon, 16 Jun 2025 16:26:07 +0300
From: Jani Nikula <jani.nikula@...ux.intel.com>
To: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>, Robin Murphy
 <robin.murphy@....com>, Yury Norov <yury.norov@...il.com>, Jakub Kicinski
 <kuba@...nel.org>
Cc: Rasmus Villemoes <linux@...musvillemoes.dk>, Jaehoon Chung
 <jh80.chung@...sung.com>, Ulf Hansson <ulf.hansson@...aro.org>, Heiko
 Stuebner <heiko@...ech.de>, Shreeya Patel <shreeya.patel@...labora.com>,
 Mauro Carvalho Chehab <mchehab@...nel.org>, Sandy Huang
 <hjc@...k-chips.com>, Andy Yan <andy.yan@...k-chips.com>, Maarten
 Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard
 <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>, David
 Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, Vinod Koul
 <vkoul@...nel.org>, Kishon Vijay Abraham I <kishon@...nel.org>, Nicolas
 Frattaroli <frattaroli.nicolas@...il.com>, Liam Girdwood
 <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>, Jaroslav Kysela
 <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>, Andrew Lunn
 <andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>, Eric
 Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Maxime
 Coquelin <mcoquelin.stm32@...il.com>, Alexandre Torgue
 <alexandre.torgue@...s.st.com>, Shawn Lin <shawn.lin@...k-chips.com>,
 Lorenzo Pieralisi <lpieralisi@...nel.org>, Krzysztof Wilczyński
 <kwilczynski@...nel.org>, Manivannan Sadhasivam <mani@...nel.org>, Rob
 Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>, Chanwoo
 Choi <cw00.choi@...sung.com>, MyungJoo Ham <myungjoo.ham@...sung.com>,
 Kyungmin Park <kyungmin.park@...sung.com>, Qin Jian <qinjian@...lus1.com>,
 Michael Turquette <mturquette@...libre.com>, Stephen Boyd
 <sboyd@...nel.org>, Nathan Chancellor <nathan@...nel.org>, Nick
 Desaulniers <nick.desaulniers+lkml@...il.com>, Bill Wendling
 <morbo@...gle.com>, Justin Stitt <justinstitt@...gle.com>,
 linux-pm@...r.kernel.org, netdev@...r.kernel.org, llvm@...ts.linux.dev,
 linux-mmc@...r.kernel.org, linux-kernel@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, linux-clk@...r.kernel.org,
 linux-rockchip@...ts.infradead.org, linux-sound@...r.kernel.org,
 linux-pci@...r.kernel.org, linux-phy@...ts.infradead.org,
 kernel@...labora.com, linux-stm32@...md-mailman.stormreply.com,
 linux-arm-kernel@...ts.infradead.org, linux-media@...r.kernel.org
Subject: Re: [PATCH 01/20] bitfield: introduce HWORD_UPDATE bitfield macros

On Mon, 16 Jun 2025, Nicolas Frattaroli <nicolas.frattaroli@...labora.com> wrote:
> 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.

I'd never guess what WM stands for in this context without looking it
up, but I'll be happy if we have FIELD_PREP_ and 16 in there. So works
for me.

> 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?

I'll let y'all fight it out.

> Furthermore, should it be FIELD_PREP_WM16_CONST or FIELD_PREP_CONST_WM16?
> I'm personally partial to the former.

Ditto.

> 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?

I think you can just let us deal with that afterwards. You have enough
users already.


BR,
Jani.


>
> 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
>
>

-- 
Jani Nikula, Intel

Powered by blists - more mailing lists