Re: [Query] checking hub port status while USB 2.0 port is resuming.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 24 May 2018, Anshuman Gupta wrote:

> > > > 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?
>   yes we want to detect and report wakeup event for above mention issue, but not in favour 
>   of adding 40ms delay. Please suggest if there is any better way of doing that.     

It sounds like you want the code in usb_port_resume() to check and see
whether the port has already received a wakeup signal and hasn't
finished processing it yet.

There's no way to do this for ports on external hubs, but in principle 
it can be done for ports on root hubs.  If we see that a wakeup signal 
was received, we can call pm_wakeup_event().  Will that be good enough?

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



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux