XHCI: trying to submit a transfer to a non-existent endpoint!

[waddlesplash]

This is the underlying cause of the (now-fixed) KDL in #12929.

Easily reproducible by plugging in an Android phone, setting it to USB MIDI mode, and then running find /dev:

KERN: usb hub 2: KERN: port 0: new device connected
KERN: usb xhci 0: cancel queued transfers for pipe 0xffffffff820d0e40 (0)
KERN: usb hub 2: KERN: port 0: new device connected
KERN: usb error hub 2: new device on a port that is already in use
KERN: usb xhci 0: cancel queued transfers for pipe 0xffffffff820d0e40 (0)
KERN: usb xhci 0: cancel queued transfers for pipe 0xffffffff96dbfa00 (0)
KERN: usb xhci 0: KERN: cancel queued transfers for pipe 0xffffffff96d9f750 (1)
KERN: usb xhci 0: KERN: cancel queued transfers for pipe 0xffffffff96d9f480 (1)
KERN: usb xhci 0: KERN: cancel queued transfers for pipe 0xffffffff96d9f430 (2)
KERN: check_sense: encountered DEFERRED ERROR - bye, bye
KERN: bt: bluetooth_std_ops: Connection Thread error
KERN: usb xhci 0: cancel queued transfers for pipe 0xffffffff82ce98e8 (1)
KERN: usb xhci 0: KERN: cancel queued transfers for pipe 0xffffffff81a9bc30 (2)
KERN: usb xhci 0: cancel queued transfers for pipe 0xffffffff818164d8 (2)
KERN: musb_midi: init_driver() version:Feb 23 2019 12:01:32
KERN: usb_midi: ...
...
KERN: usb error xhci 0: trying to submit a transfer to a non-existent endpoint!

[waddlesplash]

It seems what's going on is that the new device overwrites the old one, or at least the new endpoint is associated with the old device, and then the old device is deleted, clearing the device structure and thus implicitly destroying all the endpoints.