Re: [PATCH 4.13 03/28] Bluetooth: btusb: fix QCA Rome suspend/resume

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

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@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.

Now queued up, thanks for letting me know.

greg k-h