Re: [PATCH 2/2] Fix console handling during suspend/resume

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

> Here's a _fact_:
> 
>  - we currently walk the device chain to suspend different devices
>  - one device returns an error
>  - we've now suspended half the machine, done major things, and we need to 
>    undo it
>  - the thing fails.
> 
> Are you seriously claiming this has never happened to you? It sure has 
> happened to me.

It happens occasionally (latest was a USB controller going dead
occasionally on a box and usb suspend() method for it failing when that
happens).

When we fail, we resume() things that were suspended(), at least we used
to, and that works. That is suspending fails but at least the machine
comes back into operational state and you can look at dmesg, console,
whatever. I haven't had the case where _that_ failed.

> And YES, THIS WOULD BE IMPROVED BY MY SCHEME. Instead of getting a machine 
> that has suspended partly, and may be effectively dead and unable to even 
> tell the user that it failed half-way through, it would not have suspended 
> anything at all, and just say "Sorry, I can't do that".

That would have been fixed by a prepare() callback too as I'm advocating
it. This has nothing to do with saving state.

> Adn yes, this is a _direct_ result of THE BROKEN CONVENTION OF DOING 
> EVERYTHING IN SUSPEND()!
>
> But yeah, you go on and ignore it. Because the current scheme is obviously 
> all right.

The current scheme is not perfect, and I've proposed at least one
mecanism to improve it. My argument is that it has nothing about saving
state and changing the state save vs. suspend semantics. Changing _that_
won't help.

Ben.