Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

[Jean Tourrilhes <jt@bougret.hpl.hp.com>]

On Wed, May 14, 2003 at 06:06:36PM -0400, Jeff Garzik wrote:
> Jean Tourrilhes wrote:
> >	o get the latest airo.c fixes from CVS. This will hopefully
> >fix problems people have reported on the LKML.
> 
> please beg Javier to split up his patch.  He sends me a _huge_ patch 
> with tons of changes each time.  If I object to one thing, we spin in 
> another huge-patch loop... :/
> 
> Sending me 20, 50, 100 patches to the same file is ok.  Even encouraged.

	Javier is cc'ed.
	While we are on the subject : a few months ago, Javier added
support for MIC to the airo driver. It's basically crypto based on
AES. You refused to include that part in the kernel because crypto was
not accepted in the kernel.
	Fast forward : today we have crypto in the 2.5.X kernel. Does
this mean that you would have no objection accepting a patch from
Javier including the crypto part ?

> >	o get HostAP driver in the kernel. No consolidation of the
> >802.11 management across driver can happen until this one is in (which
> >is probably 2.7.X material). I think Jouni is mostly ready but didn't
> >find time for it.
> 
> yeah, there are many requests for this one

	By the way, the HostAP driver include crypto (currently only
RC4 for WEP). Same question, I hope you would not refuse the crypto
part of HostAP (which is mandatory because most PrismII firmwares are
broken and can't do basic WEP properly).

> >	o The last two drivers mentioned above are held up by firmware
> >issues (see flamewar on LKML a few days ago). So maybe fixing those
> >firmware issues should be a requirement for 2.6.X, because we can
> >expect more wireless devices to need firmware upload at startup coming
> >to market.
> 
> >	As this firmware business seems to me not a wireless specific
> >issue (see for example drivers/scsi/qlogicfc_asm.c or
> >drivers/atm/atmsar11.data), I would prefer a generic solution to that
> >problem, either saying it's OK to put firmware in the kernel (with
> >proper licensing) or providing working technical solutions.
> 
> 
> We need firmware upload, and, firmware _should_ be uploaded from userspace.

	Ok, so I ask it this way : currently the kernel include some
drivers containing some binary firmwares blobs which are linked
directly into the kernel/module (including networking). Does this mean
that you are going to remove those driver from the kernel ASAP ? Or
does this mean that the rule above only apply to wireless drivers ?
	Let's be logical and coherent here...

> All someone needs to do is actually write the code for their driver to 
> receive firmware from userspace, and the rest is easy.  A working 
> technical solution is obvious, it just needs interested parties to 
> implement.
> 
> We can upload firmware from initrd, if no boot device is available at 
> the time.

	Currently, it looks like every driver will use its own method,
which I guess is ok.

> 	Jeff

	Thanks !

	Jean