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

[Bitterblue Smith <rtl8821cerfe2@gmail.com>]

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);