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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aQzQjSMOSrUIgMCL@yury>
Date: Thu, 6 Nov 2025 11:45:01 -0500
From: Yury Norov <yury.norov@...il.com>
To: Geert Uytterhoeven <geert+renesas@...der.be>
Cc: Michael Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...nel.org>,
	Nicolas Ferre <nicolas.ferre@...rochip.com>,
	Alexandre Belloni <alexandre.belloni@...tlin.com>,
	Claudiu Beznea <claudiu.beznea@...on.dev>,
	Giovanni Cabiddu <giovanni.cabiddu@...el.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	David Miller <davem@...emloft.net>,
	Linus Walleij <linus.walleij@...aro.org>,
	Bartosz Golaszewski <brgl@...ev.pl>, Joel Stanley <joel@....id.au>,
	Andrew Jeffery <andrew@...econstruct.com.au>,
	Crt Mori <cmo@...exis.com>, Jonathan Cameron <jic23@...nel.org>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Jacky Huang <ychuang3@...oton.com>,
	Shan-Chun Hung <schung@...oton.com>,
	Rasmus Villemoes <linux@...musvillemoes.dk>,
	Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
	Johannes Berg <johannes@...solutions.net>,
	Jakub Kicinski <kuba@...nel.org>, Alex Elder <elder@...e.org>,
	David Laight <david.laight.linux@...il.com>,
	Vincent Mailhol <mailhol.vincent@...adoo.fr>,
	Jason Baron <jbaron@...mai.com>, Borislav Petkov <bp@...en8.de>,
	Tony Luck <tony.luck@...el.com>,
	Michael Hennerich <Michael.Hennerich@...log.com>,
	Kim Seer Paller <kimseer.paller@...log.com>,
	David Lechner <dlechner@...libre.com>,
	Nuno Sá <nuno.sa@...log.com>,
	Andy Shevchenko <andy@...nel.org>,
	Richard Genoud <richard.genoud@...tlin.com>,
	Cosmin Tanislav <demonsingur@...il.com>,
	Biju Das <biju.das.jz@...renesas.com>,
	Jianping Shen <Jianping.Shen@...bosch.com>,
	Nathan Chancellor <nathan@...nel.org>,
	Nick Desaulniers <nick.desaulniers+lkml@...il.com>,
	Miquel Raynal <miquel.raynal@...tlin.com>,
	Richard Weinberger <richard@....at>,
	Vignesh Raghavendra <vigneshr@...com>, linux-clk@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	linux-renesas-soc@...r.kernel.org, linux-crypto@...r.kernel.org,
	linux-edac@...r.kernel.org, qat-linux@...el.com,
	linux-gpio@...r.kernel.org, linux-aspeed@...ts.ozlabs.org,
	linux-iio@...r.kernel.org, linux-sound@...r.kernel.org,
	linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 00/26] Non-const bitfield helpers

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