[PATCH v2] usb: musb: Disable the D+ pullup during system suspend

[PATCH v2] usb: musb: Disable the D+ pullup during system suspend

[Nguyen Minh Tien]

When musb_suspend() clears DEVCTL, the host sees a disconnect. But VBUS
is still there, so the controller can start a new session on its own
and, with SOFTCONN still set, pull D+ up again while its interrupts are
masked. The host then fails to enumerate the gadget ("unable to
enumerate USB device") and gives up, and nothing at resume makes it try
again. On a T113-S3 board the gadget link never survived an s2idle
cycle.

Clear SOFTCONN once the context is saved; musb_restore_context() puts
it back on resume. This is what the FIXME asked for, as USB can't wake
us in time with the interrupts masked. Platforms that power the PHY off
during suspend, like the AM335x, never showed the problem: D+ drops
with the PHY.

Fixes: 6fc6f4b87cb3 ("usb: musb: Disable interrupts on suspend, enable them on resume")
Cc: stable@vger.kernel.org
Signed-off-by: Nguyen Minh Tien <tien.nguyenminh@embeddedlinux.blog>
---
Changes in v2:
- Comment: why only some platforms see this; where the PHY is powered
  off during suspend, D+ drops anyway (Andreas Kemnade).
- Message: one sentence on the same, in place of the da8xx one; da8xx
  powers its PHY off during suspend, so its host saw a disconnect
  before the patch as well.
- "Disable" instead of "Drop" in the subject.
- The code is the same as in v1.
- Link to v1: https://lore.kernel.org/all/20260927164145.1956429-1-tien.nguyenminh@embeddedlinux.blog/

I found this on a T113-S3 board (sunxi, s2idle, Intel xHCI host): ssh
over the gadget never came back after a suspend. With the patch, all 30
cycles I ran re-enumerated after resume.

To check for regressions, I also tried a BeagleBone Black (AM335x,
dsps glue, suspend to RAM). There the link came back after every
resume (10 cycles without the patch, 30 with it), as
am335x_phy_suspend() powers the PHY off. A test on an OMAP3 board
(omap2430 glue, twl4030 PHY) would be welcome.

 drivers/usb/musb/musb_core.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 73ac25f536..39b0845108 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2825,18 +2825,26 @@ static int musb_suspend(struct device *dev)
 
 	spin_lock_irqsave(&musb->lock, flags);
 
+	musb_save_context(musb);
+
 	if (is_peripheral_active(musb)) {
-		/* FIXME force disconnect unless we know USB will wake
-		 * the system up quickly enough to respond ...
+		/*
+		 * We can't answer a host with the interrupts off, so disable
+		 * the D+ pullup. musb_restore_context() puts back the state
+		 * saved above. Where the PHY is powered off during suspend
+		 * (AM335x, for one), D+ drops anyway; where it stays powered,
+		 * as on sunxi, the host would see a device that can't answer.
 		 */
+		u8 power = musb_readb(musb->mregs, MUSB_POWER);
+
+		musb_writeb(musb->mregs, MUSB_POWER,
+			    power & ~MUSB_POWER_SOFTCONN);
 	} else if (is_host_active(musb)) {
 		/* we know all the children are suspended; sometimes
 		 * they will even be wakeup-enabled.
 		 */
 	}
 
-	musb_save_context(musb);
-
 	spin_unlock_irqrestore(&musb->lock, flags);
 	return 0;
 }

base-commit: 165768bb70265b5c38cf0b73fafd75be235f8b14
-- 
2.34.1

Re: [PATCH v2] usb: musb: Disable the D+ pullup during system suspend

[sashiko-bot]

> When musb_suspend() clears DEVCTL, the host sees a disconnect. But VBUS
> is still there, so the controller can start a new session on its own
> and, with SOFTCONN still set, pull D+ up again while its interrupts are
> masked. The host then fails to enumerate the gadget ("unable to
> enumerate USB device") and gives up, and nothing at resume makes it try
> again. On a T113-S3 board the gadget link never survived an s2idle
> cycle.
> 
> Clear SOFTCONN once the context is saved; musb_restore_context() puts
> it back on resume. This is what the FIXME asked for, as USB can't wake
> us in time with the interrupts masked. Platforms that power the PHY off
> during suspend, like the AM335x, never showed the problem: D+ drops
> with the PHY.
> 
> Fixes: 6fc6f4b87cb3 ("usb: musb: Disable interrupts on suspend, enable them on resume")
> Cc: stable@vger.kernel.org
> Signed-off-by: Nguyen Minh Tien <tien.nguyenminh@embeddedlinux.blog>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261008155402.66266-1-tien.nguyenminh@embeddedlinux.blog?part=1