Re: [PATCH] wifi: rtw89: retry efuse physical map dump on transient failure

[Christian Hewitt <christianshewitt@gmail.com>]

> On 9 Mar 2026, at 6:35 am, Ping-Ke Shih <pkshih@realtek.com> wrote:
> 
> Christian Hewitt <christianshewitt@gmail.com> wrote:
>> 
>>> On 2 Mar 2026, at 10:04 am, Ping-Ke Shih <pkshih@realtek.com> wrote:
>>> 
>>> Christian Hewitt <christianshewitt@gmail.com> wrote:
>>>>> On 2 Mar 2026, at 9:47 am, Ping-Ke Shih <pkshih@realtek.com> wrote:
>>>>> 
>>>>> Christian Hewitt <christianshewitt@gmail.com> wrote:
>>>>>> On Radxa Rock 5B with a RTL8852BE combo WiFi/BT card, the efuse
>>>>>> physical map dump intermittently fails with -EBUSY during probe.
>>>>>> The failure occurs in rtw89_dump_physical_efuse_map_ddv() where
>>>>>> read_poll_timeout_atomic() times out waiting for the B_AX_EF_RDY
>>>>>> bit after 1 second.
>>>>> 
>>>>> I'm checking internally how we handle this case.
> 
> Sorry for the late. 
> 
> We encountered WiFi/BT reading efuse at the same time causing similar
> problem as yours. The workaround is like yours, which adds timeout 
> time.
> 
>>>>> 
>>>>> [...]
>>>>> 
>>>>>> 
>>>>>> For context, firmware also fails (and recovers) sometimes:
>>>>> 
>>>>> Did you mean this doesn't always happen? sometimes?
>>>> 
>>>> It’s another intermittent behaviour observed on this board (and not
>>>> related to the issue this patch targets). It occurs less frequently
>>>> than the efuse issue and the existing retry mechanism in the driver
>>>> ensures firmware load always succeeds.
> 
> This might be the same cause due to reading efuse in firmware. 
> 
> Though we can add more timeout and retry times as workaround, I wonder
> if you can control loading time of WiFi and BT kernel modules? 
> 
> More, can you do experiment that you load BT module first, and then load
> WiFi module after 10 seconds (choose a large number intentionally, or
> even larger)?

https://paste.libreelec.tv/charmed-turkey.sh

I’ve run the above script ^ which removes the wifi and bt modules in
sequence then reloads them in the reverse order with a delay between
bt and wifi modules loading, then checks for error messages. Over 200
test cycles with a 10s delay all were clean (no errors). I also ran
cycles with a 2 second delay and 0 second delay before starting wifi
module load and those were clear too. I guess that proves sequencing
avoids the efuse contention issue? - although it’s not possible in
the real-world so not sure there’s huge value in knowing that :)

Christian