usbatm : modprobe & rmmod

[Duncan Sands]

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.
This trick can also be used if you want the user to select between eg: iso
or bulk usage by setting to a sysfs attribute or something like that: just
check the value of the attribute in the bind routines and maybe fail.

Ciao,

Duncan.