https://bugzilla.kernel.org/show_bug.cgi?id=203535 Abhishek Pandit-Subedi (abhishekpandit@xxxxxxxxxxxx) changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |abhishekpandit@xxxxxxxxxxxx --- Comment #5 from Abhishek Pandit-Subedi (abhishekpandit@xxxxxxxxxxxx) --- 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; } -- You are receiving this mail because: You are the assignee for the bug.
