WLAN and SPI: going native

[Werner Almesberger]

Andy Green wrote:
> We already mentioned it will reduce our patch footprint, but it will
> also enable getting that driver upstream

The driver itself still has quite a few issues. E.g., it has its own
"OS abstraction layer" that replaces regular kernel functions with
things that usually rename them and sometimes mess a little with their
semantics.

This makes it difficult to read the code, since you can never be quite
sure if something that looks familiar has indeed the same effect, e.g.,
who would have thought that an "A_MUTEX" is a spin lock ?

#define A_MUTEX_INIT(mutex)             spin_lock_init(mutex)

And, of course, such constructs would even make it harder to change
the code and one could easily introduce breakage that's almost
impossible to spot.

There's more, like a whole flow control system that probably just
duplicates other functionality found in the kernel.

Since Atheros are now reenforcing their Linux efforts, we'll have to
see how we (Openmoko) should proceed with that driver. But in any
case, whatever we do to improve the Linux SDIO stack and the drivers
underneath will also directly benefit the AR6k driver.

> and make it easier for others
> to use it with different SDIO peripheral unit.

In theory, my HIF change should already have accomplished this :-)

All I did in the last weeks was really fixing Linux SDIO on the
2442, without having to touch anything specific to AR6k. Of
course, I didn't know that HIF wasn't to blame until solving
the other problems.

- Werner