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

[Dan Williams]

On Tue, 2008-06-03 at 10:37 -0400, Michail Bletsas wrote:
> libertas-dev-bounces at lists.infradead.org wrote on 06/03/2008 10:12:31 AM:
> 
> > On Mon, 2008-06-02 at 17:12 -0700, Brian Cavagnolo wrote:
> > > To update boot2, copy the boot2 and firmware images to /lib/firmware 
> and:
> > > 
> > > echo <boot2_image_name> > /sys/class/net/eth2/lbs_boot2
> > > echo <firmware_image_name> > /sys/class/net/eth2/lbs_fw
> > 
> > So why are we doing this with the driver, and not the userspace update
> > tool?  Marvell keeps wanting to do firmware update in the driver, and we
> > (David and I at least) keep saying no.  If there are issues that prevent
> > the userspace firmware update tool from working, then we need to fix
> > those issues.  Firmware updates from the driver were a disaster the
> > first time around, and I don't quite see how that may have changed this
> > time?
> > 
> > If you really want, the userspace tool can be rewritten in C.
> > 
> 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?

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

> This is low level hardware functionality that needs to be implemented in a 
> fail-safe manner. Out testing has showed that the driver/firmware method 
> (the driver just controls the memory updating code on the firmware) is 
> more robust than the userspace tool.

The original issue was that the driver needed to be told how to flash
using module parameters, which is just a non-starter.  A dynamic,
sysfs-based interface is quite a lot better; I'm willing to keep
discussing that solution.  But some questions:

1) is the interface extendable to flashing firmware on CF & SDIO 8385
and SD 8686 too?

2) does the patch handle resets and everything correctly, ie can I flash
the firmware and then immediately start using the device?  Can I also
stop using the device and flash the firmware on-demand without unloading
the driver?

Dan