[PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
mbletsas at laptop.org
Tue Jun 3 13:49:25 EDT 2008
Dan Williams <dcbw at redhat.com> wrote on 06/03/2008 01:20:11 PM:
> On Tue, 2008-06-03 at 13:03 -0400, Michail Bletsas wrote:
> > Dan Williams <dcbw at redhat.com> wrote on 06/03/2008 11:26:21 AM:
> > > > >
> > > > It is not a matter of Python vs C.
> > > > The userspace tool is extremely awkward to use (since it requires
> > > > driver modules to be unloaded which in turn makes the
> > of
> > >
> > > How does it make the ID more difficult? What do we need besides the
> > > bcdDevice ID that tells us what boot2 version the device has? Is
> > > something more needed to find out if the device has larger EEPROM
> > > active antenna support perhaps?
> > It makes it more difficult because instead of network interfaces
> > eth1 etc), one ends up having to deal with USB ids.
> > In devices with multiple intefaces (an XO with an active antenna for
> > example), that is very confusing.
> This is fair; except that the network interface name is subject to
> change and you can't guarantee that eth0 will always be the same device
> unless you use something like udev rules to rename devices on the fly
> when they are plugged in based on the device's MAC address, which
> requires loading the driver first. The kernel has never had a guarantee
> about device ordering.
> So if you _really_ want to make sure you're updating the right device,
> then you get Marvell to start putting real serial #s into the USB
> interface's serial number slot instead of 0. My usb8388 says:
> bcdDevice 31.02
> iManufacturer 1 Marvell
> iProduct 2 MARVELL Wireless Device
> iSerial 0 <-------------------------
> bNumConfigurations 1
> that's the only way to guarantee that you're updating the device you
> want to update.
That's a good suggestion.
>From a practical perspective though, in XOs, the onboard interface is
always eth0 these days.
More information about the libertas-dev