What is the proper way to turn wlan on/off? Other wlan questions.
fercerpav at gmail.com
Thu Dec 18 14:42:03 CET 2008
Werner Almesberger <werner at openmoko.org> writes:
> 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
Shouldn't iwpriv be used for device-specific settings? Why another utility?
> But that should do the same as SIOCGIWTXPOW with
> struct iw_param.disabled set.
So, are you suggesting to use this ioctl alone to turn wlan on/off? It
is supposed that a user wants to turn it off as completely as possible
for the maximum power savings.
>>> but recently a new driver was committed.
> A new driver ... where ?
Heh, "recently" was like month ago, introduce-gta02-pm-wlan.patch :)
>> 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.
Is it in correspondence with other devices in the wild? I mean,
userspace shouldn't be confused by any GTA-specific behaviour, it
should be the same as with any other WLAN drivers.
>> 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).
Aha, that clears the confusion. Should be documented somewhere
> 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".
Seems if userspace dares to reset WLAN, it should also take care of
producing a detection event itself.
>> 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.
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav at gmail.com
More information about the openmoko-kernel