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

Nathan Bryant
2004-07-25T00:19:05Z

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?