Messages in this thread | | | Subject | Re: [PATCH] Hotplug for device power state changes | From | Benjamin Herrenschmidt <> | Date | Fri, 30 Apr 2004 10:50:26 +1000 |
| |
> I figured system suspend/resume would need to be a separate event and > isn't covered by this patch, which is for "runtime" individual device > suspend/resume only. Also, the flood of notifications of all devices > suspending/resuming might not be useful -- the single system > suspend/resume event could imply these device events, although perhaps > in some cases something would want to know exactly which devices were > operable at system suspend time. I can also send a patch for system > suspend/resume hotplug if there's interest. > > Now that you mention it, device power hotplug should be synchronous, to > make sure the power management application has reacted to the changed > state prior to the device going into actual service (in the case of a > resume).
This is dangerous.
If the device you are suspending is on the VM path in any way, beeing synchronous with a userland call can deadlock you solid.
This is even more true for system suspend where we are suspending all devices including the main swap/storage.
There are various cases where I would have loved to get userland more involved in the suspend/resume process for various reasons, but in the end, I always got bitten by that problem. Userland cannot be relied upon unless the process is made completely resident as soon as we start the suspend dance.
More to this: If you use the "common" code in kernel/power, which I don't (yet) use on pmac for suspend-to-ram, you'll also stop all userland processes before notifying drivers (and suspend-to-disk expects that).
Ben.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |