On 16.11.2021 10.22, Greg KH wrote:

On Tue, Nov 16, 2021 at 12:16:30AM +0200, Mathias Nyman wrote:

quoted

xHC hardware can only have one slot in default state with address 0
waiting for a unique address at a time, otherwise "undefined behavior
may occur" according to xhci spec 5.4.3.4

The address0_mutex exists to prevent this across both xhci roothubs.

If hub_port_init() fails, it may unlock the mutex and exit with a xhci
slot in default state. If the other xhci roothub calls hub_port_init()
at this point we end up with two slots in default state.

Make sure the address0_mutex protects the slot default state across
hub_port_init() retries, until slot is addressed or disabled.

Note, one known minor case is not fixed by this patch.
If device needs to be reset during resume, but fails all hub_port_init()
retries in usb_reset_and_verify_device(), then it's possible the slot is
still left in default state when address0_mutex is unlocked.

Cc: <redacted>
Signed-off-by: Mathias Nyman <redacted>

What commit id does this "fix"?

Looks like original cause could be:
638139eb95d2 ("usb: hub: allow to process more usb hub events in parallel")

which was partially fixed in 4.7 by:
feb26ac31a2a ("usb: core: hub: hub_port_init lock controller instead of bus")

And now improved by this patch 

-Mathias