G'Morning, On Sunday 26 September 2004 2:15 am, Pavel Machek wrote: > > > > I don't know > > > > how closely people want to tie remote wakeup enable/disable with power > > > > states, although they are related concepts. > > > > > > They're coupled in that wakeup makes no sense without some kind of > > > suspend ... and a usable "selective suspend" has to account for devices > > > waking up out of low-power states (just like "system suspend", except > > > of course only waking up part of the system). > > > > Exactly. Furthermore, the suspend call is a logical place to specify > > whether wakeup should be enabled. Also note that once a device is > > suspended, it may not be possible to change whether wakeup is enabled or > > disabled without first resuming the device.
With PCI, you can enable wake using just config space access, so it can be done with a device in D3hot; with USB, you can't enable wake without the link being out of "suspend". Good point. > Specifying wakeup_enabled at suspend() time will mean one more > parameter to suspend() :-(. We already have enable_wake() function, I > do not think we want to change API. I thought it was already well acknowledged that the pmcore functions are functionally incomplete. This is certainly an area that's missing key features ... how to enable it (PCI has enable_wake, USB enables it for busses where the root hub can signal remote wakeup) and tools to apply, test, and manage such policies, etc. There should be lots of buttons usable to wake a system from sleep! > > > Yes, agreed. Feel free to submit a patch ;-). > > > > I would prefer to wait until there is some consensus on how selective > > suspend works as well as system-wide suspend. After all, the two ought to > > share a lot of code... > > Umm.. See past flamewars on linux-kernel. We can spend a lot of > electrons talking how it should work, but without code, it is mostly > empty words. Yeah -- but without enough words to establish at least some shared concepts, patches can be just as much wasted effort! That is, if six problems need to be solved, a patch that solves three but prevents the other three from ever being solved is not helpful. Is there a list focussed on PM issues, where such design goals could get agreed on as part of a design process that includes patches? A list not focussed exclusively on system suspend, and significantly smaller than LKML ... :) - Dave ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
