[PATCH] iso pipe support for usbatm
rkagan at mail.ru
Thu Mar 24 15:05:46 EST 2005
On Thu, Mar 24, 2005 at 06:56:18PM +0100, matthieu castet wrote:
> Roman Kagan wrote:
> >EOVERFLOW is reported when there was a babble (out-of-frame activity) on
> >the usb bus. Another indication of a hardware/firmware problem... Did
> yes, I told you that the modem don't seem to appreciate bulk transfert...
:) But it wasn't too fond of iso transfers as well, remembering the
-EILSEQ errors you reported, which might be of the same nature. You seem
to have tough hardware combination...
> >>>In case of error : status !=0 couldn't we add the buffer to the
> >>>spare_receive_buffers list ?
> >>or at least set buf->filled_cells to 0.
> >I thought urb->actual_length represented the amount of successfully
> >transferred data, i.e. in case of fatal error, 0. Thus ->filled_cells
> >would be set appropriately, so urb->status can be ignored. I'll go
> >recheck if this is true with the current hcd code.
> I is not the case if the EOVERFLOW error.
OK, does something like this help?
--- usbatm.c~ 2005-03-22 02:35:22.000000000 +0300
+++ usbatm.c 2005-03-24 22:59:27.000000000 +0300
@@ -276,7 +276,7 @@ static void usbatm_rx_complete(struct ur
struct usbatm_data *instance = rx->instance;
unsigned long flags;
- rx->filled_cells = urb->actual_length / (ATM_CELL_SIZE + instance->rx_padding);
+ rx->filled_cells = urb->status ? 0 : urb->actual_length / (ATM_CELL_SIZE + instance->rx_padding);
vdbg("usbatm_rx_complete: urb 0x%p, status %d, actual_length %d, filled_cells %u, rx 0x%p",
urb, urb->status, urb->actual_length, rx->filled_cells, rx);
More information about the Usbatm