RE: Problems with rtw89 on 5Ghz wlans.

[Ping-Ke Shih <pkshih@realtek.com>]

Hi Bitterblue,

I just quickly give some comments before you send patch.

Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> On 30/09/2026 12:21, PierluigiFrullani wrote:
> > Hello all,
> >     I'm using Linux Mint 22.1 with kernel 7.0.0-34-generic and a
> > 02:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8852BE PCIe 802.11ax Wireless
> Network Controller [1T1R] [10ec:b85b]
> > that has lot of issues with the 5Ghz wlan.
> > The problem is that has a very low sensitivity and can detect, in linux, these wlans only when I'm
> a few feet from access point.
> >
> >
> > I've then swapped the driver with https://github.com/morrownr/rtw89 and found the same behaviour.
> > I've then opened an issue there :
> >  https://github.com/morrownr/rtw89/issues/128 and the peoples there managed to find the culprit and
> patch his driver that now works perfectly.
> > For my understanding the problem was that my card ( may card model ? ) ( rfe_type 41 ) has only one
> antenna and is not correctly selected b y the driver.
> >
> > Looking into the https://github.com/pkshih/rtw/blob/rtw-next/drivers/net/wireless/realtek/rtw89
> code I can see that is really similar so then patche applied in the morrownr could possibly apply  also
> to the vanilla kernel driver.
> >
> >
> > Patch is rather easy and with this patch allied and this driver loaded now the 5Ghz is perfectly working.
> >
> >
> > Would you be interessed in pushing this patch also here ?
> >
> >
> > In case, this is the patch ( also with the comments to verify that the driver loaded is the one that
> is patched ) :
> > diff --git a/drivers/net/wireless/realtek/rtw89/mac.c b/drivers/net/wireless/realtek/rtw89/mac.c
> > index df396fbfca26..81a4be7a593d 100644
> > --- a/drivers/net/wireless/realtek/rtw89/mac.c
> > +++ b/drivers/net/wireless/realtek/rtw89/mac.c
> > @@ -3244,6 +3244,14 @@ static int rtw89_mac_setup_phycap_part0(struct rtw89_dev *rtwdev)
> >      tx_ant = u32_get_bits(phycap->w3, RTW89_C2HREG_PHYCAP_W3_ANT_TX_NUM);
> >      rx_ant = u32_get_bits(phycap->w3, RTW89_C2HREG_PHYCAP_W3_ANT_RX_NUM);
> >
> > +    if (chip->chip_id == RTL8852B && efuse->rfe_type == 41 &&

Can we add a quirk instead of checking IC and its rfe type?
I guess there might be more than one cases afterward. 

> > +        tx_nss == 1 && tx_ant == 2 && rx_nss == 1 && rx_ant == 2) {
> > +        tx_ant = 1;
> > +        rx_ant = 1;
> > +
> > +        rtw89_warn(rtwdev, "fix more stuff for RFE 41\n");

I think you will change rtw89_warn() to debug level in formal patch, right?

> > +    }
> > +
> >      hal->tx_nss = tx_nss ? min_t(u8, tx_nss, chip->tx_nss) : chip->tx_nss;
> >      hal->rx_nss = rx_nss ? min_t(u8, rx_nss, chip->rx_nss) : chip->rx_nss;
> >
> > diff --git a/drivers/net/wireless/realtek/rtw89/rtw8852b.c
> b/drivers/net/wireless/realtek/rtw89/rtw8852b.c
> > index 356623341f65..c9ee3c76cfc9 100644
> > --- a/drivers/net/wireless/realtek/rtw89/rtw8852b.c
> > +++ b/drivers/net/wireless/realtek/rtw89/rtw8852b.c
> > @@ -771,6 +771,15 @@ static void rtw8852b_btc_set_rfe(struct rtw89_dev *rtwdev)
> >      } else {
> >          md->ant.type = BTC_ANT_SHARED;
> >          md->bt0_pos = BTC_BT_BTG;
> > +
> > +        if (md->rfe_type == 41) {

Use the same quirk by the way. 

> > +            md->ant.num = 1;
> > +            md->ant.single_pos = RF_PATH_B;
> > +            md->ant.btg_pos = RF_PATH_B;
> > +            md->ant.stream_cnt = 1;
> > +
> > +            rtw89_warn(rtwdev, "fix stuff for RFE 41\n");
> > +        }
> >      }
> >      rtwdev->btc.btg_pos = md->ant.btg_pos;
> >      rtwdev->btc.ant_type = md->ant.type;
> >
> >
> >
> > All credits must absolutelly go to  dubhater (   https://github.com/dubhater ) that did all
> troubleshooting and wrote the patch.
> >
> > My interest in this is only to have a (vanilla) kernel version of this driver that works correctly
> as lot of problems are reported by peoples using the same chip.
> >
> >
> >
> > Thanks
> >
> >
> > Pierluigi
> 
> Hi,
> 
> Two other people reported the same problem recently. I decided to wait
> for them to say if the patch helps or not. But I will send the patch
> anyway next week.