Note that one thing in suspending the machine that has _nothing_ to do
with the actual device tree is that higher layers have to suspend whatever
it is they are doing anyway.
Ie part of the suspend action (which is unrelated to the driver model) is
to stop all regularly scheduled activity - not necessarily flushing all
dirty buffers, but certainly waiting for all pending IO. That's a much
higher level thing that the device though - the devices themselves should
never ever see this (except in the sense that they don't see new requests
coming in).
There are other "higher-level" issues: while a device "prepare to suspend"
call might block for some device information, that does not mean that it
can allocate memory with GFP_KERNEL, for example: when we shut off device
X, the disk may have been prepared for shutdown already, and the VM layer
cannot do any IO. So the suspend (and resume) function have to use
GFP_NOIO for their allocations - _regardless_ of any other device issues.
So sure, there are tons of issues here, but none of them have, in my
opinion, anything to do with the device model itself. More just normal
implementation details.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/