Problems with rtw89 on 5Ghz wlans.

Problems with rtw89 on 5Ghz wlans.

[PierluigiFrullani]

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 &&
+        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");
+    }
+
     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) {
+            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 

Re: Problems with rtw89 on 5Ghz wlans.

[Bitterblue Smith]

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 &&
> +        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");
> +    }
> +
>      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) {
> +            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.

RE: Problems with rtw89 on 5Ghz wlans.

[Ping-Ke Shih]

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.

Re: Problems with rtw89 on 5Ghz wlans.

[Bitterblue Smith]

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

Re: Problems with rtw89 on 5Ghz wlans.

[Luka Gejak]

On Fri Oct 2, 2026 at 7:02 PM CEST, Bitterblue Smith wrote:
> 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,
>>> 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.

Hi everyone,

I just want to make a quick note here, I have the same issue on my HP 255 G10,
and that commit at [1] fixes the issue, and everything works perfectly now,
wifi is stable, speeds are great and I didn't find any issues while using
my laptop.

Best regards,
Luka Gejak

[1]:https://github.com/morrownr/rtw89/commit/faad39934e2e23efc0df5c247c3bee2be9743b08

RE: Problems with rtw89 on 5Ghz wlans.

[Ping-Ke Shih]

Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> >>> 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?

I checked vendor driver. It looks like this:

        if (phy_hw[0].tx_num == 1 && phy_hw[0].tx_path_num == 2 &&
                phy_hw[0].rx_num == 1 && phy_hw[0].rx_path_num == 2) {

                if (rfe_type == 41) {
                        RF_DBG(rf, DBG_RF_INIT, "%s: rfe_type: %d set to 1T1R\n", __func__, rfe_type);
                        phy_hw[0].tx_path_num = 1;
                        phy_hw[0].rx_path_num = 1;
                } else if (rfe_type == 43) {
                        RF_DBG(rf, DBG_RF_INIT, "%s: rfe_type: %d set to 1T2R\n", __func__, rfe_type);
                        phy_hw[0].tx_path_num = 2;
                        phy_hw[0].rx_path_num = 2;
                }
        }

I'm not sure the "mirror" you menat. 
I feel it is okay to check tx_num/tx_patch_num before doing override the values
at first glance. But think a bit more, it looks like no checking will be also
okay, because I don't think rfe_type 41 can be another configuration.

By the way, my thinking of this patch is 

1. after reading efuse. If rfe_type 41 --> set a quirk
2. by quirk, set BTC
3. by quirk, set tx_nss/tx_ant

With the quirk, it will be easier to understand 2 and 3 related things. 

Re: Problems with rtw89 on 5Ghz wlans.

[Bitterblue Smith]

On 05/10/2026 05:30, Ping-Ke Shih wrote:
> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>>>>> 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?
> 
> I checked vendor driver. It looks like this:
> 
>         if (phy_hw[0].tx_num == 1 && phy_hw[0].tx_path_num == 2 &&
>                 phy_hw[0].rx_num == 1 && phy_hw[0].rx_path_num == 2) {
> 
>                 if (rfe_type == 41) {
>                         RF_DBG(rf, DBG_RF_INIT, "%s: rfe_type: %d set to 1T1R\n", __func__, rfe_type);
>                         phy_hw[0].tx_path_num = 1;
>                         phy_hw[0].rx_path_num = 1;
>                 } else if (rfe_type == 43) {
>                         RF_DBG(rf, DBG_RF_INIT, "%s: rfe_type: %d set to 1T2R\n", __func__, rfe_type);
>                         phy_hw[0].tx_path_num = 2;
>                         phy_hw[0].rx_path_num = 2;
>                 }
>         }
> 
> I'm not sure the "mirror" you menat. 

I meant the check in rtw8852b_btc_set_rfe(). Originally I checked
rfe_type, then later I went back to the vendor driver and traced
where p->phy_cap[0].txss and p->phy_cap[0].rxss came from, and
replaced the rfe_type check with hal->tx_nss and hal->rx_nss.

> I feel it is okay to check tx_num/tx_patch_num before doing override the values
> at first glance. But think a bit more, it looks like no checking will be also
> okay, because I don't think rfe_type 41 can be another configuration.
> 
> By the way, my thinking of this patch is 
> 
> 1. after reading efuse. If rfe_type 41 --> set a quirk
> 2. by quirk, set BTC
> 3. by quirk, set tx_nss/tx_ant
> 
> With the quirk, it will be easier to understand 2 and 3 related things. 

Sounds good.