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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi!

> > > 		 the patch appended
> > > here shows what I'm pursuing.  Same calling convention, new PRETHAW message
> > > that "pm-naive" drivers (most of them!) can handle just like FREEZE.
> > > 
> > > Other than this, it affects about 20 files with about 2/3 being drivers; say
> > > that maybe 5% of all in-tree drivers needed trivial changes, most of which
> > > could count as bugfixes _before_ defining the new message.
> > 
> > Okay, so you changed the interface, and it needed fixing at 16 places.
> 
> Not what I said ... in many of those places, the driver code was already dubious.
> Making the event code __bitwise would have helped catch those errors.

Yep, __bitwise (+ someone using sparse :-) would be nice.

> > > + * PRETHAW	Quiesce as if for FREEZE; additionally, prepare for restoring
> > > + * 		the system from a snapshot taken after an earlier FREEZE.
> > > + * 		Some drivers will need to reset their hardware state instead
> > > + * 		of preserving it, to ensure that it's never mistaken for the
> > > + * 		state which that earlier snapshot had set up.
> > 
> > And you *do* realize that PRETHAW is like a FREEZE... So... can we use
> > FREEZE, and add aditional flag field that says it is preTHAW?
> 
> Of course, FREEZE is like a SUSPEND, and SUSPEND is the only behavior that's
> required of all drivers, or which most drivers understand.  So why did you not
> implement FREEZE as a flag in the first place, if you like that model?  :)
> 
> Most drivers treat all suspend() messages as SUSPEND anyway; mesg.event was
> already little more than a fancy flag (SUSPEND vs FREEZE).  We only need
> three transition types (so far), not four (flag x flag ==> 4 states).

Okay, I still don't 100% like it, but it makes some sense and I think
we can live with PREFREEZE.

> > This will result in if (message == FREEZE || message == PRETHAW) that
> > is kind-of ugly.
> 
> switch (mesg.event) { ... } for the few drivers that actually care about
> more than one of the transitions.  Only a handful need to care about more
> than whether it's a real SUSPEND or not.

Okay, you are right that suspend and freeze are similar, too. Can you
retransmit the patch?
							Pavel
-- 
Thanks for all the (sleeping) penguins.


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux