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

[Duncan Sands]

Hi Roman,

> Attached is the driver for USB ADSL modems based on the Conexant
> AccessRunner chipset using the recently introduced usb_atm
> infrastructure.  It was inspired by the current speedtch driver (and
> actually started up by s/speedtch/cxacru/g on it, so may have inherited
> its bugs :), and is based heavily on the cxacru bundle by Josep Comas
> (http://accessrunner.sourceforge.net/), hence the name (provided Josep
> doesn't object).

I've just started looking at the code, so don't take the following comments
too seriously!

(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.

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

(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?  Now, you could just say: don't create the ATM
device until after the firmware is loaded.  There are two problems with this: (1)
the ATM device won't turn up when the USB device turns up but at a later time; that
means that scripts (or humans) will have to wait for the device to be created; (2)
firmware loading may fail at probe time (because eg the firmware is on a partition
that hasn't been mounted yet); right now the driver handles this by trying to load the
firmware again when you open the ATM device - but if there is no ATM device then that
strategy needs to be replaced with something else, but what?  Another solution is
simply to load the firmware in the probe routine, but then (1) it may hold up the USB
subsystem for a long time, and (2) you still have the problem of it failing due to
firmware not being available yet (see above).

Any thoughts?

By the way, I plan to reorganise the usbatm infrastructure so more code can be shared.

Ciao,

Duncan.