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

[Ping-Ke Shih <pkshih@realtek.com>]

Christian Hewitt <christianshewitt@gmail.com> wrote:
> > On 12 Mar 2026, at 6:22 am, Ping-Ke Shih <pkshih@realtek.com> wrote:
> >
> > Christian Hewitt <christianshewitt@gmail.com> wrote:
> >>> On 11 Mar 2026, at 7:05 am, Ping-Ke Shih <pkshih@realtek.com> wrote:
> >>>
> >>> Christian Hewitt <christianshewitt@gmail.com> wrote:
> >>>>
> >>>>> 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 :)
> >>>
> >>> 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?
> >>
> >> I’m not a kernel expert, but I’ve always understood module probe and
> >> load ordering to not be guaranteed; as many things run in parallel and
> >> are highly subjective to the specific hardware capabilities and kernel
> >> config being used.
> >
> > I have heard people about changing sequence/time of kernel modules, so
> > I'd like you can try this method.
> >
> > I did ask AI, it said it is possible to create a .conf file under
> > /etc/modprobe.d/ and use `softdep` syntax to ensure loading sequence.
> > Could you try this?
> 
> I can test this, but even if it works it’s not a fix because modprobe
> confs configured in userspace are only used with loadable modules that
> have been compiled with =m, not build-in modules that are resident in
> kernel memory and compiled with =y; and distros are free to choose how
> their kernel is configured. NB: I’m not sure if there are any general
> kernel rules for this, but I’d expect there to be general principle of
> modules being resilient to transient host states and not depending on
> userspace packaging to load correctly?

I think built-in modules will be loaded sequentially (not in parallel)
by device_initicall(), so BT and WiFi drivers will not read efuse 
at the same time.

> 
> >> 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
> >>
> >> No, because even if we have a 0s delay between each group of modules
> >> being loaded, they are loaded in series, so we workaround the issue.
> >> Tweaking the script to background the module load loops so both run
> >> in parallel would be closer to normal conditions, and I would expect
> >> to start seeing failures and the retry mechanisms within the modules
> >> (as added in this patch) being triggered.
> >
> > Additional question for downloading firmware. As you reported this
> > issue initially (load modules at boot time in parallel), it seems
> > appear this message by chance. Since this driver will retry to download
> > firmware, will it successfully downloads firmware finally? Or it still
> > fails to download after 5 times retry?
> 
> I have only seen firmware load fail a handful of times in many hundreds
> of boots and each time one retry attempt resulted in success. To be
> clear; I have am not reporting firwmare loading as a problem, it is not
> an issue for me. I’ve mentioned it only for context, i.e. it shows that
> a simple retry mechanism is effective at handling the similar issue with
> efuse map.

I have this question because I wonder downloading firmware issue might be
also a reading efuse issue. If so, retry might resolve as well.

As your results, it looks like to retry reading efuse can resolve all
issues you found. What do you think?

Ping-Ke