[PATCH] finish iso support

Duncan Sands duncan.sands at math.u-psud.fr
Wed Jun 29 16:06:10 EDT 2005


Hi Matthieu, first of all I should say that I'm not against having an
explicit "iso" flag, in fact I think it's likely better than doing some
kind of autodetection based on the endpoint.  I just wanted to hear your
reasons.

> > (1) modify the struct usbatm_driver in the bind() call, setting the right
> > endpoint (in order for this to work properly, usbatm should use a copy of
> > the original struct usbatm_driver, but that's easy to arrange).
> Weren't you reluctant to split the initialisation in 2 parts (That was 
> how Roman did it,
> but you strip this from his patch)?
> affect instance->rx_channel.endpoint before bind call and do urb init 
> after bind call.

I forget how Roman did it, but this is better because I thought of it :)

> Also actualy struct usbatm_channel is "private data", I find it was a 
> bit ugly to declare
> it public data and let's the driver acces it.

Well, the usbatm core could detect the type based on the endpoint (the minidriver
would have to set the right altsetting), and set the channel accordingly.

> > (2) supply usbatm_usb_probe with different values for struct usbatm_driver.
> > 
> What different values should I supply ?

Endpoint for bulk vs endpoint for iso.  You would also need to choose the
altsetting at this point.

> With the current values in struct usbatm_driver there no way to know if 
> we want iso or bulk.

Well it could detect it automagically.

> That's why I add a new value use_iso in struct usbatm_driver.

In any case, I think it would be convenient if minidrivers could modify
their struct usbatm_driver in the bind() call.

Ciao,

D.



More information about the Usbatm mailing list