On Wed, 27 Apr 2005, David Brownell wrote: > On Tuesday 26 April 2005 10:08 am, Alan Stern wrote: > > On Tue, 26 Apr 2005, Olav Kongas wrote: > > > > > Also, remote wakeups can result in resuming of root hub only > > > if device is not suspended. Was that correct? > > No; remote wakeup wakes up the device that was suspended plus any > parent devices that were suspended. If the device wasn't suspended, > then it can't be woken up...
Dave, you misunderstood Olav's questions. He was using "device" to refer to the PCI or platform HC device, not a USB device. (I had the same misunderstanding the first time I read his email.) > > It depends. If the device supports some form of remote wakeup, then it > > might be possible to wake up both the device and the root hub. However at > > the moment Linux doesn't have good support for remote wakeup when the > > system as a whole isn't asleep. To make matters worse, device wakeup is > > very platform-specific. So for example, with PCI right now you are right. > > Actually that's 180 degrees around from how I'd put it: > > - USB remote wakeup (with CONFIG_USB_SUSPEND) has _only_ really > been tested apart from system sleep states. And for PCI, in > particular, it's been tested with EHCI and OHCI root hubs > (but not host controllers!!) suspended ... since, unlike SOC > systems, PCI uses out-of-band signaling for device wakeup. True, but Olav was asking about what would happen if the host controller was suspended as well as the root hub. > - Wakeup _in general_ doesn't play well with system sleep states, > especially with lots of swsusp-oriented changes tuning things > for power-off states that, often as not, won't leave systems > powered up enough that wakeup can work. True again, but Olav was asking about remote wakeup when the host controller is selectively suspended and the system as a whole is awake. > > Don't forget the world outside of USB! As far as I know there aren't any > > other parts of the kernel where suspending/resuming a device will > > automatically suspend/resume the children/parent. Why should USB be any > > different? > > In the grand-and-glorious future when the device PM core has sane behavior > for those sysfs operations, it won't be. Operative word: "future". Yes. The implementation may well be quite different from the way you're doing it now, however. For example, the core may be able to take responsibility for automatically suspending parents when all of their children are suspended. Or perhaps not -- to do so might require the core to possess too much understanding of individual device states. This is one of those areas where nobody yet has even a clear picture of how it should work... Alan Stern ------------------------------------------------------- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
