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

[Nathan Bryant <nbryant@optonline.net>]

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!