What is the proper way to turn wlan on/off? Other wlan questions.

Werner Almesberger werner at openmoko.org
Thu Dec 18 14:11:19 CET 2008


Paul Fertser wrote:
> I'm a bit confused about the proper way to disable wlan. Currently,
> FSO uses SIOCGIWTXPOW ioctl

The Atheros way of disabling the WLAN module is with
wmiconfig -i eth0 --wlan disable

But that should do the same as SIOCGIWTXPOW with
struct iw_param.disabled set.

> but recently a new driver was committed.

A new driver ... where ?

> In any way eth0 is still present in iwconfig listing (is it
> a correct behaviour?).

Yes. The interface stays there as long as SDIO thinks the module
is physically present, which is almost all of the time, as long
as the modules are loaded.

> I actually tried using power_on sysfs node for wlan. After "echo 0 >
> power_on" wifi no longer operational, with "mmc0:0001: error -110
> reading SDIO_CCCR_INTx" error in dmesg. "echo 1 > power_on" doesn't
> change that, still the same error. But if i do "echo s3c2440-sdi >
> unbind; echo s3c2440-sdi > bind" in
> /sys/devices/platform/s3c2440-sdi/driver i can use wlan again.

What happens here is that by writing to slightly misnamed
power_on you force a hard reset of the WLAN module. This doesn't
trigger a detection event, so the SDIO driver is unaware of what
has happened and just notices that the module has stopped responding
(because it's now waiting for the SDIO bringup sequence).

I'm not sure if power_on should actually produce a detection event.
We've had troubled in the past with those low-level controls getting
too smart (in the case of GSM reset-to-upgrade-firmware), and it
would also be somewhat messy to feed this information into the stack
"from the outside".

> And, btw, while WiFi is operational, iwlist scan shows an obscure
> error message when there're no APs around. Is it a known issue?

The EAGAIN, accompanied by a printk complaining about data length 0 ?
I guess we should get rid of that one. It has its origin in a
mechanism that protects against confusion when access points are
added while retrieving the list, but that one's slightly botched
as well.

> Are there plans to implement rfkill interface to Wlan? Should FSO
> target it (as well as bluetooth's one)?

Sean McNeil has recently added rfkill for BT. I think it would make
sense to do the same for WLAN, yes.

> Andy, i can confirm that when wpa_supplicant is correctly associated
> with an AP, suspend/resume cycle results in correct automatic
> reestablishing of the connection.

Good news ! Thanks !

- Werner



More information about the openmoko-kernel mailing list