On Tue, Aug 24, 2004 at 05:34:21PM -0400, Alan Stern wrote:
> Jean:
>
> You might want to review some of the message in this thread on
> linux-usb-devel.
I personally never had hope of impacting the USB API one way
or another. I'm just glad that I managed to get ZERO_PACKET support in
it. At some point in 2.4.X I got all the timeout to work across all
HCD, but I guess that's now history...
At that point, I was fighting a crappy USB controller, and it
was easy to get dropped URBs. I don't have access to that hardware
anymore, and the overall quality of the HCDs has improved, so it may
no longer be an issue. But I must admit that dropped URBs is not
something the common driver authors seems to worry about, and anyway
is quite difficult to reproduce. That's why this issue pops up so
sporadically, even after all those years.
> Greg:
>
> You might want to read this thread (although I don't expect it to change
> your mind):
>
> http://marc.theaimsgroup.com/?l=linux-usb-devel&m=108476210111359&w=2
>
> Alan Stern
>
>
> On Tue, 24 Aug 2004, Greg KH wrote:
>
> > I count only 2 drivers, irda-usb and stv680. Both of them work just
> > fine on non-UHCI host controllers (tested them myself) and the code in
> > the driver does not rely on that timeout anyway.
The code in irda-usb is ultra defensive, it will take
advantage of the timeout if available (to recover faster), but doesn't
depend on it.
> > > Also, there is a proposal that's been lying around for a while to move the
> > > timeout functionality out of usb_control/bulk_msg() and into the core.
> > > Once that's done the timeout field will be perfectly functional, for all
> > > HCDs. I'd do it myself if I had the time available.
> >
> > We should judge that patch on it's own. I don't want to have fields
> > lying around that are documented as needed/working and yet they are not.
> > That's just wrong.
I guess there must be an upper bound on the time an URB is
pending in the HCD, or max number of retries, or any kind of watchdog,
to accomodate misbehaving hardware. I think it make sense to have this
watchdog configurable depending on the actual application (low latency
vs. high reliability).
I would not add an additional watchdog to the existing one, I
would just expose better the existing one.
I would say, because of the issue of synchronisation between
timers and URB processing, most driver authors would be better of
using a built in timer facility. This way, they don't have to think of
all the races between completion handler and timer handler, and
spinlocking all over the place.
Also, if you use a timer handler, you need to use
URB_ASYNC_UNLINK because timers don't have context, which means you
have to be careful when deconfiguring the device and removing the
module.
It's all manageable, and most driver authors will eventually
get it (after a few bug reports), however I believe the integrated
timer make for an easier API.
Have fun...
Jean
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
