Hello, I wrote:
The EP0 code routinely ignores interrupt at end of the data phase
because of
musb_g_ep0_giveback() resetting the state machine to "idle, waiting
for SETUP"
phase prematurely.
Signed-off-by: Sergei Shtylyov <sshtylyov@xxxxxxxxxxxxx>
---
This fixes most of the unhandled gadget interrupts that
generic_interrupt() and
davinci_interrupt() have been hiding from user by faking their result
and only
emitting 5th level debug message (for what is clearly an error).
And of course it turrned out to be only yhe tip of an iceberg. It
uncovered another race happening when the last IN packet is sent and
CSR.DataEnd bit is set along with it: there supposed to be *two*
interrupts after that -- they seem to often be coalsesced into a single
one (when using Linux host) but when testing with Windows RNDIS driver
they come separate and cause another unhandled IRQ to happen, right
after the one that got fixed by this patch.
Also, the driver falls thru to the "idle, wating for SETUP" phase
after receiving SetupEnd interrupt -- that's incorrect, what follows is
the early status phase, with another interrupt (that won't be handled as
well due to wrong phase).
Though I suspect that in reality these two distinct interrupts will often
coalesce as well as DATA1 token should follow IN/OUT pretty quick. What a racy
piece of hardware... :-/
So, I'm goind to recast this patch, adding more fixes -- if there's
s/goind/going/
no objections...
Perhaps the simplest thing to do would be to return IRQ_HANDLED from the
"idle, waiting for SETUP" phase regardess of RxPktRdy...
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
