usbatm : modprobe & rmmod

[matthieu castet]

Hi,

Duncan Sands wrote:
> Hi Roman,
> 
> For me, the new approach was always about viewing speedtch, cxacru etc as
> "mini-drivers" that register themselves with the usbatm core.  Since I never
> explained that (except to David on IRC), you couldn't be expected to know :)
> Also, the other thing I wanted to copy from usbnet was the trick of using the
> struct usb_device_id driver_info field to provide a light-weight way of registering
> mini-drivers.  I initially copied the usbnet static registration because (1) it
> was quicker to do it that way, and (2) I couldn't really see the point of making
> each mini-driver into its own module.  I was wrong about (2), and agree now that
> having each guy as its own module and doing dynamic registration is better than
> doing static registration.  However, since I always knew that flipping between static
> and dynamic schemes was trivial (as proved by the rather small patch to do it), this
> was always a minor issue to me.  As I said to David on IRC, I think you and he were
> repelled by the "huge heap of crud in a file" nature of usbnet, while missing the
> nice mini-driver aspect and the simple registration scheme (i.e. the driver_info trick,
> which is a bit hacky IMHO, but simple).
> 
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 ?
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).

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.


Matthieu