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
