All of lore.kernel.org
 help / color / mirror / Atom feed
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


WARNING: multiple messages have this Message-ID (diff)
From: Yury Norov <yury.norov@gmail.com>
To: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Cc: Giovanni Cabiddu <giovanni.cabiddu@intel.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Crt Mori <cmo@melexis.com>,
	linux-aspeed@lists.ozlabs.org, linux-iio@vger.kernel.org,
	Michael Turquette <mturquette@baylibre.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	linux-kernel@vger.kernel.org,
	Claudiu Beznea <claudiu.beznea@tuxon.dev>,
	Shan-Chun Hung <schung@nuvoton.com>,
	linux-clk@vger.kernel.org, Lars-Peter Clausen <lars@metafoo.de>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Bartosz Golaszewski <brgl@bgdev.pl>,
	Takashi Iwai <tiwai@suse.com>,
	qat-linux@intel.com, Joel Stanley <joel@jms.id.au>,
	Jakub Kicinski <kuba@kernel.org>,
	Andrew Jeffery <andrew@codeconstruct.com.au>,
	Linus Walleij <linus.walleij@linaro.org>,
	Jacky Huang <ychuang3@nuvoton.com>,
	linux-sound@vger.kernel.org, linux-gpio@vger.kernel.org,
	Alex Elder <elder@ieee.org>, Jaroslav Kysela <perex@perex.cz>,
	linux-arm-kernel@lists.infradead.org,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Stephen Boyd <sboyd@kernel.org>,
	linux-renesas-soc@vger.kernel.org, linux-crypto@vger.kernel.org,
	Johannes Berg <johannes@sipsolutions.net>,
	"David S . Miller" <davem@davemloft.net>,
	Jonathan Cameron <jic23@kernel.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


  reply	other threads:[~2025-02-03  0:16 UTC|newest]

Thread overview: 36+ 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:29     ` Alexandre Belloni
2025-01-31 16:32   ` Jonathan Cameron
2025-01-31 16:32     ` Jonathan Cameron
2025-01-31 19:03   ` David Laight
2025-01-31 19:03     ` David Laight
2025-02-14 10:28     ` Geert Uytterhoeven
2025-02-14 10:28       ` Geert Uytterhoeven
2025-02-02  8:26   ` Vincent Mailhol
2025-02-02  8:26     ` Vincent Mailhol
2025-02-02 17:53     ` Yury Norov [this message]
2025-02-02 17:53       ` Yury Norov
2025-02-03  7:44       ` Johannes Berg
2025-02-03  7:44         ` Johannes Berg
2025-02-03 13:36         ` Vincent Mailhol
2025-02-03 13:36           ` Vincent Mailhol
2025-02-03 13:59           ` Geert Uytterhoeven
2025-02-03 13:59             ` Geert Uytterhoeven
2025-02-03 15:41             ` Vincent Mailhol
2025-02-03 15:41               ` Vincent Mailhol
2025-02-03 16:48               ` Yury Norov
2025-02-03 16:48                 ` Yury Norov
2025-02-14 11:03                 ` Geert Uytterhoeven
2025-02-14 11:03                   ` Geert Uytterhoeven
2025-02-14 14:39                   ` Yury Norov
2025-02-14 14:39                     ` Yury Norov
2025-02-03 15:31           ` Johannes Berg
2025-02-03 15:31             ` Johannes Berg
2025-02-04 15:30     ` Jakub Kicinski
2025-02-04 15:30       ` Jakub Kicinski
2025-02-14 11:00       ` Geert Uytterhoeven
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.