Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754700Ab0FDJIL (ORCPT ); Fri, 4 Jun 2010 05:08:11 -0400 Received: from smtp-out.google.com ([216.239.44.51]:7206 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753933Ab0FDJIH (ORCPT ); Fri, 4 Jun 2010 05:08:07 -0400 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=wUqEJEGegrXxg0mCsfbbjQubUFsbcHAjEOs51Czie2vfCp/UiEWjgMYx3DbaDn3Dk RBNuGPg1DQhABzadZ+jgQ== MIME-Version: 1.0 In-Reply-To: <20100604085513.GE15181@elte.hu> References: <20100603193045.GA7188@elte.hu> <20100604075722.GA15181@elte.hu> <20100604085513.GE15181@elte.hu> Date: Fri, 4 Jun 2010 02:08:03 -0700 Message-ID: Subject: Re: suspend blockers & Android integration From: Brian Swetland To: Ingo Molnar Cc: tytso@mit.edu, Neil Brown , "Arve Hj?nnev?g" , Thomas Gleixner , "Rafael J. Wysocki" , Alan Stern , Felipe Balbi , Peter Zijlstra , LKML , Florian Mickler , Linux OMAP Mailing List , Linux PM , Alan Cox , James Bottomley , Linus Torvalds , Peter Zijlstra Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2152 Lines: 43 On Fri, Jun 4, 2010 at 1:55 AM, Ingo Molnar wrote: > * Brian Swetland wrote: >> > After basically two years of growing your fork (and some attempts to get >> > your drivers into drivers/staging/ - from where they have meanwhile >> > dropped out again) you re-started with the worst possible thing to merge: >> > a big and difficult kernel feature affecting many subsystems. Why? >> >> Because a large number of our drivers depend on it. > > So why not put in some stub or so? Auto-suspend/suspend-blockers is a feature, > and drivers ought to be able to work without a feature as well. Keep the > suspend-blocker changes in the android tree initially, and get the main body > of changes out first, and establish a flow of timely changes. That reduces > your maintenance burden and increases trust for future changes - a win-win > situation. The impression I got from previous discussions was that upstream did not want things that were built conditionally around APIs that did not exist in mainline nor stub implementations for things that were not agreed upon. We could easily either #if defined(CONFIG_SUSPEND_BLOCKERS) or submit a suspend_blockers.h that just makes everything a no-op, if that's an acceptable transition vehicle. I didn't think either were an option open to us. > In any case, this is not to suggest that the suspend-blocker bits are > 'impossible' to merge. I just say that if you start with your most difficult > feature you should not be surprised to be on the receiving end of a 1000+ > mails flamewar on lkml ;-) Yeah, I do understand that we're not making it easy for ourselves here. I think we hit the point where Rafael and Matthew signed off on things and thought "aha, linux-pm maintainers are happy, now we're getting somewhere" only to realize the light at the end of the tunnel was a bit further out than we anticipated ^^ Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/