From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rafael J. Wysocki" Subject: Re: Async resume patch (was: Re: [GIT PULL] PM updates for 2.6.33) Date: Tue, 8 Dec 2009 21:52:21 +0100 Message-ID: <200912082152.21910.rjw@sisk.pl> References: Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: Received: from ogre.sisk.pl ([217.79.144.158]:49141 "EHLO ogre.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966079AbZLHUvm (ORCPT ); Tue, 8 Dec 2009 15:51:42 -0500 In-Reply-To: Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Alan Stern Cc: Linus Torvalds , Zhang Rui , LKML , ACPI Devel Maling List , pm list On Tuesday 08 December 2009, Alan Stern wrote: > On Tue, 8 Dec 2009, Rafael J. Wysocki wrote: > > > > This is a little more awkward because it requires the parent to iterate > > > through its children. > > > > I can live with that. > > > > > But it does solve the off-tree dependency problem for suspends. > > > > That's a plus, but I still think we're trying to create a barrier-alike > > mechanism using lock. > > > > There's one more possibility to consider, though. What if we use a completion > > instead of the flag + wait queue? It surely is a standard synchronization > > mechanism and it seems it might work here. > > You're right. I should have thought of that. Linus's original > approach couldn't use a completion because during suspend it needed to > make one task (the parent) wait for a bunch of others (the children). > But if you iterate through the children by hand, that objection no > longer applies. BTW, is there a good reason why completion_done() doesn't use spin_lock_irqsave and spin_unlock_irqrestore? complete() and complete_all() use them, so why not here? Rafael