usbatm : modprobe & rmmod

[matthieu castet]

Hi,

Duncan Sands wrote:
> Hi Roman,
> 
> 
>>On Tue, 2005-01-25 at 12:25 +0100, Duncan Sands wrote:
>>
>>>what do you want this flexibility for?  As far as I can see cxacru has no
>>>need for it.
>>
>>Exactly.  Frankly, cxacru even needs less than is provided by usbatm2.
>>I just tried to think a bit more generically, e.g. considering the cases
>>with multiple interfaces.
> 
> 
> by the way there are several different ways multiple interfaces can come into play:
> (1) an interface for transmit+receive, an interface for firmware loading, an
> interface for line state (like the speedtouch).  This fits fine into usbatm2,
> since there is basically a one-to-one correspondance (ATM device) <-> transmit/receive
> interface.
> (2) one interface for transmission, another for reception (like eagle-usb).
Well is more complicated for eagle-usb : one interface for receive 
data(bulk or iso), one for incoming message from the modem (statistic + 
request from the modem to send it another page of the firmware), one for 
sending data to the modem (ATM frame + firmware page requested)

the eagle-usb firmware is swapped in "PC" memory because it didn't 
enough memory for all the code...

So in this case the interface 1 (sending data) is share between usbatm 
and mini driver.


> I think this can be made to work fine with usbatm2 also: when bind is called on the
> first interface, it grabs the second interface too (usb_driver_claim_interface).
Actually don't work because well because need to access private data 
usb. Also when removing, disconnect will be call 3 times, and usbatm2 
don't support it...
> Unbind drops both interfaces (usb_driver_release_interface).  The only problem is
> that you need the struct usb_driver, but that's easy to arrange (just stick it in
> usbatm_data for instance).
well some time ago usb_driver_release_interface was used, but it was 
removed from eagle-usb(i don't know why, but i think it caused ooops). 
But it is not a real problem...

> (3) some other way I didn't think of.
> 
> As far as I can see, everything is fine (or can easily be made to be fine) with
> the usbatm2 setup.  Perhaps Matthieu can comment.
> 

Actually it have some problems :
-no ioctl
-pb with claim to other interfaces
-pb with atm start : the second stage firmware is load via userspace and 
ioctl, so I need to find a way to wait in heavy_init or see if we can 
safely start without second stage firmware.
wait_event_interruptible should do the job...
-need to register 2 usb driver in module_init : one for prefirmware 
device, one for postfirmware device via usbatm_register.
-don't allow the use driver_option (give an example this evening)

I think we should dissociate usb_device and usbatm device like done in 
pci-ide.

After that the two model are quite similar : the older do some init 
before registering and the newer does it in bind/atm_start function.

Also I like the idea that the refcount is on mini driver, so you can't 
remove the module, unless all atm connection are closed (I am not sure 
of this : I only look quickly) and don't like the idea of permanent module.

I have one remark for roman : in your clean method you clean things you 
init in probe : it is a bit strange.

Matthieu