> From: "Johan Verrept" <[EMAIL PROTECTED]>
>
> At unlink, the uhci drivers call the completion handler and put the
> error or ENOENT, beautifull ;-)
> The ohci driver does not call the completion handler when unlinking the
> urb, beautifull too ;-)
Matt Dharm's been reporting some of this. I sent a patch
a while back that changed the ENOENT thing for OHCI (though
it seems wrong to return an error code in the typical case).
That didn't check for missing calls to the completion handler.
Maybe that's why it didn't help Matt ... neither of us had
noticed that one! Seems adding a call, with that errno, is
the right thing to do. I'll send a patch for this along.
> There is another possible difference, but i am not really sure...
> usb-ohci speaks of buffer under/overrun and returns -ECOMM,
> usb-uhci/uhci speak of babble and generic buffer error and return both
> EPIPE.
> Are they talking about the same things here? I smeed like it to me, but
> i don't know enough about the low level stuff to be sure...
When I looked at this a while back, it seemed to me that both
of the UHCI drivers used EPIPE in places where <linux/usb.h>
defines more specific codes, as used by OHCI. (ECOMM, EOVERFLOW
aren't returned ... plus 'uhci.c' won't return EXDEV.)
Either the UHCI drivers, or usb.h and the OHCI driver, should
change. Opinions? (I'd say change the UHCIs, so there's a
clear distinction between stalls and real failures.)
Also, I noticed that OHCI does up to three hardware retries
before reporting certain errors -- do the UHCIs provide similar
guarantees, or do they report failures without retrying? This
relates to completion in that UHCI might "complete" sooner,
and report more errors.
Oh, and one more to check. The USB 1.1 spec says things about
control and interrupt endpoints not halting. I'm not sure all
controller drivers agree with the spec on that.
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
