Cc: huang ying <huang.ying.caritas@...>, <linux-pm@...>, Eric W. Biederman <ebiederm@...>, Nigel Cunningham <nigel@...>, <nigel@...>, Kexec Mailing List <kexec@...>, <linux-kernel@...>, Huang, Ying <ying.huang@...>, Andrew Morton <akpm@...>, Len Brown <lenb@...>
Suppose that instead of using ACPI S4 state at all, you instead just
power off. Yes, you'll lose wakeup event functionality, and flashy
LEDs, but doesn't this take care of the problem? The firmware shouldn't
see the hibernate as anything other than a shutdown and reboot. ACPI
should be initialized normally when resuming, which should take care of
getting AC power status reported properly.
This should be the behavior, anyway, on the many systems that do not
support S4.
It seems that if ACPI S4 is going to be used, Switching to low power
state is something that should be done only immediately before entering
that state (i.e. after the image has already been saved). In
particular, it should not be done just before the atomic copy. It is
true that (during resume) after the atomic copy snapshot is restored,
drivers will need to be prepared (i.e. have saved whatever information
is necessary) to _resume_ devices from the low power state, but that
does not mean they have to actually be put into that low power state
before the copy is made.
I agree that for the kexec implementation there may be additional
issues. For swsusp, uswsusp, and tuxonice, though, I don't see why
there should be a problem. I think that, as was recognized before, all
of the issues are resolved by properly considering exactly what each
callback should do and when it should be called. The problems stem from
ambiguous specifications, or trying to use the same callback for two
different purposes or in two different cases.
Let me know if I'm mistaken.
--
Jeremy Maitin-Shepard
-
