rtl8822cs, mainline 6.16-rc7: kernel reports ' unsupported rf path'

rtl8822cs, mainline 6.16-rc7: kernel reports ' unsupported rf path'

[Piotr Oniszczuk]

Guys,

I’m bringing rk3576 sbc (nanopi-r76s) to mainline linux.

All works well except 8822cs wifi (m2 key module; sdio intf)

my user spacce is iwd 3.9.
linux-fw is current master.
6.16-rc7 without any rtw88 related patches.

8822cs is recognised by kernel but works ok only in 1 per 10 or so boots.
In other 9 non-working cases i’m getting:

1. no any networks are discovered
2. dmesg is stormed with

[  106.684159] rtw88_8822cs mmc1:0001:1: unsupported rf path (1)
[  106.684667] rtw88_8822cs mmc1:0001:1: unsupported rf path (1)
[  106.685169] rtw88_8822cs mmc1:0001:1: unsupported rf path (1)
[  106.716150] rtw88_8822cs mmc1:0001:1: unsupported rf path (1)
[  106.718596] rtw88_8822cs mmc1:0001:1: unsupported rf path (1)
[  106.721630] rtw88_8822cs mmc1:0001:1: unsupported rf path (1)
[  106.722132] rtw88_8822cs mmc1:0001:1: unsupported rf path (1)
[  106.722632] rtw88_8822cs mmc1:0001:1: unsupported rf path (1)
[  106.723132] rtw88_8822cs mmc1:0001:1: unsupported rf path (1)
[  106.723683] rtw88_8822cs mmc1:0001:1: unsupported rf path (1)
[  106.730767] rtw88_8822cs mmc1:0001:1: unsupported rf path (1)
[  109.357579] rtw88_8822cs mmc1:0001:1: unsupported rf path (1)

(full dmesg: https://termbin.com/i1db )

3. comparing debug output of iwd for working and non working states i see:

non-working—————————————————:

Wiphy: 0, Name: phy0
        Permanent Address: 70:68:71:a2:a8:0d
        2.4GHz Band:
                Bitrates (non-HT):
                         1.0 Mbps
                         2.0 Mbps
                         5.5 Mbps
                        11.0 Mbps
                         6.0 Mbps
                         9.0 Mbps
                        12.0 Mbps
                        18.0 Mbps
                        24.0 Mbps
                        36.0 Mbps
                        48.0 Mbps
                        54.0 Mbps
                HT Capabilities:
                        HT40
                        Short GI for 20Mhz
                        Short GI for 40Mhz
                HT RX MCS indexes:
                        0-7
                        32
        5GHz Band:
                Bitrates (non-HT):
                         6.0 Mbps
                         9.0 Mbps
                        12.0 Mbps
                        18.0 Mbps
                        24.0 Mbps
                        36.0 Mbps
                        48.0 Mbps
                        54.0 Mbps
                HT Capabilities:
                        HT40
                        Short GI for 20Mhz
                        Short GI for 40Mhz
                HT RX MCS indexes:
                        0-7
                        32
                VHT Capabilities:
                        Short GI for 80Mhz
                        Max RX MCS: 0-9 for NSS: 1
                        Max TX MCS: 0-9 for NSS: 1
        Ciphers: BIP-CMAC-256 BIP-GMAC-256 BIP-GMAC-128 CCMP-256
                 GCMP-256 GCMP-128 BIP-CMAC-128 CCMP-128
                 TKIP
        Supported iftypes: station


working--------------------------:

Wiphy: 0, Name: phy0
        Permanent Address: 70:68:71:a2:a8:0d
        2.4GHz Band:
                Bitrates (non-HT):
                         1.0 Mbps
                         2.0 Mbps
                         5.5 Mbps
                        11.0 Mbps
                         6.0 Mbps
                         9.0 Mbps
                        12.0 Mbps
                        18.0 Mbps
                        24.0 Mbps
                        36.0 Mbps
                        48.0 Mbps
                        54.0 Mbps
                HT Capabilities:
                        HT40
                        Short GI for 20Mhz
                        Short GI for 40Mhz
                HT RX MCS indexes:
                        0-15
                        32
        5GHz Band:
                Bitrates (non-HT):
                         6.0 Mbps
                         9.0 Mbps
                        12.0 Mbps
                        18.0 Mbps
                        24.0 Mbps
                        36.0 Mbps
                        48.0 Mbps
                        54.0 Mbps
                HT Capabilities:
                        HT40
                        Short GI for 20Mhz
                        Short GI for 40Mhz
                HT RX MCS indexes:
                        0-15
                        32
                VHT Capabilities:
                        Short GI for 80Mhz
                        Max RX MCS: 0-9 for NSS: 2
                        Max TX MCS: 0-9 for NSS: 2
        Ciphers: BIP-CMAC-256 BIP-GMAC-256 BIP-GMAC-128 CCMP-256
                 GCMP-256 GCMP-128 BIP-CMAC-128 CCMP-128
                 TKIP
        Supported iftypes: station


As you see main diff is in HT RX MCS indexes and VHT caps. 

Working: HT RX MCS indexes: 0-15
Non-working: HT RX MCS indexes: 0-7

Isn’t that 8-15 are for 2x2mimo? 
So maybe - by some reason - hw sometimes reports support for only 1x mimo but receives from air 2x mimo (2 streams) and thats why I see hell of "unsupported rf path"  errors from driver?   

My kernel is compiled with  CONFIG_RTW88_DEBUG=y CONFIG_RTW88_DEBUGFS=y - so if there is need for any extra debug info - i’ll be more than happy to provide….

If you have any ideas how to move forward with this - i’ll be more than happy to listen.
  

RE: rtl8822cs, mainline 6.16-rc7: kernel reports ' unsupported rf path'

[Ping-Ke Shih]

Piotr Oniszczuk <piotr.oniszczuk@gmail.com> wrote:

[...]

> 
> Working: HT RX MCS indexes: 0-15
> Non-working: HT RX MCS indexes: 0-7
> 
> Isn’t that 8-15 are for 2x2mimo?
> So maybe - by some reason - hw sometimes reports support for only 1x mimo but receives from air 2x mimo
> (2 streams) and thats why I see hell of "unsupported rf path"  errors from driver?

I think your point is correct that firmware reports incorrect value somehow. 
With below changes, we can check this:

diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
index fa0ed39cb199..3363458a9ea1 100644
--- a/drivers/net/wireless/realtek/rtw88/main.c
+++ b/drivers/net/wireless/realtek/rtw88/main.c
@@ -996,6 +996,9 @@ static void rtw_hw_config_rf_ant_num(struct rtw_dev *rtwdev, u8 hw_ant_num)
                hal->rf_path_num = 1;
                if (!chip->fix_rf_phy_num)
                        hal->rf_phy_num = hal->rf_path_num;
+               printk("%s:%d hal->rf_phy_num=%d hal->rf_path_num=%d hw_ant_num=%d\n",
+                       __func__, __LINE__, hal->rf_phy_num, hal->rf_path_num, hw_ant_num);
+
                hal->antenna_tx = BB_PATH_A;
                hal->antenna_rx = BB_PATH_A;
                break;
@@ -1874,6 +1877,8 @@ static int rtw_chip_parameter_setup(struct rtw_dev *rtwdev)
        }
        hal->rf_phy_num = chip->fix_rf_phy_num ? chip->fix_rf_phy_num :
                          hal->rf_path_num;
