Re: Problems with PM_FREEZE

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

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

Hi,

On Thursday, 29 of September 2005 20:22, David Brownell wrote:
> > > > 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.
> 
> Sorry; changing every driver in the whole tree is in my book
> under "things to avoid unless there's a more significant win".

I think it's avoidable.

Instead of changing every single driver that registers _resume(), we can
introduce another resume template, something like

void resume_from(pm_message_t state)

where we will pass the state which we expect the device to be in before
resume.  Then we can call:
- resume_from() if the driver registers it, or
- resume() if the driver registers it, etc.
(ie. resume() can only be called if resume_from() is not registered).

Just an idea.

Greetings,
Rafael

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]