[PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware

[Dan Williams]

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 the 
> > > driver modules to be unloaded which in turn makes the identification 
> 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 there
> > something more needed to find out if the device has larger EEPROM for
> > active antenna support perhaps?
> 
> It makes it more difficult because instead of network interfaces (eth0, 
> 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.

> > 
> > > devices on the XO even more difficult) and it bricks wireless modules 
> > > while the driver method doesn't. So the statement that "firmware 
> updates 
> > > from the driver were a disaster" is simply not true.
> > 
> > It bricks the modules because the only people with the access to the
> > docs and firmware (Marvell) didn't try to debug the issue, or correct
> > the tool.  There's only so much _I_ can do without access to the
> > firmware source itself if other people who have the info aren't really
> > jumping on these problems, when I don't have the info.
> 
> Marvell already has a working method. Are you suggesting that they are 
> obliged to support yours on top of theirs?

They are obliged to work with the upstream community to find a solution
that works for everyone, not just their customers.  The solution they
originally had didn't work for us (upstream or OLPC), and thus we
developed the userspace flash tool.  Now that CozyBit/Marvell have taken
a different, better approach we can restart the discussions around it.

Personally, I don't particularly care either way.  The userspace flash
tool does have some benefits, specifically that you don't have to load
the driver before you flash the device, because the patch that's been
posted will only allow the firmware to be flashed after the driver has
been bound and potentially started the device, loaded the original
firmware, and turned on the radio.

Dan