+       printk("%s:%d hal->rf_phy_num=%d hal->rf_path_num=%d\n",
+               __func__, __LINE__, hal->rf_phy_num, hal->rf_path_num);

        efuse->physical_size = chip->phy_efuse_size;
        efuse->logical_size = chip->log_efuse_size;


If we found firmware reports incorrect values, let's print out the reported
values by this below to see if we can have useful clues. 

@@ -1948,6 +1953,9 @@ static int rtw_dump_hw_feature(struct rtw_dev *rtwdev)
        for (i = 0; i < HW_FEATURE_LEN; i++)
                hw_feature[i] = rtw_read8(rtwdev, REG_C2HEVT + 2 + i);

+       printk("%s:%d hw_feature = %*ph\n",
+               __func__, __LINE__, HW_FEATURE_LEN, hw_feature);
+
        rtw_write8(rtwdev, REG_C2HEVT, 0);

        bw = GET_EFUSE_HW_CAP_BW(hw_feature);

Re: rtl8822cs, mainline 6.16-rc7: kernel reports ' unsupported rf path'

[Piotr Oniszczuk]

> Wiadomość napisana przez Ping-Ke Shih <pkshih@realtek.com> w dniu 23 lip 2025, o godz. 02:52:
> 
> Piotr Oniszczuk <piotr.oniszczuk@gmail.com> wrote:
> 
> [...]
> 
>> 
>> Working: HT RX MCS indexes: 0-15
>> Non-working: HT RX MCS indexes: 0-7
>> 
>> Isn’t that 8-15 are for 2x2mimo?
>> So maybe - by some reason - hw sometimes reports support for only 1x mimo but receives from air 2x mimo
>> (2 streams) and thats why I see hell of "unsupported rf path"  errors from driver?
> 
> I think your point is correct that firmware reports incorrect value somehow. 
> With below changes, we can check this:
> 
> diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
> index fa0ed39cb199..3363458a9ea1 100644
> --- a/drivers/net/wireless/realtek/rtw88/main.c
> +++ b/drivers/net/wireless/realtek/rtw88/main.


…….


pls find dmesg from:

non-working state: https://termbin.com/8x42
working state: https://termbin.com/b804

ps: a added rtw88 pref to printk’s to easier spot it’s otputs…

RE: rtl8822cs, mainline 6.16-rc7: kernel reports ' unsupported rf path'

[Ping-Ke Shih]

