Interesting. I also see this with 9029dff1f370018665a6e2999632a34fd0518f4d,
gta02_moredrivers_defconfig, and my minimal rootfs built in February. So
user space is pretty much exonerated.

My session went as follows:

booted and everything looked fine

iwlist scan and iwconfig essid both worked

association with an unencrypted AP succeeded. DHCP failed, but that appears
to be a problem of that AP. (My laptop couldn't DHCP either.)

when I looked again a few minutes later, iwlist scan said "Interface doesn't
support scanning." and iwconfig shows a "blank" interface and an attempt to
set the ESSID yields "SET failed on device eth0 ; Input/output error."

unbind/bind did not solve the problem (!)

What's interesting is that unbind/bind only went as far as
mmc1: new SDIO card at address 0001
and didn't print any of the AR6k-specific messages.

startup shr-testing 22 april and wait until eth0 disappears from iwconfig/ifconfig

dbus call to change wifi policy to enabled

first issue: no wpa_supplicant is started (it's configured in /etc/network/interfaces), it seems as interfaces comes up so /etc/udev/scripts/network.sh ignores it and does not launch ifup, here a workaround is simple, but should be investigated.

There appear to be multiple problems with the wifi driver. I'm attaching a proposed patch to fix the kernel oops I just described (knjmokowifi hits that case). Now, knjmokowifi still doesn't work, but gets into a state where doing anything useful with iwconfig produces i/o errors, but no oops.

makes the driver unusable. Many programs that automatically set up the network do this, and end up hosing the driver.

Long version:
In the current driver, there are several variables that define the "readiness" of the driver. One of these is ar->arWmiReady. If this variable is FALSE, no wireless calls succeed (iwconfig, iwlist, etc). Currently, this variable is set to true only from ar6000_rx, NOT from ar6000_open.

When ar6000_init is called (during the module load or the kernel boot if ar6k is compiled-in), ar6000_rx ends up being called (not quite sure why) and this allows the driver to work. ar6000_close (ifconfig eth0 down) sets ar->arWmiReady to FALSE. However, a successive "ifconfig eth0 up" does NOT reset the ar->arWmiReady variable, and the driver stays in an unusable state. Reloading the kernel module allows the driver to work again.

ar6000_open needs to set up the variables to allow the driver to work. Is the author of the driver still around?

The driver does most of its initialization in ar6000_init(), which is called
when the module is loaded. Most of this initialization is undone by
ar6000_close(), called at "ifconfig down". Noteably, ar6000_open() does NOT
reinitialize the driver. Since this is the function called by "ifconfig up",
the driver is hosed by "ifconfig down; ifconfig up".

A potential fix is to castrate ar6000_close() so that the driver can still
work even if ar6000_open() doesn't do much. The cleanup still needs to
happen when the module is removed. I'm about to attach a patch that does
this. With this patch, the driver works and the automatic network scripts
work.

One obvious potential downside with this is that since we're no longer
cleaning up at "ifconfig down", an inactive driver can still use power
needlessly. I did some tests, and while I do see this extra power usage, it
looks like it's inconsequential:

All readings were made by using the built-in coloumb counter, and each
number is good to about +- 2mA. It looks like the missing cleanup code in
the modified version costs us about 3mA or 3% of the total power usage. If
this is the case, I would argue we have a fix. It also looks like we really
should unbind (echo "s3c2440-sdi" >
/sys/bus/platform/drivers/s3c2440-sdi/unbind) the driver when not in use,
since that's where the most of the power-savings lie. Do these numbers seem
reasonable?

The reasoning outlined at ​http://lists.openmoko.org/pipermail/openmoko-kernel/2009-March/009733.html is correct but the implementation is not. In my testing reverting this patch solves the reported problems (at the expense of exposing rfkill races of course). I propose to revert 9c4451ff31b937a478f3d3eabef30b71cbe12b12 (patch attached) and to declare we don't care about rfkill races unless somebody dedicated brings driver in a sane state first.