Re: [PATCH] Hotplug for device power state changes

[Benjamin Herrenschmidt]

> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/