Message-ID: <6cc1efe7771a41919ec9b2cb1eb977ac@realtek.com>
Date: Fri, 7 Nov 2025 09:16:20 +0000
From: Ping-Ke Shih <pkshih@...ltek.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
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}()

Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> 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)

But it should be 
#define B_AX_RX_FLTR_CFG_MASK (GENMASK(31, 22) | GENMASK(15, 0))

Originally (with bug) we just backup rx_fltr and write whole 32-bits back,
but it's incorrect to modify GENMASK(21, 16) which is written by another
code.

One way is to implement a special function to replace
  rtw89_write32_mask(rtwdev, reg, B_AX_RX_FLTR_CFG_MASK, rtwdev->hal.rx_fltr);
Such as
  rtw89_write_rx_flter(rtwdev, rtwdev->hal.rx_fltr)
  {
    orig = read(reg);
    new = (orig & ~mask) | (data & mask);
    write(new);
  }

Another way is that I add value of B_AX_RX_MPDU_MAX_LEN_MASK into
rtwdev->hal.rx_fltr. Then, just write whole 32-bit, no need mask.

> 
> 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@glid
> er.be/
> in my local tree, which started flagging the use of a discontiguous
> mask with the improved checking in field_prep().

Got it. You are doing "Non-const bitfield helper conversions". 

Ping-Ke

Powered by blists - more mailing lists