[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdU3hWDOWXxuOJcBA7tphBT7X-0H+g0-oq0tZdKw+O5W3A@mail.gmail.com>
Date: Fri, 7 Nov 2025 09:35:03 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Ping-Ke Shih <pkshih@...ltek.com>
Cc: Andy Shevchenko <andriy.shevchenko@...el.com>, Yury Norov <yury.norov@...il.com>,
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-clk@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
"linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>,
"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
"linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>, "qat-linux@...el.com" <qat-linux@...el.com>,
"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
"linux-aspeed@...ts.ozlabs.org" <linux-aspeed@...ts.ozlabs.org>,
"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
"linux-sound@...r.kernel.org" <linux-sound@...r.kernel.org>,
"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
linux-wireless <linux-wireless@...r.kernel.org>
Subject: Re: [PATCH v6 12/26] bitfield: Add less-checking __FIELD_{GET,PREP}()
Hi Ping-Ke,
On Fri, 7 Nov 2025 at 02:16, Ping-Ke Shih <pkshih@...ltek.com> wrote:
> Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> > The extra checking in field_prep() in case the compiler can
> > determine that the mask is a constant already found a possible bug
> > in drivers/net/wireless/realtek/rtw89/core.c:rtw89_roc_end():
> >
> > rtw89_write32_mask(rtwdev, reg, B_AX_RX_FLTR_CFG_MASK, rtwdev->hal.rx_fltr);
> >
> > drivers/net/wireless/realtek/rtw89/reg.h:
> >
> > #define B_AX_RX_MPDU_MAX_LEN_MASK GENMASK(21, 16)
> > #define B_AX_RX_FLTR_CFG_MASK ((u32)~B_AX_RX_MPDU_MAX_LEN_MASK)
> >
> > so it looks like B_AX_RX_FLTR_CFG_MASK is not the proper mask for
> > this operation...
>
> The purpose of the statements is to update values excluding bits of
> B_AX_RX_MPDU_MAX_LEN_MASK. The use of B_AX_RX_FLTR_CFG_MASK is tricky, but
> the operation is correct because bit 0 is set, so __ffs(mask) returns 0 in
> rtw89_write32_mask(). Then, operation looks like
>
> orig = read(reg);
> new = (orig & ~mask) | (data & mask);
> write(new);
Thanks for your quick confirmation!
So the intention really is to clear bits 22-31, and write the rx_fltr
value to bits 0-15?
if the clearing is not needed, it would be better to use
#define B_AX_RX_FLTR_CFG_MASK GENMASK(15, 0)
If the clearing is needed, I still think it would be better to
change B_AX_RX_FLTR_CFG_MASK, and split the clearing off in a separate
operation, to make it more explicit and obvious for the casual reader.
> Since we don't use FIELD_{GET,PREP} macros with B_AX_RX_FLTR_CFG_MASK, how
> can you find the problem? Please guide us. Thanks.
I still have "[PATCH/RFC 17/17] rtw89: Use bitfield helpers"
https://lore.kernel.org/all/f7b81122f7596fa004188bfae68f25a68c2d2392.1637592133.git.geert+renesas@glider.be/
in my local tree, which started flagging the use of a discontiguous
mask with the improved checking in field_prep().
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Powered by blists - more mailing lists