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

[Ping-Ke Shih]

Christian Hewitt <christianshewitt@xxxxxxxxx> wrote:
> 
> > On 9 Mar 2026, at 6:35 am, Ping-Ke Shih <pkshih@xxxxxxxxxxx> wrote:
> >
> > Christian Hewitt <christianshewitt@xxxxxxxxx> wrote:
> >>
> >>> On 2 Mar 2026, at 10:04 am, Ping-Ke Shih <pkshih@xxxxxxxxxxx> wrote:
> >>>
> >>> Christian Hewitt <christianshewitt@xxxxxxxxx> wrote:
> >>>>> On 2 Mar 2026, at 9:47 am, Ping-Ke Shih <pkshih@xxxxxxxxxxx> wrote:
> >>>>>
> >>>>> Christian Hewitt <christianshewitt@xxxxxxxxx> 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 :)

Thanks for the experiments. 

Still want to know is it possible to change sequence/time of loading
kernel modules at boot time from system level? I mean can you adjust
the sequence in the Rock 5B board?

In addition, did below messages not appear in these experiments? 

[    7.864148] rtw89_8852be 0002:21:00.0: fw security fail
[    7.864154] rtw89_8852be 0002:21:00.0: download firmware fail

Ping-Ke