linux-kernel - Re: [linux-pm] suspend blockers & Android integration

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:	Sun, 6 Jun 2010 11:44:16 -0700
From:	Brian Swetland <swetland@...gle.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	James Bottomley <James.Bottomley@...e.de>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Florian Mickler <florian@...kler.org>,
	Vitaly Wool <vitalywool@...il.com>,
	Arve Hjønnevåg <arve@...roid.com>,
	Arjan van de Ven <arjan@...radead.org>, tytso@....edu,
	Peter Zijlstra <peterz@...radead.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	LKML <linux-kernel@...r.kernel.org>, Neil Brown <neilb@...e.de>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Felipe Balbi <felipe.balbi@...ia.com>
Subject: Re: [linux-pm] suspend blockers & Android integration

On Sun, Jun 6, 2010 at 11:04 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
>>
>> Right, so the sooner we make it easier for the drivers to use the kernel
>> as their main repository, the better.
>
> Yep, the fastest way is to provide two stub inlines in pm.h and let
> the driver flood come in.

As mentioned previously, we didn't know this was an option (stubs
without an implementation behind them).  If it is, and thus we can
simplify the driver merging process short-term while sorting out a
long-term implementation or replacement for suspend blockers, then I
think we're making real progress.

There is no reason that drivers that support suspend blockers cannot
(or should not) support regular suspend/resume or runtime
suspend/resume, so that shouldn't be a worry.  The various operating
modes complement, not compete with each other (we want the lowest
possible power consumption in all states, be that fully active, fully
suspended, or anything in between -- I think everyone involved agrees
with this).

> I think all of us involved in that can do with a break, where we sit
> back, calm down and rethink w/o time pressure.

Total agreement.

Brian
--
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/