usbatm : modprobe & rmmod

matthieu castet castet.matthieu at free.fr
Tue Jan 25 12:44:25 EST 2005


Hi duncan,

Duncan Sands wrote:
> Hi Matthieu,
> 
> 
>>>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)
> 
> 
> if I understand right, the modem is not usable unless all three interfaces are
> grabbed, and moreover there needs to be coordination between the transmission of
> normal packets and transmission of firmware.  How does that work?  Do you just
> submit a firmware urb occasionally on the data endpoint?  What if the firmware
> bit comes between two urbs making up one data packet?  Or must data transmission
> be stopped until the new firmware is uploaded?  What triggers the need for new
> firmware?
On the interrupt endpoint, the modem sends request of the page it wants. 
Then the requested data is sent to the modem.
On the interface, there is two endpoint, one for ATM data(04), one for 
firmware data(02).
So yes for making it work you need interface 0 for the interrupt, 
interface 1 for sending firmware and interface 1 & 2 for atm data.

I:  If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=eagle-usb
E:  Ad=04(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=eagle-usb
E:  Ad=04(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=03(Int.) MxPS=  64 Ivl=1ms


> 
>>>(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
> 
> 
> What is the ioctl for?
It is for reseting the modem, sending the firmware, sending options for 
the modem (choice of modulation standard,...).
I know some could be implemented via sysfs or firmware_* but it will 
need to rewrite lot's of things. And I prefer done things by step.


> 
>>-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...
> 
> 
> Can you explain this please.
If I understand the new usbatm2, when heavy_init is finished, you have 
supposed to have a working device.
So if it depend from userspace, you need to wait the data you want.


> 
>>-need to register 2 usb driver in module_init : one for prefirmware 
>>device, one for postfirmware device via usbatm_register.
> 
> 
> Does this mean the device mutates itself into a new device once some
> firmware is loaded?
When loading the first stage firmware yes :

Jan 23 17:31:41 localhost kernel: [eagle-usb] driver V2 loaded
Jan 23 17:31:41 localhost kernel: usbcore: registered new driver eagle-usb
Jan 23 17:31:49 localhost kernel: usb 2-1: new full speed USB device 
using uhci_hcd and address 3
Jan 23 17:31:49 localhost kernel: [eagle-usb] New pre-firmware modem 
detected
Jan 23 17:31:49 localhost kernel: [eagle-usb] Uploading firmware..
Jan 23 17:31:49 localhost usb.agent[29685]:      eagle-usb: already loaded
Jan 23 17:31:49 localhost kernel: [eagle-usb] Binding eu_instance_t to 
USB 002/003
Jan 23 17:31:50 localhost kernel: usb 2-1: USB disconnect, address 3
Jan 23 17:31:50 localhost kernel: [eagle-usb] Pre-firmware modem removed
Jan 23 17:31:52 localhost kernel: usb 2-1: new full speed USB device 
using uhci_hcd and address 4


> 
>>-don't allow the use driver_option (give an example this evening)
Oooops, s/driver_option/driver_info

Well let's say there is 3 versions of the chipset, and 1 firmware for 
each chipset.

for one chipset there are more than one device.

So if you don't use the driver_info in the firmware code, you have to do 
  if and case comparing sid and pid. And the code could came quite ugly. 
Also when you had a new chipset, you have to modify code at different 
places.

Now if you could use the driver_info in usb_device_id, you could write
static const struct usb_device_id eu_ids[] =
{
     {  USB_DEVICE (EAGLE_VID, EAGLE_I_PID_PREFIRM), 
.driver_info=EAGLE_I|PREFIRM },
     {  USB_DEVICE (EAGLE_VID, EAGLE_I_PID_PSTFIRM), 
.driver_info=EAGLE_I|PSTFIRM },
     {  USB_DEVICE (EAGLE_VID, EAGLE_II_PID_PREFIRM), 
.driver_info=EAGLE_II|PREFIRM },
     {  USB_DEVICE (EAGLE_VID, EAGLE_II_PID_PSTFIRM), 
.driver_info=EAGLE_II|PSTFIRM },
     {  USB_DEVICE (EAGLE_VID, EAGLE_IIC_PID_PREFIRM), 
.driver_info=EAGLE_II|PREFIRM },
     {  USB_DEVICE (EAGLE_VID, EAGLE_IIC_PID_PSTFIRM), 
.driver_info=EAGLE_II|PSTFIRM }, 
                                       {  USB_DEVICE (EAGLE_VID, 
EAGLE_III_PID_PREFIRM), .driver_info=EAGLE_III|PREFIRM },
     {  USB_DEVICE (EAGLE_VID, EAGLE_III_PID_PSTFIRM), 
.driver_info=EAGLE_III|PSTFIRM },
     {  USB_DEVICE (USR_VID, MILLER_A_PID_PREFIRM), 
.driver_info=EAGLE_I|PREFIRM },
     {  USB_DEVICE (USR_VID, MILLER_A_PID_PSTFIRM), 
.driver_info=EAGLE_I|PSTFIRM },
     {  USB_DEVICE (USR_VID, MILLER_B_PID_PREFIRM), 
.driver_info=EAGLE_I|PREFIRM },
     {  USB_DEVICE (USR_VID, MILLER_B_PID_PSTFIRM), 
.driver_info=EAGLE_I|PSTFIRM },
     {  USB_DEVICE (USR_VID, HEINEKEN_A_PID_PREFIRM), 
.driver_info=EAGLE_I|PREFIRM },
     {  USB_DEVICE (USR_VID, HEINEKEN_A_PID_PSTFIRM), 
.driver_info=EAGLE_I|PSTFIRM },
     {  USB_DEVICE (USR_VID, HEINEKEN_B_PID_PREFIRM), 
.driver_info=EAGLE_I|PREFIRM },
     {  USB_DEVICE (USR_VID, HEINEKEN_B_PID_PSTFIRM), 
.driver_info=EAGLE_I|PSTFIRM },
     { }
};

and in the firmware loading code there is a trivial case.

For the eagle-usb driver it is only important for the first stage 
firmware, because they said they make second firmware compatible with 
all the chips. But there is 2 different firmware for pots and isdn modem 
(the difference is on subid if I remenber). So it isn't need when using 
it with usb_atm.
But other driver could need it, if the implementation of second stage 
firmware is done in driver, it could be needed.

> 
>>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.
> 
> 
> Do you mean "can remove the module"?  
I am speaking of hardware specific module.
With version 1, you could remove it even not all the connection are 
closed. But yes you could unplug the device and it is like you remove 
the module.
So ok for this one.


Matthieu




More information about the Usbatm mailing list