[RFC][PATCH] musb: Avoid musb_gadget_pullup "Unhandled fault" oopson omap4

From: John Stultz
Date: Wed Jul 20 2011 - 20:09:46 EST

I've recently run across an "Unhandled fault: imprecise external abort"
oops that is caused when a driver called usb_gadget_connect() when there
was no cable plugged into the musb gadget port.

You can see the oops message here:

Doing some digging, it seemed the problem was triggered when reading
from the musb registers in musb_pullup() when the device controller is
powered down.

Looking at other examples of where the registers were accessed, I
noticed they were always enclosed by pm_runtime_get/put calls. So I
added such calls to the musb_gadget_pullup() function and it seemed to
resolve the problem.

Now, full disclosure: this was triggered with the out-of-tree Android
adb gadget driver. However, I suspect the same behavior could be
triggered using the composite gadget driver as well, so I think this is
a generic issue. However, if I'm wrong, let me know and I'll try to make
sure the fix is done in the right place.

If this is the right fix, it probably should be queued for 3.1 and

Comments and feedback would be greatly appreciated!

Reported-by: Zach Pfeffer <zach.pfeffer@xxxxxxxxxx>
Signed-off-by: John Stultz <john.stultz@xxxxxxxxxx>

diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 6aeb363..548338c 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1698,6 +1698,8 @@ static int musb_gadget_pullup(struct usb_gadget *gadget, int is_on)

is_on = !!is_on;

+ pm_runtime_get_sync(musb->controller);
/* NOTE: this assumes we are sensing vbus; we'd rather
* not pullup unless the B-session is active.
@@ -1707,6 +1709,9 @@ static int musb_gadget_pullup(struct usb_gadget *gadget, int is_on)
musb_pullup(musb, is_on);
spin_unlock_irqrestore(&musb->lock, flags);
+ pm_runtime_put(musb->controller);
return 0;

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