clear_halt_work

Duncan Sands baldrick at free.fr
Fri May 6 05:20:14 EDT 2005


Hi Roman,

> As per David Brownell's comment, usb core only uses urb_list field in
> struct urb when it owns that urb, that is, since the call to
> usb_submit_urb() till the entry into the completion routine.  Outside of
> this scope, drivers are free to use it for whatever they want.  Thus we
> can get rid of struct usbatm_transceiver, and use struct urb directly
> instead.

let's wait until your patch moving the list_head to the public part is
accepted.

> The following patch does this.   In addition, I've simplified a bit the
> allocation of the array of urbs (formerly transceivers), merging it into
> the allocation of struct usbatm_data.  (Also the bits related to
> -EAGAIN has sneaked in, if you still disagree with those feel free to
> strip them away.)
> 
> The patch is briefly tested and doesn't appear to lead to any failures.

It can go in later.

> BTW shouldn't we set lower limits on the number of urbs and the buffer
> sizes?  I'm pretty certain the driver won't work with no urbs and/or
> with a zero length buffer.  OTOH upper limits are arbitrary and probably
> superfluous: we seem to handle out-of-memory conditions gracefully.

Zero urbs and buffers used to work fine - I used them for testing some
failure modes (I can't remember what exactly).  With the current setup
zero urbs is fine, but zero length buffers look problematic.  I put
in upper limits so (1) I'd never have to think about overflow when doing
arithmetic and (2) so users would have an idea as to what values are
worth trying.  I've committed a patch for the lower bound.

D.




More information about the Usbatm mailing list