Messages in this thread | | | From | "Rafael J. Wysocki" <> | Subject | Re: NAK new drivers without proper power management? | Date | Tue, 13 Feb 2007 20:24:18 +0100 |
| |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |