linux-kernel - Re: [linux-pm] Re: [PATCH 2/2] Introduce CONFIG

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]

Date:	Tue, 31 Jul 2007 12:01:07 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Oliver Neukum <oliver@...kum.org>
Cc:	linux-pm@...ts.linux-foundation.org, Len Brown <lenb@...nel.org>,
	david@...g.hm, Nigel Cunningham <nigel@...el.suspend2.net>,
	linux-kernel@...r.kernel.org, Adrian Bunk <bunk@...sta.de>,
	linux-acpi@...r.kernel.org,
	Stefan Richter <stefanr@...6.in-berlin.de>,
	Pavel Machek <pavel@....cz>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [linux-pm] Re: [PATCH 2/2] Introduce CONFIG_SUSPEND (updated)

On Tuesday, 31 July 2007 11:16, Oliver Neukum wrote:
> Am Dienstag 31 Juli 2007 schrieb Rafael J. Wysocki:
> 
> > Well, the people on linux-pm seem to agree that the .suspend() and .resume()
> > callbacks are not suitable for runtime power management, so having them
> > built without SUSPEND or HIBERNATION wouldn't be very useful. ;-)
> 
> These are what USB runtime power management uses.

To be precise, I think the rule should be that if some code is needed for
anything else than suspend/hibernation, it should be under plain CONFIG_PM.
Still, if something is only needed for suspend/hibernation, it should go under
CONFIG_PM_SLEEP or CONFIG_SUSPEND/HIBERNATION, depending on what it's needed
for.

Now, AFAICS, for the majority of drivers .suspend() and .resume() are only
needed for suspend/hibernation and really should be used for suspending
only (some other callbacks are needed for hibernation).

> How many code paths for power management do you want to introduce?

At least one more, for hibernation.

That also depends on what approach to the runtime power management is widely
accepted.  For now, USB is in the vanguard. :-)

Greetings,
Rafael

-- 
"Premature optimization is the root of all evil." - Donald Knuth
-
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/