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) \> 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.
Would you like me to send a v2 using your revised version? - or?
Christian
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
> On 17 Mar 2026, at 5:37 am, Ping-Ke Shih <pkshih@realtek.com> wrote:
>
> 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.
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
© 2016 - 2026 Red Hat, Inc.