linux-kernel - [ 54/78] mmc: sdio: Use empty system suspend/resume callbacks at the bus level

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20120411231027.518643416@linuxfoundation.org>
Date:	Wed, 11 Apr 2012 16:11:12 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	linux-kernel@...r.kernel.org, stable@...r.kernel.org
Cc:	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	alan@...rguk.ukuu.org.uk, "Rafael J. Wysocki" <rjw@...k.pl>,
	Chris Ball <cjb@...top.org>
Subject: [ 54/78] mmc: sdio: Use empty system suspend/resume callbacks at the bus level

3.3-stable review patch.  If anyone has any objections, please let me know.

------------------

From: "Rafael J. Wysocki" <rjw@...k.pl>

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 <neilb@...e.de>
Signed-off-by: Rafael J. Wysocki <rjw@...k.pl>
Signed-off-by: Chris Ball <cjb@...top.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>

---
 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",

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/