On Thu, 3 Nov 2011, Sarah Sharp wrote: > I also think there's a potential race condition because the PLC bit can > race with another port status change bit to cause a port status event, > and it will take some time for the USB core to react to it. I can > envision the following scenario (although I think it's pretty unlikely > to be hit by anyone): > > 1. USB 2.0 device on port 1 has hardware LPM enabled, and it's currently > in U2. > > 2. A second device on port 2 shares a ganged power switch with port 1, > and it starts to draw too much current. > > 3. The xHC sets the overcurrent change bit for ports 1 and 2, and > generates a port status change event. > > 4. The event is handled and khubd is kicked. However, before it can > clear the OCC bit, the device on port 1 comes out of U2, and the PLC > bit is set. > > Since OCC is set, the xHC won't generate a port status change event for > the PLC bit, That's not right. Regardless of whether other port-status-change bits are set, if PLC wasn't set originally then setting it should generate a port-status-change event. If the controller doesn't behave this way then it is indeed subject to races. > and it will never have the chance to be cleared in the port > status change event handler. I think what we need to do is check if the > PLC bit is set for a USB 2.0 device in the function that clears any > other port status change bit, and make sure to clear PLC there. You're talking about USB_PORT_STAT_C_PORT_LINK_STATE, right? This happens in two places: hub_activate() and hub_events(). Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