Piotr Oniszczuk <piotr.oniszczuk@gmail.com> wrote:
> > Wiadomość napisana przez Ping-Ke Shih <pkshih@realtek.com> w dniu 23 lip 2025, o godz. 02:52:
> >
> > Piotr Oniszczuk <piotr.oniszczuk@gmail.com> wrote:
> >
> > [...]
> >
> >>
> >> Working: HT RX MCS indexes: 0-15
> >> Non-working: HT RX MCS indexes: 0-7
> >>
> >> Isn’t that 8-15 are for 2x2mimo?
> >> So maybe - by some reason - hw sometimes reports support for only 1x mimo but receives from air 2x mimo
> >> (2 streams) and thats why I see hell of "unsupported rf path"  errors from driver?
> >
> > I think your point is correct that firmware reports incorrect value somehow.
> > With below changes, we can check this:
> >
> > diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
> > index fa0ed39cb199..3363458a9ea1 100644
> > --- a/drivers/net/wireless/realtek/rtw88/main.c
> > +++ b/drivers/net/wireless/realtek/rtw88/main.
> 
> 
> …….
> 
> 
> pls find dmesg from:
> 
> non-working state: https://termbin.com/8x42
> working state: https://termbin.com/b804

The dmsg find 
non-working state:
   rtw88: rtw_chip_parameter_setup:1872 hal->rf_phy_num=1 hal->rf_path_num=1
working state:
   rtw88: rtw_chip_parameter_setup:1872 hal->rf_phy_num=2 hal->rf_path_num=2

They were induced from register 
  #define REG_SYS_CFG1		0x00F0

Please apply below change and share the working/non-working sates.

diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
index fa0ed39cb199..95decf90a43d 100644
--- a/drivers/net/wireless/realtek/rtw88/main.c
+++ b/drivers/net/wireless/realtek/rtw88/main.c
@@ -1861,6 +1864,8 @@ static int rtw_chip_parameter_setup(struct rtw_dev *rtwdev)
        hal->chip_version = rtw_read32(rtwdev, REG_SYS_CFG1);
        hal->cut_version = BIT_GET_CHIP_VER(hal->chip_version);
        hal->mp_chip = (hal->chip_version & BIT_RTL_ID) ? 0 : 1;
