Hi!
> > Pavel is obviously right that the clean solution is to add a pm_message_t
> > argument to resume().
>
> I tend to disagree with that. Changing every resume() method is
> not "clean", and it's more obvious to me that the pm_message
> semantics are (still) problematic. Any argument to resume() would
> be encouraging fragile "if (came_from(X)) { ... }" style logic.
Alan wants to cut few miliseconds from suspend-to-disk. That's okay
with me, just add pm_message_t to resume(). If it is okay to use it in
specific driver is other question.
> Heck, there's still no way for drivers to know what the target
> system state is ... and THAT is a core issue here.
>
> During FREEZE, the target system state is "something snapshottable".
> During SUSPEND, it's one of numerous variants of "low power" ... and
> device drivers can only guess which one it'll be. (Is it an ACPI
> state? S1, S3, S4? Some non-ACPI platform state?)
Why does your driver need to know? Anyway, extending pm_message_t with
flags is okay with me.
> Case in point: in some system low power states, drivers need to turn
> off certain clocks, and may not be able to support wakeup. In others,
> drivers leave those clocks on, and can support wakeup. But there is
> no way to figure out the target state given the pm_message ...
Eh? I do not see how knowing S1 vs. S3 vs. S4 help you here. It looks
more like "does user want to resume from that?" question.
Pavel
--
if you have sharp zaurus hardware you don't need... you know my address
