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 16 Mar 2026, at 9:32 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.
> >>
> >> The root cause is a timing race during boot: the WiFi driver's
> >> chip initialization (firmware download via PCIe) overlaps with the
> >> Bluetooth firmware download to the same combo chip over USB. This
> >> can leave the efuse controller temporarily unavailable when the
> >> WiFi driver attempts to read the efuse map.
> >>
> >> Add a retry loop (up to 3 attempts with 500ms delays) around the
> >> physical efuse map dump in rtw89_parse_efuse_map_ax(). The firmware
> >> download path already retries up to 5 times, but the efuse read
> >> that follows has no retry logic, making it the weak link in the
> >> probe sequence.
> >
> > I'd prefer adding a wrapper to retry 5 times without delay as bottom
> > changes for reference. If you want to limit retry only for
> > 'dav == false' case, it is also fine to me.
> >
> >>
> >> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
> >
> > [...]
> >
> >>
> >> drivers/net/wireless/realtek/rtw89/efuse.c | 13 ++++++++++++-
> >> 1 file changed, 12 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/net/wireless/realtek/rtw89/efuse.c
> >> b/drivers/net/wireless/realtek/rtw89/efuse.c
> >> index a2757a88d55d..d506f04ffd6c 100644
> >> --- a/drivers/net/wireless/realtek/rtw89/efuse.c
> >> +++ b/drivers/net/wireless/realtek/rtw89/efuse.c
> >> @@ -270,6 +270,7 @@ int rtw89_parse_efuse_map_ax(struct rtw89_dev *rtwdev)
> >>        u8 *log_map = NULL;
> >>        u8 *dav_phy_map = NULL;
> >>        u8 *dav_log_map = NULL;
> >> +       int retry;
> >>        int ret;
> >>
> >>        if (rtw89_read16(rtwdev, R_AX_SYS_WL_EFUSE_CTRL) &
> B_AX_AUTOLOAD_SUS)
> >> @@ -289,7 +290,17 @@ int rtw89_parse_efuse_map_ax(struct rtw89_dev *rtwdev)
> >>                goto out_free;
> >>        }
> >>
> >> -       ret = rtw89_dump_physical_efuse_map(rtwdev, phy_map, 0, phy_size,
> >> false);
> >> +       for (retry = 0; retry < 3; retry++) {
> >> +               if (retry) {
> >> +                       rtw89_warn(rtwdev, "efuse dump failed, retrying
> >> (%d)\n",
> >> +                                  retry);
> >> +                       fsleep(500000);
> >> +               }
> >> +               ret = rtw89_dump_physical_efuse_map(rtwdev, phy_map, 0,
> >> +                                                   phy_size, false);
> >> +               if (!ret)
> >> +                       break;
> >> +       }
> >>        if (ret) {
> >>                rtw89_warn(rtwdev, "failed to dump efuse physical map\n");
> >>                goto out_free;
> >> --
> >> 2.43.0
> >
> > How about retrying 5 times without fsleep(500000)?
> >
> > diff --git a/drivers/net/wireless/realtek/rtw89/efuse.c
> b/drivers/net/wireless/realtek/rtw89/efuse.c
> > index a2757a88d55d..89d4b1b865f8 100644
> > --- a/drivers/net/wireless/realtek/rtw89/efuse.c
> > +++ b/drivers/net/wireless/realtek/rtw89/efuse.c
> > @@ -185,8 +185,8 @@ static int rtw89_dump_physical_efuse_map_dav(struct
> rtw89_dev *rtwdev, u8 *map,
> >        return 0;
> > }
> >
> > -static int rtw89_dump_physical_efuse_map(struct rtw89_dev *rtwdev, u8 *map,
> > -                                        u32 dump_addr, u32 dump_size, bool
> dav)
> > +static int __rtw89_dump_physical_efuse_map(struct rtw89_dev *rtwdev, u8
> *map,
> > +                                          u32 dump_addr, u32 dump_size,
> bool dav)
> > {
> >        int ret;
> >
> > @@ -208,6 +208,25 @@ static int rtw89_dump_physical_efuse_map(struct rtw89_dev
> *rtwdev, u8 *map,
> >        return 0;
> > }
> >
> > +static int rtw89_dump_physical_efuse_map(struct rtw89_dev *rtwdev, u8 *map,
> > +                                        u32 dump_addr, u32 dump_size, bool
> dav)
> > +{
> > +       int retry;
> > +       int ret;
> > +
> > +       for (retry = 0; retry < 5; retry++) {
> > +               ret = __rtw89_dump_physical_efuse_map(rtwdev, map,
> dump_addr,
> > +                                                     dump_size, dav);
> > +               if (!ret)
> > +                       return 0;
> > +
> > +               rtw89_warn(rtwdev, "efuse dump (dav=%d) failed, retrying
> (%d)\n",
> > +                          dav, retry);
> > +       }
> > +
> > +       return ret;
> > +}
> > +
> > #define invalid_efuse_header(hdr1, hdr2) \
> >        ((hdr1) == 0xff || (hdr2) == 0xff)
> > #define invalid_efuse_content(word_en, i) \
> 
> I’ve run some boot tests and this also resolves my efuse map use-case, e.g.
> 
> ROCK5B:~ # dmesg | grep rtw89
> [    6.506375] rtw89_8852be 0002:21:00.0: loaded firmware
> rtw89/rtw8852b_fw-1.bin
> [    6.506539] rtw89_8852be 0002:21:00.0: enabling device (0000 -> 0003)
> [    6.516069] rtw89_8852be 0002:21:00.0: Firmware version 0.29.29.15
> (6fb3ec41), cmd version 0, type 5
> [    6.516083] rtw89_8852be 0002:21:00.0: Firmware version 0.29.29.15
> (6fb3ec41), cmd version 0, type 3
> [   10.153731] rtw89_8852be 0002:21:00.0: efuse dump (dav=0) failed, retrying
> (0)
> [   10.405347] rtw89_8852be 0002:21:00.0: chip info CID: 0, CV: 1, AID: 0, ACV:
> 1, RFE: 1
> [   10.408311] rtw89_8852be 0002:21:00.0: rfkill hardware state changed to
> enable
> 
> So far I haven’t observed more than 1x retry being required, and there are no
> issues with loading the BT module.

My changes do retry for 5 times, because your patch does 3 times retry plus
additional 500ms delay. I feel you want around 5 seconds for loading BT module.

Did you mean for now you can't reproduce the situation that long loading
time of BT module? (But it took long time days ago?)

> 
> Would you like me to send a v2 using your revised version? - or?

Yes, please help v2.

Ping-Ke