On Fri, Apr 28, 2000, David Brownell <[EMAIL PROTECTED]> wrote:
> > 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.)
EXDEV is new to me. I see both OHCI and AFS UHCI implement it. However,
I didn't see any discussion about it. Anyway, I'll implement it in my
next patch.
> 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.)
Making the error codes more specific is a good thing. I'll switch my
driver to disambiguate those error conditions.
> 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.
UHCI does the same thing. We can specify from 0 to 3 errors. Both UHCI
drivers use 3 errors almost all of the time.
> 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.
I don't think we do. I'll add this to my list of things to check.
JE
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
