usbatm : modprobe & rmmod

[matthieu castet]

Hi Duncan,

Duncan Sands wrote:
> 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?
> 
drivers/ide/setup-pci.c for the core
drivers/ide/pci/ for drivers

> 
>>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).
Yes, but it have to reparse the usb id, and this not clean as provided 
by driver_info.
>  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.
Yes but that will need lot's of bind function that differ from 2-10 
lines, so instead of doing lot's of bind function, I just want to be 
allowed to set a driver info.
Also from the actual model, that will need also separate id_table.

What I would like :
the usb_register is done by driver (he can use the driver_info for is 
own use)
then it call in the probe function 
usbatm_register(intf,&speedtch_driver); like pci-ide

Here you could : in probe function copy your driver_info 
usbatm_driver.driver_info or make several usbatm_driver structs and 
register the good one by looking at the driver_info (it is done like 
that in pci-ide).


Matthieu