On Wed, 21 Aug 2013, Sarah Sharp wrote: > Possible fixes > -------------- > > The USB core obviously needs to be changed to check the port status > after the TRSMRCY timeout, and continue to wait if the port is still in > the resuming state. I will have to study the EHCI port status diagrams > in detail to figure out how the USB core can do this. As far as EHCI is concerned, this is a non-problem. The closest analogy to the RExit->U0 transition is in the description of the Force Port Resume bit (bit 6) in Table 2-16 of the EHCI spec, where it says that the host controller must complete the transition to the high-speed idle state within 2 milliseconds of software setting the bit to a zero (which happens when the hub driver does its Get-Port-Status call). Thus, as soon as the TRSMRCY delay is finished, the device and the port are supposed to be ready. In fact, the hardware doesn't provide any means of telling whether they are ready or not. > I can easily do > this without the USB core being involved, by changing the xHCI driver to > either: > > 1. Busy wait with xhci_handshake() in the xHCI get port status until > the port is in U0. > > 2. Add a completion per xHCI port. In xHCI get port status, initiate > U0 entry, and wait on the port's completion for up to 20 ms. In the > port status change event code, complete that port's completion when > the port is in U0 and the bus_state->resuming_ports bit is set. I would expect either of those to be adequate. 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
