Re: swsusp: don't eat ide disks

[Benjamin Herrenschmidt]

>Anyway, this is why I'd much rather have higher layers use a standardized
>queue packet (a SCSI command) to inform lower-level drivers about special
>events, rather than have the lower levels decide on their own command set
>and have specialized ways to try to tell them to use that specialized
>command some other way (a bdev "ops" structure would probably be the way
>we'd go).
>
>So assuming that drivers will accepts commands down the request queue 
>anyway (because it's the only sane way to push them down and get any kind 
>of reasonable ordering), then that would make it a waste of time and extra 
>complexity to _also_ have another interface to push special commands. 
>Especially as that other interface would end up being almost certainly 
>broken wrt synchronization (proof: look at the current mess).

Ok, I see your point. However, even if having a common mecanism to
push down a "generic" (ie SCSI packet) "suspend" command down the
queue, the problem of doing proper suspend/resume has other issues
to deal with, and it's basically not a higher level layer thing.

One is ordering (regarding the controller's own power management
facilities if any, I do power down the controller itself on pmacs
for example, or regarding other PM issues on the bus path down to
that controller). A given IDE disk/cd/tape (same with SCSI or
anything else) must be suspended/resumed at the proper moment,
that is exactly just before it's parent, as a result of the
suspend request getting down the device tree.

Another is proper save/restore. We aren't just sending a "please
stop that disk spinning" command, like one would do for automatic
power management of inactive disks or whatever. Indeed, a common
packet command would be very well suited for that. But in our case,
we are dealing with suspend-to-disk/ram, which usually involves
a bit more than that. We want to block the queue atomically with
reception of this suspend command for example until machine is
resumed. We need to send commands to restore the device state
(ATA/ATAPI reset, LBA setting, timings, ...) on resume before
we actually accept new commands from the queue (pushing them
at head of queue before de-blocking it ?)

All of the above is quite device specific. You won't need the
same commands & state restore stuffs for a disk, cd, tape, ...
So it's really the driver for that specific device that is
the only one to know what has to be done for this specific
device. 

I'm not quite yet sure what is the best way to deal with all
that yet for IDE, what I did for pmac so far was a lot simpler
but not definitely generic enough (basically blocking the
hwgroup state to "busy" and hand-blasting ATA regs to send
STANDBY command).

Ben.