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

Nathan Bryant
2004-07-24T16:44:34Z

Benjamin Herrenschmidt wrote:
> sysfs only takes care about the bus hierarchy as far as suspend/resume
> is concerned (which is the only sane way to do it imho)

I saw comments in one of the PCI IDE driver pcidev->suspend routines
that say "we don't need to iterate over the list of drives, sysfs does
that for us."

> No, the ordering cannot be dictated by the upper layer, but by the
> physical bus hierarchy. The low level driver gets the suspend callback
> and need to notify the parent. The md/multipath must keep track that one
> of the device it relies on is going away and thus block the queues.
>
> That is at least for machine suspend/resume.

We're talking past each other. I'm saying you take into consideration
the physical bus hierarchy: PCI bus x is a parent of SCSI bus y which is
a parent of SCSI disk drive z. Suspend disk z, with involvement from the
block layer and scsi midlayer, before even calling the actual
pcidev->suspend routine on the SCSI bus adapter. Shouldn't require more
than minimal LLD involvement.

>>Looking in /sys/devices shows that sysfs already knows that 'host0' is a
>>child of a SCSI PCI device.
>
>
> Yes, but the PM herarchy is the bus hierarchy, I don't see a simple way
> of going through both in this case ...

In the case of IDE, IDE is registered as a bus_type and has generic
suspend code for the whole bus that is unrelated to the pcidev. The PIIX
IDE (Intel chipsets) PCI pcidev struct doesn't even have suspend and
resume callbacks filled in, but it works fine!