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

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

[Salvatore Bonaccorso]

Control: forwarded -1 https://lore.kernel.org/regressions/7179104011040.2214689.5921682013387867802@eldamar.lan

Hi

In Debian Erik Brangs reported that after the update from 6.12.107 to
6.12.111, specifically with the backport of 980084de4d9b ("Bluetooth:
btusb: Add ASUS USB-BT540 for Realtek 8761CU") Bluetooth is not
anymore working, the full report is found at
https://bugs.debian.org/1149377 .

| [   38.135482] Bluetooth: hci0: RTL: btrtl_initialize: key id 0
| [   38.135486] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761cu_fw.bin
| [   38.135751] snd_hda_intel 0000:08:00.1: bound 0000:08:00.0 (ops amdgpu_dm_audio_component_bind_ops [amdgpu])
| [   38.138313] input: HDA ATI HDMI HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:03.1/0000:06:00.0/0000:07:00.0/0000:08:00.1/sound/card1/input11
| [   38.138410] input: HDA ATI HDMI HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:03.1/0000:06:00.0/0000:07:00.0/0000:08:00.1/sound/card1/input12
| [   38.138478] input: HDA ATI HDMI HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:03.1/0000:06:00.0/0000:07:00.0/0000:08:00.1/sound/card1/input13
| [   38.138534] input: HDA ATI HDMI HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:03.1/0000:06:00.0/0000:07:00.0/0000:08:00.1/sound/card1/input14
| [   38.138657] bluetooth hci0: firmware: failed to load rtl_bt/rtl8761cu_fw.bin (-2)
| [   38.138860] bluetooth hci0: firmware: failed to load rtl_bt/rtl8761cu_fw.bin (-2)
| [   38.138874] bluetooth hci0: firmware: failed to load rtl_bt/rtl8761cu_fw.bin (-2)
| [   38.138877] bluetooth hci0: Direct firmware load for rtl_bt/rtl8761cu_fw.bin failed with error -2
| [   38.138881] Bluetooth: hci0: RTL: firmware file rtl_bt/rtl8761cu_fw not found
| [   38.194794] snd_hda_codec_realtek hdaudioC2D0: autoconfig for ALC887-VD: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:line
| [   38.194806] snd_hda_codec_realtek hdaudioC2D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
| [   38.194809] snd_hda_codec_realtek hdaudioC2D0:    hp_outs=1 (0x1b/0x0/0x0/0x0/0x0)
| [   38.194812] snd_hda_codec_realtek hdaudioC2D0:    mono: mono_out=0x0
| [   38.194815] snd_hda_codec_realtek hdaudioC2D0:    inputs:
| [   38.194817] snd_hda_codec_realtek hdaudioC2D0:      Rear Mic=0x18
| [   38.194820] snd_hda_codec_realtek hdaudioC2D0:      Front Mic=0x19
| [   38.194822] snd_hda_codec_realtek hdaudioC2D0:      Line=0x1a
| [   38.208365] snd_hda_codec_realtek hdaudioC0D1: autoconfig for ALC898: line_outs=3 (0x14/0x15/0x16/0x0/0x0) type:line
| [   38.208384] snd_hda_codec_realtek hdaudioC0D1:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
| [   38.208387] snd_hda_codec_realtek hdaudioC0D1:    hp_outs=1 (0x1b/0x0/0x0/0x0/0x0)
| [   38.208390] snd_hda_codec_realtek hdaudioC0D1:    mono: mono_out=0x0
| [   38.208392] snd_hda_codec_realtek hdaudioC0D1:    inputs:
| [   38.208394] snd_hda_codec_realtek hdaudioC0D1:      Rear Mic=0x18
| [   38.208396] snd_hda_codec_realtek hdaudioC0D1:      Front Mic=0x19
| [   38.208398] snd_hda_codec_realtek hdaudioC0D1:      Line=0x1a
| [   38.237349] input: HD-Audio Generic Rear Mic as /devices/pci0000:00/0000:00:08.1/0000:0a:00.4/sound/card2/input15
| [   38.237414] input: HD-Audio Generic Front Mic as /devices/pci0000:00/0000:00:08.1/0000:0a:00.4/sound/card2/input16
| [   38.237517] input: HD-Audio Generic Line as /devices/pci0000:00/0000:00:08.1/0000:0a:00.4/sound/card2/input17
| [   38.237541] input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:01.3/0000:01:00.2/0000:02:04.0/0000:03:00.0/sound/card0/input20
| [   38.237619] input: HDA Creative Rear Mic as /devices/pci0000:00/0000:00:01.3/0000:01:00.2/0000:02:04.0/0000:03:00.0/sound/card0/input21
| [   38.237651] input: HD-Audio Generic Line Out as /devices/pci0000:00/0000:00:08.1/0000:0a:00.4/sound/card2/input18
| [   38.237712] input: HD-Audio Generic Front Headphone as /devices/pci0000:00/0000:00:08.1/0000:0a:00.4/sound/card2/input19
| [   38.237778] input: HDA Creative Front Mic as /devices/pci0000:00/0000:00:01.3/0000:01:00.2/0000:02:04.0/0000:03:00.0/sound/card0/input22
| [   38.239278] input: HDA Creative Line as /devices/pci0000:00/0000:00:01.3/0000:01:00.2/0000:02:04.0/0000:03:00.0/sound/card0/input23
| [   38.239482] input: HDA Creative Line Out Front as /devices/pci0000:00/0000:00:01.3/0000:01:00.2/0000:02:04.0/0000:03:00.0/sound/card0/input24
| [   38.239593] input: HDA Creative Line Out Surround as /devices/pci0000:00/0000:00:01.3/0000:01:00.2/0000:02:04.0/0000:03:00.0/sound/card0/input25
| [   38.239799] input: HDA Creative Line Out CLFE as /devices/pci0000:00/0000:00:01.3/0000:01:00.2/0000:02:04.0/0000:03:00.0/sound/card0/input26
| [   38.241509] input: HDA Creative Front Headphone as /devices/pci0000:00/0000:00:01.3/0000:01:00.2/0000:02:04.0/0000:03:00.0/sound/card0/input27
| [   38.252148] intel_rapl_common: Found RAPL domain package
| [   38.252153] intel_rapl_common: Found RAPL domain core
| [   38.285591] usbcore: registered new interface driver ath9k_htc
| [   38.287837] usb 1-9: firmware: failed to load ath9k_htc/htc_9271-1.dev.0.fw (-2)
| [   38.287850] usb 1-9: firmware: failed to load ath9k_htc/htc_9271-1.dev.0.fw (-2)
| [   38.287860] usb 1-9: firmware: failed to load ath9k_htc/htc_9271-1.dev.0.fw (-2)
| [   38.287863] usb 1-9: Direct firmware load for ath9k_htc/htc_9271-1.dev.0.fw failed with error -2
| [   38.368469] Adding 33487868k swap on /dev/sda6.  Priority:-2 extents:1 across:33487868k SS
| [   38.748227] audit: type=1400 audit(1790704634.157:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="brave" pid=1418 comm="apparmor_parser"
| [   38.748260] audit: type=1400 audit(1790704634.157:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="Discord" pid=1413 comm="apparmor_parser"
| [   38.748306] audit: type=1400 audit(1790704634.157:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="vscode" pid=1426 comm="apparmor_parser"
| [   38.748347] audit: type=1400 audit(1790704634.157:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="balena-etcher" pid=1417 comm="apparmor_parser"
| [   38.748381] audit: type=1400 audit(1790704634.157:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="crun" pid=1427 comm="apparmor_parser"
| [   38.748419] audit: type=1400 audit(1790704634.157:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="busybox" pid=1420 comm="apparmor_parser"
| [   38.748470] audit: type=1400 audit(1790704634.157:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="chrome" pid=1424 comm="apparmor_parser"
| [   38.748511] audit: type=1400 audit(1790704634.157:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="buildah" pid=1419 comm="apparmor_parser"
| [   38.748556] audit: type=1400 audit(1790704634.157:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="cam" pid=1421 comm="apparmor_parser"
| [   38.748595] audit: type=1400 audit(1790704634.157:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="chromium" pid=1425 comm="apparmor_parser"
| [   39.218164] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
| [   39.218168] Bluetooth: BNEP filters: protocol multicast
| [   39.218175] Bluetooth: BNEP socket layer initialized
| [   39.363652] usb 1-9: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008
| [   39.440211] Generic FE-GE Realtek PHY r8169-0-400:00: attached PHY driver (mii_bus:phy_addr=r8169-0-400:00, irq=MAC)
| [   39.442083] NET: Registered PF_QIPCRTR protocol family
| [   39.614314] ath9k_htc 1-9:1.0: ath9k_htc: HTC initialized with 33 credits
| [   39.640566] r8169 0000:04:00.0 enp4s0: Link is Down
| [   39.845845] ath9k_htc 1-9:1.0: ath9k_htc: FW Version: 1.4
| [   39.845849] ath9k_htc 1-9:1.0: FW RMW support: On
| [   39.845851] ath: EEPROM regdomain: 0x809c
| [   39.845853] ath: EEPROM indicates we should expect a country code
| [   39.845855] ath: doing EEPROM country->regdmn map search
| [   39.845856] ath: country maps to regdmn code: 0x52
| [   39.845857] ath: Country alpha2 being used: CN
| [   39.845859] ath: Regpair used: 0x52
| [   39.849223] ieee80211 phy0: Atheros AR9271 Rev:1
| [   39.854386] ath9k_htc 1-9:1.0 wlx30b5c211d175: renamed from wlan0
| [   41.745845] wlx30b5c211d175: authenticate with 1c:ed:6f:bb:ed:4c (local address=30:b5:c2:11:d1:75)
| [   41.745849] wlx30b5c211d175: send auth to 1c:ed:6f:bb:ed:4c (try 1/3)
| [   41.807272] wlx30b5c211d175: authenticate with 1c:ed:6f:bb:ed:4c (local address=30:b5:c2:11:d1:75)
| [   41.807275] wlx30b5c211d175: send auth to 1c:ed:6f:bb:ed:4c (try 1/3)
| [   41.813896] wlx30b5c211d175: authenticated
| [   41.816186] wlx30b5c211d175: associate with 1c:ed:6f:bb:ed:4c (try 1/3)
| [   41.821911] wlx30b5c211d175: RX AssocResp from 1c:ed:6f:bb:ed:4c (capab=0x1431 status=0 aid=5)
| [   41.828348] wlx30b5c211d175: associated
| [   41.948210] wlx30b5c211d175: Limiting TX power to 20 (20 - 0) dBm as advertised by 1c:ed:6f:bb:ed:4c
| [   42.675206] r8169 0000:04:00.0 enp4s0: Link is Up - 1Gbps/Full - flow control rx/tx
| [   45.079778] kauditd_printk_skb: 119 callbacks suppressed
| [   45.079783] audit: type=1400 audit(1790704640.485:131): apparmor="ALLOWED" operation="capable" class="cap" profile="Xorg" pid=1955 comm="Xorg" capability=12  capname="net_admin"
| [   45.272603] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
| [   46.036834] audit: type=1400 audit(1790704641.445:132): apparmor="STATUS" operation="profile_load" profile="unconfined" name="docker-default" pid=2246 comm="apparmor_parser"
| [   46.186122] evm: overlay not supported
| [   46.358551] Bridge firewalling registered
| [   46.408480] Initializing XFRM netlink socket
| [   46.552168] audit: type=1400 audit(1790704641.957:133): apparmor="ALLOWED" operation="capable" class="cap" profile="Xorg" pid=1955 comm="Xorg" capability=12  capname="net_admin"
| [   67.792012] Guest personality initialized and is inactive
| [   67.792063] VMCI host device registered (name=vmci, major=10, minor=260)
| [   67.792065] Initialized host personality
| [   67.799049] NET: Registered PF_VSOCK protocol family
| [   68.979467] systemd-journald[544]: Time jumped backwards, rotating.

the device now requests rtl_bt/rtl8761cu_fw.bin firwmare (assumtion the device
had previously working firwmare but with adding support for ASUS USB-BT540 for
Realtek 8761CU, tries to load the not avaialble firmware and get not
functional? I'm looping in Ben Hutchings which has much more experience on that
on our end.

#regzbot introduced: f05baf6e0680d8c10d2fbbc5953848fc3e3db957
#regzbot link: https://bugs.debian.org/1149377

Maybe the answer is simply here, Debian needs to provide the firmware from now
on in the firmware-realtek in stable?

Regards,
Salvatore

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)

[Sasha Levin]

> In Debian Erik Brangs reported that after the update from 6.12.107 to
> 6.12.111, specifically with the backport of 980084de4d9b ("Bluetooth:
> btusb: Add ASUS USB-BT540 for Realtek 8761CU") Bluetooth is not
> anymore working, the full report is found at
> https://bugs.debian.org/1149377 .
>
> | [   38.138881] Bluetooth: hci0: RTL: firmware file rtl_bt/rtl8761cu_fw not found

The stable code matches mainline. The failure is a missing firmware file:
rtl_bt/rtl8761cu_fw.bin has been in linux-firmware only since 20251111,
and Debian trixie's firmware-realtek 20250410-2 does not have it.

Marcel, Luiz: could you, or Christoph Zwerschke as the author of the ID
commit, send an upstream revert, or a fallback to ROM firmware when
rtl8761cu_fw.bin is missing? Stable will take it for 7.2, 6.18 and 6.12
through the normal Cc: stable route once it is in mainline.

-- 
Thanks,
Sasha

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)

[Thorsten Leemhuis]

On 10/4/26 18:29, Sasha Levin wrote:
>> In Debian Erik Brangs reported that after the update from 6.12.107 to
>> 6.12.111, specifically with the backport of 980084de4d9b ("Bluetooth:
>> btusb: Add ASUS USB-BT540 for Realtek 8761CU") Bluetooth is not
>> anymore working, the full report is found at
>> https://bugs.debian.org/1149377 .
>>
>> | [   38.138881] Bluetooth: hci0: RTL: firmware file rtl_bt/rtl8761cu_fw not found
> 
> The stable code matches mainline. The failure is a missing firmware file:
> rtl_bt/rtl8761cu_fw.bin has been in linux-firmware only since 20251111,
> and Debian trixie's firmware-realtek 20250410-2 does not have it.
> 
> Marcel, Luiz: could you, or Christoph Zwerschke as the author of the ID
> commit, send an upstream revert, or a fallback to ROM firmware when
> rtl8761cu_fw.bin is missing? Stable will take it for 7.2, 6.18 and 6.12
> through the normal Cc: stable route once it is in mainline.

Hmmm, that was a week (granted: with the LPC) ago and nothing happened.
Anyone working on this?

If not: Should we revert 980084de4d9b and its backports? Or only the
backports to older stable series?

Strictly speaking it should be the former due to our policies wrt to
firmware -- but I guess most users of a more recent kernels also have a
newer firmware, so I wonder if reverting the change might do more harm
then good now.

Ciao, Thorsten

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)

[Salvatore Bonaccorso]

Ciao Thorsten,

Thanks for looking into this regression as well.

On Mon, Oct 12, 2026 at 02:00:18PM +0200, Thorsten Leemhuis wrote:
> On 10/4/26 18:29, Sasha Levin wrote:
> >> In Debian Erik Brangs reported that after the update from 6.12.107 to
> >> 6.12.111, specifically with the backport of 980084de4d9b ("Bluetooth:
> >> btusb: Add ASUS USB-BT540 for Realtek 8761CU") Bluetooth is not
> >> anymore working, the full report is found at
> >> https://bugs.debian.org/1149377 .
> >>
> >> | [   38.138881] Bluetooth: hci0: RTL: firmware file rtl_bt/rtl8761cu_fw not found
> > 
> > The stable code matches mainline. The failure is a missing firmware file:
> > rtl_bt/rtl8761cu_fw.bin has been in linux-firmware only since 20251111,
> > and Debian trixie's firmware-realtek 20250410-2 does not have it.
> > 
> > Marcel, Luiz: could you, or Christoph Zwerschke as the author of the ID
> > commit, send an upstream revert, or a fallback to ROM firmware when
> > rtl8761cu_fw.bin is missing? Stable will take it for 7.2, 6.18 and 6.12
> > through the normal Cc: stable route once it is in mainline.
> 
> Hmmm, that was a week (granted: with the LPC) ago and nothing happened.
> Anyone working on this?
> 
> If not: Should we revert 980084de4d9b and its backports? Or only the
> backports to older stable series?
> 
> Strictly speaking it should be the former due to our policies wrt to
> firmware -- but I guess most users of a more recent kernels also have a
> newer firmware, so I wonder if reverting the change might do more harm
> then good now.

If my understanding is correct from a earlier fixed regression in the
ariea, aka
https://lore.kernel.org/regressions/0fd8c1c9-7f56-4bcb-a727-e4386d8ef094@online.de/
should then not only 980084de4d9b ("Bluetooth: btusb: Add ASUS
USB-BT540 for Realtek 8761CU") be reverted, but as well along
6f0624b4427e ("Bluetooth: btusb: Add ASUS USB-BT600 for Realtek
8761CU") and as well 4a23ce935f74 ("Bluetooth: btrtl: Add the support
for RTL8761CUV")?

Regards,
Salvatore

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)

[Thorsten Leemhuis]

On 10/12/26 19:28, Salvatore Bonaccorso wrote:
> On Mon, Oct 12, 2026 at 02:00:18PM +0200, Thorsten Leemhuis wrote:
>> On 10/4/26 18:29, Sasha Levin wrote:
>>>> In Debian Erik Brangs reported that after the update from 6.12.107 to
>>>> 6.12.111, specifically with the backport of 980084de4d9b ("Bluetooth:
>>>> btusb: Add ASUS USB-BT540 for Realtek 8761CU") Bluetooth is not
>>>> anymore working, the full report is found at
>>>> https://bugs.debian.org/1149377 .
>>>>
>>>> | [   38.138881] Bluetooth: hci0: RTL: firmware file rtl_bt/rtl8761cu_fw not found
>>>
>>> The stable code matches mainline. The failure is a missing firmware file:
>>> rtl_bt/rtl8761cu_fw.bin has been in linux-firmware only since 20251111,
>>> and Debian trixie's firmware-realtek 20250410-2 does not have it.
>>>
>>> Marcel, Luiz: could you, or Christoph Zwerschke as the author of the ID
>>> commit, send an upstream revert, or a fallback to ROM firmware when
>>> rtl8761cu_fw.bin is missing? Stable will take it for 7.2, 6.18 and 6.12
>>> through the normal Cc: stable route once it is in mainline.
>>
>> Hmmm, that was a week (granted: with the LPC) ago and nothing happened.
>> Anyone working on this?
>>
>> If not: Should we revert 980084de4d9b and its backports? Or only the
>> backports to older stable series?
>>
>> Strictly speaking it should be the former due to our policies wrt to
>> firmware -- but I guess most users of a more recent kernels also have a
>> newer firmware, so I wonder if reverting the change might do more harm
>> then good now.
> 
> If my understanding is correct from a earlier fixed regression in the
> ariea, aka
> https://lore.kernel.org/regressions/0fd8c1c9-7f56-4bcb-a727-e4386d8ef094@online.de/
> should then not only 980084de4d9b ("Bluetooth: btusb: Add ASUS
> USB-BT540 for Realtek 8761CU") be reverted, but as well along
> 6f0624b4427e ("Bluetooth: btusb: Add ASUS USB-BT600 for Realtek
> 8761CU") and as well 4a23ce935f74 ("Bluetooth: btrtl: Add the support
> for RTL8761CUV")?
Maybe, I didn't look closer, but that's why reverting in mainline likely
really is a bad idea: it might cause a regression for users that depend
on those changes (one of which is from 6.19).

So I guess reverting some or all of those backports in "older stable
series", as Sasha suggested, might be the best -- but I guess it would
be good if someone with more knowledge in this area could provide an
opinion.

Ciao, Thorsten

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)

[Thorsten Leemhuis]

On 10/13/26 11:03, Thorsten Leemhuis wrote:
> On 10/12/26 19:28, Salvatore Bonaccorso wrote:
>> On Mon, Oct 12, 2026 at 02:00:18PM +0200, Thorsten Leemhuis wrote:
>>> On 10/4/26 18:29, Sasha Levin wrote:
>>>>> In Debian Erik Brangs reported that after the update from 6.12.107 to
>>>>> 6.12.111, specifically with the backport of 980084de4d9b ("Bluetooth:
>>>>> btusb: Add ASUS USB-BT540 for Realtek 8761CU") Bluetooth is not
>>>>> anymore working, the full report is found at
>>>>> https://bugs.debian.org/1149377 .
>>>>> | [   38.138881] Bluetooth: hci0: RTL: firmware file rtl_bt/rtl8761cu_fw not found

This is still unresolved. Salvatore, Erik, and/or Christoph, could you
confirm my analyses below -- and if it is ask the stable team for the
reverts?

>>>> The stable code matches mainline. The failure is a missing firmware file:
>>>> rtl_bt/rtl8761cu_fw.bin has been in linux-firmware only since 20251111,
>>>> and Debian trixie's firmware-realtek 20250410-2 does not have it.
>>>>
>>>> Marcel, Luiz: could you, or Christoph Zwerschke as the author of the ID
>>>> commit, send an upstream revert, or a fallback to ROM firmware when
>>>> rtl8761cu_fw.bin is missing? Stable will take it for 7.2, 6.18 and 6.12
>>>> through the normal Cc: stable route once it is in mainline.
>>>
>>> Hmmm, that was a week (granted: with the LPC) ago and nothing happened.
>>> Anyone working on this?
>>>
>>> If not: Should we revert 980084de4d9b and its backports? Or only the
>>> backports to older stable series?
>>>
>>> Strictly speaking it should be the former due to our policies wrt to
>>> firmware -- but I guess most users of a more recent kernels also have a
>>> newer firmware, so I wonder if reverting the change might do more harm
>>> then good now.
>>
>> If my understanding is correct from a earlier fixed regression in the
>> ariea, aka
>> https://lore.kernel.org/regressions/0fd8c1c9-7f56-4bcb-a727-e4386d8ef094@online.de/

There Christoph asked "please revert them from every tree below 6.19" --
but they afaics were only reverted for 6.6 and earlier.

"Them" meant the backports of these:

* 980084de4d9b25 ("Bluetooth: btusb: Add ASUS USB-BT540 for Realtek
8761CU") [v7.3-rc1]
* 6f0624b4427e38 ("Bluetooth: btusb: Add ASUS USB-BT600 for Realtek
8761CU") [v7.3-rc1]

Maybe because 4a23ce935f74d1 ("Bluetooth: btrtl: Add the support for
RTL8761CUV") was included in v6.18.53, v6.12.111. Which lead to the
current situation with "firmware file rtl_bt/rtl8761cu_fw not found" in
Debian.

>> should then not only 980084de4d9b ("Bluetooth: btusb: Add ASUS
>> USB-BT540 for Realtek 8761CU") be reverted, but as well along
>> 6f0624b4427e ("Bluetooth: btusb: Add ASUS USB-BT600 for Realtek
>> 8761CU") and as well 4a23ce935f74 ("Bluetooth: btrtl: Add the support
>> for RTL8761CUV")?
>
> Maybe, I didn't look closer,

I did meanwhile and agree, the backports of these should be reverted
from 6.18.y and 6.12.y:

* 980084de4d9b25 ("Bluetooth: btusb: Add ASUS USB-BT540 for Realtek
8761CU") [v7.3-rc1]
* 6f0624b4427e38 ("Bluetooth: btusb: Add ASUS USB-BT600 for Realtek
8761CU") [v7.3-rc1]
* 4a23ce935f74d1 ("Bluetooth: btrtl: Add the support for RTL8761CUV")
[v6.19-rc1]

At least if the problem wasn't resolved meanwhile, but that wasn't the
case afaics -- or did I miss it? Salvatore, Erik, or Christoph? Or was
it meanwhile agree on to fix this differently, for example by including
that file in a linux-firmware update maybe?
Ciao, Thorsten


 but that's why reverting in mainline likely
> really is a bad idea: it might cause a regression for users that depend
> on those changes (one of which is from 6.19).
> 
> So I guess reverting some or all of those backports in "older stable
> series", as Sasha suggested, might be the best -- but I guess it would
> be good if someone with more knowledge in this area could provide an
> opinion.

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)

[Erik Brangs]

Hi,

On 23.10.26 15:43, Thorsten Leemhuis wrote:
> I did meanwhile and agree, the backports of these should be reverted
> from 6.18.y and 6.12.y:
> 
> * 980084de4d9b25 ("Bluetooth: btusb: Add ASUS USB-BT540 for Realtek
> 8761CU") [v7.3-rc1]
> * 6f0624b4427e38 ("Bluetooth: btusb: Add ASUS USB-BT600 for Realtek
> 8761CU") [v7.3-rc1]
> * 4a23ce935f74d1 ("Bluetooth: btrtl: Add the support for RTL8761CUV")
> [v6.19-rc1]
> 
> At least if the problem wasn't resolved meanwhile, but that wasn't the
> case afaics -- or did I miss it? Salvatore, Erik, or Christoph? Or was
> it meanwhile agree on to fix this differently, for example by including
> that file in a linux-firmware update maybe?
> Ciao, Thorsten

The problem has not been resolved yet AFAICT.

Kind regards,

Erik Brangs

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)

[Sasha Levin]

> I did meanwhile and agree, the backports of these should be reverted
> from 6.18.y and 6.12.y:
>
> * 980084de4d9b25 ("Bluetooth: btusb: Add ASUS USB-BT540 for Realtek
> 8761CU") [v7.3-rc1]
> * 6f0624b4427e38 ("Bluetooth: btusb: Add ASUS USB-BT600 for Realtek
> 8761CU") [v7.3-rc1]
> * 4a23ce935f74d1 ("Bluetooth: btrtl: Add the support for RTL8761CUV")
> [v6.19-rc1]

The stable trees match mainline here, so nothing is going into stable for
this. The fix has to come from the Bluetooth maintainers or Christoph: an
upstream revert of the ID commits, or a fallback to the ROM firmware when
rtl8761cu_fw.bin is missing. Stable will take either one for 7.2, 6.18 and
6.12 through the normal Cc: stable route once it is in mainline.

The other way out is on the distro side. rtl_bt/rtl8761cu_fw.bin has been in
linux-firmware since 20251111, so a newer firmware-realtek package fixes this
without any kernel change.

-- 
Thanks,
Sasha

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)

[Greg Kroah-Hartman]

On Sat, Oct 24, 2026 at 04:10:59PM -0400, Sasha Levin wrote:
> > I did meanwhile and agree, the backports of these should be reverted
> > from 6.18.y and 6.12.y:
> >
> > * 980084de4d9b25 ("Bluetooth: btusb: Add ASUS USB-BT540 for Realtek
> > 8761CU") [v7.3-rc1]
> > * 6f0624b4427e38 ("Bluetooth: btusb: Add ASUS USB-BT600 for Realtek
> > 8761CU") [v7.3-rc1]
> > * 4a23ce935f74d1 ("Bluetooth: btrtl: Add the support for RTL8761CUV")
> > [v6.19-rc1]
> 
> The stable trees match mainline here, so nothing is going into stable for
> this. The fix has to come from the Bluetooth maintainers or Christoph: an
> upstream revert of the ID commits, or a fallback to the ROM firmware when
> rtl8761cu_fw.bin is missing. Stable will take either one for 7.2, 6.18 and
> 6.12 through the normal Cc: stable route once it is in mainline.
> 
> The other way out is on the distro side. rtl_bt/rtl8761cu_fw.bin has been in
> linux-firmware since 20251111, so a newer firmware-realtek package fixes this
> without any kernel change.

That's the simplest solution, any users hitting this should also upgrade
that package as it's been out for almost a year now.

thanks,

greg k-h

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)

[Thorsten Leemhuis]

On 10/25/26 07:16, Greg Kroah-Hartman wrote:
> On Sat, Oct 24, 2026 at 04:10:59PM -0400, Sasha Levin wrote:
>>> I did meanwhile and agree, the backports of these should be reverted
>>> from 6.18.y and 6.12.y:
>>>
>>> * 980084de4d9b25 ("Bluetooth: btusb: Add ASUS USB-BT540 for Realtek
>>> 8761CU") [v7.3-rc1]
>>> * 6f0624b4427e38 ("Bluetooth: btusb: Add ASUS USB-BT600 for Realtek
>>> 8761CU") [v7.3-rc1]
>>> * 4a23ce935f74d1 ("Bluetooth: btrtl: Add the support for RTL8761CUV")
>>> [v6.19-rc1]
>>
>> The stable trees match mainline here, so nothing is going into stable for
>> this. The fix has to come from the Bluetooth maintainers or Christoph: an
>> upstream revert of the ID commits, or a fallback to the ROM firmware when
>> rtl8761cu_fw.bin is missing. Stable will take either one for 7.2, 6.18 and
>> 6.12 through the normal Cc: stable route once it is in mainline.
>>
>> The other way out is on the distro side. rtl_bt/rtl8761cu_fw.bin has been in
>> linux-firmware since 20251111, so a newer firmware-realtek package fixes this
>> without any kernel change.
> 
> That's the simplest solution, any users hitting this should also upgrade
> that package as it's been out for almost a year now.
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.

Ciao, Thorsten

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]

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

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)

[Thorsten Leemhuis]

On 10/25/26 08:37, Christoph Zwerschke wrote:
> 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.
> 
> I can confirm the analysis: [...]

Thx for taking the time explaining this in details to us, much appreciated!

> [...]
> 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.
> [...] 
> 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.
I didn't see any regression reports for 7.x releases about those
changes, as I suspect that people that regularly switch to the latest
stable or mainline releases often update their firmware package, too. So
I'm still inclined to say: leave everything as it is in mainline to
avoid any risk and revert only the backports of those two in 6.18.y and
6.12.y.

Ciao, Thorsten

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)

[Sasha Levin]

> > 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.
> I didn't see any regression reports for 7.x releases about those
> changes, [...] So I'm still inclined to say: leave everything as it is
> in mainline to avoid any risk and revert only the backports of those
> two in 6.18.y and 6.12.y.

Yup, that would be appreciated.

-- 
Thanks,
Sasha

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)

[Salvatore Bonaccorso]

Hi,

On Sun, Oct 25, 2026 at 07:29:50PM -0400, Sasha Levin wrote:
> > > 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.
> > I didn't see any regression reports for 7.x releases about those
> > changes, [...] So I'm still inclined to say: leave everything as it is
> > in mainline to avoid any risk and revert only the backports of those
> > two in 6.18.y and 6.12.y.
> 
> Yup, that would be appreciated.

I'm bit lost here :) Who is now going to sen the reverts for the older
stable series? I'm bit worried that it will fall through the cracks,
but at least from Debian point of view given we want to closely follow
upstream stable releases I would pick the revert only in advance once
I know it is already as well in the stable queue for the next release.

Regards,
Salvatore