From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ohad Ben-Cohen Subject: Re: subtle pm_runtime_put_sync race and sdio functions Date: Tue, 28 Dec 2010 21:15:27 +0200 Message-ID: References: <201012261245.29680.rjw@sisk.pl> <201012261937.21256.rjw@sisk.pl> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <201012261937.21256.rjw@sisk.pl> 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: "Rafael J. Wysocki" Cc: linux-wireless@vger.kernel.org, linux-mmc@vger.kernel.org, Ido Yariv , linux-pm@lists.linux-foundation.org, Johannes Berg List-Id: linux-pm@vger.kernel.org On Sun, Dec 26, 2010 at 8:37 PM, Rafael J. Wysocki wrote: > So, it only happens during asynchronous suspend? =A0In other words, if su= spend > is synchronous, everything should be fine, right? Not necessarily. Consider this simple scenario, where a device was added after the mmc host controller, but before mac80211. In this case its suspend handler will have the chance to abort system suspend after mac80211 already told our driver to power down the device (but the device wasn't powered down yet, because the driver used pm_runtime_put_sync() which is disabled). Thanks, Ohad.