Hi,
I'm working on both the f/w and host s/w for a custom driver (I need a
tty talking to a bootloader running on an embedded device). I've gotten
to the point where the f/w sends a continous stream of 'x' to a bulk-in
endpoint (as a test), and the s/w submits read URBs for that endpoint.
The s/w callback resubmits read URB's unless
a) one comes back with urb->actual_length > 0 or
b) urb->status is -ENOENT (indicating it was canceled due to a close or
disconnect)
What I get is a continous stream of read callbacks, with the following
debug:
URB [c79711a0] urbp [c5eedfc0]
QH [c67a6fe0]
td 0: [c66d7f20]
00000001 e0 SPD IOC Stalled CRC/Timeo Length=7ff MaxLen=7f DT1
EndPt=1 Dev=10, PID=69(IN) (buf=07971620)
And urb->status is always -EILSEQ. The Device Driver Writer's doc says
this is a CRC/Timeout error. A search in the archives indicates that for
IN URBs this may indicate a disconnect or a data toggle mismatch from
the device. Unfortunately, I don't have an analyzer, so I don't really
know what the device is sending back.
Can someone tell me exactly what makes EILSEQ get returned in
urb->status? Or better yet, point me to the appropriate place in the
code where this error is detected?
Incidentally, my tty driver's close routine unlinks urbs, my disconnect
routine frees the urbs. Is it dangerous to unlink urb's after they're
freed? Prior to calling disconnect does the uhci driver automatically
unlink urbs?
Thanks,
--gmcnutt
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
