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

From: Christian Hewitt

Date: Tue Mar 17 2026 - 02:16:09 EST

> On 17 Mar 2026, at 5:37 am, Ping-Ke Shih <pkshih@xxxxxxxxxxx> wrote:
>
> Christian Hewitt <christianshewitt@xxxxxxxxx> wrote:
>>> On 16 Mar 2026, at 9:32 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.
>>>>
>>>> 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@xxxxxxxxx>
>>>
>>> [...]
>>>
>>>>
>>>> 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.

Understood.

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

I’ve never noticed a long loading time for the BT module and timings seem
to be consistent both with and without the patch (and not a problem).

>> Would you like me to send a v2 using your revised version? - or?
>
> Yes, please help v2.

Thanks, will send v2 later today.

Christian