Hi, Werner Almesberger <[email protected]> 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 properly... > 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. Exactly. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:[email protected]
