usbatm : modprobe & rmmod

[Duncan Sands]

> > you can do plenty of tricks this way.  For example, suppose you have two
> > variants of the same modem with the same product ids (so you can only tell
> > them apart at bind time), but one of them supports iso endpoints and the
> > other does not.  Then you can register two usbatm_driver's with the same
> > product ids, say bulk_driver and iso_driver.  In the bulk driver's bind
> > routine you check if the modem can handle iso endpoints, and if so you
> > exit with an error code (contrarywise for iso_driver).  The USB subsystem
> > will then go on to probe other drivers, finally causing iso_driver to be used.
> How do we know the order in which the driver will be called. What happen 
> if we want handle both case : bulk_driver -> iso_driver and iso_driver 
> -> bulk_driver ?
> You need to put iso check in bulk_driver, and bulk check in iso driver, 
> instead of a generic code that check the characteristic of the device.

The check can be common code.  On the other hand, you might have to check twice,
but I doubt that matters.

> They could be different frame sizes for iso driver (7 for eagle-usb), if 
> one failed, we should try another one. So we need to register 7 drivers...

In this case you can surely just set the value of a variable in your private data.

> For me these hacks seem to show the rigidity of the api.

Correct.

Ciao,

Duncan.