@@ -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;
}
https://bugzilla.kernel.org/show_bug.cgi?id=203535 Abhishek Pandit-Subedi (abhishekpandit@chromium.org) changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |abhishekpandit@chromium.org --- Comment #5 from Abhishek Pandit-Subedi (abhishekpandit@chromium.org) --- 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).