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

[Duncan Sands]

Hi Roman,

> > (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?
> 
> Changing the MAC address of a working device from userspace is allowed
> (see ip(8) link set DEVICE address LLADDR), so doing it here may also be
> fine.  However, having given it some thought, I now tend to believe that
> the right solution is to create the ATM device only when it's usable,
> i.e. after the firmware is loaded (and the MAC address is known).

I agree that it makes more sense to only create the ATM device when the modem is fully
initialised.

> > 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;
> 
> This is the common problem of using a device before it's ready.  The
> right answer to it is using hotplug.  This will require adding driver
> model support to ATM, though; class/atm or something like that.  I'll
> try to look at how easily this can be done.

In the short term we can work around using a clever USB hotplug script.  But yes, it would
be better if the ATM layer was fully integrated into the driver model.  Maybe Chas can tell
us more about that.  Also, I'm wondering if the driver model has any special stuff for
drivers belong to more than one subsystem (ATM, USB).

> >  (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?
> 
> I'd simply make sure that the firmware is available no later than the
> driver module itself is, and then let the hotplug/udev/initramfs people
> figure out how to handle staged system initialisation :)

I came to the same conclusion.

> (As a side note, on my machines I currently do /sys scan and
> coldplugging from within initramfs with minimal module set first, then
> mount the root filesystem with all the necessary stuff and repeat.  This
> may have issues, though).

Ciao,

Duncan.