[PATCH] iso pipe support for usbatm

[Roman Kagan]

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);


  Roman.