]> git.baikalelectronics.ru Git - kernel.git/commit
usb: hub: Wait for connection to be reestablished after port reset
authorGuenter Roeck <linux@roeck-us.net>
Thu, 1 Dec 2016 21:49:59 +0000 (13:49 -0800)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 5 Dec 2016 14:13:58 +0000 (15:13 +0100)
commitab1083164dfb75d800f8c89e4e7ccdf37c0f32f2
tree845da88353e5044e07938eecae49bbbccb549fba
parent3b3e3391cd57516803d52c9d3161a42ef07fcb9f
usb: hub: Wait for connection to be reestablished after port reset

On a system with a defective USB device connected to an USB hub,
an endless sequence of port connect events was observed. The sequence
of events as observed is as follows:

- Port reports connected event (port status=USB_PORT_STAT_CONNECTION).
- Event handler debounces port and resets it by calling hub_port_reset().
- hub_port_reset() calls hub_port_wait_reset() to wait for the reset
  to complete.
- The reset completes, but USB_PORT_STAT_CONNECTION is not immediately
  set in the port status register.
- hub_port_wait_reset() returns -ENOTCONN.
- Port initialization sequence is aborted.
- A few milliseconds later, the port again reports a connected event,
  and the sequence repeats.

This continues either forever or, randomly, stops if the connection
is already re-established when the port status is read. It results in
a high rate of udev events. This in turn destabilizes userspace since
the above sequence holds the device mutex pretty much continuously
and prevents userspace from actually reading the device status.

To prevent the problem from happening, let's wait for the connection
to be re-established after a port reset. If the device was actually
disconnected, the code will still return an error, but it will do so
only after the long reset timeout.

Cc: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/usb/core/hub.c