On Tue, 22 May 2018, Anshuman Gupta wrote: > Hi, > > When a xhci USB2.0 port is resuming and waiting for resume signaling, > completion of > USB_RESUME_TIMEOUT, it just reports the port status as USB_PORT_STAT_SUSPEND, > and let the usbcore to check the port status again. > > https://elixir.bootlin.com/linux/v4.17-rc6/source/drivers/usb/host/xhci-hub.c#L960 > > > USB core just checks the port status in usb_port_resume function > and if port status is in suspended state, it clears the port suspend feature. > > https://elixir.bootlin.com/linux/v4.17-rc6/source/drivers/usb/core/hub.c#L3441 > > But when system resumes due to a USB remote wakeup event from suspend state, > and port which causes remote wakeup is still waiting for resume signaling, > usb_port_resume function in this particular case clears the port suspend > feature, > and wait for 40ms again(USB_RESUME_TIMEOUT). > > Query regarding above case: > Here in this case USB core will miss the wake up event from the port which > causes > the remote wake. > https://elixir.bootlin.com/linux/v4.17-rc6/source/drivers/usb/core/hub.c#L3444
What do you mean? You said above: "system resumes due to a USB remote wakeup event". The fact that the system is resuming indicates that it did _not_ miss the wakeup event. > If a port is already resuming and waiting for resume signaling, does it make > sense to clear the port suspend feature and wait for 40ms again. When the system resumes from a suspend state, it wakes up _all_ the suspended USB ports. Waiting an extra 40 ms for one port won't make much difference. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
