So I'm working on this MCP2210 driver which talks in 64-byte
request/response pairs using interrupt URBs (it can be used with
hid-generic, but I don't want to do that). I'm testing on a Raspberry
Pi Model B using the Raspbian 3.9.7 kernel. My usual order of things is:
I submit an out URB (to rx my response)
I submit an in URB (with my request)
My in URB completion handler is called
My out URB completion handler is called.
But occasionally (more so when my system is heavily loaded, spamming
printks & such), the out URB completion handler is called first. I
initially thought this was due to the device chattering or some
electrical noise as I have all of this open with wires in bread-boards &
such, but then I dumped the contents of the out URB and discovered that
it was a valid response for the given request. So the transaction must
have completed normally & correctly, but my completion handlers weren't
called in the same order as the actual communications occurred.
I'm (obviously) new to device drivers, but I wasn't able to find any
information saying that this is normal. Is it?
Also, again usually when I have debug enabled, it is common for me to
have a stalled out URB (that I detect with a manager thread running in a
delayed work queue) that I have to kill and re-submit. This almost
always stalls as well, so I have to re-submit the in URB (request) as
well. I'm not sure of the cause of that either, but it causes me to
think that some of my responses are being dropped on the floor, which
wont allow me to build a reliable device since double-sending some
requests will cause undesired results.
Anyway, I guess I'll test on my workstation for now, but it would be
nice to understand what's happening.
Daniel
--
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
