On Fri, Dec 15, 2017 at 07:05:39PM -0800, Matthias Kaehlcke wrote:
> 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@xxxxxxxxx>
> >
> > 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@xxxxxxxxx>
> > Signed-off-by: Marcel Holtmann <marcel@xxxxxxxxxxxx>
> > Cc: Kai Heng Feng <kai.heng.feng@xxxxxxxxxxxxx>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> >
> > ---
> > 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@xxxxxxxxx>
> 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.
Now queued up, thanks for letting me know.
greg k-h