usbatm : modprobe & rmmod

[Roman Kagan]

  Hi Matthieu,

On Tue, Jan 25, 2005 at 06:44:25PM +0100, matthieu castet wrote:
> >Does this mean the device mutates itself into a new device once some
> >firmware is loaded?
> When loading the first stage firmware yes :
> 
> Jan 23 17:31:41 localhost kernel: [eagle-usb] driver V2 loaded
> Jan 23 17:31:41 localhost kernel: usbcore: registered new driver eagle-usb
> Jan 23 17:31:49 localhost kernel: usb 2-1: new full speed USB device 
> using uhci_hcd and address 3
> Jan 23 17:31:49 localhost kernel: [eagle-usb] New pre-firmware modem 
> detected
> Jan 23 17:31:49 localhost kernel: [eagle-usb] Uploading firmware..
> Jan 23 17:31:49 localhost usb.agent[29685]:      eagle-usb: already loaded
> Jan 23 17:31:49 localhost kernel: [eagle-usb] Binding eu_instance_t to 
> USB 002/003
> Jan 23 17:31:50 localhost kernel: usb 2-1: USB disconnect, address 3
> Jan 23 17:31:50 localhost kernel: [eagle-usb] Pre-firmware modem removed
> Jan 23 17:31:52 localhost kernel: usb 2-1: new full speed USB device 
> using uhci_hcd and address 4
> 
> [...] 
> 
> 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.

Cheers,
  Roman.