speedtch usbatm.c,1.20,1.21 usbatm.h,1.13,1.14

[Roman Kagan]

On Tue, Apr 26, 2005 at 11:50:45PM +0200, Duncan Sands wrote:
>         if (unlikely(urb->status)) {
>                 /* throttle processing in case of an error */
>                 mod_timer(&channel->delay, jiffies + msecs_to_jiffies(THROTTLE_MSECS));
>                 if (urb->status == -EPIPE)              /* this one may be cleaned up at times */
>                         schedule_work(&channel->clear_halt_work);
>         }
> 
> >From the doc for usb_clear_halt:
> 
>  * This is used to clear halt conditions for bulk and interrupt endpoints,
>  * as reported by URB completion status.  Endpoints that are halted are
>  * sometimes referred to as being "stalled".  Such endpoints are unable
>  * to transmit or receive data until the halt status is cleared.  Any URBs
>  * queued for such an endpoint should normally be unlinked by the driver
>  * before clearing the halt condition, as described in sections 5.7.5
>  * and 5.8.5 of the USB 2.0 spec.
> 
> However it looks like you don't unlink the other urbs, and even the
> current urb can be rescheduled if the usb_clear_halt takes more than
> THROTTLE_MSECS (5 milliseconds).

My vague perception was that it was hcd which was supposed to unlink all
pending urbs on the stalled endpoint queue.  I'll check it out.

> It's not clear exactly what's meant
> by endpoint here - for the speedtch tx and rx are on the same endpoint,
> except that the in endpoint has the in bit set; does that count as the
> same endpoint?

I don't think so: the USB spec treats endpoints as uni-directional.  The
enpoint numbers (0x0 - 0xf) can be the same for both directions and are
distinguished by the bit #7; in Linux this bit is usually adjusted
according to the context, but the endpoint data, including queues, are
completely separate.

Cheers,
  Roman.