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

Linus Torvalds
2006-06-21T00:49:50Z

On Wed, 21 Jun 2006, Benjamin Herrenschmidt wrote:
>
> But they will :) If you look at IDE, actually spinning down the platter
> or not is a very simple decision in the suspend process (which is a
> state machine). About 95% of the code in there is absolutely identical
> between the freeze and the suspend case. It's only a "detail" that when
> doing suspend we actually go hit the disk with a spindown request.

Nope.

You could actually make the disk driver do nothing AT ALL for the freeze
case.

I really don't understand how anybody even half-way sane can say that
"freeze" and "suspend" is 95% the same thing for IDE. There is exactly
_zero_ in common.

If the drive queue is quiescent (which isn't even a driver issue), a IDE
controller won't touch memory _anyway_. So "freeze" for the IDE driver is
100% a total no-op, apart from perhaps disabling interrupts, "just
because".

Unlike network devices and USB, an IDE controller doesn't do anything on
its own anyway.

So where do you find that "95% the same" logic?

Let's recap: for "freeze"/"unfreeze", there is absolutely zero to do. The
disk controller won't be doing any IO on its own anyway.

For "suspend"/"resume", you need to put the controller in a sleep state
(which, in the case of IDE, means turning it off into D3cold - there is
absolutely no reason to even keep it powered), and on resume you need to
do a lot of work to wait for the disks etc to actuall come back and
re-connect to the disks.

Where's the "95% shared?"

I tell you where it is: it's in the current _IDIOTIC_ design, which thinks
that the two are the same issue, when they have absolutely _zero_ in
common.

Linus