From: Hans de Goede <hdegoede@redhat.com>
To: Marcel Holtmann <marcel@holtmann.org>,
Johan Hedberg <johan.hedberg@gmail.com>,
Ismael Ferreras Morezuelas <swyterzone@gmail.com>
Cc: Hans de Goede <hdegoede@redhat.com>, linux-bluetooth@vger.kernel.org
Subject: [PATCH v3] Bluetooth: btusb: Add workaround for remote-wakeup issues with Barrot 8041a02 fake CSR controllers
Date: Thu, 3 Dec 2020 12:09:44 +0100 [thread overview]
Message-ID: <20201203110944.49307-2-hdegoede@redhat.com> (raw)
In-Reply-To: <20201203110944.49307-1-hdegoede@redhat.com>
With the recent btusb change to detect and deal with more fake CSR
controllers, I decided to see if fake CSR controllers with Barrot
8041a02 chips would now work.
After much experimentation I came to the conclusion that it works, if I
have autosuspend enabled initially and then disable it after the device
has suspended at least once. Yes this is very weird, but I've tried many
things, like manually clearing the remote-wakeup feature. Doing a
runtime-resume + runtime suspend is the only way to get the receiver
to actually report received data (and/or pairing info) through its
bulk rx endpoint.
But the funkyness of the bulk-endpoint does not stop there, I mainly
found out about this problem, because with autosuspend enabled
(which usually ensures the suspend at least once condition is met),
the receiver stops reporting received data through its bulk rx endpoint
as soon as autosuspend kicks in. So I initially just disabled
autosuspend, but then the receiver does not work at all.
This was with a fake CSR receiver with a Barrot 8041a02 chip with a
bcdDevice value of 0x8891, a lmp_subver of 0x1012, a hci_rev of 0x0810
and a hci_ver of BLUETOOTH_VER_4_0.
Summarizing this specific fake CSR receiver has the following 2 issues:
1. The bulk rx endpoint will never report any data unless
the device was suspended at least once.
2. They will not wakeup when autosuspended and receiving data on their
bulk rx endpoint from e.g. a keyboard or mouse (IOW remote-wakeup support
is broken for the bulk endpoint).
Add a workaround for 1. which enables runtime-suspend, force-suspends
the hci and then wakes-it up by disabling runtime-suspend again.
Add a workaround for 2. which clears the hci's can_wake flag, this way
the hci will still be autosuspended when it is not open.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v3:
- Add info about which fake CSR chip this happens on to the commit message
and source code comment
- Only apply the workaround on this specific chip
---
drivers/bluetooth/btusb.c | 38 ++++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index ac7fede4f951..236aefaf925c 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -1768,6 +1768,7 @@ static int btusb_setup_csr(struct hci_dev *hdev)
struct hci_rp_read_local_version *rp;
struct sk_buff *skb;
bool is_fake = false;
+ int ret;
BT_DBG("%s", hdev->name);
@@ -1856,6 +1857,43 @@ static int btusb_setup_csr(struct hci_dev *hdev)
*/
clear_bit(HCI_QUIRK_RESET_ON_CLOSE, &hdev->quirks);
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).
+ * 2. They will not wakeup when autosuspended and receiving data
+ * 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.
+ *
+ * To fix 2. clear the hci's can_wake flag, this way the hci
+ * will still be autosuspended when it is not open.
+ */
+ 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\n");
+
+ 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\n");
+
+ 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);
--
2.28.0
next prev parent reply other threads:[~2020-12-03 11:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-03 11:09 [PATCH v3 0/1] Bluetooth: btusb: Add workaround for Barrot 8041a02 fake CSR controllers Hans de Goede
2020-12-03 11:09 ` Hans de Goede [this message]
2020-12-03 12:01 ` [v3] Bluetooth: btusb: Add workaround for remote-wakeup issues with " bluez.test.bot
2020-12-03 12:52 ` [PATCH v3] " kernel test robot
2020-12-03 13:59 ` [PATCH v3 0/1] Bluetooth: btusb: Add workaround for " Marcel Holtmann
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=20201203110944.49307-2-hdegoede@redhat.com \
--to=hdegoede@redhat.com \
--cc=johan.hedberg@gmail.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=marcel@holtmann.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).