linux-kernel - [PATCH v2 2/2] USB: musb: dsps: add explicit runtime resume at suspend

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] [day] [month] [year] [list]

Message-Id: <20170726150046.22757-3-johan@kernel.org>
Date:   Wed, 26 Jul 2017 17:00:46 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Bin Liu <b-liu@...com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-usb@...r.kernel.org, linux-omap@...r.kernel.org,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
        Johan Hovold <johan@...nel.org>,
        Alan Stern <stern@...land.harvard.edu>,
        Daniel Mack <zonque@...il.com>,
        Tony Lindgren <tony@...mide.com>
Subject: [PATCH v2 2/2] USB: musb: dsps: add explicit runtime resume at suspend

The musb_dsps driver is special in that the parent (glue) device's
driver is accessing registers mapped by the child. The clock is however
shared and is managed by the grandparent device.

Since commit 869c59782981 ("usb: musb: dsps: add support for suspend and
resume") the dsps driver has been accessing these registers as part of
suspend and resume.

The parent driver obviously cannot runtime resume the child during
system suspend and is currently relying on the fact that the child will
be RPM_ACTIVE throughout suspend. The suspend implementation also makes
sure to check that the child is indeed present (and hence the clock
enabled) before accessing the registers.

Let's add an explicit runtime resume of the glue device itself to enable the
clock before doing the register accesses in case these assumptions ever change
(i.e. if the child is left runtime suspended).

Note that the glue-timer cancellation is moved after the child-presence
check to keep error handling simple. This should be fine as the timer is
not setup until the controller is being registered and at that time
glue->musb and its driver data have already been initialised.

Cc: Alan Stern <stern@...land.harvard.edu>
Cc: Daniel Mack <zonque@...il.com>
Cc: Tony Lindgren <tony@...mide.com>
Signed-off-by: Johan Hovold <johan@...nel.org>
---
 drivers/usb/musb/musb_dsps.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index bc6a9be2ccc5..f6b526606ad1 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -1015,13 +1015,20 @@ static int dsps_suspend(struct device *dev)
 	const struct dsps_musb_wrapper *wrp = glue->wrp;
 	struct musb *musb = platform_get_drvdata(glue->musb);
 	void __iomem *mbase;
-
-	del_timer_sync(&glue->timer);
+	int ret;

 	if (!musb)
 		/* This can happen if the musb device is in -EPROBE_DEFER */
 		return 0;

+	ret = pm_runtime_get_sync(dev);
+	if (ret < 0) {
+		pm_runtime_put_noidle(dev);
+		return ret;
+	}
+
+	del_timer_sync(&glue->timer);
+
 	mbase = musb->ctrl_base;
 	glue->context.control = musb_readl(mbase, wrp->control);
 	glue->context.epintr = musb_readl(mbase, wrp->epintr_set);
@@ -1060,6 +1067,8 @@ static int dsps_resume(struct device *dev)
 	    musb->port_mode == MUSB_PORT_MODE_DUAL_ROLE)
 		dsps_mod_timer(glue, -1);

+	pm_runtime_put(dev);
+
 	return 0;
 }
 #endif
-- 
2.13.3