On Mon, May 17, 2004 at 02:37:50PM -0400, Alan Stern wrote:
> On Mon, 17 May 2004, Jean Tourrilhes wrote:
>
> > Yes, but only if the URB is idle. Check what the status in
> > question mean.
>
> I did check. You change urb->status when it is non-zero and not equal to
> -EINPROGRESS. So what? The status can be set to many possible values
> while the URB is still active and in use by the USB core. That's why
> you're not supposed to look at it unless the URB is idle.
You are right, the "default" case should not be handled this
way, but with an "unlink". I'll fix that.
> > I spent enough time testing the driver and working around the
> > "features" of the USB API that I can say : be my guest.
>
> The basic idea is simple enough. When an URB has been successfully
> submitted it is owned by the USB core, not your driver. You may not
> modify it and probably shouldn't even read it until the completion
> handler is called.
This is good in theory, but doesn't always work in
practice. I've seen USB screwing up far too many time to trust it
entirely with URBs. Yes, I tend to have crappy HCI controllers.
> What is there to test in ohci-hcd? The only occurrences of "timeout" in
> the OHCI sources are in a comment and in "schedule_timeout". The driver
> completely ignores urb->timeout.
Yes, you are correct, I may have not tested properly. It is
present and working in usb-ohci, so maybe I assumed it was carried in
ohci-hcd.
> Alan Stern
Jean
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
