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...
Er, no... those should be more spaced in time because of 8-byte SETUP
packet that gets received in between them.
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.
I'm considering addition of another (tryly "idle") phase because the
stage after the status phase completion interrupt and before the
RxPktRdy interrupt was clearly missed.
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
