ipw(4) driver

[Joerg Sonnenberger]

On Tue, Nov 09, 2004 at 09:08:13PM +0100, Damien Bergamini wrote:
> | > - For the driver to work, some external firmware from INTEL is 
> needed,
> | >   that has licensing issues. Damien is trying to resolve this 
> problem.
> 
> We tried to make Intel release their firmware under a less restrictive
> license but Intel finally said no:
> http://monkey.org/openbsd/archive/misc/0411/msg01185.html

Hm. This is bad. As I read the LICENSE file of the ipw-firmware,
the only problem is EXHIBIT "A", point 2. If they would remove that one,
I think we could live with the rest.

> | There's one important
> | point I want to discuss publically before commiting. How do we want to
> | handle the firmware? I personally prefer the way e.g. wi(4) handles 
> the
> | firmware with directly embedding it into the kernel module / kernel 
> image.
> | This simplifies the code a lot and with minor modifications would 
> allow us
> | to support e.g. diskless operation.
> 
> I don't think the firmware licensing actually permits this. Moreover,
> firmware images are huge (three images for ipw, about 120KB each one).
> You obviously don't want this to be statically linked in the kernel!

Well, 120 KB is not that much. The symbol firmware for wi(4) is 70kb
for comparision.

> 
> | The disadvantage is that for now, the user has to manually build the 
> driver
> | after putting the firmware in some known location.
> 
> No. The firmware is "sent" to the driver by ipwcontrol using a special 
> ioctl.

Yes, I know. I read the driver and to be precise I don't like that part
at all. IMO iwi_init does too much work which belongs either into
iwi_attach or iwi_resume.

BTW, there's a race in the attach code. If the interrupt assigned to
iwi(4) is really shared, iwi_intr can actually be called. This could lead
to corruption and other bad things.

[skip part about how to get firmware images]
> | The third option would be a general firmware framework, but I'm not 
> sure if
> | it is that useful.
> 
> A more general framework for loading firmwares would be good but the 
> current
> implementation based on ioctl is quite flexible according to me. And 
> it's
> only a few lines of code in if_ipw.c and if_iwi.c

One reason to not like the ioctl interface is that it's adding even
more driver specific configuration programs. wicontrol is now general
program for the many 802.11 devices, it has grown over it's initial use.

E.g. the SIOCGTABLE0 and SIOCGRADIO can be better handled with a sysctl
handler, I'll start writing some support code for it soon.

Joerg

> 
> --
> Damien
> damien at xxxxxxxxxxx