Re: STANDBY IMMEDIATE failed on NVIDIA MCP5x controllers when system suspend

[Aaron Lu <aaron.lu@intel.com>]

Hi James and Alan,

On 03/11/2013 11:00 PM, Alan Stern wrote:
> On Mon, 11 Mar 2013, James Bottomley wrote:
> 
>> Oh, that seems to be the suspend order isn't careful enough.
>> __device_suspend() waits for its children, but the host disk are too far
>> separated in the device tree.  If the immediate children of the host are
>> all sync, that wait never actually waits for anything.
> 
> I was going to make exactly this same point.  During async suspend, the
> PM core is careful to make sure that no device is suspended before its
> children.  But there aren't any other checks, so if device A isn't an
> ancestor of device B then it's possible for async suspend to power down
> A before B.  This can cause problems if B needs A to be active while B
> is suspending.

Thanks for the suggestions.

> 
> Does the ATA system have any non-ancestor dependencies like this?  If 
> it does, the appropriate driver can be fixed to take them into account.

I don't think there is, and the relationship is like this:

    ata_host_controller* (named sata_nv xxx)
	    |
	ata_port* (named atax, while "ata_port atax" is another device)
	/	\
scsi_host	ata_link
    |		   |
scsi_target	ata_device
    |
scsi_device* (named sd x:x:x:x)

With the devices that have actual PM operation functions defined have
the asterisk next to it.

So ata_host_controller waits for all of the ata_ports, and the ata_port
waits for both scsi_host and ata_link. scsi_host waits for scsi_target,
and scsi_target waits for scsi_device. So if scsi_device is not done,
ata_port will not start. Doesn't look like a problem to me.

And from the log:
https://bugzilla.kernel.org/attachment.cgi?id=95101
It also looks like the order is correct.

Thanks,
Aaron