usbatm : modprobe & rmmod

[Duncan Sands]

Hi Matthieu,

> Ok, now the new model look saner and is quite similar than pci-ide (same 
> problem where pci~usb and ide~atm) ;)
> 
> I have still one complain : why driver info is still used ?
> why not doing like pci-ide and give when registering struct 
> usbatm_driver and usb_interface ?

I don't know anything about pci-ide.  Where should I look in the kernel tree?

> Also you need to provide a driver info in your struct usbatm_driver, for 
> the drivers that need it (a chipset could have different revision and 
> need loding a different firmware).

I don't understand what you mean here.  The minidriver can detect the revision
or anything else it wants in bind, and store it in its own private data (which
it can store in usbatm_data).  Then in the firmware loading part it can look
up that value (or the firmware loading bit can simply find out the revision
for itself).  If you want different usbatm_driver structs for devices with
different USB ids, then you can just register several different usbatm_driver
structs.

> Also I don't understand the difference between bind & usbatm_atm_init 
> and atm_stop & unbind.
>
> usbatm_atm_init could be done in bind if there is no heavy_init or in 
> heavy_init.
> 
> atm_stop could be done in unbind.

Yes, if there is no heavy_init.  These methods are clearly needed if there is
a heavy_init, and I prefer to have the no-heavy-init and heavy-init cases be
as similar as possible.  I don't see that it hurts to have them both.  You
could also do all the bind stuff in atm_start by the way, and drop bind.

Ciao,

Duncan.