> > > > No, that's not what I meant. Suppose there is no intermediate hub, > > > only a 3G modem plugged directly into the root hub. The 3G modem > does > > > a runtime autosuspend, and then 2 seconds later sends a wakeup > request. > > > > > > But the autosuspend timeout for the root hub is also 2 seconds, so > the > > > root hub suspends and the PHY goes into low-power mode at just the > same > > > time as when the wakeup request arrives. > > > > At your case, if we put PHY enters low power mode code at both > ehci_hub_control > > and ehci_bus_suspend, once 3G modem is suspended, the ehci_hub_control > > (USB_PORT_FEAT_SUSPEND) will be called, then PHY enters low power mode > code > > will be called. roohub suspend (ehci_bus_suspend) will not set > PORT_SUSPEND > > at portsc and call PHY enters low power mode code again. > > Okay, I didn't realize you wanted to change the PHY state in > ehci_hub_control also. You would power-down the PHY whenever every > connected port was suspended, right? > Oh, I have no experiences on multi-port system, all Freescale i.mx SoC has only one port. > So consider this scenario instead. There is no intermediate hub, but > there are two devices plugged directly into the root hub: a 3G modem > and a flash drive. The 3G modem goes into runtime suspend. A minute > later, the user unplugs the flash drive, and at that point the PHY is > powered down. What's to prevent the modem from sending a wakeup signal > at the same time? Modem can send wakeup at any time, yes, on multi-port system, the things are different, it needs roothub handles one port's resume as well as PHY is entering low power mode. -- 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
