On 23/07/2025 12:07, Ping-Ke Shih wrote:
> Piotr Oniszczuk <piotr.oniszczuk@xxxxxxxxx> wrote:
>>> Wiadomość napisana przez Ping-Ke Shih <pkshih@xxxxxxxxxxx> 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);
