From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
stable@vger.kernel.org, Hans de Goede <hdegoede@redhat.com>,
Ismael Ferreras Morezuelas <swyterzone@gmail.com>,
Marcel Holtmann <marcel@holtmann.org>
Subject: [PATCH 5.13 10/22] Bluetooth: btusb: Make the CSR clone chip force-suspend workaround more generic
Date: Fri, 10 Sep 2021 14:30:09 +0200 [thread overview]
Message-ID: <20210910122916.273789753@linuxfoundation.org> (raw)
In-Reply-To: <20210910122915.942645251@linuxfoundation.org>
From: Ismael Ferreras Morezuelas <swyterzone@gmail.com>
commit f4292e2faf522f899b642d2040a2edbcbd455b9f upstream.
Turns out Hans de Goede completed the work I started last year trying to
improve Chinese-clone detection of CSR controller chips. Quirk after quirk
these Bluetooth dongles are more usable now.
Even after a few BlueZ regressions; these clones are so fickle that some
days they stop working altogether. Except on Windows, they work fine.
But this force-suspend initialization quirk seems to mostly do the trick,
after a lot of testing Bluetooth now seems to work *all* the time.
The only problem is that the solution ended up being masked under a very
stringent check; when there are probably hundreds of fake dongle
models out there that benefit from a good reset. Make it so.
Fixes: 81cac64ba258a ("Bluetooth: Deal with USB devices that are faking CSR vendor")
Fixes: cde1a8a992875 ("Bluetooth: btusb: Fix and detect most of the Chinese Bluetooth controllers")
Fixes: d74e0ae7e0303 ("Bluetooth: btusb: Fix detection of some fake CSR controllers with a bcdDevice val of 0x0134")
Fixes: 0671c0662383e ("Bluetooth: btusb: Add workaround for remote-wakeup issues with Barrot 8041a02 fake CSR controllers")
Cc: stable@vger.kernel.org
Cc: Hans de Goede <hdegoede@redhat.com>
Tested-by: Ismael Ferreras Morezuelas <swyterzone@gmail.com>
Signed-off-by: Ismael Ferreras Morezuelas <swyterzone@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/bluetooth/btusb.c | 63 ++++++++++++++++++++++++----------------------
1 file changed, 34 insertions(+), 29 deletions(-)
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -1890,7 +1890,7 @@ static int btusb_setup_csr(struct hci_de
is_fake = true;
if (is_fake) {
- bt_dev_warn(hdev, "CSR: Unbranded CSR clone detected; adding workarounds...");
+ bt_dev_warn(hdev, "CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once...");
/* Generally these clones have big discrepancies between
* advertised features and what's actually supported.
@@ -1907,41 +1907,46 @@ static int btusb_setup_csr(struct hci_de
clear_bit(HCI_QUIRK_SIMULTANEOUS_DISCOVERY, &hdev->quirks);
/*
- * Special workaround for clones with a Barrot 8041a02 chip,
- * these clones are really messed-up:
- * 1. Their bulk rx endpoint will never report any data unless
- * the device was suspended at least once (yes really).
+ * Special workaround for these BT 4.0 chip clones, and potentially more:
+ *
+ * - 0x0134: a Barrot 8041a02 (HCI rev: 0x1012 sub: 0x0810)
+ * - 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).
* 2. They will not wakeup when autosuspended and receiving data
- * on their bulk rx endpoint from e.g. a keyboard or mouse
+ * 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.
+ * HCI and then wake-it up by disabling runtime-suspend.
*
- * To fix 2. clear the hci's can_wake flag, this way the hci
+ * To fix 2. clear the HCI's can_wake flag, this way the HCI
* will still be autosuspended when it is not open.
+ *
+ * --
+ *
+ * Because these are widespread problems we prefer generic solutions; so
+ * apply this initialization quirk to every controller that gets here,
+ * it should be harmless. The alternative is to not work at all.
*/
- if (bcdDevice == 0x8891 &&
- le16_to_cpu(rp->lmp_subver) == 0x1012 &&
- le16_to_cpu(rp->hci_rev) == 0x0810 &&
- le16_to_cpu(rp->hci_ver) == BLUETOOTH_VER_4_0) {
- bt_dev_warn(hdev, "CSR: detected a fake CSR dongle using a Barrot 8041a02 chip, this chip is very buggy and may have issues");
-
- pm_runtime_allow(&data->udev->dev);
-
- ret = pm_runtime_suspend(&data->udev->dev);
- if (ret >= 0)
- msleep(200);
- else
- bt_dev_err(hdev, "Failed to suspend the device for Barrot 8041a02 receive-issue workaround");
-
- pm_runtime_forbid(&data->udev->dev);
-
- device_set_wakeup_capable(&data->udev->dev, false);
- /* Re-enable autosuspend if this was requested */
- if (enable_autosuspend)
- usb_enable_autosuspend(data->udev);
- }
+ pm_runtime_allow(&data->udev->dev);
+
+ ret = pm_runtime_suspend(&data->udev->dev);
+ if (ret >= 0)
+ msleep(200);
+ else
+ bt_dev_err(hdev, "CSR: Failed to suspend the device for our Barrot 8041a02 receive-issue workaround");
+
+ pm_runtime_forbid(&data->udev->dev);
+
+ device_set_wakeup_capable(&data->udev->dev, false);
+
+ /* Re-enable autosuspend if this was requested */
+ if (enable_autosuspend)
+ usb_enable_autosuspend(data->udev);
}
kfree_skb(skb);
next prev parent reply other threads:[~2021-09-10 12:32 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-10 12:29 [PATCH 5.13 00/22] 5.13.16-rc1 review Greg Kroah-Hartman
2021-09-10 12:30 ` [PATCH 5.13 01/22] firmware: dmi: Move product_sku info to the end of the modalias Greg Kroah-Hartman
2021-09-10 12:30 ` [PATCH 5.13 02/22] igmp: Add ip_mc_list lock in ip_check_mc_rcu Greg Kroah-Hartman
2021-09-10 12:30 ` [PATCH 5.13 03/22] net: ll_temac: Remove left-over debug message Greg Kroah-Hartman
2021-09-10 12:30 ` [PATCH 5.13 04/22] Revert "r8169: avoid link-up interrupt issue on RTL8106e if user enables ASPM" Greg Kroah-Hartman
2021-09-10 12:30 ` [PATCH 5.13 05/22] blk-mq: fix kernel panic during iterating over flush request Greg Kroah-Hartman
2021-09-10 12:30 ` [PATCH 5.13 06/22] blk-mq: fix is_flush_rq Greg Kroah-Hartman
2021-09-10 12:30 ` [PATCH 5.13 07/22] blk-mq: clearing flush request reference in tags->rqs[] Greg Kroah-Hartman
2021-09-10 12:30 ` [PATCH 5.13 08/22] ALSA: usb-audio: Add registration quirk for JBL Quantum 800 Greg Kroah-Hartman
2021-09-10 12:30 ` [PATCH 5.13 09/22] Bluetooth: Add additional Bluetooth part for Realtek 8852AE Greg Kroah-Hartman
2021-09-10 12:30 ` Greg Kroah-Hartman [this message]
2021-09-10 12:30 ` [PATCH 5.13 11/22] usb: host: xhci-rcar: Dont reload firmware after the completion Greg Kroah-Hartman
2021-09-10 12:30 ` [PATCH 5.13 12/22] usb: xhci-mtk: fix issue of out-of-bounds array access Greg Kroah-Hartman
2021-09-10 12:30 ` [PATCH 5.13 13/22] usb: cdnsp: fix the wrong mult value for HS isoc or intr Greg Kroah-Hartman
2021-09-10 12:30 ` [PATCH 5.13 14/22] usb: gadget: tegra-xudc: " Greg Kroah-Hartman
2021-09-10 12:30 ` [PATCH 5.13 15/22] usb: mtu3: restore HS function when set SS/SSP Greg Kroah-Hartman
2021-09-10 12:30 ` [PATCH 5.13 16/22] usb: mtu3: use @mult for HS isoc or intr Greg Kroah-Hartman
2021-09-10 12:30 ` [PATCH 5.13 17/22] usb: mtu3: fix the wrong HS mult value Greg Kroah-Hartman
2021-09-10 12:30 ` [PATCH 5.13 18/22] xhci: fix even more unsafe memory usage in xhci tracing Greg Kroah-Hartman
2021-09-10 12:30 ` [PATCH 5.13 19/22] xhci: fix " Greg Kroah-Hartman
2021-09-10 12:30 ` [PATCH 5.13 20/22] xhci: Fix failure to give back some cached cancelled URBs Greg Kroah-Hartman
2021-09-10 12:30 ` [PATCH 5.13 21/22] x86/reboot: Limit Dell Optiplex 990 quirk to early BIOS versions Greg Kroah-Hartman
2021-09-10 12:30 ` [PATCH 5.13 22/22] PCI: Call Max Payload Size-related fixup quirks early Greg Kroah-Hartman
2021-09-10 18:38 ` [PATCH 5.13 00/22] 5.13.16-rc1 review Fox Chen
2021-09-10 19:43 ` Florian Fainelli
2021-09-10 23:17 ` Shuah Khan
2021-09-11 16:20 ` Justin Forbes
2021-09-11 19:36 ` Guenter Roeck
2021-09-12 0:48 ` Daniel Díaz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210910122916.273789753@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--cc=hdegoede@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcel@holtmann.org \
--cc=stable@vger.kernel.org \
--cc=swyterzone@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).