usbatm : modprobe & rmmod
duncan.sands at math.u-psud.fr
Thu Jan 27 05:58:12 EST 2005
> > 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.
More information about the Usbatm