Re: Problems with rtw89 on 5Ghz wlans.

[Bitterblue Smith <rtl8821cerfe2@gmail.com>]

On 02/10/2026 06:44, Ping-Ke Shih wrote:
> 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. 
> 

I think that should work.

>>> +        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?
> 

The messages will be gone completely. I only added them to be
sure that Pierluigi is testing the patched code.

>>> +    }
>>> +
>>>      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. 
> 

This was the initial version of the patch. Since then I changed
it to check hal->tx_nss and hal->rx_nss, to mirror what the
vendor driver does. Is that okay?

>>> +            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.
>