Re: [PATCH] USB: hub: Don't record a connect-change event during reset-resume

[Paul Zimmerman <pauldzim@gmail.com>]

On Fri, 31 Jan 2020 10:39:26 -0500 (EST)
Alan Stern <stern@rowland.harvard.edu> wrote:

> Paul Zimmerman reports that his USB Bluetooth adapter sometimes
> crashes following system resume, when it receives a
> Get-Device-Descriptor request while it is busy doing something else.
> 
> Such a request was added by commit a4f55d8b8c14 ("usb: hub: Check
> device descriptor before resusciation").  It gets sent when the hub
> driver's work thread checks whether a connect-change event on an
> enabled port really indicates a new device has been connected, as
> opposed to an old device momentarily disconnecting and then
> reconnecting (which can happen with xHCI host controllers, since they
> automatically enable connected ports).

< snip > 

> Note that performing the unnecessary check is not actually a bug.
> Devices are supposed to be able to send descriptors back to the host
> even when they are busy doing something else.  The underlying cause of
> Paul's problem lies in his Bluetooth adapter.  Nevertheless, we
> shouldn't perform the same check twice in a row -- and as a nice side
> benefit, removing the extra check allows the Bluetooth adapter to work
> more reliably.

Actually, at the time the failure happens, the bluetooth driver is putting
the device into a "manufacturer mode" and downloading a firmware patch to
the device. So I don't think we can fault the device for not responding to
a get-descriptor request at that point. Probably there should be some kind
of locking in the driver while that is being done.

Nevertheless, your patch makes everything work again, so I think it's
"good enough" :)

Thanks,
Paul