Re: [linux-pm] [patch/rft 2.6.17-rc2] swsusp resume must not device_suspend()

[Nigel Cunningham <ncunningham@cyclades.com>]

[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]

Hi.

On Friday 28 April 2006 05:21, David Brownell wrote:
> On Thursday 27 April 2006 9:55 am, Patrick Mochel wrote:
> > On Thu, Apr 27, 2006 at 10:34:16AM -0400, Alan Stern wrote:
> > > 		During swsusp the system is
> > > supposed to be completely off, with no suspend power available.  Hence
> > > all the power sessions are guaranteed to be interrupted, and the boot
> > > kernel doesn't have to worry about destroying any of them.
> >
> > Not necessarily. x86 hardware implementations of suspend-to-disk retain
> > some power during suspend. Not many (if any) devices will retain context,
> > but the system is definitely not completely "off".
>
> As a rule swsusp (or firmware suspend-to-disk) power off everything except
> what's needed to power up the motherboard ... or to provide "5 AM wakeup"
> type events using a battery-backed realtime clock.  Maintaining VBUS power
> sessions from USB host controllers is one of those "theoretically allowed,
> but never observed in the wild" cases.
>
> Right, not "completely" off ... but certainly nowhere as close to "on" as
> would be true of suspend-to-RAM.  And regardless, the problem in $SUBJECT
> is when Linux trashes the state which the limited "on" is there to
> maintain.

This isn't necessarily true either. Suspend2 has supported writing the image, 
then suspending to ram for a year or two. uswsusp has just gained the same 
functionality. In this state, if you don't pull the plug/drain the battery, 
you never actually power down. Having said that, this might be a different 
kettle of fish though, because there's no boot kernel in that case. For 
Suspend2 (and uswsusp, I assume), it's more akin to backing out of the cycle 
at the last possible moment before powering down.

Regards,

Nigel

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]