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