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

[Bitterblue Smith <rtl8821cerfe2@gmail.com>]

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.