On Tue, 22 May 2018, Anshuman Gupta wrote: > On Tue, May 22, 2018 at 09:53:09AM -0400, Alan Stern wrote: > > On Tue, 22 May 2018, Anshuman Gupta wrote: > > > Thanks Alan for your quick response. > > > 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. > > > What was i meaning, if system come out of suspend due to a key pressed on usb > keyboard. > For the above mention case, it will not raise any pm_wakeup_event so the > notification > of the pm_wakeup_event for usb keyboard will get missed.
Okay, let's say you're right. What difference does it make if the pm_wakeup_event gets lost? Will that cause a problem? Alan Stern > > > 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
