Re: [RFC][PATCH] PM: Avoid losing wakeup events during suspend

From: tytso@mit.edu
To: markgross@thegnar.org
Cc: "Alan Stern" <stern@rowland.harvard.edu>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	"Linux-pm mailing list" <linux-pm@lists.linux-foundation.org>,
	"Matthew Garrett" <mjg59@srcf.ucam.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
	"Arve Hjønnevåg" <arve@android.com>, "Neil Brown" <neilb@suse.de>,
	"mark gross" <640e9920@gmail.com>
Subject: Re: [RFC][PATCH] PM: Avoid losing wakeup events during suspend
Date: Mon, 21 Jun 2010 08:10:58 -0400	[thread overview]
Message-ID: <20100621121058.GF6199@thunk.org> (raw)
In-Reply-To: <20100621061345.GF9735@gvim.org>

So where are we at this point?

Discussion had completely died down for a while, and it's picked up
again, but it's not clear to me that we're any closer to reaching
consensus.

There's been one proposal that we simply merge in a set of no-op
inline functions for suspend blockers, just so we can get let the
drivers go in (assuming that Greg K-H believes this is still a
problem), but with an automatical removal of N months (N to be
decided, say 9 or 12 or 18 months).

My concern is that if we do that, we will have simply kicked the ball
down the road for N months.  Another approach is to simply merge in
no-op functions and not leave any kind of deprecation schedule.
That's sort of an implicit admission of the fact that we may not reach
consensus on this issue.  Or we could simply ship the patches as-is to
Linus after he gets back from vacation and ask him for a thumbs up or
thumbs down vote, which might settle things once and for all.

How do we go forward from here?

					- Ted