diff options
| author | Mathias Nyman <mathias.nyman@linux.intel.com> | 2021-11-16 01:16:30 +0300 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2021-11-17 17:04:52 +0300 |
| commit | 6ae6dc22d2d1ce6aa77a6da8a761e61aca216f8b (patch) | |
| tree | 10ae1b037723d636b028bd7d3d14ddb50aa1b395 /drivers/usb/chipidea | |
| parent | 362468830dd5bea8bf6ad5203b2ea61f8a4e8288 (diff) | |
| download | linux-6ae6dc22d2d1ce6aa77a6da8a761e61aca216f8b.tar.xz | |
usb: hub: Fix usb enumeration issue due to address0 race
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: <stable@vger.kernel.org>
Fixes: 638139eb95d2 ("usb: hub: allow to process more usb hub events in parallel")
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20211115221630.871204-1-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers/usb/chipidea')
0 files changed, 0 insertions, 0 deletions