linux-kernel - Re: NAK new drivers without proper power management?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200702132024.20053.rjw@sisk.pl>
Date:	Tue, 13 Feb 2007 20:24:18 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Tilman Schmidt <tilman@...p.cc>
Cc:	Pavel Machek <pavel@....cz>,
	Nigel Cunningham <nigel@...el.suspend2.net>,
	Manu Abraham <abraham.manu@...il.com>,
	Willy Tarreau <w@....eu>,
	Arjan van de Ven <arjan@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Robert Hancock <hancockr@...w.ca>
Subject: Re: NAK new drivers without proper power management?

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/