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)
Perhaps it's the status completion and the SETUP packet reception
interrupts that get coalesced...
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,
No, that's correct. What's actually incorrect is that the driver
doesn't complete the request in that case... will address by the
different patch.
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... :-/
I think I'll experiment with this (not setting the DataEnd bit should
cause SetupEnd interrupts).
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...
It's not just simplest, it now seems the only correct thing to do.
However, falling thru from the status in/out state right into the idle
state seems of dubios value. I always see (at least) two distinct
interrupts.
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
