[ARCHIVED] Fix for CSR Dongle 0a12:0001 ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

archived.md

This gist is currenctly archived.

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

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.

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?

OKay found this thread when debugging my bluetooth hid device. Sometimes it works on linux, and doesnt work on my phone and windows. And when it works on windows and android, it doesnt work on linux. My issue is that it doesnt show up as a joystick and so it doesnt subscribe to the hid characteristic. Using TP-LINK UB400 and it shows up just like yours.

These CSR clones are not one device. They use the same case, but there may be different chips inside. They simply use the API from an existing driver so as not to write their own. But they only test it on Windows. Since different chips are used, their firmware has a variety of bugs, so workarounds for one clone will not help for another.

These CSR clones are not one device. They use the same case, but there may be different chips inside. They simply use the API from an existing driver so as not to write their own. But they only test it on Windows. Since different chips are used, their firmware has a variety of bugs, so workarounds for one clone will not help for another.

The CSR's barely work on Windows even. Maybe for very basic stuff. But, if it says that it has Bluetooth LE and advanced features, it definitely does not, or if it does, it's extremely broken.

These CSR clones are not one device. They use the same case, but there may be different chips inside. They simply use the API from an existing driver so as not to write their own. But they only test it on Windows. Since different chips are used, their firmware has a variety of bugs, so workarounds for one clone will not help for another.

The CSR's barely work on Windows even. Maybe for very basic stuff. But, if it says that it has Bluetooth LE and advanced features, it definitely does not, or if it does, it's extremely broken.

well the one i have is tp-link ub400, thought they were a reputable brand

These CSR clones are not one device. They use the same case, but there may be different chips inside. They simply use the API from an existing driver so as not to write their own. But they only test it on Windows. Since different chips are used, their firmware has a variety of bugs, so workarounds for one clone will not help for another.

The CSR's barely work on Windows even. Maybe for very basic stuff. But, if it says that it has Bluetooth LE and advanced features, it definitely does not, or if it does, it's extremely broken.

well the one i have is tp-link ub400, thought they were a reputable brand

TP-Link should be a good one. But, the generic no-name ones like one I posted pictures to above is awful even on Windows.

I wonder if it's possible to rewrite and reflash the firmware of the CSR Clones. They could be an interesting thing for a common open-source firmware. The device is awful, but it's extremely common and cheap.

I wonder if it's possible to rewrite and reflash the firmware of the CSR Clones. They could be an interesting thing for a common open-source firmware. The device is awful, but it's extremely common and cheap.

Chinese manufacturers produce identical looking Bluetooth dongles with different chips. They use new chips over time. So you can't have one firmware to fix them all.

I wonder if it's possible to rewrite and reflash the firmware of the CSR Clones. They could be an interesting thing for a common open-source firmware. The device is awful, but it's extremely common and cheap.

Chinese manufacturers produce identical looking Bluetooth dongles with different chips. They use new chips over time. So you can't have one firmware to fix them all.

Ah, that's unfortunate.