updated patch with throttling

[Roman Kagan]

On Fri, Mar 25, 2005 at 02:26:43PM +0100, Duncan Sands wrote:
> On Fri, 2005-03-25 at 16:21 +0300, Roman Kagan wrote:
> > On Fri, Mar 25, 2005 at 01:51:28PM +0100, Duncan Sands wrote:
> > > mightn't you need to call usb_clear_halt somewhere?
> > 
> > Hmm, maybe...  On urb->status == -EPIPE.  BTW in the proposed change the
> > urb status is propagated to the tasklet, so it can do better handling of
> > completion errors too.  Most natural seems to be to update atm stats
> > (now we only update it on decoding errors), and probably do some
> > throttling too.
> 
> The big problem with usb_clear_halt is that it needs to be called
> in process context.  This may have a big impact on the design, which
> is why I'm mentioning it.

Then I would add a limit counter.  If we get this number of consecutive
usb errors (either on submission or on completion) then we just barf and
tell the user to wipe it out.  I guess it shouldn't influence overall
design too much.

Still I'd set this limit reasonably high, and leave the throttling in
place, in case the error is actually transient (e.g. usb bus is too busy
with other traffic).

Cheers,
  Roman.