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

Ping-Ke