linux-kernel - Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

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:	Fri, 14 May 2010 15:59:16 -0700
From:	Brian Swetland <swetland@...gle.com>
To:	Kevin Hilman <khilman@...prootsystems.com>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Tony Lindgren <tony@...mide.com>,
	Matthew Garrett <mjg@...hat.com>,
	Alan Stern <stern@...land.harvard.edu>,
	Paul Walmsley <paul@...an.com>,
	Arve Hjønnevåg <arve@...roid.com>,
	Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	Tejun Heo <tj@...nel.org>, Oleg Nesterov <oleg@...hat.com>,
	magnus.damm@...il.com, "Theodore Ts'o" <tytso@....edu>,
	mark gross <mgross@...ux.intel.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Geoff Smith <geoffx.smith@...el.com>,
	Benoît Cousson <b-cousson@...com>,
	linux-omap@...r.kernel.org, Vitaly Wool <vitalywool@...il.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Liam Girdwood <lrg@...mlogic.co.uk>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

On Fri, May 14, 2010 at 3:45 PM, Kevin Hilman
<khilman@...prootsystems.com> wrote:
>>> Personally, I suspect that lack of this feature is not the real
>>> obstacle to getting these out-of-tree drivers upstream.  Having this
>>> API upstream will not change the product schedules and corporate
>>> cultures that have prevented code from making its way upstream.
>>
>> But apparently it is considered as a suitable excuse.
>
> No, it is not a _technical_ excuse.  Just a healthy, experience-based
> dose of skepticism.
>
> It was expressed because I find the arguments above for merging
> because it prevents out-of-tree drivers from merging quite
> unconvincing.  This is not just about opportunistic suspend + suspend
> blockers specifically but comes from several years experience in the
> embedded Linux world.

It provides useful functionality -- you apparently disagree, but the
wakelock/suspendblock model is in use, shipping, and solving problems
for quite a lot of android devices that have been shipping for a while
now.  We actively go to lowest power state in idle (on omap, msm,
etc), and use drivers that aggressively declock and depower modules
(similar to runtime pm), but we have found that using the
opportunistic suspend model combined with wakelocks allows us to
attain even lower average power consumption in always-connected,
actively-syncing devices.

It has been claimed that because Android userspace makes use of this
functionality a number of silicon vendors who want to submit code
upstream are inconvenienced by having to maintain "android" and
"mainline" versions of their drivers.  I can't speak for them, since
nobody has identified the particular inconvenienced vendors to me, nor
have they spoken with me directly, but personally I do find that
having to maintain two different versions of drivers (one version for
upstream, one for shipping products) is inconvenient.

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/