RE: suspend/resume support for driver requires an external firmware

[Li, Shaohua]

>> We talked about this in Ottawa a few months ago, and I think this is
the
>> right approach. Note though, that I think it needs to be more
complete:
>>
>> - There needs to be restore_state() to be symmetic.
>> - There needs to be the proper failure recovery
>>   If save_state() or suspend() fails, every device that has had their
>>   state saved needs to be restored.
>> - It needs to be called for all power management requests.
>> - The PCI implementation should call pci_save_state() in it, instead
of
>in
>>   ->suspend().
>>
>> It would be great if you could add these things. Otherwise, I'll add
it
>to
>> my TODO list..
>
>Additionally, for devices like the above that need either to rely on
>userland for firmware download or to allocate large amounts of memory
>for firmware backup/restore, I think we need to revive the pre-suspend
>and post-resume notifiers ... Of course, if a device that needs
userland
>to reload a firmware is on the swap patch, then we have a chicken & egg
>problem, but there is no easy solution for that one, unless the driver
>uses the pre-suspend callback to pre-load the firmware that it will
need
>for resume
I somewhat think choice 2 is better. The pre-load can be invoked in any
order instead of in the device tree hierarchy order. And currently only
few devices need it, is it worth adding it in the device core?
In addition, the notifiers have better flexibility. We can easily add
more notifier types if needed, such as adding a callback between the
sysdev resume and regular devices resume. To tell the truth, we actually
have the case. An ACPI link device must resume before regular devices
but must be with IRQ enabled. I'm considering add a call back between
sysdev and regular devices resume for the issue. I guess the MTRR driver
in SMP has the same requirement. Anyway, notifier solution sounds like
easier to extend, but we can't extend device core casually.

Thanks,
Shaohua
-
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/