On a system with a defective USB device connected to an USB hub,an endless sequence of port connect events was observed. The sequenceof 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 connectionis already re-established when the port status is read. It results ina high rate of udev events. This in turn destabilizes userspace sincethe above sequence holds the device mutex pretty much continuouslyand prevents userspace from actually reading the device status.

To prevent the problem from happening, let's wait for the connectionto be re-established after a port reset. If the device was actuallydisconnected, the code will still return an error, but it will do soonly after the long reset timeout.

- /* The port state is unknown until the reset completes. */- if (!(portstatus & USB_PORT_STAT_RESET))+ /*+ * The port state is unknown until the reset completes.+ *+ * On top of that, some chips may require additional time+ * to re-establish a connection after the reset is complete,+ * so also wait for the connection to be re-established.+ */+ if (!(portstatus & USB_PORT_STAT_RESET) &&+ (portstatus & USB_PORT_STAT_CONNECTION)) break;