lkml.org 
[lkml]   [2017]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 4.13 03/28] Bluetooth: btusb: fix QCA Rome suspend/resume
Hi,

El Sun, Nov 19, 2017 at 03:43:50PM +0100 Greg Kroah-Hartman ha dit:

> 4.13-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Leif Liddy <leif.linux@gmail.com>
>
> commit fd865802c66bc451dc515ed89360f84376ce1a56 upstream.
>
> There's been numerous reported instances where BTUSB_QCA_ROME
> bluetooth controllers stop functioning upon resume from suspend. These
> devices seem to be losing power during suspend. Patch will detect a status
> change on resume and perform a reset.
>
> Signed-off-by: Leif Liddy <leif.linux@gmail.com>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> Cc: Kai Heng Feng <kai.heng.feng@canonical.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> ---
> drivers/bluetooth/btusb.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -3068,6 +3068,12 @@ static int btusb_probe(struct usb_interf
> if (id->driver_info & BTUSB_QCA_ROME) {
> data->setup_on_usb = btusb_setup_qca;
> hdev->set_bdaddr = btusb_set_bdaddr_ath3012;
> +
> + /* QCA Rome devices lose their updated firmware over suspend,
> + * but the USB hub doesn't notice any status change.
> + * Explicitly request a device reset on resume.
> + */
> + set_bit(BTUSB_RESET_RESUME, &data->flags);
> }
>
> #ifdef CONFIG_BT_HCIBTUSB_RTL
>
>

On Chrome OS QCA Bluetooth stopped working after a merge from v4.4-stable:

[ 124.789298] usb 2-1.1: reset full-speed USB device number 3 using ehci-platform
[ 126.624274] Bluetooth: hci0 command 0x2005 tx timeout
[ 128.672262] Bluetooth: hci0 command 0x200b tx timeout
[ 130.720264] Bluetooth: hci0 command 0x200c tx timeout

We identified the above patch as the culprit, in combination with USB
autosuspend being enabled for the Bluetooth controller.

We found that the following (recent) upstream patch fixes the issue on
most devices (we are still investigating one case on a specific device):

commit a0085f2510e8976614ad8f766b209448b385492f
Author: Sukumar Ghorai <sukumar.ghorai@intel.com>
Date: Wed Aug 16 14:46:55 2017 -0700

Bluetooth: btusb: driver to enable the usb-wakeup feature

BT-Controller connected as platform non-root-hub device and
usb-driver initialize such device with wakeup disabled,
Ref. usb_new_device().

At present wakeup-capability get enabled by hid-input device from usb
function driver(e.g. BT HID device) at runtime. Again some functional
driver does not set usb-wakeup capability(e.g LE HID device implement
as HID-over-GATT), and can't wakeup the host on USB.

Most of the device operation (such as mass storage) initiated from host
(except HID) and USB wakeup aligned with host resume procedure. For BT
device, usb-wakeup capability need to enable form btusc driver as a
generic solution for multiple profile use case and required for USB remote
wakeup (in-bus wakeup) while host is suspended. Also usb-wakeup feature
need to enable/disable with HCI interface up and down.


stable branches are currently broken for BTUSB_QCA_ROME with USB
autosuspend enabled, since the above patch is not included (I only
checked v4.4 and v4.9), so we probably want to integrate it.

Thanks

Matthias

\
 
 \ /
  Last update: 2017-12-16 04:06    [W:0.128 / U:4.868 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site