[PATCH v6 00/26] Non-const bitfield helpers
Yury Norov
yury.norov at gmail.com
Fri Nov 7 03:45:01 AEDT 2025
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.
Thanks,
Yury
More information about the Linux-aspeed
mailing list