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