[linux-pm] Problems with PM_FREEZE

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

 



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

[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