On Thu, 24 May 2018, Anshuman Gupta wrote: > On Wed, May 23, 2018 at 09:55:40AM -0400, Alan Stern wrote: > > 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. > What i was looking for, report the pm_wakeup_event for the port, which is the source of > remote wakeup, as below code snippet from usb_port_resume() does that. > > /* Skip the initial Clear-Suspend step for a remote wakeup */ > status = hub_port_status(hub, port1, &portstatus, &portchange); > if (status == 0 && !port_is_suspended(hub, portstatus)) { > if (portchange & USB_PORT_STAT_C_SUSPEND) > pm_wakeup_event(&udev->dev, 0); > goto SuspendCleared; > } > > But in some cases as i mentioned above, if a port is resuming, it waits for 40ms to report > change in port status and port change bits, In those cases usb_port_resume function > will not increment wakeup-count and it will clear the suspend feature, so now we can not > distinguish whethwer a port has resume due to remote wakeup or by clearing its suspend > feature by usb_port_resume function. > > We want to address this issue, Is there any way so that hub_port_status can wait > for port resume completion? Let me make sure I understand. You want to slow down system resume of xHCI root hubs by 40 ms in order to detect and report port wakeup requests. Is that correct? 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
