[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <74cab7d1ec31e7531cdda0f1eb47acdebd5c8d3f.camel@sipsolutions.net>
Date: Mon, 03 Feb 2025 08:44:06 +0100
From: Johannes Berg <johannes@...solutions.net>
To: Yury Norov <yury.norov@...il.com>, Vincent Mailhol
<mailhol.vincent@...adoo.fr>
Cc: Geert Uytterhoeven <geert+renesas@...der.be>, linux-clk@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-renesas-soc@...r.kernel.org,
linux-crypto@...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-kernel@...r.kernel.org, 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 S . 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>, Jakub Kicinski <kuba@...nel.org>, Alex Elder
<elder@...e.org>
Subject: Re: [PATCH treewide v2 1/3] bitfield: Add non-constant
field_{prep,get}() helpers
On Sun, 2025-02-02 at 12:53 -0500, Yury Norov wrote:
>
> > 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.
On the flip side, there have been discussions in the past (though I
think not all, if any, on the list(s)) about the argument order. Since
the value is typically not a constant, requiring the mask to be a
constant has ensured that the argument order isn't as easily mixed up as
otherwise.
With a non-constant mask there can also be no validation that the mask
is contiguous etc.
Now that doesn't imply a strong objection - personally I've come to
prefer the lower-case typed versions anyway - but something to keep in
mind when doing this.
However, the suggested change to BUILD_BUG_ON_NOT_POWER_OF_2 almost
certainly shouldn't be done for the same reason - not compiling for non-
constant values is [IMHO] part of the API contract for that macro. This
can be important for the same reasons.
(Obviously, doing that change now doesn't invalidate existing code, but
it does remove checks that may have been intended to be present in the
code.)
johannes
Powered by blists - more mailing lists