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

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Friday 26 May 2006 05:06, David Brownell wrote:
> On Tuesday 02 May 2006 9:12 am, Patrick Mochel wrote:
> > On Thu, Apr 27, 2006 at 12:41:28PM -0700, David Brownell wrote:
> > 
> > > There does seem to be agreement that the current FREEZE invocation is not
> > > sufficient.  I'm looking at a slightly different solution now ... one which
> > > unfortunately involves changing drivers, but can indeed allow swsusp resume
> > > paths to do the right thing (instead of what it does now).
> > 
> > It's Ok if it involves a drive change, so long as its an optional change, which
> > means that it shouldn't affect the interface very much (i.e. the calling 
> > convention). That's why it'd be good to augment and/or modify pm_message_t
> > to implement the changes, so we wouldn't have to change every single driver
> > again.. 
> 
> I'll post more patches after I sort out some oddness -- why is swsusp_suspend()
> leaving preempt_count() == 1, code I was nowhere near? -- but 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.

Frankly I thought you'd add a new member to pm_message_t, to be ignored by the
drivers that didn't care.

That said I also see the point in what you're doing. :-)

Greetings,
Rafael