From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Machek Subject: Re: [PATCH 05/11] PM: Enable early suspend through /sys/power/state Date: Mon, 2 Feb 2009 12:44:01 +0100 Message-ID: <20090202114400.GA4631@elf.ucw.cz> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-pm-bounces@lists.linux-foundation.org Errors-To: linux-pm-bounces@lists.linux-foundation.org To: Alan Stern Cc: swetland@google.com, linux-pm@lists.linux-foundation.org List-Id: linux-pm@vger.kernel.org On Sat 2009-01-31 10:49:16, Alan Stern wrote: > On Fri, 30 Jan 2009, Arve Hj?nnev?g wrote: > > > > No, please don't break compatibility like this. You changed semantics > > > of 'mem'... > > > > > > Just add another two states, for example "auto-mem" and > > > "auto-standby", and make them enter mem/standby when required. > > > > > > > What would you want to happen if someone writes "mem"? If we just call > > enter_state, it will fail and return an error if a wakelock is locked. > > We can call request_suspend_state and then wait for another thread to > > write "on", but this still requires user-space changes to work > > correctly. If the goal is to allow the kernel to be compiled with > > wakelock and early suspend support while preserving the old behaviour > > if wakelocks are not used, then the first option is better. > > This is exactly what I am complaining about in another thread. The > code should be written so that when the user writes "mem", the system > goes into suspend even if some wakelocks are locked. Yes please. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html