Comment 13 for bug 1998103

There's a recovery mechanism via `cmd_timeout` that the btusb driver uses to recover from these issues. For Intel chipsets, this requires having a reset gpio available and listed in the ACPI/DeviceTree. From the logs above, it looks like that's not the case.

I've had some success on a QCA chipset (6174A) by just resetting the port when this happens (see https://patchwork.kernel.org/patch/11624041/)

If you don't mind patching your kernel, you could try the following and see if it helps (you will need the series I linked above as well if you're not using bluetooth-next master branch).

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 0e143c0cecf2a1..cf86104fd62018 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -511,6 +511,7 @@ struct btusb_data {
        unsigned cmd_timeout_cnt;
 };

+static void btusb_qca_cmd_timeout(struct hci_dev *hdev);
 static void btusb_intel_cmd_timeout(struct hci_dev *hdev)
 {
        struct btusb_data *data = hci_get_drvdata(hdev);
@@ -520,7 +521,8 @@ static void btusb_intel_cmd_timeout(struct hci_dev *hdev)
                return;

        if (!reset_gpio) {
- bt_dev_err(hdev, "No way to reset. Ignoring and continuing");
+ bt_dev_err(hdev, "No reset gpio. Resetting usb instead.");
+ btusb_qca_cmd_timeout(hdev);
                return;
        }