From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rafael J. Wysocki" Subject: Re: [PATCH V2 0/4] introduce device async actions mechanism Date: Wed, 12 Aug 2009 22:10:35 +0200 Message-ID: <200908122210.35591.rjw@sisk.pl> References: Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Alan Stern Cc: Zhang Rui , Linux Kernel Mailing List , linux-pm , linux-acpi , Pavel Machek , Len Brown , Arjan van de Ven , "dtor@mail.ru" List-Id: linux-acpi@vger.kernel.org On Wednesday 12 August 2009, Alan Stern wrote: > On Wed, 12 Aug 2009, Rafael J. Wysocki wrote: > > > That looks quite complicated at first sight, but asynchronous resume with > > completions can be done in a relatively simple patch. I've got one, so > > tomorow I'll post it for further discussion. > > Okay. I would think that managing the threads would account for most > of the complexity in either implementation, but I'll wait to see how > your approach works out. > > > Thanks, > > Rafael > > > > > > PS > > Did you have a chance to look at rev. 15 of the runtime PM patch > > (http://patchwork.kernel.org/patch/40306/)? > > Yes, sorry for not getting back to you. It looks okay. > > The one thing I'm not sure of is the pm_runtime_put_noidle calls in > driver_probe_device and __device_release_driver. It seems that we > should always call pm_runtime_put regardless of whether the probe > succeeds or not. Did you mean pm_runtime_put_sync()? > For example, the USB stack is set up to suspend devices that don't have > a driver (this is handled at the bus subsystem level). But if probing > failed, there wouldn't be any idle callback and so the suspend wouldn't > take place. OK, I'll make this change. Thanks, Rafael