On Thu, 31 May 2018, Anshuman Gupta wrote:

> > +           resuming_ports = hcd->driver->get_resuming_ports(hcd);
> > +           for (i = 0; i < hdev->maxchild; ++i) {
> > +                   if (test_bit(i, &resuming_ports)) {
> > +                           struct usb_port *port_dev = hub->ports[i];
> > +
> > +                           pm_wakeup_event(&port_dev->dev, 0);
>   port_dev does not have a wakeup source, there will not any wakeup_count 
> increment 
>   for port_dev, usb_dev for a particular port has wakeup source associated 
> with it,
>   so using port_dev->child usb_dev instead of usb_port device. 

Okay.  However, there might not be a child usb_dev below the port.  For 
example, a wakeup signal could happen as a result of the user plugging 
in a new device.

In any case, when the system wakes up because of a signal received by a 
USB host controller, there should be a wakeup event associated with the 
host controller.  Don't you get those events?

Alan Stern

PS: Do you have a wakeup-capable USB-3 device?  I'm not sure that the 
patch will work the way you want for USB-3 devices.

--
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