Re: swsusp: don't eat ide disks

>> Here's patch to prevent random scribling over disks during
>> suspend... In the meantime alan killed (unreferenced at that time)
>> idedisk_suspend() and idedisk_release(), so I have to reintroduce
>> them.
>
>Please fix this at a different level. idedisk is not the place to be
>doing this. If the device layer is doing the right thing then the
>request queue will be idle. 

Hrm... I don't think so Alan. The PM ordering is bus driven,
so actual bus binding of the disk is it's controller, not
the request queue which is the functional binding. It's up to
the disk driver to shut down processing of the request queue.

On the same idea, it's not the network layer that will stop
sending packets to an eth driver, it's the eth driver that
gets suspended by it's bus binding (PCI for example) that
will eventually request the network layer not to send it
any more packets (netif_stop_queue() typically).

So in our case, what we want is the pci controller driver
getting the suspend request (and non-PCI IDE controller will
have to write their own bus binding according to the new model).

It will then tell it's own subdevices (disks in this case) to
suspend (hrm... I don't have the source at hand, I'm away for
a few days right now, does disks have struct device attached
as childs of the ATA controller ? they should...). At that
point, it's up to the _disk_ suspend() function to actually
request the block layer to stop queue processing, typically
this can be done by just not eating requests from the queue,
or better, by (un)plugging the queue on suspend/resume.

Now, there is indeed as subtle race if the disk driver wants
to queue itself a request to actually send the suspend command
to the disk. This request has to be the _last_ of the queue.
That is, the queue must be stopped right after processing this
request with no room for a new request to be taken in between.

The way I see it is that the queue should be stopped not by
the suspend function itself, but by the request processing
function when fetching that STANDBY request from the queue.
We need special care not to mixup with hdparm originated
STANDBY though (but do those go through the queue ? I'm not
sure how far the cleanup went here....)

Ben.