Re: [PATCH v6 00/26] Non-const bitfield helpers

Yury Norov
2025-11-19T14:50:32Z

On Thu, Nov 06, 2025 at 11:45:02AM -0500, Yury Norov wrote:
> On Thu, Nov 06, 2025 at 02:33:48PM +0100, Geert Uytterhoeven wrote:
> > Hi all,
> >
> > <linux/bitfield.h> contains various helpers for accessing bitfields, as
> > typically used in hardware registers for memory-mapped I/O blocks.
> > These helpers ensure type safety, and deduce automatically shift values
> > from mask values, avoiding mistakes due to inconsistent shifts and
> > masks, and leading to a reduction in source code size.
> >
> > The existing FIELD_{GET,PREP}() macros are limited to compile-time
> > constants. However, it is very common to prepare or extract bitfield
> > elements where the bitfield mask is not a compile-time constant (e.g. it
> > comes from a table, or is created by shifting a compile-time constant).
> > To avoid this limitation, the AT91 clock driver introduced its own
> > field_{prep,get}() macros. During the past four years, these have been
> > copied to multiple drivers, and more copies are on their way[1], leading
> > to the obvious review comment "please move this to <linux/bitfield.h>".
> >
> > Hence this series
> > 1. Takes preparatory steps in drivers definining local
> > field_{get,prep}() macros (patches 1-11),
> > 2. Introduces __FIELD_{PREP,GET}() helpers to avoid clang W=1 warnings
> > (patch 12),
> > 3. Makes field_{prep,get}() available for general use (patch 13),
> > 4. Converts drivers with local variants to the common helpers (patches
> > 14-24),
> > 5. Converts a few Renesas drivers to the existing FIELD_{GET,PREP}()
> > and the new field_{get,prep}() helpers (patches 25-26).
> >
> > Alternatives would be to use the typed {u*,be*,le*,...}_{get,encode}_bits()
> > macros instead (which currently do not work with non-constant masks
> > either, and the first attempt to change that generates much worse code),
> > or to store the low bit and width of the mask instead (which would
> > require changing all code that passes masks directly, and also generates
> > worse code).
>
> Everyone please send your tags. I'm going to merge it in
> bitmap-for-next before Monday.

Fortunately I didn't specify the exact Monday. :)

Now it's in my tree for local testing:

https://github.com/norov/linux/tree/field-prep-for-6.19

Will move in bitmap-for-next shortly.

Thanks,
Yury