Re: [regression 6.12.y] After backport of 980084de4d9b ("Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU") bluethooth not anymore working on 0b05:1bef ASUSTek Computer, Inc. Bluetooth Controller (requests firmware)

[Christoph Zwerschke <cito@online.de>]

On 25.10.26 07:27, Thorsten Leemhuis wrote:
> Feels wrong to me, as
> Documentation/driver-api/firmware/firmware-usage-guidelines.rst says
> "Users switching to a newer kernel should *not* have to install newer
> firmware files to keep their hardware working.". So what those three
> commits did in mainline even there could be considered a
> mistake/regression. No worries, mistakes happen. And reverting it now in
> mainline would do more damage than good. But overall it feels wrong to
> bring that mistake over to older stable series.
Hi Thorsten, all,

I can confirm the analysis: with the two ID entries, btusb hands both
adapters to btrtl, which, with 4a23ce935f74 ("Bluetooth: btrtl: Add
the support for RTL8761CUV"), requires rtl_bt/rtl8761cu_fw.bin and
aborts the setup if the file is missing.

The original commit messages of my two ID commits, 980084de4d9b
("Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU") and
6f0624b4427e ("Bluetooth: btusb: Add ASUS USB-BT600 for Realtek
8761CU"), say that without the entries the controllers are
"non-functional". I had concluded that from earlier experiments
where things did not work as expected, and I wrongly blamed that
on the firmware not being loaded. In fact the adapters work fine
on their ROM firmware; the problems had other causes. It seems
that when I prepared the patches in July, I did not properly test
the adapters without the entries, and I tested the patches only on
7.1, where btrtl already supports the RTL8761CU.

What I should have done: test the unpatched adapters first, test the
stable trees the patches would reach, and consider systems without
rtl8761cu_fw.bin. As it is, the patches made things worse, first in
the trees without the btrtl commit and now for everyone with older
firmware. I'm sorry for the trouble this has caused, especially to
Ralf, Erik, and the stable and Debian maintainers.

I have now tested more thoroughly, with both adapters (BT540
0b05:1bef, BT600 0b05:1d70), re-plugging before each case, using
linux-firmware 20261019 with the rtl8761cu files hidden or present.
Kernels were CachyOS 7.3.0 and 6.18.55, with btusb built from the
v7.3 and v6.18.55 sources, with and without the ID entries:

- 7.3 and 6.18.55, IDs present, firmware hidden: "firmware file
   rtl_bt/rtl8761cu_fw not found", no controller (as Erik reported).
- 7.3 and 6.18.55, both ID entries removed (i.e. the two ID commits
   reverted, the btrtl commit kept), firmware hidden: no btrtl
   involvement, the adapters run on ROM firmware (lmp_subver 0x8761),
   A2DP works.
- 7.3, ID entries removed, firmware present: same, ROM firmware, A2DP
   works.

Regarding your concern that a revert in mainline would do more damage
than good: on 7.3 I also compared both variants (with and without the
ID entries) with the BT600 for HFP and LE Audio (BlueZ 5.87, PipeWire
1.6.10). mSBC is negotiated and used even without the wide-band-speech
flag, and I found no difference between ROM and loaded firmware. So
for these two adapters I could not find any damage from reverting the
ID entries in mainline. Of course this does not rule out that the
loaded firmware contains fixes or improvements that my tests did not
cover.

For these two adapters, the btrtl commit 4a23ce935f74 (RTL8761CUV
support in btrtl) does not need to be reverted: without the ID
entries, they never reach btrtl (no "RTL:" lines at all in the logs).
What reverting it would mean for other RTL8761CU devices, e.g. with
Realtek's own vendor ID, I cannot say.

Not tested: 6.12, other RTL8761CU devices, HFP and LE Audio on 6.18,
and older audio stacks that might evaluate the wide-band-speech flag.

If it helps, I can send reverts of 980084de4d9b and 6f0624b4427e
(on top of bluetooth.git master, with Cc: stable). Alternatively,
btrtl could fall back to the ROM firmware when rtl8761cu_fw.bin
is missing.

Thanks,
Christoph