On Wed, 23 May 2018, Anshuman Gupta wrote: > On Tue, May 22, 2018 at 11:54:19AM -0400, Alan Stern wrote: > > 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? > There is no as such problem for usb core but on chrome-os we want to increment > the wakeup-count for the usb device which is causing wakeup from suspend. > > So to address above mention case, is it appropriate that hub_port_status URB completion > can wait for port to be resume, if the particular port was resuming at that instant? I'm not sure what you're asking. If the port's suspend feature is set, of course the kernel has to clear the feature and wait for the port to resume. If the suspend feature isn't set then the pm_wakeup_event will be sent, which is what you want. Have I misunderstood something? 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
