On Fri, 31 Jan 2020 10:39:26 -0500 (EST)
Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> 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
