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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
