On Wed, 31 Dec 2014, Peter Chen wrote: > > The only solution I can think of is not very satisfactory. Suppose the > > controller doesn't send any SoF packets within 3 ms of getting a wakeup > > signal. Then the device will go back into suspend. Later on, when the > > controller starts running, the hub driver will see that the device > > requested a wakeup and will resume the device. > > Thanks, Alan. > > If the roothub will send resume before sending SoF, it should be ok, I > just remembered I had seen "disconnect" before due to host send > SoF to suspended device, will check it again. There may be a problem, because the wakeup signal will cause the port to switch automatically from suspend to active status. This means it will use the high-speed terminations. But the device will go back into suspend when it doesn't get any SoF packets within 3 ms, so it will be using the full-speed terminations. Then when the host controller does start sending out SoF packets, the mismatched terminations will show up as a disconnect. (I really think this is a mistake in the USB spec. Allowing only 3 ms for a host system to turn itself on is not reasonable.) We could try putting the port back into suspend before turning on the Run/Stop bit. That might work -- but if we don't do it carefully, we will lose track of the fact that the device sent a wakeup signal. Can you try testing this approach to see if it will work? 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
