Return-path: Received: from mail-iw0-f194.google.com ([209.85.214.194]:62256 "EHLO mail-iw0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750867Ab0L1TPs convert rfc822-to-8bit (ORCPT ); Tue, 28 Dec 2010 14:15:48 -0500 MIME-Version: 1.0 In-Reply-To: <201012261937.21256.rjw@sisk.pl> References: <201012261245.29680.rjw@sisk.pl> <201012261937.21256.rjw@sisk.pl> From: Ohad Ben-Cohen Date: Tue, 28 Dec 2010 21:15:27 +0200 Message-ID: Subject: Re: [linux-pm] subtle pm_runtime_put_sync race and sdio functions To: "Rafael J. Wysocki" Cc: Alan Stern , linux-pm@lists.linux-foundation.org, Johannes Berg , linux-wireless@vger.kernel.org, linux-mmc@vger.kernel.org, Ido Yariv , Kevin Hilman Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Sun, Dec 26, 2010 at 8:37 PM, Rafael J. Wysocki wrote: > So, it only happens during asynchronous suspend? ?In other words, if suspend > 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.