Re: [RFC PATCH v1 0/9] wifi: rtw88: add RTL8723B/RTL8723BS support

["Luka Gejak" <luka.gejak@linux.dev>]

On Tue Jul 21, 2026 at 4:47 PM CEST, Bitterblue Smith wrote:
> On 21/07/2026 13:55, Luka Gejak wrote:
>> Hi Ping-Ke,
>> 
>> Thanks, and noted on stopping the v1 review. Before I send v2 I want to
>> report two things: the firmware experiment you suggested, and what I
>> found when I tried to work out which patches are actually droppable.
>> 
>> 1. Firmware
>> 
>> I tried all of them, plus the staging blob:
>> 
>>   rtlwifi/rtl8723befw.bin      loads, version 15.17.0, associates
>>   rtlwifi/rtl8723befw_36.bin   loads, version 36.0.0,  associates
>>   rtlwifi/rtl8723bs_nic.bin    loads, version 35.0.0,  associates
>> 
>> So the driver runs on all of them. But the coex reading does not change:
>> BT Rpt stays 0x00000069 on every one, byte for byte. That makes sense in
>> hindsight, since the version is reported by the BT firmware
>> (rtl_bt/rtl8723bs_fw.bin) and relayed through, so no WiFi firmware can
>> move it. rtl8723bs_nic.bin additionally produced 72 RA report WARNs,
>> because the driver sets c2h_ra_report_size = 4 for the v41 report format
>> where the siblings use 7.
>> 
>> Since the driver was developed and tuned against v41 and swapping the
>> blob does not help coex, I am keeping v41 and leaving the linux-firmware
>> submission as it is rather than withdrawing it. If you would still
>> rather I hold it, say so and I will.
>> ,
>> I have not closed the coex question, and I no longer think it can be
>> closed from this driver.
>> 
>> The driver does ask: rtw_fw_query_bt_info() goes out on the connect and
>> scan paths and at power on. The BT side answers, so this is not a
>> missing or timed out request. The answer is the problem. With A2DP
>> streaming it reports conn-idle and an empty profile list,
>> BT_RSP = 01 01 40 12, while the same dump shows 440 low priority packets
>> each way. The profile byte stays 0x01 (CONNECTION) and never sets A2DP
>> or ACL_BUSY. I checked the decode against the vendor driver, which reads
>> the same byte, so this is not a parsing error on my side, and the coex
>> algorithm itself is clearly running: TDMA case-3, table 10, reason
>> BTINFO.
>
> Does the driver receive BTINFO regularly after you connect the headphones?
>
> If it doesn't, maybe rtw_coex_active_query_bt_info() can help. Currently
> it only does something for RTL8821A.

Hi Bitterblue,

Thanks, that was worth checking. I measured it with debug_mask=0x40.

It does receive BTINFO regularly. With the headphones connected and A2DP
actually streaming I get 19 Bt_info arrivals in a 30 second window, so
roughly one every 1.5 seconds, and the values do change between them:

  [BTCoex], Bt_info[1], len=7, data=[01 40 0e 00 00 00]
  [BTCoex], Bt_info[2], len=7, data=[01 40 11 00 00 00]
  [BTCoex], Bt_info[2], len=7, data=[01 40 0e 00 00 00]
  [BTCoex], Bt_info[1], len=7, data=[01 40 0f 00 00 00]
  [BTCoex], Bt_info[2], len=7, data=[01 41 0f 00 00 00]

For comparison, with BT disconnected it is 1 arrival in 30 seconds. So
this firmware does not go quiet the way the RTL8821AU one does, and
rtw_coex_active_query_bt_info() would not add anything here. Good idea
though, it was the obvious thing to rule out first.

The problem is what is in the reports rather than how often they come.
bt_info_lb2 is 0x01 in all 19 of them: BIT(0) CONNECTION set, BIT(3)
ACL_BUSY never set, no profile bits. So bt_acl_busy stays false and
rtw_coex_update_bt_link_info() logs CON_IDLE 18 times, which is the
correct conclusion from that input. Meanwhile the same coex_info dump
shows Lo-Pri TX/RX at 419/418, so BT is clearly moving traffic.

In other words the BT firmware reports connected, not busy, no profile,
so I do not think this one is fixable from the WiFi driver, therefore I 
am documenting it as a known limitation rather than guessing at BT state
in coex.

Best regards,
Luka Gejak