Re: Fix up power managment in 2.6

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Wed, 2003-09-03 at 15:02, Alan Cox wrote:
> On Maw, 2003-09-02 at 11:21, Benjamin Herrenschmidt wrote:
> > The whole point was to get rid of the old 2 step save_state, then
> > suspend model which didn't make sense. A saved state is only meaningful
> > as long as that state doesn't get modified afterward, so saving state
> > and suspending are an atomic operation.
> 
> Very old myth. In fact just about every scheduler on the planet exploits
> the fact this is untrue.
> 
> 		save state
> 		continue running doing scheduler stuff
> 		restore other state losing the state in the middle we dont need
> 
> Ditto with a lot of I/O devices. My audio save state and suspend can be
> seperated - I might play a little bit of a song twice but is that a bug

It is in lots of case with IO. Especially if your state don't match
between different devices that rely on each other (parent/child
typically), or if some of that state information matches something
persistent on the HW (devices don't necessarily get fully powered
off during suspend).

Note that in most case, there isn't really a notion of "state" to
store or save anyway, that is "state" is just whatever is in your
net_device structure for a network driver, or whatever private
structure in your whatever-other driver, so you just have to restore
a couple of things on wakeup, but really nothing to save on suspend.

The single callback is much simpler, and will avoid lots of mistakes
imho.

Ben.