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
