PRISM2_NON_VOLATILE_DOWNLOAD in kernel 2.6.14

[Pavel Roskin]

Hi, Jouni!

Quoting Jouni Malinen <jkmaline at cc.hut.fi>:

> > I can tell with all certainty that instability of the flash download
> > code is a myth.  Since that code was fixed in October 2003 in version
> > v0.1.0, I flashed dozens of cards, such as true PCI, miniPCI and PCMCIA
> > using hostap_pci, hostap_plx and hostap_cs drivers.  I've never had any
> > problems with flashing.
>
> I'm not that worried about instability of the implementation. However,
> it is still possible to break HFA3841-based cards in a way that is very
> difficult to recover from (requires hardware modifications).

One would need corrupt firmware for that, I believe.  I think prism2_srec is
really good at sanity checking.

> Because of
> this, I have not been pushing to make it easier to enable firmware
> upgrades. RAM download is suitable for most cases and the only real need
> I see for non-volatile download would be a device with very limited root
> file system (i.e., no room to store the firmware image).

Please consider systems where boot time is critical, and the CPU is slow.

Please consider cards with unstable firmware (primary 1.0.x in Prism 2.5,
secondary 0.6.2 for Prism 2) on systems that require high reliability.  Failure
to start up even in 1% of cases could be very bad for some applications.

> All other cases
> should be able to handle volatile downloads that are very unlikely to
> get the card in a state where recovery would not be an easy operation.

OK, I agree about _other_ cases :)

> > Please be advised that the CVS version of the hostap driver is broken
> > and crashes the kernel, as it was reported many times.  I think it
> > should be removed from CVS if it cannot be fixed.
>
> I haven't looked into the details of these reports yet. Are they for
> 2.6.14 or also for older versions? CVS version (i.e., 0.4.x) is not
> expected to support newer kernel versions (i.e., versions that include
> Host AP driver in the main kernel distribution). However, it is supposed
> to work with older versions.

I'll test it if I have time.  However, it's odd that the driver compiles and
crashes.  Normally, if a driver is too old for the kernel, it doesn't compile.

> I don't think the driver would be removed from CVS, but adding an #if
> block for case of kernel version being > 2.6.14 and #error to prevent
> building the CVS version would certainly be acceptable modification..

I understand your reluctance to maintain the driver in two places.  But I think
it's better to fix the CVS version to work with all kernels it compiles for. 
I'm not saying it should be in sync with the kernel version, it just shouldn't
crash.

You could add a #warning for the recent kernels.  As for the #error, future API
changes will take care of it one day :)

--
Regards,
Pavel Roskin