From: NeilBrown <neilb@suse.de>
To: Felipe Balbi <balbi@ti.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-usb@vger.kernel.org, linux-omap@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Infinite looping in omap2430.c USB driver
Date: Sat, 7 Jul 2012 08:39:49 +1000 [thread overview]
Message-ID: <20120707083949.2cf91eeb@notabene.brown> (raw)
[-- Attachment #1: Type: text/plain, Size: 2505 bytes --]
Hello `./scripts/get_maintainer.pl -f drivers/usb/musb/omap2430.c`
omap2430_musb_set_vbus in omap2430.c contains:
while (musb_readb(musb->mregs, MUSB_DEVCTL) & 0x80) {
cpu_relax();
if (time_after(jiffies, timeout)) {
dev_err(musb->controller,
"configured as A device timeout");
ret = -EINVAL;
break;
}
}
having set
unsigned long timeout = jiffies + msecs_to_jiffies(1000);
so it can busy-loop for up to 1 second. Probably not ideal, but if it works
I wouldn't complain.
The
if (int_usb & MUSB_INTR_SESSREQ) {
branch of musb_stage0_irq() called from musb_interrupt (from
generic_interrupt) calls this:
if (musb->int_usb)
retval |= musb_stage0_irq(musb, musb->int_usb,
devctl, power);
so the busy loop can happen in an interrupt handler (not a threaded interrupt
handler), which is probably less ideal.
However this can be called with interrupt disabled, as happens at least
during resume when resume_irqs() calls:
raw_spin_lock_irqsave(&desc->lock, flags);
__enable_irq(desc, irq, true);
raw_spin_unlock_irqrestore(&desc->lock, flags);
and an interrupt is found to be IRQS_PENDING.
In this case interrupts are disabled so 'jiffies' never changes so this loop
can continue forever.
This happens on my (GTA04) phone fairly regularly - between 1 in 10 and 1 in
30 resumes. The musb-hdrc interrupt is pending and reports
[ 4957.624176] musb-hdrc musb-hdrc: ** IRQ peripheral usb0040 tx0000 rx0000
'usb0040' is MUSB_INTR_SESSREQ. I think this is triggered by detecting a
voltage change on the USB ID pin - is that right? A short-to-earth would be
a request to switch to host mode, which is why it tries to enable VBUS.
Maybe there is some electrical noise which is being picked up?
In any case I get the interrupt despite nothing being plugged in, and the 0x80
bit of MUSB_DEVCTL never gets cleared.
I've added a simple loop counter which aborts the loop after 1000 loops -
this takes about 5 seconds, but includes some printks which probably slow it
down.
In 2 out of 2 cases, subsequent messages show that the hsmmc driver for the
uSD card that holds my root filesystem is messed up. It seems to be waiting
for a request that is never going to complete.
So maybe the hsmmc is causing the noise that triggers the musb issue.
I can send a patch which add a loop count if you like, but I suspect you can
come up with a much better approach.
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next reply other threads:[~2012-07-06 22:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-06 22:39 NeilBrown [this message]
2012-07-09 8:32 ` Infinite looping in omap2430.c USB driver Tony Lindgren
2012-07-30 0:16 ` NeilBrown
2012-08-09 11:15 ` Felipe Balbi
2012-08-13 2:34 ` NeilBrown
[not found] ` <20120813123453.4cba14ca-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2012-08-13 14:32 ` Felipe Balbi
2012-08-13 14:32 ` Felipe Balbi
2012-08-13 21:46 ` NeilBrown
2012-08-14 7:58 ` Felipe Balbi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120707083949.2cf91eeb@notabene.brown \
--to=neilb@suse.de \
--cc=balbi@ti.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.