On Wed, 2002-10-30 at 15:48, Benjamin Herrenschmidt wrote:
> The way it should be done is as follow (propagation of suspend/resume):
>
> arch->pci_bus->...->pci_driver->ide_subdriver
----> disk
> The details as I see them (and that would match my needs on ppc) are
> that the suspend request originates from the bus binding of the
> controller, as any other device. (non PCI hosts will need specific
> arch tweaks here or whatever parent bus they have in the news model
> will deal with sending them the suspend call).
We have the hwif structures (ugly I know) which know what the interface
is nailed to and what is nailed to each device so it isnt that bad.
There are the odd complications of course - chips that appear as two PCI
devices and either one of them turns off both for example 8)
> Another is that I feel (and I know Pavel doesn't agree here) that
> the disk driver should also block further incoming requests (that
> is leave them in the queue) instead of panic'ing. That is the
> driver should not rely on not beeing fed any more request, but
> rather make sure it will leave them in the queue and deal with
> them when resumed.
It is cleaner if the ordering of power off is right. If the model is
right then the first suspend would be the drives. Part of drive suspend
ought to be corking the queue.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Oct 31 2002 - 22:00:48 EST