On Thursday, 5 July 2007 17:01, Alan Stern wrote: > On Thu, 5 Jul 2007, Zhang Rui wrote: > > > IMO, device runtime wakeup and wakeup from a system sleep state are > > different. > > I sort of agree with you. (Except that on smaller or embedded systems, > there isn't always such a clear distinction between runtime suspend and > system suspend. One sort of blends into the other as more and more > components are powered down. But let's ignore that.) > > > If we want to make use of the wakeup setting in sysfs, we can't simply > > enable/disable /sys/.../power/wakeup. > > > > Some different values like "device_runtime" and "system_sleep" are > > needed to indicate the different remote wakeup state. > > Take ACPI platform for example: > > "disable": disable remote wakeup. > > "device_runtime": device runtime wakeup is enabled, while device > > can not wakeup the system from a sleep state. > > For ACPI platforms, that's disable the wakeup > > GPE of the device. > > "system_sleep": the ability of wakeup system from a sleep state > > is enabled. It needs to enable the device > > runtime wakeup ability first. and enable wakeup > > GPE as well for ACPI platforms. > > Allow me to rephrase. You seem to be saying that /sys/.../power/wakeup > should be able to hold four different values: > > 1. always disabled > 2. always enabled > 3. enabled at runtime but not during system sleep > 4. enabled during system sleep but not at runtime > > Right? With the default being 3 (except for a few things like the > power button). > > Or maybe there should be two attribute files: wakeup (used during > system sleep) and wakeup_runtime (used for runtime suspend). I like the last idea. I think that, at least for now, we shouldn't mix the runtime power management with entering the system sleep states. Of course on the low level it may be possible to use the same code for suspending the device regardless of the purpose, but on the high level mixing the two things often leads to confusion. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
