This is a note to let you know that I've just added the patch titled

    mmc: sdio: Use empty system suspend/resume callbacks at the bus level

to the 3.3-stable tree which can be found at:
    
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     mmc-sdio-use-empty-system-suspend-resume-callbacks-at-the-bus-level.patch
and it can be found in the queue-3.3 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.


>From e841a7c69b708eeaf784fd517978006e8319b03a Mon Sep 17 00:00:00 2001
From: "Rafael J. Wysocki" <[email protected]>
Date: Sun, 1 Apr 2012 00:34:58 -0400
Subject: mmc: sdio: Use empty system suspend/resume callbacks at the bus level

From: "Rafael J. Wysocki" <[email protected]>

commit e841a7c69b708eeaf784fd517978006e8319b03a upstream.

Neil Brown reports that commit 35cd133c

   PM: Run the driver callback directly if the subsystem one is not there

breaks suspend for his libertas wifi, because SDIO has a protocol
where the suspend method can return -ENOSYS and this means "There is
no point in suspending, just turn me off".  Moreover, the suspend
methods provided by SDIO drivers are not supposed to be called by
the PM core or bus-level suspend routines (which aren't presend for
SDIO).  Instead, when the SDIO core gets to suspend the device's
ancestor, it calls the device driver's suspend function, catches the
ENOSYS, and turns the device off.

The commit above breaks the SDIO core's assumption that the device
drivers' callbacks won't be executed if it doesn't provide any
bus-level callbacks.  If fact, however, this assumption has never
been really satisfied, because device class or device type suspend
might very well use the driver's callback even without that commit.

The simplest way to address this problem is to make the SDIO core
tell the PM core to ignore driver callbacks, for example by providing
no-operation suspend/resume callbacks at the bus level for it,
which is implemented by this change.

Reported-and-tested-by: Neil Brown <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Chris Ball <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
 drivers/mmc/core/sdio_bus.c |   12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

--- a/drivers/mmc/core/sdio_bus.c
+++ b/drivers/mmc/core/sdio_bus.c
@@ -192,9 +192,15 @@ static int sdio_bus_remove(struct device
        return ret;
 }
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
+
+static int pm_no_operation(struct device *dev)
+{
+       return 0;
+}
 
 static const struct dev_pm_ops sdio_bus_pm_ops = {
+       SET_SYSTEM_SLEEP_PM_OPS(pm_no_operation, pm_no_operation)
        SET_RUNTIME_PM_OPS(
                pm_generic_runtime_suspend,
                pm_generic_runtime_resume,
@@ -204,11 +210,11 @@ static const struct dev_pm_ops sdio_bus_
 
 #define SDIO_PM_OPS_PTR        (&sdio_bus_pm_ops)
 
-#else /* !CONFIG_PM_RUNTIME */
+#else /* !CONFIG_PM */
 
 #define SDIO_PM_OPS_PTR        NULL
 
-#endif /* !CONFIG_PM_RUNTIME */
+#endif /* !CONFIG_PM */
 
 static struct bus_type sdio_bus_type = {
        .name           = "sdio",


Patches currently in stable-queue which might be from [email protected] are

queue-3.3/pm-sleep-mitigate-race-between-the-freezer-and-request_firmware.patch
queue-3.3/mmc-sdio-use-empty-system-suspend-resume-callbacks-at-the-bus-level.patch
queue-3.3/firmware_class-rework-usermodehelper-check.patch
queue-3.3/pm-sleep-move-disabling-of-usermode-helpers-to-the-freezer.patch
queue-3.3/pm-hibernate-disable-usermode-helpers-right-before-freezing-tasks.patch
queue-3.3/pm-runtime-don-t-forget-to-wake-up-waitqueue-on-failure.patch
queue-3.3/firmware_class-do-not-warn-that-system-is-not-ready-from-async-loads.patch
queue-3.3/firmware_class-split-_request_firmware-into-three-functions-v2.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to