On Mon, 16 Jun 2025, Nicolas Frattaroli <nicolas.frattar...@collabora.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