+       printk("rtw88: %s:%d hal->chip_version=0x%x\n",
+               __func__, __LINE__, hal->chip_version);
        if (hal->chip_version & BIT_RF_TYPE_ID) {
                hal->rf_type = RF_2T2R;
                hal->rf_path_num = 2;

Re: rtl8822cs, mainline 6.16-rc7: kernel reports ' unsupported rf path'

[Piotr Oniszczuk]

> Wiadomość napisana przez Ping-Ke Shih <pkshih@realtek.com> w dniu 23 lip 2025, o godz. 09:50:
> 
> The dmsg find 
> non-working state:
>   rtw88: rtw_chip_parameter_setup:1872 hal->rf_phy_num=1 hal->rf_path_num=1
> working state:
>   rtw88: rtw_chip_parameter_setup:1872 hal->rf_phy_num=2 hal->rf_path_num=2
> 
> They were induced from register 
>  #define REG_SYS_CFG1 0x00F0
> 
> Please apply below change and share the working/non-working sates.
> 
> diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
> index fa0ed39cb199..95decf90a43d 100644
> --- a/drivers/net/wireless/realtek/rtw88/main.c
> +++ b/drivers/net/wireless/realtek/rtw88/main.c
> @@ -1861,6 +1864,8 @@ static int rtw_chip_parameter_setup(struct rtw_dev *rtwdev)
>        hal->chip_version = rtw_read32(rtwdev, REG_SYS_CFG1);
>        hal->cut_version = BIT_GET_CHIP_VER(hal->chip_version);
>        hal->mp_chip = (hal->chip_version & BIT_RTL_ID) ? 0 : 1;
> +       printk("rtw88: %s:%d hal->chip_version=0x%x\n",
> +               __func__, __LINE__, hal->chip_version);
>        if (hal->chip_version & BIT_RF_TYPE_ID) {
>                hal->rf_type = RF_2T2R;
>                hal->rf_path_num = 2;


here it is:

non-working: https://termbin.com/7goz
working: https://termbin.com/lpsq

RE: rtl8822cs, mainline 6.16-rc7: kernel reports ' unsupported rf path'

[Ping-Ke Shih]

Piotr Oniszczuk <piotr.oniszczuk@gmail.com> wrote:
> > Wiadomość napisana przez Ping-Ke Shih <pkshih@realtek.com> w dniu 23 lip 2025, o godz. 09:50:
> >
> > The dmsg find
> > non-working state:
> >   rtw88: rtw_chip_parameter_setup:1872 hal->rf_phy_num=1 hal->rf_path_num=1
> > working state:
> >   rtw88: rtw_chip_parameter_setup:1872 hal->rf_phy_num=2 hal->rf_path_num=2
> >
> > They were induced from register
> >  #define REG_SYS_CFG1 0x00F0
> >
> > Please apply below change and share the working/non-working sates.
> >
> > diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
> > index fa0ed39cb199..95decf90a43d 100644
> > --- a/drivers/net/wireless/realtek/rtw88/main.c
> > +++ b/drivers/net/wireless/realtek/rtw88/main.c
> > @@ -1861,6 +1864,8 @@ static int rtw_chip_parameter_setup(struct rtw_dev *rtwdev)
> >        hal->chip_version = rtw_read32(rtwdev, REG_SYS_CFG1);
> >        hal->cut_version = BIT_GET_CHIP_VER(hal->chip_version);
> >        hal->mp_chip = (hal->chip_version & BIT_RTL_ID) ? 0 : 1;
> > +       printk("rtw88: %s:%d hal->chip_version=0x%x\n",
> > +               __func__, __LINE__, hal->chip_version);
> >        if (hal->chip_version & BIT_RF_TYPE_ID) {
> >                hal->rf_type = RF_2T2R;
> >                hal->rf_path_num = 2;
> 
> 
> here it is:
> 
> non-working: https://termbin.com/7goz
> working: https://termbin.com/lpsq

Not sure why bit BIT_RF_TYPE_ID (27) is different: 

working state:
   rtw88: rtw_chip_parameter_setup:1859 hal->chip_version=0x493d30ea
non-working state:
   rtw88: rtw_chip_parameter_setup:1859 hal->chip_version=0x303030ea

I'd try to read more times to see if it can become correct...
Also, I force to use correct value at the last iteration to see if it
can work even incorrect value of register 0xF0.

diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
index fa0ed39cb199..137418d1108d 100644
--- a/drivers/net/wireless/realtek/rtw88/main.c
+++ b/drivers/net/wireless/realtek/rtw88/main.c
@@ -1858,9 +1861,14 @@ static int rtw_chip_parameter_setup(struct rtw_dev *rtwdev)
                return -EINVAL;
        }

-       hal->chip_version = rtw_read32(rtwdev, REG_SYS_CFG1);
+       for (int i = 0; i < 20; i++) {
+       hal->chip_version = i == 19 ? 0x493d30ea : rtw_read32(rtwdev, REG_SYS_CFG1);
        hal->cut_version = BIT_GET_CHIP_VER(hal->chip_version);
        hal->mp_chip = (hal->chip_version & BIT_RTL_ID) ? 0 : 1;
+       printk("rtw88: %s:%d hal->chip_version=0x%x\n",
+               __func__, __LINE__, hal->chip_version);
+       mdelay(100);
+       }
        if (hal->chip_version & BIT_RF_TYPE_ID) {
                hal->rf_type = RF_2T2R;
                hal->rf_path_num = 2;

Re: rtl8822cs, mainline 6.16-rc7: kernel reports ' unsupported rf path'

[Piotr Oniszczuk]

> Wiadomość napisana przez Ping-Ke Shih <pkshih@realtek.com> w dniu 23 lip 2025, o godz. 10:19:
> 
> working state:
>   rtw88: rtw_chip_parameter_setup:1859 hal->chip_version=0x493d30ea
> non-working state:
>   rtw88: rtw_chip_parameter_setup:1859 hal->chip_version=0x303030ea
> 
> I'd try to read more times to see if it can become correct...
> Also, I force to use correct value at the last iteration to see if it
> can work even incorrect value of register 0xF0.
> 
> diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
> index fa0ed39cb199..137418d1108d 100644
> --- a/drivers/net/wireless/realtek/rtw88/main.c
> +++ b/drivers/net/wireless/realtek/rtw88/main.c
> @@ -1858,9 +1861,14 @@ static int rtw_chip_parameter_setup(struct rtw_dev *rtwdev)
>                return -EINVAL;
>        }
> 
> -       hal->chip_version = rtw_read32(rtwdev, REG_SYS_CFG1);
> +       for (int i = 0; i < 20; i++) {
> +       hal->chip_version = i == 19 ? 0x493d30ea : rtw_read32(rtwdev, REG_SYS_CFG1);
>        hal->cut_version = BIT_GET_CHIP_VER(hal->chip_version);
>        hal->mp_chip = (hal->chip_version & BIT_RTL_ID) ? 0 : 1;
> +       printk("rtw88: %s:%d hal->chip_version=0x%x\n",
> +               __func__, __LINE__, hal->chip_version);
> +       mdelay(100);
> +       }
>        if (hal->chip_version & BIT_RF_TYPE_ID) {
>                hal->rf_type = RF_2T2R;
>                hal->rf_path_num = 2;
> 
> 

well - with above patch all starts to work well :-)
10 boots, 10 working wifi with correct scans.

demsg from working sys: https://termbin.com/bhs4

RE: rtl8822cs, mainline 6.16-rc7: kernel reports ' unsupported rf path'

[Ping-Ke Shih]

Piotr Oniszczuk <piotr.oniszczuk@gmail.com> wrote:
> > Wiadomość napisana przez Ping-Ke Shih <pkshih@realtek.com> w dniu 23 lip 2025, o godz. 10:19:
> >
> > working state:
> >   rtw88: rtw_chip_parameter_setup:1859 hal->chip_version=0x493d30ea
> > non-working state:
> >   rtw88: rtw_chip_parameter_setup:1859 hal->chip_version=0x303030ea
> >
> > I'd try to read more times to see if it can become correct...
> > Also, I force to use correct value at the last iteration to see if it
> > can work even incorrect value of register 0xF0.
> >
> > diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
> > index fa0ed39cb199..137418d1108d 100644
> > --- a/drivers/net/wireless/realtek/rtw88/main.c
> > +++ b/drivers/net/wireless/realtek/rtw88/main.c
> > @@ -1858,9 +1861,14 @@ static int rtw_chip_parameter_setup(struct rtw_dev *rtwdev)
> >                return -EINVAL;
> >        }
> >
> > -       hal->chip_version = rtw_read32(rtwdev, REG_SYS_CFG1);
> > +       for (int i = 0; i < 20; i++) {
> > +       hal->chip_version = i == 19 ? 0x493d30ea : rtw_read32(rtwdev, REG_SYS_CFG1);
> >        hal->cut_version = BIT_GET_CHIP_VER(hal->chip_version);
> >        hal->mp_chip = (hal->chip_version & BIT_RTL_ID) ? 0 : 1;
> > +       printk("rtw88: %s:%d hal->chip_version=0x%x\n",
> > +               __func__, __LINE__, hal->chip_version);
> > +       mdelay(100);
> > +       }
> >        if (hal->chip_version & BIT_RF_TYPE_ID) {
> >                hal->rf_type = RF_2T2R;
> >                hal->rf_path_num = 2;
> >
> >
> 
> well - with above patch all starts to work well :-)
> 10 boots, 10 working wifi with correct scans.

Good.

> 
> demsg from working sys: https://termbin.com/bhs4

Unfortunately, the log said:
first read:
  rtw88: rtw_chip_parameter_setup:1860 hal->chip_version=0x303030ea
2nd~19th read:
  rtw88: rtw_chip_parameter_setup:1860 hal->chip_version=0x30303030

Not sure if I can use this pattern to make a workaround. I think the better
way would be to use firmware report to fix this. I'll try to make a patch
and get back to you soon.

Re: rtl8822cs, mainline 6.16-rc7: kernel reports ' unsupported rf path'

[Bitterblue Smith]

On 23/07/2025 12:07, Ping-Ke Shih wrote:
> Piotr Oniszczuk <piotr.oniszczuk@gmail.com> wrote:
>>> Wiadomość napisana przez Ping-Ke Shih <pkshih@realtek.com> w dniu 23 lip 2025, o godz. 10:19:
>>>
>>> working state:
>>>   rtw88: rtw_chip_parameter_setup:1859 hal->chip_version=0x493d30ea
>>> non-working state:
>>>   rtw88: rtw_chip_parameter_setup:1859 hal->chip_version=0x303030ea
>>>
>>> I'd try to read more times to see if it can become correct...
>>> Also, I force to use correct value at the last iteration to see if it
>>> can work even incorrect value of register 0xF0.
>>>
>>> diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
>>> index fa0ed39cb199..137418d1108d 100644
>>> --- a/drivers/net/wireless/realtek/rtw88/main.c
>>> +++ b/drivers/net/wireless/realtek/rtw88/main.c
>>> @@ -1858,9 +1861,14 @@ static int rtw_chip_parameter_setup(struct rtw_dev *rtwdev)
>>>                return -EINVAL;
>>>        }
>>>
>>> -       hal->chip_version = rtw_read32(rtwdev, REG_SYS_CFG1);
>>> +       for (int i = 0; i < 20; i++) {
>>> +       hal->chip_version = i == 19 ? 0x493d30ea : rtw_read32(rtwdev, REG_SYS_CFG1);
>>>        hal->cut_version = BIT_GET_CHIP_VER(hal->chip_version);
>>>        hal->mp_chip = (hal->chip_version & BIT_RTL_ID) ? 0 : 1;
>>> +       printk("rtw88: %s:%d hal->chip_version=0x%x\n",
>>> +               __func__, __LINE__, hal->chip_version);
>>> +       mdelay(100);
>>> +       }
>>>        if (hal->chip_version & BIT_RF_TYPE_ID) {
>>>                hal->rf_type = RF_2T2R;
>>>                hal->rf_path_num = 2;
>>>
>>>
>>
>> well - with above patch all starts to work well :-)
>> 10 boots, 10 working wifi with correct scans.
> 
> Good.
> 
>>
>> demsg from working sys: https://termbin.com/bhs4
> 
> Unfortunately, the log said:
> first read:
>   rtw88: rtw_chip_parameter_setup:1860 hal->chip_version=0x303030ea
> 2nd~19th read:
>   rtw88: rtw_chip_parameter_setup:1860 hal->chip_version=0x30303030
> 
> Not sure if I can use this pattern to make a workaround. I think the better
> way would be to use firmware report to fix this. I'll try to make a patch
> and get back to you soon.
> 
> 

