From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Brown Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6) Date: Thu, 13 May 2010 23:27:49 +0100 Message-ID: <20100513222748.GA3240@opensource.wolfsonmicro.com> References: <1272667021-21312-1-git-send-email-arve@android.com> <201005132311.26293.rjw@sisk.pl> <1273785399.19100.98.camel@c-dwalke-linux.qualcomm.com> <201005132327.16163.rjw@sisk.pl> <1273786409.19100.104.camel@c-dwalke-linux.qualcomm.com> <20100513214653.GA21120@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from opensource.wolfsonmicro.com ([80.75.67.52]:38016 "EHLO opensource2.wolfsonmicro.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753228Ab0EMW1w (ORCPT ); Thu, 13 May 2010 18:27:52 -0400 Content-Disposition: inline In-Reply-To: <20100513214653.GA21120@suse.de> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Greg KH Cc: Daniel Walker , "Rafael J. Wysocki" , Matthew Garrett , Brian Swetland , Paul Walmsley , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , linux-pm@lists.linux-foundation.org, linux-kernel@vger.kernel.org, Tejun Heo , Oleg Nesterov , Tony Lindgren , Kevin Hilman , Alan Stern , magnus.damm@gmail.com, Theodore Ts'o , mark gross , Arjan van de Ven , Geoff Smith , =?iso-8859-1?Q?Beno=EEt?= Cousson , linux-omap@vger.kernel.org, Vitaly Wool , Liam Girdwood On Thu, May 13, 2010 at 02:46:53PM -0700, Greg KH wrote: > On Thu, May 13, 2010 at 02:33:29PM -0700, Daniel Walker wrote: > > You get the driver mainlined, then maintain a small patch to add > > wakelocks. Not hard at all , with lots of incentive to do so since you > > don't have to maintain such a large block of code out of tree. > Sorry, but it doesn't seem to work that way. Look at the large number > of out-of-tree android device drivers that remain sitting there because > of the lack of this interface being in the kernel. Is that really the issue? The ones I've looked at have mostly suffered from being built on 2.6.29 and needing refreshes for current kernel APIs or from general code quality issues - I don't recall ever looking at one and thinking that the wakelocks were the one issue. > Also note that such a driver, without wakelocks, would never get tested, > and so, things start quickly diverging. Chances are that if the driver is useful people will start using it in non-Android systems anyway. As people have already observed wakelocks needn't have any practical effect on the running system so if the drivers are broken without wakelocks they'd be broken anyway. If this really is a big concern with getting drivers into mainline then surely we could just add some noop wakelock functions for the drivers to call? It's not particularly pretty but it'd deal with the driver merge side of things.