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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to