From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Berg Subject: Re: subtle pm_runtime_put_sync race and sdio functions Date: Sat, 18 Dec 2010 17:40:07 +0100 Message-ID: <1292690407.3653.2.camel__12593.3361392983$1292690492$gmane$org@jlt3.sipsolutions.net> References: <201012181607.26628.rjw@sisk.pl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: 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: Ohad Ben-Cohen Cc: linux-wireless@vger.kernel.org, Linux-pm mailing list , linux-mmc@vger.kernel.org, Ido Yariv List-Id: linux-pm@vger.kernel.org On Sat, 2010-12-18 at 18:00 +0200, Ohad Ben-Cohen wrote: > > That's where the problem is. If there's a difference, from the driver's > > point of view, between suspend and some other operation, there should be a > > way to tell the driver what case it actually is dealing with. > > Yes, the problem will be solved if the driver would bypass the runtime > PM framework on system suspend. mac80211 obviously has this > information, and technically it's very easy to let the driver know > about it. > > But the difference between suspend and normal operation is really > artificial: in both cases mac80211 just asks the driver to power its > device down, and the end result is exactly the same (a GPIO line of > the device is de-asserted in our case). The difference between these > two scenarios > exist only because runtime PM is effectively disabled during system > suspend, and therefore the driver has to look for an alternative way > to power down the device. Sounds to me like the difference isn't really in the driver, but the core PM subsystem. Why does it care when powering off a device whether it's during suspend, or during runtime? johannes