Re: device_suspend() levels [was Re: [patch] ACPI work on aic7xxx]

[Nathan Bryant <nbryant@optonline.net>]

Benjamin Herrenschmidt wrote:

> That's different, because the disks are actually registered as
> "struct device" childs of the bus, and thus get proper suspend/resume
> callbacks.

Ok, Seems like we rely on the BIOS a lot, here.

> Oh sure, the disks are in the loop, the problem happens with multipath
> and such which "breaks" the bus hiearchy somewhat. The queue management
> is part of the "functional" hierarchy (read: block layer) on top of
> SCSI disks, thus the disks will be the one getting the suspend callback,
> but they have to "notify" their functional parent (block layer, md, ...)
> to properly get the queues stopped.

All right, I can see where that's probably the easiest solution.

> IDE sort-of does that internally, by generating a special request that
> goes down the queue (in order to be properly ordered with whatever
> is pending in the queue, including pending tagged commands if any),
> and the "toplevel" IDE handling will stop processing the queue once
> that request got past, but it's a hackery that at this point is quite
> specific to drivers/ide/

The queued special command trick does mostly the same thing as the 
scsi_device_quiesce(), right? As far as I can tell, the only difference 
is that we attempt to drain the queue (and sometimes leave error 
handlers running) and they just pause it at some mostly sane stopping point.

Now correct me if I'm wrong, but it seems that with what we understand 
now, we are in a position that we could decide to make SCSI layer do the 
following on suspend, in this order:

scsi_device_quiesce();
{ LLD pause and flush work; aic7xxx will run the completion queue at 
this point }
blk_stop_queue();
{ LLD reset registers and shutdown, etc }

And once the MD problem is solved we will also need to do another call 
before blk_stop_queue().

Am I missing anything?