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

[Benjamin Herrenschmidt]

On Sat, 2004-07-24 at 11:31, Nathan Bryant wrote:
> Benjamin Herrenschmidt wrote:
> 
> >save_state is a nonsense, didn't we kill it ? 

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)

> queue quiescing must be
> >done by the upper level, which is a bit nasty with things like md &
> >multipath... basically, the low level driver must have a way to notify
> >it's functional parent (as opposed to it's bus parent) that it's going
> >to sleep, and any path using this low level driver must then be
> >quiesced, the parent must resume only when all the drivers it relies
> >on are back up.
> >
> Isn't sysfs supposed to take care of this for us? IOW, I shouldn't have 
> to call up to the SCSI midlayer from pcidev->suspend in order to notify 
> it of a suspend, the midlayer should call the driver before we ever try 
> to suspend. This may become important some day when the upper layers 
> need to decide which order to bring pci devices down

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.

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

> $ ls 
> /sys/devices/pci0000\:00/0000\:00\:1e.0/0000\:02\:02.0/host0/0\:0\:0\:0/
> block   detach_state    model  queue_depth  rev         state    type
> delete  device_blocked  power  rescan       scsi_level  timeout  vendor
-- 
Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/