[linux-usb-devel] [RFC] Conexant AccessRunner ADSL USB modem driver

Roman Kagan rkagan at mail.ru
Tue Jan 11 02:02:16 EST 2005


Hi,

On Mon, 2005-01-10 at 17:44 +0100, Duncan Sands wrote:
> (1) cxacru_blocking_completion, cxacru_timeout_kill and cxacru_start_wait_urb
> will have to go.  I think Josep put them in because in linux 2.4 there was no
> way to cancel the generic versions in message.c on disconnect.  In 2.6 any urbs
> that are in flight when the device is disconnected are shot down automatically
> so this is no longer an issue.

Josep isn't guilty here, this stuff is all mine (he supported a set of
userspace tools similar to modem_run for speedtouch, and a patch to the
pre-2.6.10 speedtch.c which entered the new usb_atm.c).

The reason to add those functions was also different: I tried to make it
behave closer to the Windows driver, than Josep's tool.  Namely, upon
loading the firmware the modem is switched to the "cm" mode where it
responds to each message, with the first byte in the reply being the
same request code (one of cxacru_cm_request) as in the message to the
modem, and the second byte being the status code (one of
cxacru_cm_status).  According to the usbsnoop log, the Windows driver in
this mode

 a) accesses 0x01/0x81 endpoints via interrupt pipes (rather than bulk
pipes when loading firmware)

 b) submits with the sending urb with the request _after_ the receiving
urb to read the modem response to this request while, quite naturally,
the sending urb should complete before the receiving one

Neither a) nor b) is possible with the generics in message.c, so I added
the three functions you mentioned and the supporting data members to
struct cxacru_instance (buffers, urbs, completions and a semaphore for
the mutex).

> (2) What does the cm in cxacru_cm stand for?  I'd prefer a more self-explanatory
> version of the name.

It denotes that this function is used to send CM_REQUEST_* to the modem
and receive CM_STATUS_* back :)  The names of CM_* constants in turn
come from running "strings | grep '^CM_' | tac" on the Windows driver.
Presumably they've been put there for debugging purposes, which was
suggested by the Conexant driver for Linux distributed by some modem
vendors.  I suspect CM is to mean "command".  I'm not particularly
attached to this name, can change it to whatever looks more
comprehensible.

> (3) Setting the MAC address in cxacru_got_firmware.  This one worries me: we create
> the ATM device when the device is probed.  The firmware is loaded at some later time
> (in a kernel thread, because it would take too long for khubd).  At that point the
> MAC address is changed.  What if this change in the MAC address confuses user space
> tools or other parts of the kernel?

I can't judge right now if it's a problem for the ATM layer, I'll have
to take a closer look.  However the MAC address is unavailable until the
firmware is loaded anyway.

Cheers,
  Roman.




More information about the Usbatm mailing list