From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rafael J. Wysocki" Subject: Re: subtle pm_runtime_put_sync race and sdio functions Date: Sun, 26 Dec 2010 12:45:29 +0100 Message-ID: <201012261245.29680.rjw__46025.205605156$1293364080$gmane$org@sisk.pl> References: 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-mmc@vger.kernel.org, Ido Yariv , linux-pm@lists.linux-foundation.org, Johannes Berg List-Id: linux-pm@vger.kernel.org On Sunday, December 26, 2010, Ohad Ben-Cohen wrote: > On Sun, Dec 26, 2010 at 4:48 AM, Alan Stern wrote: > > Is there a separate handler responsible for powering the device back > > on? What are the names of these handlers? > > wl1271_sdio_power_on() and wl1271_sdio_power_off(). > > If you're taking a look, please do so using the latest code as seen on mmc-next: > > git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git mmc-next > > > That's not a race > > It is. > > If system suspend will continue uninterruptedly, and the driver will > be suspended (by the SDIO subsystem), then the device will be powered > down, and everything will work. > > But if something will interrupt the suspend transition _before_ our > driver is suspended (e.g. some other suspend() handler will fail), > then we have a problem, because the device will not be reset as the > driver needs it to be. Now, that's interesting. (It still is not a race, though.) Why does the driver need the device to be reset even though it hasn't been suspeneded yet? Rafael