Please refer to previous revisions if you know what to do.
The patch proposed was merged into kernel in 5.8 release, but no longer working as of linux 5.11
@Swyter Okay thanks sound good! I can just apply the patch my self though?
After a couple days banging my head around this, I finally was able to get my CSR "5.0" dongle to work. Thank you all so much for this thread. What worked for me was basically using the script above to automate kernel module compilation, but I modified it to apply the HCI_FLT_CLEAR_ALL patch instead of the old patch. I was using a newer version of the kernel anyways (5.15.7), so the force-suspend patch was already in as well.
I also had to change some flags in the .config file to disable module signing and to tinker with version magic before compilation.
Don't know if it helps but here's info about my device with lsusb:
ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 224 Wireless
bDeviceSubClass 1 Radio Frequency
bDeviceProtocol 1 Bluetooth
bMaxPacketSize0 64
idVendor 0x0a12 Cambridge Silicon Radio, Ltd
idProduct 0x0001 Bluetooth Dongle (HCI mode)
bcdDevice 88.91
iManufacturer 0
iProduct 2 BT DONGLE10
iSerial 0
bNumConfigurations 1
I'm using 5.15.7-1-MANJARO x86_64, though I also tested it with kernel 5.14.21-2 and it worked.
To anyone who wants to try and is a Linux beginner like me, I strongly encourage you to modprobe the module after you finish installing and check the outputs with dmesg | grep btusb or something. This is how I figured out what was missing after several attempts.
That's great to read, @lemonteus. If you don't mind your name and e-mail being public it would be neat if you could give me permission to include you in the Tested-by: Name <em@il.com>
lines for the final submission. The more real-life testers the better; I don't want to cause regressions.
Who knows how many variants are out there. I actually bought another buggy dongle just to fix it.
Oh sure @Swyter, meant to do so before but forgot.
Tested by: Mateus Lemos <lemonsmateus@gmail.com>
Hi guys, is there any kernel ready to use/already patched to download?
I'd rather change my distro and reinstall it than do this whole process.
I'm on Debian testing now.
Hello
I am using a ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
device on an old machine with kernel 3.
The device works initially (I am periodically using a hcitool name
to verify that another device is close) but after a few hours it stops working (the other device is there but no response is returned).
At that point dmesg says: Bluetooth: hci0 command tx timeout
for every time the hcitool command runs
After unplugging and re-plugging the dongle, it starts working again
I tried to set options btusb reset=1 enable_autosuspend=0
in /etc/modprobe.d/csr-bluetoothdongle.conf
but I get error btusb: Unknown parameter 'enable_autosuspend'
(guessing because of the old kernel)
Any ideas about this ?
edit: I should also mention that with an other dongle (a lot older BT v1) things work fine non-stop, but I just need newer BT version so that is why I am tryin to make this v5 BT device work
Just a quick heads-up, I have submitted the initial version of the HCI_FLT_CLEAR_ALL
patch (the one that fixes the fake "V5.0" CSR dongles) for review, but this may take a while:
https://patchwork.kernel.org/project/bluetooth/patch/6a3f5e8b-fbc1-bad8-aef0-3e2cf9be364e@gmail.com/
@Swyter just tested your patch on top of 5.16-rc8, but it still fails for me:
[ 1225.690537] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[ 1230.924877] Bluetooth: hci0: CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround
[ 1236.043828] Bluetooth: hci0: setting interface failed (110)
My device has a different bcdDevice, but it's still recognized as a 'fake' one:
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 224 Wireless
bDeviceSubClass 1 Radio Frequency
bDeviceProtocol 1 Bluetooth
bMaxPacketSize0 64
idVendor 0x0a12 Cambridge Silicon Radio, Ltd
idProduct 0x0001 Bluetooth Dongle (HCI mode)
bcdDevice 25.20
iManufacturer 0
iProduct 2 CSR8510 A10
iSerial 0
bNumConfigurations 1
I loaded the btusb module using reset=1 and enable_autosuspend=0. I have a spare machine for compiling and testing some paches, please let me know if I can test any new version of your patchset, or if I can provide more info about my device.
@Swyter if I comment the PM code in btusb_setup_csr, along with your patch, can setup the interface correctly, but return other errors:
[ 3796.392461] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[ 3796.464490] Bluetooth: RFCOMM TTY layer initialized
[ 3796.464495] Bluetooth: RFCOMM socket layer initialized
[ 3796.464498] Bluetooth: RFCOMM ver 1.11
[ 3803.657404] Bluetooth: hci0: failed to disable LE scan: status 0x1f
[ 3803.657403] Bluetooth: hci0: command 0x200c tx timeout
[ 3808.777299] Bluetooth: hci0: command 0x200c tx timeout
I don't understand a thing about bluetooth, but I'll do some research and try to fix it for my device if time allows. In the meantime, do you have any idea what can be wrong in this case? Thanks!
@marcosps I see. The most important thing to distinguish your dongle from the rest is getting the Read Local Version Information
packet with hcidump
/btmon
, we're making a list, trying to classify them by needs and common traits. Also, try running it without kernel arguments.
Knowing how your dongle looks like (PCB/exterior/chip markings) and where you bought it helps, too.
Another thing, if you comment out the pm
code without applying the HCI_FLT_CLEAR_ALL
patch, does your controller get stuck, too? You can use sudo btmon
to see what happens.
I want to see if it has also that (HCI_OP_SET_EVENT_FLT
) problem with other issues on top or it's broken in a completely different way. So the logs help.
Hi,
I would like to thank and congratulate everyone involved in this gist, you are clearly putting a lot of effort into making this BT dongle work.
On Arch Linux 5.16.1-arch1-1
my ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
worked after @bennehcarvalho's simple solution
[19:00:43] ik@lostark ~ $ sudo btmon
Bluetooth monitor ver 5.63
= Note: Linux version 5.16.1-arch1-1 (x86_64) 0.438059
= Note: Bluetooth subsystem version 2.22 0.438062
@ MGMT Open: bluetoothd (privileged) version 1.21 {0x0001} 0.438064
= New Index: 00:00:00:00:00:00 (Primary,USB,hci0) [hci0] 3.079067
= Open Index: 00:00:00:00:00:00 [hci0] 3.079086
< HCI Command: Read Local Version Information (0x04|0x0001) plen 0 #1 [hci0] 3.079091
> HCI Event: Command Status (0x0f) plen 4 #2 [hci0] 3.079385
NOP (0x00|0x0000) ncmd 1
Status: Success (0x00)
> HCI Event: Hardware Error (0x10) plen 1 #3 [hci0] 3.080379
Code: 0x35
> HCI Event: Command Complete (0x0e) plen 12 #4 [hci0] 3.081386
Read Local Version Information (0x04|0x0001) ncmd 1
Status: Success (0x00)
HCI version: Bluetooth 4.0 (0x06) - Revision 8891 (0x22bb)
LMP version: Bluetooth 4.0 (0x06) - Subversion 8891 (0x22bb)
Manufacturer: Cambridge Silicon Radio (10)
< HCI Command: Reset (0x03|0x0003) plen 0
@Swyter here is the btmon output related to Local Version Info:
< HCI Command: Read Local Version Information (0x04|0x0001) plen 0 #1 [hci0] 6.270237
> HCI Event: Command Complete (0x0e) plen 12 #2 [hci0] 6.272023
Read Local Version Information (0x04|0x0001) ncmd 1
Status: Success (0x00)
HCI version: Bluetooth 5.0 (0x09) - Revision 12576 (0x3120)
LMP version: Bluetooth 5.0 (0x09) - Subversion 8891 (0x22bb)
Manufacturer: Cambridge Silicon Radio (10)
You were right, removing the PM code make it to not get stuck, but it has some other failing cases as I posted before:
Scanning: Enabled (0x01)
Filter duplicates: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #96 [hci0] 7.817033
LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Success (0x00)
@ MGMT Event: Command Complete (0x0001) plen 4 {0x0001} [hci0] 7.817100
Start Service Discovery (0x003a) plen 1
Status: Success (0x00)
Address type: 0x07
BR/EDR
LE Public
LE Random
@ MGMT Event: Discovering (0x0013) plen 2 {0x0001} [hci0] 7.817107
Address type: 0x07
BR/EDR
LE Public
LE Random
Discovery: Enabled (0x01)
@ MGMT Command: Start Service Discovery (0x003a) plen 4 {0x0001} [hci0] 7.817231
Address type: 0x07
BR/EDR
LE Public
LE Random
RSSI: invalid (0x7f)
UUIDs: 0
@ MGMT Event: Command Complete (0x0001) plen 4 {0x0001} [hci0] 7.817237
Start Service Discovery (0x003a) plen 1
Status: Busy (0x0a)
Address type: 0x07
BR/EDR
LE Public
LE Random
@ MGMT Command: Start Service Discovery (0x003a) plen 4 {0x0001} [hci0] 7.817312
Address type: 0x07
BR/EDR
LE Public
LE Random
RSSI: invalid (0x7f)
UUIDs: 0
@ MGMT Event: Command Complete (0x0001) plen 4 {0x0001} [hci0] 7.817315
Start Service Discovery (0x003a) plen 1
Status: Busy (0x0a)
Address type: 0x07
BR/EDR
LE Public
LE Random
Here it fails twice (retry maybe?). Here is states where it stops working:
HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #97 [hci0] 13.180894
Scanning: Disabled (0x00)
Filter duplicates: Disabled (0x00)
> HCI Event: LE Meta Event (0x3e) plen 29 #98 [hci0] 15.488224
LE Advertising Report (0x02)
Num reports: 1
Event type: Connectable undirected - ADV_IND (0x00)
Address type: Random (0x01)
Address: 76:CA:6D:37:3E:20 (Resolvable)
Data length: 17
Flags: 0x1a
LE General Discoverable Mode
Simultaneous LE and BR/EDR (Controller)
Simultaneous LE and BR/EDR (Host)
TX power: 12 dBm
Company: Apple, Inc. (76)
Type: Unknown (16)
Data: 151c1ee9c9
RSSI: 0 dBm (0x00)
> HCI Event: LE Meta Event (0x3e) plen 12 #99 [hci0] 15.490216
LE Advertising Report (0x02)
Num reports: 1
Event type: Scan response - SCAN_RSP (0x04)
Address type: Random (0x01)
Address: 76:CA:6D:37:3E:20 (Resolvable)
Data length: 0
RSSI: 0 dBm (0x00)
@ MGMT Event: Device Found (0x0012) plen 31 {0x0001} [hci0] 15.490302
LE Address: 76:CA:6D:37:3E:20 (Resolvable)
RSSI: 0 dBm (0x00)
Flags: 0x00000000
Data length: 17
Flags: 0x1a
LE General Discoverable Mode
Simultaneous LE and BR/EDR (Controller)
Simultaneous LE and BR/EDR (Host)
TX power: 12 dBm
Company: Apple, Inc. (76)
Type: Unknown (16)
Data: 151c1ee9c9
@ MGMT Command: Stop Discovery (0x0024) plen 1 {0x0001} [hci0] 17.604224
Address type: 0x07
BR/EDR
LE Public
LE Random
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #100 [hci0] 17.604369
Scanning: Disabled (0x00)
Filter duplicates: Disabled (0x00)
@ MGMT Event: Command Complete (0x0001) plen 4 {0x0001} [hci0] 19.612835
Stop Discovery (0x0024) plen 1
Status: Failed (0x03)
Address type: 0x07
BR/EDR
LE Public
LE Random
Now I'll try to digest this and map the output to the code :)
Again, this working without your patch, only by commenting the autosuspend and pm_* functions in btusb_setup_csr.
Ola @igorkelvin :)
I tried the same steps (reset=1 and autosuspend disabled, but in my case it didn't work). Thanks for sharing!
@Swyter maybe we could set the reset and autosuspend for some specific devices, like the one from @igorkelvin , similar to what we have for i8042 devices for disabling selftests.
$ sudo hciconfig hci0 up
Can't init device hci0: Invalid argument (22)
[ 921.000192] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[ 921.000198] Bluetooth: hci0: CSR: Failed to suspend the device for our Barrot 8041a02 receive-issue workaround
[ 921.021185] debugfs: File 'dut_mode' in directory 'hci0' already present!
When I try to bring up hci0 on one of those "5.0" dongles. It actually identifies as:
[ 811.722229] usb 1-1: Product: BT DONGLE10
@sfjuocekr With any luck, this is what my patch attempts to solve via quirk, I just sent the v2
for review, give it a go: https://patchwork.kernel.org/project/bluetooth/patch/4957ed07-36b8-58a0-2307-d2e6e2940527@gmail.com/
Yea, I found it already and will test it probably tomorrow! Had something else to work on :)
ok im running 5.16-5 and idk how to patch kernel this way, i use pamac manager and install dkm, can yall make a AUR for Arch users cauce i bought 10 of these bluetooth and none work on Linux
Quick heads up, had some time today and sent v3
for kernel review. We'll see if they like it:
https://patchwork.kernel.org/project/bluetooth/patch/3b6c7c18-dc48-b924-bd09-3638a5c741a4@gmail.com/
Quick heads up, had some time today and sent
v3
for kernel review. We'll see if they like it: https://patchwork.kernel.org/project/bluetooth/patch/3b6c7c18-dc48-b924-bd09-3638a5c741a4@gmail.com/
Do you think that I should unarchive this gist with the new patch? That is the minimal kernel version to apply without issues?
This patch only works on very recent kernels (they changed how pretty much the Bluetooth protocol implementation works in January), I had to rewrite it. But there are some older versions here, up in the comments. If they merge this one all my Chinese dongles will run alright.
Super neat, the v4
patch series has been merged by Marcel in bluetooth-next
, maybe it even gets backported to stable kernels:
That means it's probably going to get merged into the parent net-next
tree and if there are no weird regressions Linus Torvalds merges that and it's going to eventually be part of the next kernel version. Whenever that happens, thanks for testing. @tornaria and @lemonteus are credited in the commit log. :)
With this all my Chinese dongles (even those purchased for kernel work) finally work on Linux. I'm sure there are still more quirks to add, but hopefully other random people will start chipping away at it as a learning experience. It's been fun.
YOU ROCK MAN THANKS FOR YOUR WORK!
Super neat, the
v4
patch series has been merged by Marcel inbluetooth-next
, maybe it even gets backported to stable kernels:* https://git.kernel.org/bluetooth/bluetooth-next/c/d35c9b22957a * https://git.kernel.org/bluetooth/bluetooth-next/c/4afc6c743557
That means it's probably going to get merged into the parent
net-next
tree and if there are no weird regressions Linus Torvalds merges that and it's going to eventually be part of the next kernel version. Whenever that happens, thanks for testing. @tornaria and @lemonteus are credited in the commit log. :)With this all my Chinese dongles (even those purchased for kernel work) finally work on Linux. I'm sure there are still more quirks to add, but hopefully other random people will start chipping away at it as a learning experience. It's been fun.
I am using latest kernel 5.16.15
Is there a way to add your patch to the current kernel and recompile for example ?
@ahmed-tasaly Try out this earlier patch or older iterations submitted to Patchwork, some of these probably apply fine on kernel 5.16:
v0
: https://raw.githubusercontent.com/void-linux/void-packages/be587c070716d820eceee2377f966874ae51eb67/srcpkgs/linux5.15/patches/btusb-quirk-HCI_FLT_CLEAR_ALL.patchv1
: https://patchwork.kernel.org/project/bluetooth/patch/6a3f5e8b-fbc1-bad8-aef0-3e2cf9be364e@gmail.com/v2
: https://patchwork.kernel.org/project/bluetooth/patch/4957ed07-36b8-58a0-2307-d2e6e2940527@gmail.com/v3
: https://patchwork.kernel.org/project/bluetooth/patch/3b6c7c18-dc48-b924-bd09-3638a5c741a4@gmail.com/@ahmed-tasaly Try out this earlier patch or older iterations submitted to Patchwork, some of these probably apply fine on kernel 5.16:
* `v0`: _https://raw.githubusercontent.com/void-linux/void-packages/be587c070716d820eceee2377f966874ae51eb67/srcpkgs/linux5.15/patches/btusb-quirk-HCI_FLT_CLEAR_ALL.patch_ * `v1`: _https://patchwork.kernel.org/project/bluetooth/patch/6a3f5e8b-fbc1-bad8-aef0-3e2cf9be364e@gmail.com/_ * `v2`: _https://patchwork.kernel.org/project/bluetooth/patch/4957ed07-36b8-58a0-2307-d2e6e2940527@gmail.com/_ * `v3`: _https://patchwork.kernel.org/project/bluetooth/patch/3b6c7c18-dc48-b924-bd09-3638a5c741a4@gmail.com/_
can you tell me the instructions of patching the kernel by this patch
because I have spent serveral hours trying to figure this out but I couldnt
@ahmed-tasaly You can probably use the script from this Gist with the different/newer patch you want to apply: https://gist.github.com/nevack/6b36b82d715dc025163d9e9124840a07/545f26d353da9c146a8f4d04ff89efa9094dcacc
There's also this handy guide that also applies for the most part: https://old.reddit.com/r/AnnePro/comments/e76ij8/csr_40_bluetooth_dongle_on_linux/
Kernel 5.13.1 already had the patch (I downloaded it here)
But when I copy the patched driver, bluetooth module can't be enabled like this. Does anyone here has any idea?
$ modprobe btusb
modprobe: ERROR: could not insert 'btusb': Invalid argument
In step make -C $name oldconfig
, should I choose default for all?
I compiled bluetooth-next
, and tried using that. My dongle is still not working and the dmesg log is as follows:
rein ~ $ sudo dmesg | grep Bluetooth
[ 8.549642] Bluetooth: Core ver 2.22
[ 8.549661] Bluetooth: HCI device and connection manager initialized
[ 8.549664] Bluetooth: HCI socket layer initialized
[ 8.549666] Bluetooth: L2CAP socket layer initialized
[ 8.549668] Bluetooth: SCO socket layer initialized
[ 8.589852] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[ 8.589858] Bluetooth: hci0: CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround
[ 9.063531] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 9.063534] Bluetooth: BNEP filters: protocol multicast
[ 9.063537] Bluetooth: BNEP socket layer initialized
[ 11.340353] Bluetooth: hci0: command 0x0c01 tx timeout
[ 11.340354] Bluetooth: hci0: Opcode 0x c01 failed: -110
@LevitatingBusinessMan Dropping a link of a place where the dongle is sold or posting photos of the thing as shown above helps. It's a mishmash of variants, so we need to narrow down what's fixed and what not; there are no silver bullets, it's going to be a continuous trickle of quirks. See the comments above for ways of dumping more information via btmon
, btusb
and the like.
Here's a great report: https://gist.github.com/nevack/6b36b82d715dc025163d9e9124840a07?permalink_comment_id=4031963#gistcomment-4031963
@LevitatingBusinessMan Dropping a link of a place where the dongle is sold or posting photos of the thing as shown above helps. It's a mishmash of variants, so we need to narrow down what's fixed and what not; there are no silver bullets, it's going to be a continuous trickle of quirks. See the comments above for ways of dumping more information via
btmon
,btusb
and the like.
I also have a bbs.archlinux.org forum post going on here.
The dongle in question is sold here.
It came with a little install disc for the rtl8761b
driver (for windows).
I am not entirely sure how to get btmon
to read anything. But if you give instructions I'll send any data that might be of help.
Edit: btmon output after I plugged the device in.
@LevitatingBusinessMan The latest patch was aimed to fix an identical V5.0
-marked dongle with exactly the same plastic shell. Now it works correctly. As you can see we need internal photos of the PCB and chip, as well as the IDs if we ever want to classify them and make some sense out of them.
@Swyter Hmm then shouldn't it work for me? Maybe I am doing something wrong?
I'll try to crack it open but it doesn't seem easy, and I've never taken a usb device like this apart before.
@LevitatingBusinessMan Either the insides are different or they don't get along with certain USB ports/controllers. Try deleting these lines and recompiling your bluetooth-next
kernel. Does that work?
@LevitatingBusinessMan Either the insides are different or they don't get along with certain USB ports/controllers. Try deleting these lines and recompiling your
bluetooth-next
kernel. Does that work?
It does not.
[ 9.378832] Bluetooth: Core ver 2.22
[ 9.378870] Bluetooth: HCI device and connection manager initialized
[ 9.378874] Bluetooth: HCI socket layer initialized
[ 9.378876] Bluetooth: L2CAP socket layer initialized
[ 9.378879] Bluetooth: SCO socket layer initialized
[ 9.600790] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[ 10.821114] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 10.821117] Bluetooth: BNEP filters: protocol multicast
[ 10.821121] Bluetooth: BNEP socket layer initialized
[ 12.403740] Bluetooth: hci0: Opcode 0x c01 failed: -110
[ 12.403760] Bluetooth: hci0: command tx timeout
However the dmesg logs are slightly different
@LevitatingBusinessMan Thanks for the photos, yeah, the PCB and innards seem to be completely different compared to mine, the one that now works. My chip is marked with a UG8413
. Seemingly same enclosure and features.
@LevitatingBusinessMan You can try logging what the dongle does by running sudo btmon
before plugging the thing. It should show everything and where it stops. In any case the rtl8761b
mention is more than a really good hint. So thanks for that, and for testing the other thing, that narrows it down and helps a lot.
@LevitatingBusinessMan Sorry, there are so many reports that it's hard to follow who posts what. Because this one seems like a completely different vendor I would try deleting quirks one by one (the stuff surrounding the CSR lines from before) and see if anything helps. Try deleting the power management stuff, too.
That log is very useful to isolate any future codepaths to those models, but I don't see any HCI failures, just a bunch of reconnects. HCI events (responses from what we ask the dongle to do) causing the controller to go nuts.
Not that I know what I'm doing, I'm just another user fumbling around. ¯\_(ツ)_/¯
@LevitatingBusinessMan Okay, took another good look at the whole thing.
This is very interesting, seems like the problem is that the Realtek controller isn't initializing and needs firmware, you said in the Arch forum thread that you tried hex-editing, but the VID/PID here are different: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1955916/comments/21
Edit this line and replace the BTUSB_CSR
with BTUSB_REALTEK|BTUSB_WIDEBAND_SPEECH
and then copy the firmware files as instructed in the Launchpad comment: https://github.com/bluez/bluetooth-next/blob/4afc6c7435575398b4a3d045ccc8a8b1eab02fe9/drivers/bluetooth/btusb.c#L178
Maybe that does the trick. It's a hack, though.
(PS: I don't know why these Chinese companies like to squat specifically on this darn VID/PID combination for every dongle on Earth. Why not reuse some other Realtek PID to make Windows PnP driver autoinstall work. ¯\_(ツ)_/¯)
(I would guess windows XP didn't have all that much diversity of drivers)
sudo dmesg | grep Bluetooth
[ 25.827958] Bluetooth: Core ver 2.22
[ 25.827987] Bluetooth: HCI device and connection manager initialized
[ 25.827990] Bluetooth: HCI socket layer initialized
[ 25.827991] Bluetooth: L2CAP socket layer initialized
[ 25.827994] Bluetooth: SCO socket layer initialized
[ 33.198651] Bluetooth: hci0: RTL: examining hci_ver=09 hci_rev=0001 lmp_ver=09 lmp_subver=0001
[ 33.247119] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 33.247122] Bluetooth: BNEP filters: protocol multicast
[ 33.247126] Bluetooth: BNEP socket layer initialized
[ 33.407606] Bluetooth: hci0: RTL: examining hci_ver=09 hci_rev=0001 lmp_ver=09 lmp_subver=0001
[ 33.407616] Bluetooth: hci0: RTL: unknown IC info, lmp subver 0001, hci rev 0001, hci ver 0009
[ 33.407619] Bluetooth: hci0: RTL: assuming no firmware upload needed
[ 36.300103] Bluetooth: hci0: command 0x0c01 tx timeout
[ 36.303733] Bluetooth: hci0: Opcode 0x c01 failed: -110
With:
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 50df417207af..34203a216cd9 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -175,7 +175,7 @@ MODULE_DEVICE_TABLE(usb, btusb_table);
static const struct usb_device_id blacklist_table[] = {
/* CSR BlueCore devices */
- { USB_DEVICE(0x0a12, 0x0001), .driver_info = BTUSB_CSR },
+ { USB_DEVICE(0x0a12, 0x0001), .driver_info = BTUSB_REALTEK|BTUSB_WIDEBAND_SPEECH },
/* Broadcom BCM2033 without firmware */
{ USB_DEVICE(0x0a5c, 0x2033), .driver_info = BTUSB_IGNORE },
(PS: I don't know why these Chinese companies like to squat specifically on this darn VID/PID combination for every dongle on Earth. Why not reuse some other Realtek PID to make Windows PnP driver autoinstall work. ¯_(ツ)_/¯)
FYI this dongle did work automatically when I plugged it into windows.
Edit: Do I also install rtl8761usb(-dkms)
?
@LevitatingBusinessMan What's the driver running under Windows? I'm guessing it's the generic one.
Took a look at the proprietary Linux Realtek driver and it's unlikely it's going to bind, seeing as they use the LMP subver field for their internal "project" ID. So, for the RTL8761X
that field should be 0x8761
instead of your 0x0001
. Even for an early RTL8723A
(the only which doesn't match) the code is 0x1200
. Also, the HCI rev field sometimes stores the letter of the project; 0x000a
for the RTL8761A
, 0x000d
for RTL8723D
and so on. Yours is also 0x0001
.
So, it seems unlikely it's an actual Realtek chip. Sounds like a seller lie to me.
Another thing. The kernel says 8761B
is the UART/laptop version, for the USB version of that chip it probably should be the 8761A
, but if we look at the datasheet it says that the RTL8761BTV is the UART and RTL8761BUV the USB version. So make of that what you will. See:
The Launchpad hack works because the mainline Realtek driver only has a VID/PID whitelist in btusb
to mark devices as Realtek-compatible, and btrtl
then matches by LMP subver (=0x8761
) and so on. On the other hand you have the external GPL Realtek driver, which does include the USB product ID in the list. Take a look at the two first elements of each line, which are pid
and lmp_sub
:
{0xA761, 0x8761, "mp_rtl8761a_fw", "rtl8761au_fw", "rtl8761a_config", NULL, 0}, /* RTL8761AU only */
{0x818B, 0x8761, "mp_rtl8761a_fw", "rtl8761aw_fw", "rtl8761aw_config", NULL, 0}, /* RTL8761AW + 8192EU */
{0x818C, 0x8761, "mp_rtl8761a_fw", "rtl8761aw_fw", "rtl8761aw_config", NULL, 0}, /* RTL8761AW + 8192EU */
{0x8760, 0x8761, "mp_rtl8761a_fw", "rtl8761au8192ee_fw", "rtl8761a_config", NULL, 0}, /* RTL8761AU + 8192EE */
{0xB761, 0x8761, "mp_rtl8761a_fw", "rtl8761au_fw", "rtl8761a_config", NULL, 0}, /* RTL8761AUV only */
{0x8761, 0x8761, "mp_rtl8761a_fw", "rtl8761au8192ee_fw", "rtl8761a_config", NULL, 0}, /* RTL8761AU + 8192EE for LI */
{0x8A60, 0x8761, "mp_rtl8761a_fw", "rtl8761au8812ae_fw", "rtl8761a_config", NULL, 0}, /* RTL8761AU + 8812AE */
{0x3527, 0x8761, "mp_rtl8761a_fw", "rtl8761au8192ee_fw", "rtl8761a_config", NULL, 0}, /* RTL8761AU + 8814AE */
So a device with an unregistered ghetto vendor 2550
and PID 8761
will work once whitelisted in btusb
, but the LMP thingie must match for it to be considered a legit chip, which in that case it was, and it did, but whoever made it didn't want to pay the USB-IF association US$6,000 annually for a number.
So yeah, it's a miracle anything works at all. It's a freaking mess of legit chips, counterfeit chips, legit but unregistered vendor ID'd chips and more horrors of the computer world. All under the same plastic case.
@Swyter Thanks for your research, for someone that claims to just be fumbling around you seem to know what's up. I had the purchase refunded and the dongle will be picked up again by the vendor tomorrow.
my btmon output
Bluetooth monitor ver 5.64
= Note: Linux version 5.16.16-arch1-1 (x86_64) 0.500959
= Note: Bluetooth subsystem version 2.22 0.500961
@ MGMT Open: bluetoothd (privileged) version 1.21 {0x0001} 0.500962
= New Index: 00:00:00:00:00:00 (Primary,USB,hci0) [hci0] 6.856064
= Open Index: 00:00:00:00:00:00 [hci0] 6.856124
< HCI Command: Read Local Version Information (0x04|0x0001) plen 0 #1 [hci0] 6.856277
> HCI Event: Command Complete (0x0e) plen 12 #2 [hci0] 6.857698
Read Local Version Information (0x04|0x0001) ncmd 1
Status: Success (0x00)
HCI version: Bluetooth 5.0 (0x09) - Revision 12576 (0x3120)
LMP version: Bluetooth 5.0 (0x09) - Subversion 8891 (0x22bb)
Manufacturer: Cambridge Silicon Radio (10)
< HCI Command: Reset (0x03|0x0003) plen 0 #3 [hci0] 11.979445
= Close Index: 00:00:00:00:00:00
[hci0] 22.005233
at the same time
the output of
dmesg | grep Bluetooth
[ 3.403370] Bluetooth: Core ver 2.22
[ 3.403409] Bluetooth: HCI device and connection manager initialized
[ 3.403414] Bluetooth: HCI socket layer initialized
[ 3.403417] Bluetooth: L2CAP socket layer initialized
[ 3.403422] Bluetooth: SCO socket layer initialized
[ 3.748036] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[ 5.392060] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 5.392063] Bluetooth: BNEP filters: protocol multicast
[ 5.392066] Bluetooth: BNEP socket layer initialized
[ 8.915575] Bluetooth: hci0: CSR: Failed to suspend the device for our Barrot 8041a02 receive-issue workaround
[ 14.035380] Bluetooth: hci0: setting interface failed (110)
[ 3146.055870] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[ 3151.177553] Bluetooth: hci0: CSR: Failed to suspend the device for our Barrot 8041a02 receive-issue workaround
[ 3156.297179] Bluetooth: hci0: setting interface failed (110)
Quick heads up, had some time today and sent
v3
for kernel review. We'll see if they like it: https://patchwork.kernel.org/project/bluetooth/patch/3b6c7c18-dc48-b924-bd09-3638a5c741a4@gmail.com/
I applied these v4
patches on linux 5.17.0
https://patchwork.kernel.org/project/bluetooth/patch/20220307200445.5554-1-swyterzone@gmail.com/
https://patchwork.kernel.org/project/bluetooth/patch/20220307200445.5554-2-swyterzone@gmail.com/
and now my dongle is working for the first time!
It never worked before, not in the previous versions of the patch, not in any of the kernels with the patches already included.
Thank you so much for your great work.
Quick heads up, had some time today and sent
v3
for kernel review. We'll see if they like it: https://patchwork.kernel.org/project/bluetooth/patch/3b6c7c18-dc48-b924-bd09-3638a5c741a4@gmail.com/I applied these
v4
patches on linux 5.17.0https://patchwork.kernel.org/project/bluetooth/patch/20220307200445.5554-1-swyterzone@gmail.com/ https://patchwork.kernel.org/project/bluetooth/patch/20220307200445.5554-2-swyterzone@gmail.com/
and now my dongle is working for the first time! It never worked before, not in the previous versions of the patch, not in any of the kernels with the patches already included. Thank you so much for your great work.
How did you do that ?
Can you help me with the steps ?
thanks in advance
Quick heads up, had some time today and sent
v3
for kernel review. We'll see if they like it: https://patchwork.kernel.org/project/bluetooth/patch/3b6c7c18-dc48-b924-bd09-3638a5c741a4@gmail.com/I applied these
v4
patches on linux 5.17.0
https://patchwork.kernel.org/project/bluetooth/patch/20220307200445.5554-1-swyterzone@gmail.com/ https://patchwork.kernel.org/project/bluetooth/patch/20220307200445.5554-2-swyterzone@gmail.com/
and now my dongle is working for the first time! It never worked before, not in the previous versions of the patch, not in any of the kernels with the patches already included. Thank you so much for your great work.How did you do that ? Can you help me with the steps ? thanks in advance
Just compile and install the latest kernel (5.17.1). It doesn't need any patches and it will work without any problems.
Never read through this whole long thread, but thanks so much senpai! I just updated to linux 5.17 and my dongle works now! I bought a metric ton of them (like 8 or whatever) on aliexpress because they were like 2€s and I keep losing my normal 10€ dongles. I knew it was a gamble from the beginning. I have read about how support for these devices is known problem and there are even blog articles with kernel patches. However, none seemed to cover this specific hardware version. What's worse, trying them in a windows virtual machine actually worked :( Anyways, you did it! I was so happy that I thought I just had to read through the git log and find out who fixie wixied this fucksy upsy!
P.S.: How did you get the kernel guys to respond to you? I have recently made my first kernel patch that even made it into their patchwork:
https://patchwork.kernel.org/project/linux-input/patch/b401e453-9c66-15e3-1a1d-21f33b7a64e8@gmail.com/
However so far, no one has actually made a single comment to me about it. I have no idea if they like or despise it and it doesn't even build against the current sources anymore...
Many thanks.
P.S.: How did you get the kernel guys to respond to you? I have recently made my first kernel patch that even made it into their patchwork: https://patchwork.kernel.org/project/linux-input/patch/b401e453-9c66-15e3-1a1d-21f33b7a64e8@gmail.com/ However so far, no one has actually made a single comment to me about it. I have no idea if they like or despise it and it doesn't even build against the current sources anymore...
That looks like a reasonable patch to me. Unfortunately the HID subsystem maintainers have been a bit overloaded lately. I would suggest rebasing the patch on 5.17 (or 5.18-rc1 when it is out) and then resending it, with a note that it is a resend because v1 did not get any replies.
I updated to linux 5.17, and my dongle is still not working :((
dmesg report:
[ 39.167468] usb 1-4: new full-speed USB device number 4 using xhci_hcd
[ 39.316166] usb 1-4: Duplicate descriptor for config 1 interface 1 altsetting 5, skipping
[ 39.316488] usb 1-4: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=88.91
[ 39.316491] usb 1-4: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 39.316493] usb 1-4: Product: USB2.0-BT
[ 39.344509] Bluetooth: Core ver 2.22
[ 39.344536] NET: Registered PF_BLUETOOTH protocol family
[ 39.344551] Bluetooth: HCI device and connection manager initialized
[ 39.344554] Bluetooth: HCI socket layer initialized
[ 39.344557] Bluetooth: L2CAP socket layer initialized
[ 39.344560] Bluetooth: SCO socket layer initialized
[ 39.356119] usbcore: registered new interface driver btusb
[ 39.356687] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[ 39.356690] Bluetooth: hci0: CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround
[ 39.396406] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 39.396409] Bluetooth: BNEP filters: protocol multicast
[ 39.396412] Bluetooth: BNEP socket layer initialized
[ 42.119083] Bluetooth: hci0: command 0x0c01 tx timeout
[ 42.119314] Bluetooth: hci0: Opcode 0x c01 failed: -110
I plug another dongle which has exactly the same cover (CSR 4.0 on both), and it works.
dmesg report of second dongle:
[ 98.435150] usb 1-4: USB disconnect, device number 4
[ 103.387316] usb 1-4: new full-speed USB device number 5 using xhci_hcd
[ 103.536318] usb 1-4: Duplicate descriptor for config 1 interface 1 altsetting 5, skipping
[ 103.536759] usb 1-4: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=88.91
[ 103.536772] usb 1-4: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 103.536778] usb 1-4: Product: USB2.0-BT
I updated to linux 5.17, and my dongle is still not working :(( dmesg report:
[ 39.167468] usb 1-4: new full-speed USB device number 4 using xhci_hcd [ 39.316166] usb 1-4: Duplicate descriptor for config 1 interface 1 altsetting 5, skipping [ 39.316488] usb 1-4: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=88.91 [ 39.316491] usb 1-4: New USB device strings: Mfr=0, Product=2, SerialNumber=0 [ 39.316493] usb 1-4: Product: USB2.0-BT [ 39.344509] Bluetooth: Core ver 2.22 [ 39.344536] NET: Registered PF_BLUETOOTH protocol family [ 39.344551] Bluetooth: HCI device and connection manager initialized [ 39.344554] Bluetooth: HCI socket layer initialized [ 39.344557] Bluetooth: L2CAP socket layer initialized [ 39.344560] Bluetooth: SCO socket layer initialized [ 39.356119] usbcore: registered new interface driver btusb [ 39.356687] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once... [ 39.356690] Bluetooth: hci0: CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround [ 39.396406] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 39.396409] Bluetooth: BNEP filters: protocol multicast [ 39.396412] Bluetooth: BNEP socket layer initialized [ 42.119083] Bluetooth: hci0: command 0x0c01 tx timeout [ 42.119314] Bluetooth: hci0: Opcode 0x c01 failed: -110
I plug another dongle which has exactly the same housing (CSR 4.0 on both), and it works. dmesg report of second dongle:
[ 98.435150] usb 1-4: USB disconnect, device number 4 [ 103.387316] usb 1-4: new full-speed USB device number 5 using xhci_hcd [ 103.536318] usb 1-4: Duplicate descriptor for config 1 interface 1 altsetting 5, skipping [ 103.536759] usb 1-4: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=88.91 [ 103.536772] usb 1-4: New USB device strings: Mfr=0, Product=2, SerialNumber=0 [ 103.536778] usb 1-4: Product: USB2.0-BT
Linux 5.17 still needs the v4 patches to be applied manually. You should use Linux 5.17.1.
@huynp1999 If you read the conversation above with @LevitatingBusinessMan you will see that having the exact enclosure does not guarantee anything. The photos show completely different PCBs and chips, counterfeit vendors mix and mash. Please take a look at that and share the same kind of photos and information. It really helps a lot to identify the different dongle families, finding enough patterns to fix them in a generic fashion.
@MikuChan03 I have also sent four or five trivial patches to the input subsystem since early 2021 and unfortunately no maintainers from that team have reviewed or responded, even after being Acked
or Reviewed
by others. Even after resending them, as Hans says. I feel like they need more manpower, there's an absolute backlog of submissions going on there that are being bottlenecked at the review stage.
Linux 5.17 still needs the v4 patches to be applied manually. You should use Linux 5.17.1.
yes, I'm using 5.17.1
@Swyter oh ok, thank you for your support. I will take a look inside these dongles
You guys are right, I didn't notice the massive amount of patches pilling up on them. I'll lay back a little and mention it in time.
Have a good one!
@huynp1999 First one you showed (that doesn't work) looks a lot like mine, which I also couldn't get to work.
Yeah, it's the same PCB revision and everything. Good to have better pics and the chip vendor name. So it was a Barrot Technology one masking as a CSR, and sold as a Realtek. Go figure.
Does the second one that works get detected as a clone? I wonder if the HCI revision and LMP subversion numbers match.
I'm checking with hciconfig -a
and dmesg
. The first one don't show anything about HCI and LMP
Result of the second one that works:
HCI Version: 4.0 (0x6) Revision: 0x22bb
LMP Version: 4.0 (0x6) Subversion: 0x22bb
Anyone who needs a patch for linux 5.15.x LTS series, can use this patch. Credit goes to @Swyter for creating the original patches.
I just combined them and made it compatible with linux 5.15.x LTS.
It has been tested on linux 5.15.27.
Just copy and save it as a .diff file and apply it on the kernel source.
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index ac90392cc..39b189b16 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -1942,6 +1942,8 @@ static int btusb_setup_csr(struct hci_dev *hdev)
*/
set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks);
set_bit(HCI_QUIRK_BROKEN_ERR_DATA_REPORTING, &hdev->quirks);
+ set_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks);
+ set_bit(HCI_QUIRK_NO_SUSPEND_NOTIFIER, &hdev->quirks);
/* Clear the reset quirk since this is not an actual
* early Bluetooth 1.1 device from CSR.
@@ -1952,16 +1954,16 @@ static int btusb_setup_csr(struct hci_dev *hdev)
/*
* Special workaround for these BT 4.0 chip clones, and potentially more:
*
- * - 0x0134: a Barrot 8041a02 (HCI rev: 0x1012 sub: 0x0810)
+ * - 0x0134: a Barrot 8041a02 (HCI rev: 0x0810 sub: 0x1012)
* - 0x7558: IC markings FR3191AHAL 749H15143 (HCI rev/sub-version: 0x0709)
*
* These controllers are really messed-up.
*
* 1. Their bulk RX endpoint will never report any data unless
- * the device was suspended at least once (yes, really).
+ * the device was suspended at least once (yes, really).
* 2. They will not wakeup when autosuspended and receiving data
- * on their bulk RX endpoint from e.g. a keyboard or mouse
- * (IOW remote-wakeup support is broken for the bulk endpoint).
+ * on their bulk RX endpoint from e.g. a keyboard or mouse
+ * (IOW remote-wakeup support is broken for the bulk endpoint).
*
* To fix 1. enable runtime-suspend, force-suspend the
* HCI and then wake-it up by disabling runtime-suspend.
@@ -1981,7 +1983,7 @@ static int btusb_setup_csr(struct hci_dev *hdev)
if (ret >= 0)
msleep(200);
else
- bt_dev_err(hdev, "CSR: Failed to suspend the device for our Barrot 8041a02 receive-issue workaround");
+ bt_dev_warn(hdev, "CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround");
pm_runtime_forbid(&data->udev->dev);
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 9ce46cb85..41f0026b6 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -255,6 +255,16 @@ enum {
* during the hdev->setup vendor callback.
*/
HCI_QUIRK_BROKEN_READ_TRANSMIT_POWER,
+
+ /* When this quirk is set, HCI_OP_SET_EVENT_FLT requests with
+ * HCI_FLT_CLEAR_ALL are ignored and event filtering is
+ * completely avoided. A subset of the CSR controller
+ * clones struggle with this and instantly lock up.
+ *
+ * Note that devices using this must (separately) disable
+ * runtime suspend, because event filtering takes place there.
+ */
+ HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL,
};
/* HCI device flags */
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 53f1b0801..4c7f748b8 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -271,6 +271,7 @@ static int hci_init1_req(struct hci_request *req, unsigned long opt)
static void bredr_setup(struct hci_request *req)
{
+ struct hci_dev *hdev = req->hdev;
__le16 param;
__u8 flt_type;
@@ -292,9 +293,14 @@ static void bredr_setup(struct hci_request *req)
/* Read Current IAC LAP */
hci_req_add(req, HCI_OP_READ_CURRENT_IAC_LAP, 0, NULL);
- /* Clear Event Filters */
- flt_type = HCI_FLT_CLEAR_ALL;
- hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type);
+ /* Clear Event Filters; some fake CSR controllers lock up after setting
+ * this type of filter, so avoid sending the request altogether.
+ */
+ if (!test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks))
+ {
+ flt_type = HCI_FLT_CLEAR_ALL;
+ hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type);
+ }
/* Connection accept timeout ~20 secs */
param = cpu_to_le16(0x7d00);
diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c
index 1d34d330a..35308de87 100644
--- a/net/bluetooth/hci_request.c
+++ b/net/bluetooth/hci_request.c
@@ -1156,11 +1156,15 @@ static bool adv_instance_is_scannable(struct hci_dev *hdev, u8 instance)
static void hci_req_clear_event_filter(struct hci_request *req)
{
struct hci_cp_set_event_filter f;
+ struct hci_dev *hdev = req->hdev;
+
+ if (!hci_dev_test_flag(hdev, HCI_BREDR_ENABLED))
+ return;
- if (!hci_dev_test_flag(req->hdev, HCI_BREDR_ENABLED))
+ if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks))
return;
- if (hci_dev_test_flag(req->hdev, HCI_EVENT_FILTER_CONFIGURED)) {
+ if (hci_dev_test_flag(hdev, HCI_EVENT_FILTER_CONFIGURED)) {
memset(&f, 0, sizeof(f));
f.flt_type = HCI_FLT_CLEAR_ALL;
hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &f);
@@ -1169,15 +1173,18 @@ static void hci_req_clear_event_filter(struct hci_request *req)
static void hci_req_set_event_filter(struct hci_request *req)
{
+ struct hci_dev *hdev = req->hdev;
struct bdaddr_list_with_flags *b;
struct hci_cp_set_event_filter f;
- struct hci_dev *hdev = req->hdev;
u8 scan = SCAN_DISABLED;
bool scanning = test_bit(HCI_PSCAN, &hdev->flags);
if (!hci_dev_test_flag(hdev, HCI_BREDR_ENABLED))
return;
+ if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks))
+ return;
+
/* Always clear event filter when starting */
hci_req_clear_event_filter(req);
/drivers/bluetooth/btusb.c
Hi, can you please tell me how to apply this patch?
regards,
Paulo
Hello! I use kernel 5.17.5 but this adapter doesn't working. What's to do?
/drivers/bluetooth/btusb.c
Hi, can you please tell me how to apply this patch?
regards, Paulo
Copy and save the patch as a .diff
file.
Get the latest linux 5.15.36 LTS source, unpack and cd
to it.
apply the patch:
patch -p1 < /path/to/the/patch.diff
start compiling and then use the new kernel.
/драйверы/bluetooth/btusb.c
Привет, не могли бы вы сказать мне, как применить этот патч?
с уважением, ПаулоСкопируйте и сохраните исправление в виде файла. Получите последнюю версию исходного кода linux 5.15.36 LTS, распакуйте и к нему. применить патч:
.diff``cd
patch -p1 < /path/to/the/patch.diff
начните компиляцию, а затем используйте новое ядро.
Okay, where is patch?
/драйверы/bluetooth/btusb.c
Привет, не могли бы вы сказать мне, как применить этот патч?
с уважением, ПаулоСкопируйте и сохраните исправление в виде файла. Получите последнюю версию исходного кода linux 5.15.36 LTS, распакуйте и к нему. применить патч:
.diff
cd ``patch -p1 < /path/to/the/patch.diff
начните компиляцию, а затем используйте новое ядро.Okay, where is patch?
It's right up there in my earlier commets, can't you see?
Here's the comment's link
/драйверы/bluetooth/btusb.c
Привет, не могли бы вы сказать мне, как применить этот патч? с уважением, Пауло
Скопируйте и сохраните исправление в виде файла. Получите последнюю версию исходного кода linux 5.15.36 LTS, распакуйте и к нему. применить патч:cd '' начните компиляцию, а затем используйте новое ядро.
.diff``patch -p1 < /path/to/the/patch.diff
Хорошо, где патч?
Это прямо там, в моих ранних комметах, не так ли? Вот ссылка на комментарий
Thank you!
I'm in the same boat with this little guy, tried everything listed here, also tried with the patches from a known bug listed on the arch linux wiki bluetooth page but couldn't even compile the kernel with those patches (https://bugzilla.kernel.org/show_bug.cgi?id=60824) here is some info if someone can help me out:
here are some outputs from my tries:
lsusb
Bus 001 Device 024: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
btmon
Bluetooth monitor ver 5.64
= Note: Linux version 5.15.32-1-MANJARO (x86_64) 0.181266
= Note: Bluetooth subsystem version 2.22 0.181268
= New Index: 00:00:00:00:00:00 (Primary,USB,hci1) [hci1] 0.181268
= New Index: 48:E2:44:F6:F3:F4 (Primary,USB,hci0) [hci0] 0.181269 # this one (wifi/tb card) is powered off
@ MGMT Open: bluetoothd (privileged) version 1.21
hciconfig -a
hci1: Type: Primary Bus: USB
BD Address: 00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0
DOWN
RX bytes:14 acl:0 sco:0 events:1 errors:0
TX bytes:3 acl:0 sco:0 commands:2 errors:1
Features: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Packet type: DM1 DH1 HV1
Link policy:
Link mode: PERIPHERAL ACCEPT
hci0: Type: Primary Bus: USB
BD Address: 48:E2:44:F6:F3:F4 ACL MTU: 1021:8 SCO MTU: 64:1
DOWN
mhwd-kernel -li
Currently running: 5.15.32-1-MANJARO (linux515)
sudo hciconfig hci1 up
Can't init device hci1: Connection timed out (110)
dmesg | grep Bluetooth
[68300.546822] Bluetooth: hci1: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[68305.731582] Bluetooth: hci1: CSR: Failed to suspend the device for our Barrot 8041a02 receive-issue workaround
[68310.851263] Bluetooth: hci1: setting interface failed (110)
mhwd-kernel -li
Currently running: 5.15.32-1-MANJARO (linux515)
sudo hciconfig hci0 up
Can't init device hci0: Connection timed out (110)
dmesg | grep Bluetooth
[ 4.701306] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[ 9.753582] Bluetooth: hci0: CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround
[ 14.873783] Bluetooth: hci0: setting interface failed (110)
mhwd-kernel -li
Currently running: 5.17.1-3-MANJARO (linux517)
hciconfig hci0 up
Can't init device hci0: Broken pipe (32)
dmesg | grep Bluetooth
[ 5.017199] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[ 10.176336] Bluetooth: hci0: CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround
[ 12.305840] Bluetooth: hci0: Opcode 0x c03 failed: -110
[ 258.608877] Bluetooth: hci0: CSR: Local version failed (-32)
mhwd-kernel -li
Currently running: 5.17.7-1-MANJARO (linux517)
hciconfig hci0 up
Can't init device hci0: Broken pipe (32)
dmesg | grep Bluetooth
[ 4.579313] Bluetooth: Core ver 2.22
[ 4.579378] Bluetooth: HCI device and connection manager initialized
[ 4.579382] Bluetooth: HCI socket layer initialized
[ 4.579384] Bluetooth: L2CAP socket layer initialized
[ 4.579388] Bluetooth: SCO socket layer initialized
[ 4.794437] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[ 4.941822] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 4.941826] Bluetooth: BNEP filters: protocol multicast
[ 4.941831] Bluetooth: BNEP socket layer initialized
[ 9.959543] Bluetooth: hci0: CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround
[ 12.092630] Bluetooth: hci0: Opcode 0x c03 failed: -110
Sorry, I have to remove my contact info from gist.
My initial purpose was to let people contact me if anybody finds some new fix/patch.
Everything I got is a ton of spam like "help me please to fix bluetooth dongle on linux [version]".
Have a good day, yall!
Hey :)
Is there any ETA for when the current working patch will be merged into the main kernel? I am currently on kernel version 5.18, and it does not work.. Alternatively is there anyone adding the patch to the AUR?
Hey :) Is there any ETA for when the current working patch will be merged into the main kernel? I am currently on kernel version 5.18, and it does not work.. Alternatively is there anyone adding the patch to the AUR?
There's no working patch at the moment.
Well, it's fixed for all the dongles I have and the ones I bought just to fix more Linux kernel issues. Everything I submitted has been merged.
I can't really justify buying a sack of random AliExpress dongles and wait months for them to arrive and cross my fingers so that the seller is kind enough to not swap the advertised PCB (which happened two months ago, getting specific controllers is crazy hard) just to submit more patches. I bought one of the Barrot ones that still don't work and ended up with a duplicate that worked out of the box already. Super great.
--
I'm just a random Linux user doing it as a hobby after arriving at the same place, there is no ETA. Be the change you want to see in the world, if everyone did what I did with the hardware they own everything would be fixed.
Just make the jump and learn, even if it's through hacks and experimentation it will help getting to the correct solution if you stick around. Often you can fix a dongle by commenting out something or submitting an one-liner.
Thank you for your work on this, @Swyter. You helped inspire me to compile the kernel for the first time and you got my dongle working. I really appreciate the time you took developing the patches and hanging out here answering questions.
I compilied kernel with this patch, but problem with Bluetooth didn't fixed.
System: Fedora Linux.
Compilied version: 5.15.70
Have installed 5.17.1-051701-generic
on Ubuntu 22.04.1
and still have the problem
lsusb: Bus 005 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Have tried with 6.0.7-060007-generic
and still same output
[ 3.776546] Bluetooth: Core ver 2.22
[ 3.776576] NET: Registered PF_BLUETOOTH protocol family
[ 3.776577] Bluetooth: HCI device and connection manager initialized
[ 3.776582] Bluetooth: HCI socket layer initialized
[ 3.776585] Bluetooth: L2CAP socket layer initialized
[ 3.776589] Bluetooth: SCO socket layer initialized
[ 3.859412] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[ 4.406985] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 4.406988] Bluetooth: BNEP filters: protocol multicast
[ 4.406992] Bluetooth: BNEP socket layer initialized
[ 9.019046] Bluetooth: hci0: CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround
[ 11.032916] Bluetooth: hci0: Opcode 0x c03 failed: -110
Did somebody solve this?
Got the same problems and outputs on Ubuntu 22.04.1 LTS.
My dongle CSR 8510 A10 works fine on windows 7 on Microsoft generic driver.
Tried kernels 5.15.0 and 5.19.16.
I`m running Fedora 37 with kernel 6.0.7-301, unmodified.
Also getting errors, it used to work just fine on Fedora 35 and on older kernels in other distros.
[ 15.034386] Bluetooth: Core ver 2.22
[ 15.034400] Bluetooth: HCI device and connection manager initialized
[ 15.034402] Bluetooth: HCI socket layer initialized
[ 15.034404] Bluetooth: L2CAP socket layer initialized
[ 15.034407] Bluetooth: SCO socket layer initialized
[ 15.825231] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...
[ 15.825235] Bluetooth: hci0: CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround
[ 15.825238] Bluetooth: hci0: HCI Delete Stored Link Key command is advertised, but not supported.
[ 15.825239] Bluetooth: hci0: HCI Set Event Filter command not supported.
[ 17.948972] Bluetooth: hci0: command 0x0c5a tx timeout
[ 17.949005] Bluetooth: hci0: Opcode 0x c5a failed: -110
[ 20.711035] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 20.711037] Bluetooth: BNEP filters: protocol multicast
[ 20.711041] Bluetooth: BNEP socket layer initialized
See here: https://bugzilla.kernel.org/show_bug.cgi?id=60824#c242
Submitted a patch series here: https://bugzilla.kernel.org/show_bug.cgi?id=60824#c243
There was another simultaneous conversation in the mailing list here: https://linuxlists.cc/l/15/linux-bluetooth/t/4663230/(regression)_cambridge_silicon_radio,_ltd_bluetooth_dongle_unusable_again_with_kernel_6.0#post4683596
In the end, Luiz merged 2 out of the 3 patches upstream. There's radio silence about the third one.
Subscribe to the Bugzilla ticket if you want to stay up to date.
The patch series talked above is currently empty: https://patchwork.kernel.org/project/bluetooth/list/?series=690177&state
I'd patch my own kernel if possible. This problem has kept me out of Linux entirely.
Anyone who needs a patch for linux 5.15.x LTS series, can use this patch. Credit goes to @Swyter for creating the original patches. I just combined them and made it compatible with linux 5.15.x LTS. It has been tested on linux 5.15.27.
Just copy and save it as a .diff file and apply it on the kernel source.
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index ac90392cc..39b189b16 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -1942,6 +1942,8 @@ static int btusb_setup_csr(struct hci_dev *hdev) */ set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks); set_bit(HCI_QUIRK_BROKEN_ERR_DATA_REPORTING, &hdev->quirks); + set_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks); + set_bit(HCI_QUIRK_NO_SUSPEND_NOTIFIER, &hdev->quirks); /* Clear the reset quirk since this is not an actual * early Bluetooth 1.1 device from CSR. @@ -1952,16 +1954,16 @@ static int btusb_setup_csr(struct hci_dev *hdev) /* * Special workaround for these BT 4.0 chip clones, and potentially more: * - * - 0x0134: a Barrot 8041a02 (HCI rev: 0x1012 sub: 0x0810) + * - 0x0134: a Barrot 8041a02 (HCI rev: 0x0810 sub: 0x1012) * - 0x7558: IC markings FR3191AHAL 749H15143 (HCI rev/sub-version: 0x0709) * * These controllers are really messed-up. * * 1. Their bulk RX endpoint will never report any data unless - * the device was suspended at least once (yes, really). + * the device was suspended at least once (yes, really). * 2. They will not wakeup when autosuspended and receiving data - * on their bulk RX endpoint from e.g. a keyboard or mouse - * (IOW remote-wakeup support is broken for the bulk endpoint). + * on their bulk RX endpoint from e.g. a keyboard or mouse + * (IOW remote-wakeup support is broken for the bulk endpoint). * * To fix 1. enable runtime-suspend, force-suspend the * HCI and then wake-it up by disabling runtime-suspend. @@ -1981,7 +1983,7 @@ static int btusb_setup_csr(struct hci_dev *hdev) if (ret >= 0) msleep(200); else - bt_dev_err(hdev, "CSR: Failed to suspend the device for our Barrot 8041a02 receive-issue workaround"); + bt_dev_warn(hdev, "CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround"); pm_runtime_forbid(&data->udev->dev); diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h index 9ce46cb85..41f0026b6 100644 --- a/include/net/bluetooth/hci.h +++ b/include/net/bluetooth/hci.h @@ -255,6 +255,16 @@ enum { * during the hdev->setup vendor callback. */ HCI_QUIRK_BROKEN_READ_TRANSMIT_POWER, + + /* When this quirk is set, HCI_OP_SET_EVENT_FLT requests with + * HCI_FLT_CLEAR_ALL are ignored and event filtering is + * completely avoided. A subset of the CSR controller + * clones struggle with this and instantly lock up. + * + * Note that devices using this must (separately) disable + * runtime suspend, because event filtering takes place there. + */ + HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, }; /* HCI device flags */ diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c index 53f1b0801..4c7f748b8 100644 --- a/net/bluetooth/hci_core.c +++ b/net/bluetooth/hci_core.c @@ -271,6 +271,7 @@ static int hci_init1_req(struct hci_request *req, unsigned long opt) static void bredr_setup(struct hci_request *req) { + struct hci_dev *hdev = req->hdev; __le16 param; __u8 flt_type; @@ -292,9 +293,14 @@ static void bredr_setup(struct hci_request *req) /* Read Current IAC LAP */ hci_req_add(req, HCI_OP_READ_CURRENT_IAC_LAP, 0, NULL); - /* Clear Event Filters */ - flt_type = HCI_FLT_CLEAR_ALL; - hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type); + /* Clear Event Filters; some fake CSR controllers lock up after setting + * this type of filter, so avoid sending the request altogether. + */ + if (!test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks)) + { + flt_type = HCI_FLT_CLEAR_ALL; + hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type); + } /* Connection accept timeout ~20 secs */ param = cpu_to_le16(0x7d00); diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c index 1d34d330a..35308de87 100644 --- a/net/bluetooth/hci_request.c +++ b/net/bluetooth/hci_request.c @@ -1156,11 +1156,15 @@ static bool adv_instance_is_scannable(struct hci_dev *hdev, u8 instance) static void hci_req_clear_event_filter(struct hci_request *req) { struct hci_cp_set_event_filter f; + struct hci_dev *hdev = req->hdev; + + if (!hci_dev_test_flag(hdev, HCI_BREDR_ENABLED)) + return; - if (!hci_dev_test_flag(req->hdev, HCI_BREDR_ENABLED)) + if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks)) return; - if (hci_dev_test_flag(req->hdev, HCI_EVENT_FILTER_CONFIGURED)) { + if (hci_dev_test_flag(hdev, HCI_EVENT_FILTER_CONFIGURED)) { memset(&f, 0, sizeof(f)); f.flt_type = HCI_FLT_CLEAR_ALL; hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &f); @@ -1169,15 +1173,18 @@ static void hci_req_clear_event_filter(struct hci_request *req) static void hci_req_set_event_filter(struct hci_request *req) { + struct hci_dev *hdev = req->hdev; struct bdaddr_list_with_flags *b; struct hci_cp_set_event_filter f; - struct hci_dev *hdev = req->hdev; u8 scan = SCAN_DISABLED; bool scanning = test_bit(HCI_PSCAN, &hdev->flags); if (!hci_dev_test_flag(hdev, HCI_BREDR_ENABLED)) return; + if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks)) + return; + /* Always clear event filter when starting */ hci_req_clear_event_filter(req);
Thank you! Worked on Ubuntu 22.04!
uname -r
5.15.64-bluetooth
How fascinating - on an earlier standard Ubuntu kernel, the one of these I have Just Worked (and worked better than the 1Mii B10 dongle that's supposed to be the gold standard for doing this on Linux!)
But on the 5.15 kernel, it doesn't. I am not sure I have the patience to patch it.
Try a more updated or newer kernel instead of patching manually. Ubuntu and Debian are notorious for being extremely slow when moving from one version to another. The fix exists, it just hasn't arrived yet to your door. Arch Linux got it in early December, for example.
Anyone who needs a patch for linux 5.15.x LTS series, can use this patch. Credit goes to @Swyter for creating the original patches. I just combined them and made it compatible with linux 5.15.x LTS. It has been tested on linux 5.15.27.
Just copy and save it as a .diff file and apply it on the kernel source.diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index ac90392cc..39b189b16 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -1942,6 +1942,8 @@ static int btusb_setup_csr(struct hci_dev *hdev) */ set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks); set_bit(HCI_QUIRK_BROKEN_ERR_DATA_REPORTING, &hdev->quirks); + set_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks); + set_bit(HCI_QUIRK_NO_SUSPEND_NOTIFIER, &hdev->quirks); /* Clear the reset quirk since this is not an actual * early Bluetooth 1.1 device from CSR. @@ -1952,16 +1954,16 @@ static int btusb_setup_csr(struct hci_dev *hdev) /* * Special workaround for these BT 4.0 chip clones, and potentially more: * - * - 0x0134: a Barrot 8041a02 (HCI rev: 0x1012 sub: 0x0810) + * - 0x0134: a Barrot 8041a02 (HCI rev: 0x0810 sub: 0x1012) * - 0x7558: IC markings FR3191AHAL 749H15143 (HCI rev/sub-version: 0x0709) * * These controllers are really messed-up. * * 1. Their bulk RX endpoint will never report any data unless - * the device was suspended at least once (yes, really). + * the device was suspended at least once (yes, really). * 2. They will not wakeup when autosuspended and receiving data - * on their bulk RX endpoint from e.g. a keyboard or mouse - * (IOW remote-wakeup support is broken for the bulk endpoint). + * on their bulk RX endpoint from e.g. a keyboard or mouse + * (IOW remote-wakeup support is broken for the bulk endpoint). * * To fix 1. enable runtime-suspend, force-suspend the * HCI and then wake-it up by disabling runtime-suspend. @@ -1981,7 +1983,7 @@ static int btusb_setup_csr(struct hci_dev *hdev) if (ret >= 0) msleep(200); else - bt_dev_err(hdev, "CSR: Failed to suspend the device for our Barrot 8041a02 receive-issue workaround"); + bt_dev_warn(hdev, "CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround"); pm_runtime_forbid(&data->udev->dev); diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h index 9ce46cb85..41f0026b6 100644 --- a/include/net/bluetooth/hci.h +++ b/include/net/bluetooth/hci.h @@ -255,6 +255,16 @@ enum { * during the hdev->setup vendor callback. */ HCI_QUIRK_BROKEN_READ_TRANSMIT_POWER, + + /* When this quirk is set, HCI_OP_SET_EVENT_FLT requests with + * HCI_FLT_CLEAR_ALL are ignored and event filtering is + * completely avoided. A subset of the CSR controller + * clones struggle with this and instantly lock up. + * + * Note that devices using this must (separately) disable + * runtime suspend, because event filtering takes place there. + */ + HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, }; /* HCI device flags */ diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c index 53f1b0801..4c7f748b8 100644 --- a/net/bluetooth/hci_core.c +++ b/net/bluetooth/hci_core.c @@ -271,6 +271,7 @@ static int hci_init1_req(struct hci_request *req, unsigned long opt) static void bredr_setup(struct hci_request *req) { + struct hci_dev *hdev = req->hdev; __le16 param; __u8 flt_type; @@ -292,9 +293,14 @@ static void bredr_setup(struct hci_request *req) /* Read Current IAC LAP */ hci_req_add(req, HCI_OP_READ_CURRENT_IAC_LAP, 0, NULL); - /* Clear Event Filters */ - flt_type = HCI_FLT_CLEAR_ALL; - hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type); + /* Clear Event Filters; some fake CSR controllers lock up after setting + * this type of filter, so avoid sending the request altogether. + */ + if (!test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks)) + { + flt_type = HCI_FLT_CLEAR_ALL; + hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type); + } /* Connection accept timeout ~20 secs */ param = cpu_to_le16(0x7d00); diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c index 1d34d330a..35308de87 100644 --- a/net/bluetooth/hci_request.c +++ b/net/bluetooth/hci_request.c @@ -1156,11 +1156,15 @@ static bool adv_instance_is_scannable(struct hci_dev *hdev, u8 instance) static void hci_req_clear_event_filter(struct hci_request *req) { struct hci_cp_set_event_filter f; + struct hci_dev *hdev = req->hdev; + + if (!hci_dev_test_flag(hdev, HCI_BREDR_ENABLED)) + return; - if (!hci_dev_test_flag(req->hdev, HCI_BREDR_ENABLED)) + if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks)) return; - if (hci_dev_test_flag(req->hdev, HCI_EVENT_FILTER_CONFIGURED)) { + if (hci_dev_test_flag(hdev, HCI_EVENT_FILTER_CONFIGURED)) { memset(&f, 0, sizeof(f)); f.flt_type = HCI_FLT_CLEAR_ALL; hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &f); @@ -1169,15 +1173,18 @@ static void hci_req_clear_event_filter(struct hci_request *req) static void hci_req_set_event_filter(struct hci_request *req) { + struct hci_dev *hdev = req->hdev; struct bdaddr_list_with_flags *b; struct hci_cp_set_event_filter f; - struct hci_dev *hdev = req->hdev; u8 scan = SCAN_DISABLED; bool scanning = test_bit(HCI_PSCAN, &hdev->flags); if (!hci_dev_test_flag(hdev, HCI_BREDR_ENABLED)) return; + if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks)) + return; + /* Always clear event filter when starting */ hci_req_clear_event_filter(req);
Thank you! Worked on Ubuntu 22.04! uname -r 5.15.64-bluetooth
Hello, I tried this patch on my Raspberry OS aarch64 with kernel 5.15.89-v8 however it didn't work. My 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode). My usb is still down according to hciconfig. It doesn't work for arm?
This patch helped get the Ritmix RWA-350 working on Ubuntu 22.04.
Shown in lsusb
as:
ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
I cleaned up the patch:
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 8c41c76..9632251 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -1979,6 +1979,8 @@ static int btusb_setup_csr(struct hci_dev *hdev)
*/
set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks);
set_bit(HCI_QUIRK_BROKEN_ERR_DATA_REPORTING, &hdev->quirks);
+ set_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks);
+ set_bit(HCI_QUIRK_NO_SUSPEND_NOTIFIER, &hdev->quirks);
/* Clear the reset quirk since this is not an actual
* early Bluetooth 1.1 device from CSR.
@@ -2018,7 +2020,7 @@ static int btusb_setup_csr(struct hci_dev *hdev)
if (ret >= 0)
msleep(200);
else
- bt_dev_err(hdev, "CSR: Failed to suspend the device for our Barrot 8041a02 receive-issue workaround");
+ bt_dev_warn(hdev, "CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround");
pm_runtime_forbid(&data->udev->dev);
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 9ce46cb..b97602a 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -255,6 +255,7 @@ enum {
* during the hdev->setup vendor callback.
*/
HCI_QUIRK_BROKEN_READ_TRANSMIT_POWER,
+ HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL,
};
/* HCI device flags */
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index bb84ff5..2a7af9a 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -294,6 +294,7 @@ static void bredr_setup(struct hci_request *req)
/* Clear Event Filters */
flt_type = HCI_FLT_CLEAR_ALL;
+ if (!test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &req->hdev->quirks))
hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type);
/* Connection accept timeout ~20 secs */
diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c
index c2db60a..39a871a 100644
--- a/net/bluetooth/hci_request.c
+++ b/net/bluetooth/hci_request.c
@@ -1160,6 +1160,9 @@ static void hci_req_clear_event_filter(struct hci_request *req)
if (!hci_dev_test_flag(req->hdev, HCI_BREDR_ENABLED))
return;
+ if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &req->hdev->quirks))
+ return;
+
if (hci_dev_test_flag(req->hdev, HCI_EVENT_FILTER_CONFIGURED)) {
memset(&f, 0, sizeof(f));
f.flt_type = HCI_FLT_CLEAR_ALL;
@@ -1178,6 +1181,9 @@ static void hci_req_set_event_filter(struct hci_request *req)
if (!hci_dev_test_flag(hdev, HCI_BREDR_ENABLED))
return;
+ if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks))
+ return;
+
/* Always clear event filter when starting */
hci_req_clear_event_filter(req);
Extract the linux-source
archive corresponding to your kernel and do the following:
$ patch -p1 < csr-clean.patch
$ make -C /lib/modules/$(uname -r)/build M=$(pwd)/net/bluetooth ccflags-y="$(echo "-include "$(pwd)/include/net/bluetooth/{bluetooth.h,hci.h})" modules
$ make -C /lib/modules/$(uname -r)/build M=$(pwd)/drivers/bluetooth ccflags-y="$(echo "-include "$(pwd)/include/net/bluetooth/{bluetooth.h,hci.h})" modules
$ strip --strip-debug net/bluetooth/bluetooth.ko
$ strip --strip-debug drivers/bluetooth/btusb.ko
Then you can replace the old drivers in /usr/lib/modules/$(uname -r)/kernel
with the new ones. Don't forget to backup the old files.
I compiled this patch 5.15 but unfortunately it didn't work for my dongle.
It works if you remove the reset code from the bluetooth driver, no patches affect to this adapter
Anyone who needs a patch for linux 5.15.x LTS series, can use this patch. Credit goes to @Swyter for creating the original patches. I just combined them and made it compatible with linux 5.15.x LTS. It has been tested on linux 5.15.27.
Just copy and save it as a .diff file and apply it on the kernel source.
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index ac90392cc..39b189b16 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -1942,6 +1942,8 @@ static int btusb_setup_csr(struct hci_dev *hdev) */ set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks); set_bit(HCI_QUIRK_BROKEN_ERR_DATA_REPORTING, &hdev->quirks); + set_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks); + set_bit(HCI_QUIRK_NO_SUSPEND_NOTIFIER, &hdev->quirks); /* Clear the reset quirk since this is not an actual * early Bluetooth 1.1 device from CSR. @@ -1952,16 +1954,16 @@ static int btusb_setup_csr(struct hci_dev *hdev) /* * Special workaround for these BT 4.0 chip clones, and potentially more: * - * - 0x0134: a Barrot 8041a02 (HCI rev: 0x1012 sub: 0x0810) + * - 0x0134: a Barrot 8041a02 (HCI rev: 0x0810 sub: 0x1012) * - 0x7558: IC markings FR3191AHAL 749H15143 (HCI rev/sub-version: 0x0709) * * These controllers are really messed-up. * * 1. Their bulk RX endpoint will never report any data unless - * the device was suspended at least once (yes, really). + * the device was suspended at least once (yes, really). * 2. They will not wakeup when autosuspended and receiving data - * on their bulk RX endpoint from e.g. a keyboard or mouse - * (IOW remote-wakeup support is broken for the bulk endpoint). + * on their bulk RX endpoint from e.g. a keyboard or mouse + * (IOW remote-wakeup support is broken for the bulk endpoint). * * To fix 1. enable runtime-suspend, force-suspend the * HCI and then wake-it up by disabling runtime-suspend. @@ -1981,7 +1983,7 @@ static int btusb_setup_csr(struct hci_dev *hdev) if (ret >= 0) msleep(200); else - bt_dev_err(hdev, "CSR: Failed to suspend the device for our Barrot 8041a02 receive-issue workaround"); + bt_dev_warn(hdev, "CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround"); pm_runtime_forbid(&data->udev->dev); diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h index 9ce46cb85..41f0026b6 100644 --- a/include/net/bluetooth/hci.h +++ b/include/net/bluetooth/hci.h @@ -255,6 +255,16 @@ enum { * during the hdev->setup vendor callback. */ HCI_QUIRK_BROKEN_READ_TRANSMIT_POWER, + + /* When this quirk is set, HCI_OP_SET_EVENT_FLT requests with + * HCI_FLT_CLEAR_ALL are ignored and event filtering is + * completely avoided. A subset of the CSR controller + * clones struggle with this and instantly lock up. + * + * Note that devices using this must (separately) disable + * runtime suspend, because event filtering takes place there. + */ + HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, }; /* HCI device flags */ diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c index 53f1b0801..4c7f748b8 100644 --- a/net/bluetooth/hci_core.c +++ b/net/bluetooth/hci_core.c @@ -271,6 +271,7 @@ static int hci_init1_req(struct hci_request *req, unsigned long opt) static void bredr_setup(struct hci_request *req) { + struct hci_dev *hdev = req->hdev; __le16 param; __u8 flt_type; @@ -292,9 +293,14 @@ static void bredr_setup(struct hci_request *req) /* Read Current IAC LAP */ hci_req_add(req, HCI_OP_READ_CURRENT_IAC_LAP, 0, NULL); - /* Clear Event Filters */ - flt_type = HCI_FLT_CLEAR_ALL; - hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type); + /* Clear Event Filters; some fake CSR controllers lock up after setting + * this type of filter, so avoid sending the request altogether. + */ + if (!test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks)) + { + flt_type = HCI_FLT_CLEAR_ALL; + hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type); + } /* Connection accept timeout ~20 secs */ param = cpu_to_le16(0x7d00); diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c index 1d34d330a..35308de87 100644 --- a/net/bluetooth/hci_request.c +++ b/net/bluetooth/hci_request.c @@ -1156,11 +1156,15 @@ static bool adv_instance_is_scannable(struct hci_dev *hdev, u8 instance) static void hci_req_clear_event_filter(struct hci_request *req) { struct hci_cp_set_event_filter f; + struct hci_dev *hdev = req->hdev; + + if (!hci_dev_test_flag(hdev, HCI_BREDR_ENABLED)) + return; - if (!hci_dev_test_flag(req->hdev, HCI_BREDR_ENABLED)) + if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks)) return; - if (hci_dev_test_flag(req->hdev, HCI_EVENT_FILTER_CONFIGURED)) { + if (hci_dev_test_flag(hdev, HCI_EVENT_FILTER_CONFIGURED)) { memset(&f, 0, sizeof(f)); f.flt_type = HCI_FLT_CLEAR_ALL; hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &f); @@ -1169,15 +1173,18 @@ static void hci_req_clear_event_filter(struct hci_request *req) static void hci_req_set_event_filter(struct hci_request *req) { + struct hci_dev *hdev = req->hdev; struct bdaddr_list_with_flags *b; struct hci_cp_set_event_filter f; - struct hci_dev *hdev = req->hdev; u8 scan = SCAN_DISABLED; bool scanning = test_bit(HCI_PSCAN, &hdev->flags); if (!hci_dev_test_flag(hdev, HCI_BREDR_ENABLED)) return; + if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks)) + return; + /* Always clear event filter when starting */ hci_req_clear_event_filter(req);
بخدا مسلمون نیستی رضا. یه راهنمای قدم به قدمی چیزی مینوشتی که یکی با معلومات ضعیف مثل من هم بتونه استفاده کنه این رو. من debian 11 kernel 5.10-0.22rt دارم. میتونی یکم ساده تر توضیح بدی باید چیکار کنم ؟
This patch helped get the Ritmix RWA-350 working on Ubuntu 22.04.
Shown in
lsusb
as:
ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
I cleaned up the patch:
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index 8c41c76..9632251 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -1979,6 +1979,8 @@ static int btusb_setup_csr(struct hci_dev *hdev) */ set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks); set_bit(HCI_QUIRK_BROKEN_ERR_DATA_REPORTING, &hdev->quirks); + set_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks); + set_bit(HCI_QUIRK_NO_SUSPEND_NOTIFIER, &hdev->quirks); /* Clear the reset quirk since this is not an actual * early Bluetooth 1.1 device from CSR. @@ -2018,7 +2020,7 @@ static int btusb_setup_csr(struct hci_dev *hdev) if (ret >= 0) msleep(200); else - bt_dev_err(hdev, "CSR: Failed to suspend the device for our Barrot 8041a02 receive-issue workaround"); + bt_dev_warn(hdev, "CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround"); pm_runtime_forbid(&data->udev->dev); diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h index 9ce46cb..b97602a 100644 --- a/include/net/bluetooth/hci.h +++ b/include/net/bluetooth/hci.h @@ -255,6 +255,7 @@ enum { * during the hdev->setup vendor callback. */ HCI_QUIRK_BROKEN_READ_TRANSMIT_POWER, + HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, }; /* HCI device flags */ diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c index bb84ff5..2a7af9a 100644 --- a/net/bluetooth/hci_core.c +++ b/net/bluetooth/hci_core.c @@ -294,6 +294,7 @@ static void bredr_setup(struct hci_request *req) /* Clear Event Filters */ flt_type = HCI_FLT_CLEAR_ALL; + if (!test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &req->hdev->quirks)) hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type); /* Connection accept timeout ~20 secs */ diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c index c2db60a..39a871a 100644 --- a/net/bluetooth/hci_request.c +++ b/net/bluetooth/hci_request.c @@ -1160,6 +1160,9 @@ static void hci_req_clear_event_filter(struct hci_request *req) if (!hci_dev_test_flag(req->hdev, HCI_BREDR_ENABLED)) return; + if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &req->hdev->quirks)) + return; + if (hci_dev_test_flag(req->hdev, HCI_EVENT_FILTER_CONFIGURED)) { memset(&f, 0, sizeof(f)); f.flt_type = HCI_FLT_CLEAR_ALL; @@ -1178,6 +1181,9 @@ static void hci_req_set_event_filter(struct hci_request *req) if (!hci_dev_test_flag(hdev, HCI_BREDR_ENABLED)) return; + if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks)) + return; + /* Always clear event filter when starting */ hci_req_clear_event_filter(req);Extract the
linux-source
archive corresponding to your kernel and do the following:$ patch -p1 < csr-clean.patch $ make -C /lib/modules/$(uname -r)/build M=$(pwd)/net/bluetooth ccflags-y="$(echo "-include "$(pwd)/include/net/bluetooth/{bluetooth.h,hci.h})" modules $ make -C /lib/modules/$(uname -r)/build M=$(pwd)/drivers/bluetooth ccflags-y="$(echo "-include "$(pwd)/include/net/bluetooth/{bluetooth.h,hci.h})" modules $ strip --strip-debug net/bluetooth/bluetooth.ko $ strip --strip-debug drivers/bluetooth/btusb.koThen you can replace the old drivers in
/usr/lib/modules/$(uname -r)/kernel
with the new ones. Don't forget to backup the old files.
It worked for me, tanks.
I currently have kernel 5.15.0-78-generic
My archives copilled:
https://drive.google.com/drive/folders/1cn7CZZUWD4B8hi-y0RKCNZIo78Bw7wFV?usp=sharing
I backed up and replaced the files
btusb.ko in /usr/lib/modules/5.15.0-XX-generic/kernel/drivers/bluetooth
bluetooth.ko in /usr/lib/modules/5.15.0-XX-generic/kernel/net/bluetooth/
Tossing my picture in for others. Was anyone lucky enough to find the exact chip used or have a module where the markings aren't etched away and replaced with what I assume is a serial number or datecode?
It was advertised as a Bluetooth 4.0 radio and it supposedly has the Qualcomm CSR8510A10 chip inside of it, but I seriously doubt it.
Chip markings which seem meaningless of EAG435 with 24 pins total (Those little copper rectangles on the edge) and 13 pins soldered in a Quad Flat No-Lead (QFN) package.
Side view of chip with markings of 24Mhz crystal
Front of PCB with flash
2018.12.06
LV-B14-V1.0
Pinout so far: (Adding the pinout later. Beeping everything out currently.)
@JeffreyO Thanks a lot for going above and beyond with your teardown! I remember trying to find the actual Chinese ASIC vendor, which (unless one takes a microscope photo of the bare die) it's going to be hard, but there are mentions to companies like Barrot in the kernel, which may be a good start point for more shady stuff: https://elixir.bootlin.com/linux/latest/source/drivers/bluetooth/btusb.c#L2322
If someone tried to clone the CSR chips they haven't done it correctly. ¯\_(ツ)_/¯
@JeffreyO Thanks a lot for going above and beyond with your teardown! I remember trying to find the actual Chinese ASIC vendor, which (unless one takes a microscope photo of the bare die) it's going to be hard, but there are mentions to companies like Barrot in the kernel, which may be a good start point for more shady stuff: https://elixir.bootlin.com/linux/latest/source/drivers/bluetooth/btusb.c#L2322
If someone tried to clone the CSR chips they haven't done it correctly. ¯_(ツ)_/¯
Thank you. Also, for anyone wondering, there is a way to properly and nondestructively open up the USB dongle. I just gently pried it apart and wiggled it enough and was lucky not to break anything.
But, that's not the right way. The right way is that there's a clip in the USB part latching to the outside of the case. You press down on that and slide the dongle apart away from the metal. It should all come out in one piece.
To put it back together, you sandwich the plastic parts and the PCB back together and slide it into the metal part (Keep it mind that those 2 tiny divots in the metal are the clips. It only goes together one way.) while applying very light pressure to the clip. You should hear a click when everything is back together successfully.
This patch helped get the Ritmix RWA-350 working on Ubuntu 22.04.
Shown inlsusb
as:
ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
I cleaned up the patch:diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index 8c41c76..9632251 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -1979,6 +1979,8 @@ static int btusb_setup_csr(struct hci_dev *hdev) */ set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks); set_bit(HCI_QUIRK_BROKEN_ERR_DATA_REPORTING, &hdev->quirks); + set_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks); + set_bit(HCI_QUIRK_NO_SUSPEND_NOTIFIER, &hdev->quirks); /* Clear the reset quirk since this is not an actual * early Bluetooth 1.1 device from CSR. @@ -2018,7 +2020,7 @@ static int btusb_setup_csr(struct hci_dev *hdev) if (ret >= 0) msleep(200); else - bt_dev_err(hdev, "CSR: Failed to suspend the device for our Barrot 8041a02 receive-issue workaround"); + bt_dev_warn(hdev, "CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround"); pm_runtime_forbid(&data->udev->dev); diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h index 9ce46cb..b97602a 100644 --- a/include/net/bluetooth/hci.h +++ b/include/net/bluetooth/hci.h @@ -255,6 +255,7 @@ enum { * during the hdev->setup vendor callback. */ HCI_QUIRK_BROKEN_READ_TRANSMIT_POWER, + HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, }; /* HCI device flags */ diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c index bb84ff5..2a7af9a 100644 --- a/net/bluetooth/hci_core.c +++ b/net/bluetooth/hci_core.c @@ -294,6 +294,7 @@ static void bredr_setup(struct hci_request *req) /* Clear Event Filters */ flt_type = HCI_FLT_CLEAR_ALL; + if (!test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &req->hdev->quirks)) hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type); /* Connection accept timeout ~20 secs */ diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c index c2db60a..39a871a 100644 --- a/net/bluetooth/hci_request.c +++ b/net/bluetooth/hci_request.c @@ -1160,6 +1160,9 @@ static void hci_req_clear_event_filter(struct hci_request *req) if (!hci_dev_test_flag(req->hdev, HCI_BREDR_ENABLED)) return; + if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &req->hdev->quirks)) + return; + if (hci_dev_test_flag(req->hdev, HCI_EVENT_FILTER_CONFIGURED)) { memset(&f, 0, sizeof(f)); f.flt_type = HCI_FLT_CLEAR_ALL; @@ -1178,6 +1181,9 @@ static void hci_req_set_event_filter(struct hci_request *req) if (!hci_dev_test_flag(hdev, HCI_BREDR_ENABLED)) return; + if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks)) + return; + /* Always clear event filter when starting */ hci_req_clear_event_filter(req);Extract the
linux-source
archive corresponding to your kernel and do the following:$ patch -p1 < csr-clean.patch $ make -C /lib/modules/$(uname -r)/build M=$(pwd)/net/bluetooth ccflags-y="$(echo "-include "$(pwd)/include/net/bluetooth/{bluetooth.h,hci.h})" modules $ make -C /lib/modules/$(uname -r)/build M=$(pwd)/drivers/bluetooth ccflags-y="$(echo "-include "$(pwd)/include/net/bluetooth/{bluetooth.h,hci.h})" modules $ strip --strip-debug net/bluetooth/bluetooth.ko $ strip --strip-debug drivers/bluetooth/btusb.koThen you can replace the old drivers in
/usr/lib/modules/$(uname -r)/kernel
with the new ones. Don't forget to backup the old files.It worked for me, tanks.
I currently have kernel 5.15.0-78-generic
My archives copilled: https://drive.google.com/drive/folders/1cn7CZZUWD4B8hi-y0RKCNZIo78Bw7wFV?usp=sharing
I backed up and replaced the files
btusb.ko in /usr/lib/modules/5.15.0-XX-generic/kernel/drivers/bluetooth bluetooth.ko in /usr/lib/modules/5.15.0-XX-generic/kernel/net/bluetooth/
I have no idea on how to apply those patches and I'm willing a lot do so as my usb dongle shows up with same name in lsusb. Is there any material or could you explain me in a simple manner so I can reproduce it myself for kernel 6.6.6-arch1-1
?
Yeah, I think we were talking about this in the thread last time; I'll try to get the patches in shape and ask them to review them by e-mail a few times until they get good enough for the official thing, and some subsystem maintainer likes it enough to merge it.
After that you need to wait for the bundle of patches of that subsystem to get merged by Linus Torvalds at the top, he then tags/stamps a new version every X weeks and after three or four months it should arrive on Arch and other rolling-ish/early bird distros.
It can take years for more stable distros to get it if you don't ask them to include your patch in the stable "backports".
So yeah, not the most straightforward thing. But that is how all this works. It's free, but takes some time and patience for the back-and-forth.