From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitry Torokhov Subject: Re: [PATCH 0/8] Suspend block api (version 6) Date: Tue, 25 May 2010 11:33:35 -0700 Message-ID: <20100525183334.GA4669@core.coreip.homeip.net> References: <20100525165137.GB2730@core.coreip.homeip.net> 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: Greg Kroah-Hartman , Sven Neumann , Jesse Barnes , Kernel development list , Tero Saarni , linux-input@vger.kernel.org, Linux-pm mailing list , Arjan van de Ven , Alexey Dobriyan , Matthew Garrett , Len Brown , Jacob Pan , Daniel Mack , Oleg Nesterov , linux-omap@vger.kernel.org, Liam Girdwood , Daniel Walker , Theodore Ts'o , =?iso-8859-1?Q?M=E1rton_N=E9meth?= , Brian Swetland List-Id: linux-input@vger.kernel.org On Tue, May 25, 2010 at 02:25:08PM -0400, Alan Stern wrote: > On Tue, 25 May 2010, Dmitry Torokhov wrote: > > > BTW, If you are concerned about events that already "left" physical > > device but has not reached userspace yet - maybe instead of suspend > > blockers we should make sure that all drivers throughout the chain > > implement suspend/resume and refuse suspending if their queues are not > > empty. In input land that would mean extending suspend routine in > > input_dev and adding one to evdev. > > That's not the only problem. We also have to consider events that have > reached userspace but not yet been fully processed. The user thread > handling the event needs some way to prevent the system from suspending > until it is all done. > It is a problem if kernel initiated suspend transition on its own. I believe that it is userspace responsibility to initiate sustend (and make sure that needs of userspace, including processing of certain events, are served beforehand). -- Dmitry