From: Yury Norov <ynorov@nvidia.com>
To: David Laight <david.laight.linux@gmail.com>
Cc: "Thomas Gleixner" <tglx@kernel.org>,
"Ingo Molnar" <mingo@redhat.com>,
"Borislav Petkov" <bp@alien8.de>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
"Andy Lutomirski" <luto@kernel.org>,
"Peter Zijlstra" <peterz@infradead.org>,
"Jonathan Cameron" <jic23@kernel.org>,
"David Lechner" <dlechner@baylibre.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"Andy Shevchenko" <andy@kernel.org>,
"Ping-Ke Shih" <pkshih@realtek.com>,
"Richard Cochran" <richardcochran@gmail.com>,
"Andrew Lunn" <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
"Yury Norov" <yury.norov@gmail.com>,
"Rasmus Villemoes" <linux@rasmusvillemoes.dk>,
"Hans de Goede" <hansg@kernel.org>,
"Linus Walleij" <linusw@kernel.org>,
"Sakari Ailus" <sakari.ailus@linux.intel.com>,
"Salah Triki" <salah.triki@gmail.com>,
"Achim Gratz" <Achim.Gratz@stromeko.de>,
"Ben Collins" <bcollins@watter.com>,
linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-rtc@vger.kernel.org
Subject: Re: [PATCH 1/9] bitfield: add FIELD_GET_SIGNED()
Date: Fri, 17 Apr 2026 17:09:35 -0400 [thread overview]
Message-ID: <aeKhj3W4ycqY5wPb@yury> (raw)
In-Reply-To: <20260417204355.37fd960d@pumpkin>
On Fri, Apr 17, 2026 at 08:43:55PM +0100, David Laight wrote:
> On Fri, 17 Apr 2026 13:36:12 -0400
> Yury Norov <ynorov@nvidia.com> wrote:
>
> > The bitfields are designed in assumption that fields contain unsigned
> > integer values, thus extracting the values from the field implies
> > zero-extending.
> >
> > Some drivers need to sign-extend their fields, and currently do it like:
> >
> > dc_re += sign_extend32(FIELD_GET(0xfff000, tmp), 11);
> > dc_im += sign_extend32(FIELD_GET(0xfff, tmp), 11);
> >
> > It's error-prone because it relies on user to provide the correct
> > index of the most significant bit and proper 32 vs 64 function flavor.
> >
> > Thus, introduce a FIELD_GET_SIGNED() macro, which is the more
> > convenient and compiles (on x86_64) to just a couple instructions:
> > shl and sar.
> >
> > Signed-off-by: Yury Norov <ynorov@nvidia.com>
> > ---
> > include/linux/bitfield.h | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
> > index 54aeeef1f0ec..35ef63972810 100644
> > --- a/include/linux/bitfield.h
> > +++ b/include/linux/bitfield.h
> > @@ -178,6 +178,22 @@
> > __FIELD_GET(_mask, _reg, "FIELD_GET: "); \
> > })
> >
> > +/**
> > + * FIELD_GET_SIGNED() - extract a signed bitfield element
> > + * @mask: shifted mask defining the field's length and position
> > + * @reg: value of entire bitfield
> > + *
> > + * Returns the sign-extended field specified by @_mask from the
> > + * bitfield passed in as @_reg by masking and shifting it down.
> > + */
> > +#define FIELD_GET_SIGNED(mask, reg) \
> > + ({ \
> > + __BF_FIELD_CHECK(mask, reg, 0U, "FIELD_GET_SIGNED: "); \
> > + ((__signed_scalar_typeof(mask))((long long)(reg) << \
> > + __builtin_clzll(mask) >> (__builtin_clzll(mask) + \
> > + __builtin_ctzll(mask))));\
>
> Have you looked at what that generates on a typical 32bit architecture?
Yes, for arm32:
#define FIELD_GET_SIGNED(mask, reg) \
((long long)(reg) << \
__builtin_clzll(mask) >> (__builtin_clzll(mask) + \
__builtin_ctzll(mask)))
long long foo(long long reg)
{
return FIELD_GET_SIGNED(0x00f00000ULL, reg);
}
generates:
foo(long long):
lsls r1, r0, #8
asrs r0, r1, #28
asrs r1, r1, #31
bx lr
Just as good as x86_64.
https://godbolt.org/z/eMnKrnocq
> It really a bad idea to use __signed_scalar_typeof() on anything that isn't
> a simple variable.
> The bloat from all this when 'mask' is an expansion of GENMASK() is horrid.
> Indeed both signed_scalar_typeof() and unsigned_scalar_typeof() should
> really not be used - there are generally much better ways.
David, it's not the first time you're throwing "bad idea, horrid bloat,
really not be used"-like rant with absolutely no evidence that people
do something wrong. Today I became another random victim of your style
of communication, and I don't think there's any benefit to tolerate it
for me or anybody else.
I encourage you to change your attitude, and use professional and
specific communication style in the kernel mailing list.
Starting from now, I'm not a free tester for your ideas anymore. If
you think that my patch is wrong, please prove it yourself. If you
think that 32-bit or whatever code generation is bad - please send
an example. If you believe that your implementation is any better -
please bother yourself to convince me.
I will continue receiving patches from you in my tree, but if your
patch is claimed to improve code generation, performance of any sort,
or similar things, and doesn't provide any numbers - I'll not waste
my time on it.
Thanks,
Yury
> In this case you can just write:
> ({
> auto _mask = mask;
> unsigned int __sl = __builtin_clzll(_mask);
> unsigned int __sr = __sl + __builtin_ctzll(_mask);
> __builtin_chose_expr(sizeof(_mask) <= 4,
> (int)(reg) << __sl - 32 >> __sr - 32,
> ((long long)(reg) << __sl >> __sr)
> })
> and let the compiler do any more integer promotions (etc).
>
> I'm also not convinced that the checks __BF_FIELD_CHECK() does
> on 'reg' are in any sense worth the effort.
>
> I have tried some simpler alternatives, eg:
> !__builtin_constant_p(reg) && statically_true((reg & mask) == 0)
> however that throws up some false positives due to some of weird ways
> people have used FIELD_GET() where it is nothing like the simplest
> (or most obvious) way to do things.
> That might have been the code that split a 32bit value into bytes
> in a printf with:
> FIELD_GET(GENMASK(7, 0), val), FIELD_GET(GENMASK(15, 8), val),
> FIELD_GET(GENMASK(23, 16), val), FIELD_GET(GENMASK(31, 24), val),
>
> David
>
> > + })
> > +
> > /**
> > * FIELD_MODIFY() - modify a bitfield element
> > * @_mask: shifted mask defining the field's length and position
next prev parent reply other threads:[~2026-04-17 21:09 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-17 17:36 [PATCH 0/9] bitfield: add FIELD_GET_SIGNED() Yury Norov
2026-04-17 17:36 ` [PATCH 1/9] " Yury Norov
2026-04-17 18:12 ` Andy Shevchenko
2026-04-17 19:43 ` David Laight
2026-04-17 21:09 ` Yury Norov [this message]
2026-04-17 17:36 ` [PATCH 2/9] x86/extable: switch to using FIELD_GET_SIGNED() Yury Norov
2026-04-17 17:36 ` [PATCH 3/9] iio: intel_dc_ti_adc: " Yury Norov
2026-04-17 17:36 ` [PATCH 4/9] iio: magnetometer: yas530: " Yury Norov
2026-04-17 17:36 ` [PATCH 5/9] iio: pressure: bmp280: " Yury Norov
2026-04-17 17:36 ` [PATCH 6/9] iio: mcp9600: " Yury Norov
2026-04-17 17:36 ` [PATCH 7/9] wifi: rtw89: " Yury Norov
2026-04-17 17:36 ` [PATCH 8/9] rtc: rv3032: " Yury Norov
2026-04-17 17:36 ` [PATCH 9/9] ptp: " Yury Norov
2026-04-17 18:23 ` [PATCH 0/9] bitfield: add FIELD_GET_SIGNED() Andy Shevchenko
2026-04-17 19:21 ` Yury Norov
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=aeKhj3W4ycqY5wPb@yury \
--to=ynorov@nvidia.com \
--cc=Achim.Gratz@stromeko.de \
--cc=alexandre.belloni@bootlin.com \
--cc=andrew+netdev@lunn.ch \
--cc=andy@kernel.org \
--cc=bcollins@watter.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=david.laight.linux@gmail.com \
--cc=dlechner@baylibre.com \
--cc=edumazet@google.com \
--cc=hansg@kernel.org \
--cc=hpa@zytor.com \
--cc=jic23@kernel.org \
--cc=kuba@kernel.org \
--cc=linusw@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=pabeni@redhat.com \
--cc=peterz@infradead.org \
--cc=pkshih@realtek.com \
--cc=richardcochran@gmail.com \
--cc=sakari.ailus@linux.intel.com \
--cc=salah.triki@gmail.com \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
--cc=yury.norov@gmail.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