summaryrefslogtreecommitdiff
path: root/net/bluetooth
diff options
context:
space:
mode:
authorHans de Goede <hdegoede@redhat.com>2020-12-05 18:02:01 +0300
committerJohan Hedberg <johan.hedberg@intel.com>2020-12-07 18:01:54 +0300
commit0671c0662383eefc272e107364cba7fe229dee44 (patch)
tree73959464358c5b88d4ff9668d5f4d6a52d30934b /net/bluetooth
parentd74e0ae7e03032b47b8631cc1e52a7ae1ce988c0 (diff)
downloadlinux-0671c0662383eefc272e107364cba7fe229dee44.tar.xz
Bluetooth: btusb: Add workaround for remote-wakeup issues with Barrot 8041a02 fake CSR controllers
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> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Diffstat (limited to 'net/bluetooth')
0 files changed, 0 insertions, 0 deletions