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

Linus Torvalds
2006-06-15T18:31:09Z

On Thu, 15 Jun 2006, Pavel Machek wrote:
>
> Okay, you _can_ do
>
> suspend whole tree but disk and video
> freeze disk and video
> create snapshot
> unfreeze disk and video

I really think that's totalyl unnecessary.

At most, you could make the "save_state()" also say "stop listening to
external stuff" for devices that otherwise do things on their own. That's
not a "freeze" - the device would still obey commands coming from the
host - and it would need a "unsave" logic when a suspend fails, but it
doesn't change the fundamental "save means _save_, not suspend" logic.

And we currently don't have _anything_ like that. Playing games with
sending different commands down the "suspend()" thing is not ever going to
work. Drivers are going to do it wrong. We really need to add a
"save_state()" callback, and it needs to be called that, so that people
realize that they should not suspend in it.

It would actually simplify and clarify a lot of the confusion we have now.

I already fixed one driver (sky2) that simply didn't save it's PCI state,
it just suspended (and then in resume it tried to "restore" the state
that had never been saved). And I _bet_ that was because it's just a very
natural thing to do when you look at "suspend()" as an independent op.

So it's actually important - _especially_ for device drivers - to have
logical and _distinct_ operations, because device driver writers seldom
see the big picture. But if you tell a device driver writer that he needs
to save the state, he'll understand that. He might even understand the
notion of shutting down the receive side for devices that need it. But if
you tell a device driver writer that they need to write a "suspend"
function, that's exactly what he will do.

Linus