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/[email protected]/
> 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

Reply via email to