From: Yury Norov <yury.norov@gmail.com>
To: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>,
linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-renesas-soc@vger.kernel.org, linux-crypto@vger.kernel.org,
qat-linux@intel.com, linux-gpio@vger.kernel.org,
linux-aspeed@lists.ozlabs.org, linux-iio@vger.kernel.org,
linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
Nicolas Ferre <nicolas.ferre@microchip.com>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
Claudiu Beznea <claudiu.beznea@tuxon.dev>,
Giovanni Cabiddu <giovanni.cabiddu@intel.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
"David S . Miller" <davem@davemloft.net>,
Linus Walleij <linus.walleij@linaro.org>,
Bartosz Golaszewski <brgl@bgdev.pl>,
Joel Stanley <joel@jms.id.au>,
Andrew Jeffery <andrew@codeconstruct.com.au>,
Crt Mori <cmo@melexis.com>, Jonathan Cameron <jic23@kernel.org>,
Lars-Peter Clausen <lars@metafoo.de>,
Jacky Huang <ychuang3@nuvoton.com>,
Shan-Chun Hung <schung@nuvoton.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
Johannes Berg <johannes@sipsolutions.net>,
Jakub Kicinski <kuba@kernel.org>, Alex Elder <elder@ieee.org>
Subject: Re: [PATCH treewide v2 1/3] bitfield: Add non-constant field_{prep,get}() helpers
Date: Sun, 2 Feb 2025 12:53:53 -0500 [thread overview]
Message-ID: <Z5-xMUqrDuaE8Eo_@thinkpad> (raw)
In-Reply-To: <e20a177a-30cd-4088-89e1-b479aba1356c@wanadoo.fr>
On Sun, Feb 02, 2025 at 05:26:04PM +0900, Vincent Mailhol wrote:
> On 31/01/2025 at 22:46, Geert Uytterhoeven wrote:
> > 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.
>
> Why is it that the existing FIELD_{GET,PREP}() macros must be limited to
> compile time constants?
I guess, for historical reasons?
> Instead of creating another variant for
> non-constant bitfields, wouldn't it be better to make the existing macro
> accept both?
Yes, it would definitely be better IMO.
> As far as I can see, only __BUILD_BUG_ON_NOT_POWER_OF_2() and
> __BF_FIELD_CHECK() need to be adjusted. I am thinking of this:
>
> diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
> index 63928f173223..c6bedab862d1 100644
> --- a/include/linux/bitfield.h
> +++ b/include/linux/bitfield.h
> @@ -8,6 +8,7 @@
> #define _LINUX_BITFIELD_H
>
> #include <linux/build_bug.h>
> +#include <linux/compiler.h>
> #include <asm/byteorder.h>
>
> /*
> @@ -62,15 +63,13 @@
>
> #define __BF_FIELD_CHECK(_mask, _reg, _val, _pfx) \
> ({ \
> - BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask), \
> - _pfx "mask is not constant"); \
> - BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero"); \
> - BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ? \
> - ~((_mask) >> __bf_shf(_mask)) & \
> - (0 + (_val)) : 0, \
> + BUILD_BUG_ON_MSG(statically_true((_mask) == 0), \
> + _pfx "mask is zero"); \
> + BUILD_BUG_ON_MSG(statically_true(~((_mask) >>
This should be a const_true(), because statically_true() may be OK
with something like:
((runtime_var << 1) & 1 == 0)
I think it's your own patch that adds const_true(): 4f3d1be4c2f8a :)
Thanks,
Yury
next prev parent reply other threads:[~2025-02-02 17:53 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-31 13:46 [PATCH v2 0/3] Non-const bitfield helpers Geert Uytterhoeven
2025-01-31 13:46 ` [PATCH treewide v2 1/3] bitfield: Add non-constant field_{prep,get}() helpers Geert Uytterhoeven
2025-01-31 16:29 ` Alexandre Belloni
2025-01-31 16:32 ` Jonathan Cameron
2025-01-31 19:03 ` David Laight
2025-02-14 10:28 ` Geert Uytterhoeven
2025-02-02 8:26 ` Vincent Mailhol
2025-02-02 17:53 ` Yury Norov [this message]
2025-02-03 7:44 ` Johannes Berg
2025-02-03 13:36 ` Vincent Mailhol
2025-02-03 13:59 ` Geert Uytterhoeven
2025-02-03 15:41 ` Vincent Mailhol
2025-02-03 16:48 ` Yury Norov
2025-02-14 11:03 ` Geert Uytterhoeven
2025-02-14 14:39 ` Yury Norov
2025-02-03 15:31 ` Johannes Berg
2025-02-04 15:30 ` Jakub Kicinski
2025-02-14 11:00 ` Geert Uytterhoeven
2025-01-31 13:46 ` [PATCH v2 2/3] clk: renesas: Use bitfield helpers Geert Uytterhoeven
2025-01-31 13:46 ` [PATCH v2 3/3] soc: " Geert Uytterhoeven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z5-xMUqrDuaE8Eo_@thinkpad \
--to=yury.norov@gmail.com \
--cc=alexandre.belloni@bootlin.com \
--cc=andrew@codeconstruct.com.au \
--cc=brgl@bgdev.pl \
--cc=claudiu.beznea@tuxon.dev \
--cc=cmo@melexis.com \
--cc=davem@davemloft.net \
--cc=elder@ieee.org \
--cc=geert+renesas@glider.be \
--cc=giovanni.cabiddu@intel.com \
--cc=herbert@gondor.apana.org.au \
--cc=jic23@kernel.org \
--cc=joel@jms.id.au \
--cc=johannes@sipsolutions.net \
--cc=kuba@kernel.org \
--cc=lars@metafoo.de \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-aspeed@lists.ozlabs.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=mailhol.vincent@wanadoo.fr \
--cc=mturquette@baylibre.com \
--cc=nicolas.ferre@microchip.com \
--cc=perex@perex.cz \
--cc=qat-linux@intel.com \
--cc=sboyd@kernel.org \
--cc=schung@nuvoton.com \
--cc=tiwai@suse.com \
--cc=ychuang3@nuvoton.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).