usbatm : modprobe & rmmod

matthieu castet castet.matthieu at free.fr
Thu Jan 27 05:38:15 EST 2005


Duncan Sands wrote:
> Hi Roman,
> 
> 
>>>Now if you could use the driver_info in usb_device_id, you could write
>>>static const struct usb_device_id eu_ids[] =
>>>{
>>>    {  USB_DEVICE (EAGLE_VID, EAGLE_I_PID_PREFIRM), 
>>>.driver_info=EAGLE_I|PREFIRM },
>>>    {  USB_DEVICE (EAGLE_VID, EAGLE_I_PID_PSTFIRM), 
>>>.driver_info=EAGLE_I|PSTFIRM },
>>>[...]
>>
>>Then I'd rather do two subdrivers with two separate usb_device_id tables
>>in one module, first for the prefirmware devices, with empty
>>.atm_{start,stop} methods and a .heavy_init method uploading firmware
>>and returning failure (so that usbatm_atm_start isn't called), and
>>second for the postfirmware devices with nontrivial .atm_start and
>>without .heavy_init.
>>
>>Both subdrivers would be registered with usbatm in module init, and when
>>a modem is probed and matched against the prefirmware device table, the
>>prefirmware subdriver would be called to load the firmware without
>>creating an ATM device.  Then the modem would change its personality,
>>the prefirmware device would disconnect and the postfirmware device
>>would call the postfirmware subdriver.
> 
> 
> 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.

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...

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

Cheers,

Matthieu



More information about the Usbatm mailing list