Maybe there is a mistake in rtw_sdio_read32() ? It's pretty complicated.
The equivalent function in the vendor driver is reg_r32_sdio_8822c().
I think for reading REG_SYS_CFG1 in rtw_chip_parameter_setup() it needs
to do the indirect read in the snippet below:

u32
reg_r32_sdio_8822c(struct halmac_adapter *adapter, u32 offset)
{
	enum halmac_ret_status status = HALMAC_RET_SUCCESS;
	union {
		__le32 dword;
		u8 byte[4];
	} value32 = { 0x00000000 };

	if (((offset & 0xFFFF0000) == 0) &&
	    adapter->halmac_state.mac_pwr == HALMAC_MAC_POWER_OFF) {
		return r_indir_sdio_88xx(adapter, offset, HALMAC_IO_DWORD);


But the conditions for doing an indirect read in rtw_sdio_read32() are
a bit different.

You can add this message to check:

diff --git a/drivers/net/wireless/realtek/rtw88/sdio.c b/drivers/net/wireless/realtek/rtw88/sdio.c
index d26bc8a5c2e8..f8f055b6e884 100644
--- a/drivers/net/wireless/realtek/rtw88/sdio.c
+++ b/drivers/net/wireless/realtek/rtw88/sdio.c
@@ -314,6 +314,9 @@ static u32 rtw_sdio_read32(struct rtw_dev *rtwdev, u32 addr)
 	addr = rtw_sdio_to_io_address(rtwdev, addr, direct);
 	bus_claim = rtw_sdio_bus_claim_needed(rtwsdio);
 
+	if (addr == REG_SYS_CFG1)
+		printk("%s: addr %#x direct %d\n", __func__, addr, direct);
+
 	if (bus_claim)
 		sdio_claim_host(rtwsdio->sdio_func);

Re: rtl8822cs, mainline 6.16-rc7: kernel reports ' unsupported rf path'

[Ping-Ke Shih]

Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> 
> On 23/07/2025 12:07, Ping-Ke Shih wrote:
> > Piotr Oniszczuk <piotr.oniszczuk@gmail.com> wrote:
> >>> Wiadomość napisana przez Ping-Ke Shih <pkshih@realtek.com> w dniu 23 lip 2025, o godz. 10:19:
> >>>
> >>> working state:
> >>>   rtw88: rtw_chip_parameter_setup:1859 hal->chip_version=0x493d30ea
> >>> non-working state:
> >>>   rtw88: rtw_chip_parameter_setup:1859 hal->chip_version=0x303030ea
> >>>
> >>> I'd try to read more times to see if it can become correct...
> >>> Also, I force to use correct value at the last iteration to see if it
> >>> can work even incorrect value of register 0xF0.
> >>>
> >>> diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
> >>> index fa0ed39cb199..137418d1108d 100644
> >>> --- a/drivers/net/wireless/realtek/rtw88/main.c
> >>> +++ b/drivers/net/wireless/realtek/rtw88/main.c
> >>> @@ -1858,9 +1861,14 @@ static int rtw_chip_parameter_setup(struct rtw_dev *rtwdev)
> >>>                return -EINVAL;
> >>>        }
> >>>
> >>> -       hal->chip_version = rtw_read32(rtwdev, REG_SYS_CFG1);
> >>> +       for (int i = 0; i < 20; i++) {
> >>> +       hal->chip_version = i == 19 ? 0x493d30ea : rtw_read32(rtwdev, REG_SYS_CFG1);
> >>>        hal->cut_version = BIT_GET_CHIP_VER(hal->chip_version);
> >>>        hal->mp_chip = (hal->chip_version & BIT_RTL_ID) ? 0 : 1;
> >>> +       printk("rtw88: %s:%d hal->chip_version=0x%x\n",
> >>> +               __func__, __LINE__, hal->chip_version);
> >>> +       mdelay(100);
> >>> +       }
> >>>        if (hal->chip_version & BIT_RF_TYPE_ID) {
> >>>                hal->rf_type = RF_2T2R;
> >>>                hal->rf_path_num = 2;
> >>>
> >>>
> >>
> >> well - with above patch all starts to work well :-)
> >> 10 boots, 10 working wifi with correct scans.
> >
> > Good.
> >
> >>
> >> demsg from working sys: https://termbin.com/bhs4
> >
> > Unfortunately, the log said:
> > first read:
> >   rtw88: rtw_chip_parameter_setup:1860 hal->chip_version=0x303030ea
> > 2nd~19th read:
> >   rtw88: rtw_chip_parameter_setup:1860 hal->chip_version=0x30303030
> >
> > Not sure if I can use this pattern to make a workaround. I think the better
> > way would be to use firmware report to fix this. I'll try to make a patch
> > and get back to you soon.
> >
> >
> 
> Maybe there is a mistake in rtw_sdio_read32() ? It's pretty complicated.
> The equivalent function in the vendor driver is reg_r32_sdio_8822c().
> I think for reading REG_SYS_CFG1 in rtw_chip_parameter_setup() it needs
> to do the indirect read in the snippet below:
> 
> u32
> reg_r32_sdio_8822c(struct halmac_adapter *adapter, u32 offset)
> {
>         enum halmac_ret_status status = HALMAC_RET_SUCCESS;
>         union {
>                 __le32 dword;
>                 u8 byte[4];
>         } value32 = { 0x00000000 };
> 
>         if (((offset & 0xFFFF0000) == 0) &&
>             adapter->halmac_state.mac_pwr == HALMAC_MAC_POWER_OFF) {
>                 return r_indir_sdio_88xx(adapter, offset, HALMAC_IO_DWORD);

Thanks for the hints. I think it's worth to try:

diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
index fa0ed39cb199..5ea13c775796 100644
--- a/drivers/net/wireless/realtek/rtw88/main.c
+++ b/drivers/net/wireless/realtek/rtw88/main.c
@@ -1861,6 +1861,8 @@ static int rtw_chip_parameter_setup(struct rtw_dev *rtwdev)
        hal->chip_version = rtw_read32(rtwdev, REG_SYS_CFG1);
        hal->cut_version = BIT_GET_CHIP_VER(hal->chip_version);
        hal->mp_chip = (hal->chip_version & BIT_RTL_ID) ? 0 : 1;
+       printk("rtw88: %s:%d hal->chip_version=0x%x\n",
+               __func__, __LINE__, hal->chip_version);
        if (hal->chip_version & BIT_RF_TYPE_ID) {
                hal->rf_type = RF_2T2R;
                hal->rf_path_num = 2;
diff --git a/drivers/net/wireless/realtek/rtw88/sdio.c b/drivers/net/wireless/realtek/rtw88/sdio.c
index cc2d4fef3587..5c9e7c8cdd7e 100644
--- a/drivers/net/wireless/realtek/rtw88/sdio.c
+++ b/drivers/net/wireless/realtek/rtw88/sdio.c
@@ -144,6 +144,10 @@ static u32 rtw_sdio_to_io_address(struct rtw_dev *rtwdev, u32 addr,
 
 static bool rtw_sdio_use_direct_io(struct rtw_dev *rtwdev, u32 addr)
 {
+       if (!rtw_sdio_is_bus_addr(addr) &&
+           !test_bit(RTW_FLAG_POWERON, rtwdev->flags))
+               return false;
+
        return !rtw_sdio_is_sdio30_supported(rtwdev) ||
                rtw_sdio_is_bus_addr(addr);
 }

Re: rtl8822cs, mainline 6.16-rc7: kernel reports ' unsupported rf path'

[Piotr Oniszczuk]

> Wiadomość napisana przez Ping-Ke Shih <pkshih@realtek.com> w dniu 23 lip 2025, o godz. 14:23:
> 
> Thanks for the hints. I think it's worth to try:
> 
> diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
> index fa0ed39cb199..5ea13c775796 100644
> --- a/drivers/net/wireless/realtek/rtw88/main.c
> +++ b/drivers/net/wireless/realtek/rtw88/main.c
> @@ -1861,6 +1861,8 @@ static int rtw_chip_parameter_setup(struct rtw_dev *rtwdev)
>        hal->chip_version = rtw_read32(rtwdev, REG_SYS_CFG1);
>        hal->cut_version = BIT_GET_CHIP_VER(hal->chip_version);
>        hal->mp_chip = (hal->chip_version & BIT_RTL_ID) ? 0 : 1;
> +       printk("rtw88: %s:%d hal->chip_version=0x%x\n",
> +               __func__, __LINE__, hal->chip_version);
>        if (hal->chip_version & BIT_RF_TYPE_ID) {
>                hal->rf_type = RF_2T2R;
>                hal->rf_path_num = 2;
> diff --git a/drivers/net/wireless/realtek/rtw88/sdio.c b/drivers/net/wireless/realtek/rtw88/sdio.c
> index cc2d4fef3587..5c9e7c8cdd7e 100644
> --- a/drivers/net/wireless/realtek/rtw88/sdio.c
> +++ b/drivers/net/wireless/realtek/rtw88/sdio.c
> @@ -144,6 +144,10 @@ static u32 rtw_sdio_to_io_address(struct rtw_dev *rtwdev, u32 addr,
> 
> static bool rtw_sdio_use_direct_io(struct rtw_dev *rtwdev, u32 addr)
> {
> +       if (!rtw_sdio_is_bus_addr(addr) &&
> +           !test_bit(RTW_FLAG_POWERON, rtwdev->flags))
> +               return false;
> +
>        return !rtw_sdio_is_sdio30_supported(rtwdev) ||
>                rtw_sdio_is_bus_addr(addr);
> }
> 

With this change all works ok.
15 boots and all 15 were with nice wifi :-)

 dmesg from working system: https://termbin.com/09a1

RE: rtl8822cs, mainline 6.16-rc7: kernel reports ' unsupported rf path'

[Ping-Ke Shih]

Piotr Oniszczuk <piotr.oniszczuk@gmail.com> wrote:
> > Wiadomość napisana przez Ping-Ke Shih <pkshih@realtek.com> w dniu 23 lip 2025, o godz. 14:23:
> >
> > Thanks for the hints. I think it's worth to try:
> >
> > diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
> > index fa0ed39cb199..5ea13c775796 100644
> > --- a/drivers/net/wireless/realtek/rtw88/main.c
> > +++ b/drivers/net/wireless/realtek/rtw88/main.c
> > @@ -1861,6 +1861,8 @@ static int rtw_chip_parameter_setup(struct rtw_dev *rtwdev)
> >        hal->chip_version = rtw_read32(rtwdev, REG_SYS_CFG1);
> >        hal->cut_version = BIT_GET_CHIP_VER(hal->chip_version);
> >        hal->mp_chip = (hal->chip_version & BIT_RTL_ID) ? 0 : 1;
> > +       printk("rtw88: %s:%d hal->chip_version=0x%x\n",
> > +               __func__, __LINE__, hal->chip_version);
> >        if (hal->chip_version & BIT_RF_TYPE_ID) {
> >                hal->rf_type = RF_2T2R;
> >                hal->rf_path_num = 2;
> > diff --git a/drivers/net/wireless/realtek/rtw88/sdio.c b/drivers/net/wireless/realtek/rtw88/sdio.c
> > index cc2d4fef3587..5c9e7c8cdd7e 100644
> > --- a/drivers/net/wireless/realtek/rtw88/sdio.c
> > +++ b/drivers/net/wireless/realtek/rtw88/sdio.c
> > @@ -144,6 +144,10 @@ static u32 rtw_sdio_to_io_address(struct rtw_dev *rtwdev, u32 addr,
> >
> > static bool rtw_sdio_use_direct_io(struct rtw_dev *rtwdev, u32 addr)
> > {
> > +       if (!rtw_sdio_is_bus_addr(addr) &&
> > +           !test_bit(RTW_FLAG_POWERON, rtwdev->flags))
> > +               return false;
> > +
> >        return !rtw_sdio_is_sdio30_supported(rtwdev) ||
> >                rtw_sdio_is_bus_addr(addr);
> > }
> >
> 
> With this change all works ok.
> 15 boots and all 15 were with nice wifi :-)
> 
>  dmesg from working system: https://termbin.com/09a1

I sent a patch [1] with a change that check RTW_FLAG_POWERON flag first, 
so things will be the same as this final try. Still want you test the patch
again, and give me a Tested-by tag there. Thanks.

[1] https://lore.kernel.org/linux-wireless/20250724004815.7043-1-pkshih@realtek.com/T/#u

Re: rtl8822cs, mainline 6.16-rc7: kernel reports ' unsupported rf path'

[Piotr Oniszczuk]

> Wiadomość napisana przez Ping-Ke Shih <pkshih@realtek.com> w dniu 24 lip 2025, o godz. 02:52:
> 
> I sent a patch [1] with a change that check RTW_FLAG_POWERON flag first, 
> so things will be the same as this final try. Still want you test the patch
> again, and give me a Tested-by tag there. Thanks.
> 
> [1] https://lore.kernel.org/linux-wireless/20250724004815.7043-1-pkshih@realtek.com/T/#u
> 
> 

I give test and with this patch issue disappear.
thx for fixing this!

pla add 

Tested-by: Piotr Oniszczuk <piotr.oniszczuk@gmail.com <mailto:piotr.oniszczuk@gmail.com>>

RE: rtl8822cs, mainline 6.16-rc7: kernel reports ' unsupported rf path'

[Ping-Ke Shih]

Piotr Oniszczuk <piotr.oniszczuk@gmail.com> wrote:
> > Wiadomość napisana przez Ping-Ke Shih <pkshih@realtek.com> w dniu 24 lip 2025, o godz. 02:52:
> >
> > I sent a patch [1] with a change that check RTW_FLAG_POWERON flag first,
> > so things will be the same as this final try. Still want you test the patch
> > again, and give me a Tested-by tag there. Thanks.
> >
> > [1] https://lore.kernel.org/linux-wireless/20250724004815.7043-1-pkshih@realtek.com/T/#u
> >
> >
> 
> I give test and with this patch issue disappear.
> thx for fixing this!
> 
> pla add
> 
> Tested-by: Piotr Oniszczuk <piotr.oniszczuk@gmail.com <mailto:piotr.oniszczuk@gmail.com>>

Could you please add this tag to the patch? Then, your Tested-by will be added
into commit message during getting merged.