usbatm : modprobe & rmmod
castet.matthieu at free.fr
Tue Jan 25 08:36:45 EST 2005
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
> (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 :
-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
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.
More information about the Usbatm