musb_gadget: fix unhandled endpoint 0 IRQs

The gadget EP0 code routinely ignores an interrupt at end of
the data phase because of musb_g_ep0_giveback() resetting the
state machine to "idle, waiting for SETUP" phase prematurely.

The driver also prematurely leaves the status phase on
receiving the SetupEnd interrupt.

As there were still unhandled endpoint 0 interrupts happening
from time to time after fixing these issues, there turned to
be yet another culprit: two distinct gadget states collapsed
into one.

The (missing) state that comes after STATUS IN/OUT states was
typically indiscernible from them since the corresponding
interrupts tend to happen within too little period of time
(due to only a zero-length status packet in between) and so
they got coalesced; yet this state is not the same as the next
one which is associated with the reception of a SETUP packet.

Adding this extra state seems to have fixed the rest of the
unhandled interrupts that generic_interrupt() and
davinci_interrupt() hid by faking their result and only
emitting a debug message -- so, stop doing that.

Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

1 files changed, 1 insertions, 6 deletions

diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
index 10d11ab113ab..898b52fcff5d 100644
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -372,12 +372,7 @@ static irqreturn_t davinci_interrupt(int irq, void *__hci)
 
 	spin_unlock_irqrestore(&musb->lock, flags);
 
-	/* REVISIT we sometimes get unhandled IRQs
-	 * (e.g. ep0).  not clear why...
-	 */
-	if (retval != IRQ_HANDLED)
-		DBG(5, "unhandled? %08x\n", tmp);
-	return IRQ_HANDLED;
+	return retval;
 }
 
 int musb_platform_set_mode(struct musb *musb, u8 mode)