Re: NAK new drivers without proper power management?

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

On Tuesday, 13 February 2007 10:42, Tilman Schmidt wrote:
> Rafael J. Wysocki schrieb:
> > I think we can introduce a "pm_safe" flag that will indicate if the driver
> > handles suspend/resume correctly.  If we do it, we can flag all of the drivers
> > currently in the tree as "pm_safe" unless we know that they aren't.  Next,
> > we can convert the core to fail the suspend for any driver that is not flagged
> > as "pm_safe".  But I think that will take time.
> 
> Why a new flag?

For example, there are drivers that define .suspend() and .resume() which
do not work correctly and we can use the flag to mark them.

> IMHO it would be both more readable and more efficient 
> to create a pm_generic_nosuspend() function which does "return -ENOSYS",
> and set that as the .suspend method on drivers known to break
> suspend/resume. New drivers should either have .suspend and .resume
> methods of their own or set .suspend = pm_generic_nosuspend.

This is quite similar to what we are trying to do now: ask driver authors to
define .suspend that will return -ENOSYS if they can't ensure that the driver
will handle the suspend and resume correctly.

> That way, NULL .suspend/.resume methods retain their current semantics
> ("don't know whether suspend would work, never thought about it"),

I think this convention is unfortunate.  The default should be to fail the
suspend if there's no .suspend defined, IMO.  Still, it's hard to change now.

> error-returning ones would clearly signal "cannot suspend safely", and
> success-returning ones would equally clearly signal "suspend works ok".
> (Bugs nonwithstanding.)
> 
> There could then be a policy parameter (Kconfig selectable to start)
> to abort suspend when encountering a driver without .suspend/.resume
> methods, or to proceed with a warning message.

I think there are many drivers without .suspend and .resume already in the
tree, so that wouldn't be practical.

Greetings,
Rafael