Re: prevent swsusp from eating disks

[Benjamin Herrenschmidt]

>> Why aren't those fields initialized explicitly in the static declaration
>> of idedisk_driver? And what are the do_idedisk_suspend/do_idedisk_resume
>> functions, that _are_ initialized explicitly?
>> 
>> I want to understand the madness, not add to it.
>
>The IDE devices are already beginning to use the pci suspend/resume
>callbacks so I would prefer that we have a very clear model of WTF is
>going on here.

The way it should be done is as follow (propagation of suspend/resume):

arch->pci_bus->...->pci_driver->ide_subdriver

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).

The driver (interface driver) is then acting like a bus. So it's
it's responsiblity to forward the request to it's sub-drivers
(typically ide-disk, ide-cd, whatever is attached to that
physical interface). Once the subdrivers are done, the interface
driver can proceed to shutting down the actual HW.

However, that leads to some problems regarding the existing bits
of code I see in there.

One of them is that the do_idedisk_suspend & friends don't take
the proper "level" parameter defined by the device model, which
makes it difficult to implement the various suspend/resume steps
as defined by the new driver model.

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.

I hope I'll finally find enough time to tackle porting of all
of the Pmac stuff to the new model, that will give me a chance
to implement our power management scheme based on the new
semantics and thus validate them (FYI, we've had fairly well
working power management on pmac for a couple of years now,
based on an arch specific mecanism & driver hooks, and I hope
I discussed enough with Patrick & Greg to make sure our experience
in this domain ended up in the design of the new model).

Ben.