usbatm : modprobe & rmmod
castet.matthieu at free.fr
Mon Jan 24 16:44:51 EST 2005
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
> 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
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
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).
More information about the Usbatm