Paul Fertser wrote: > Shouldn't iwpriv be used for device-specific settings? Why another utility?
Don't look at me ;-) This is an Atheros thing. For now, we're actually trying to change as little in that driver as possible and only fix bugs, not clean it up. The chip has a very "heavy" firmware that implements lots of things you normally don't expect to control via iw* (e.g., traffic control), so I can understand why they didn't bother with "standard" controls for wildly non-standard functionality. > 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. It seems that there is no standard interface to power WLAN on or off. The Atheros-specific extension wmiconfig --wlan (or the corresponding ioctl) would be the closest thing to what you're looking for in terms of functionality, up to the point that any attempts to talk (ioctl) to the device fail while it is disabled. SIOCSIWTXPOW and rfkill are only concerned with the transmitter. So their nominal semantics do not include power reduction, even though their de facto semantics might. SIOCSIWTXPOW isn't implemented by all WLAN drivers, so it's not a "standard" interface either. Furthermore, it can be countermanded by other "standard" ioctls. This looks like a bug, but I have to check. rfkill, if implemented, would have clearer semantics with regard to what it takes to re-enable power. However, the rfkill documentation is quite clear on limiting the purpose of rfkill, so you should not consider it a general way to enter the lowest-power mode, even though it might do that on the AR6k. All the above are some sort of "standby". You can also use bind/unbind without suspend/resume, which gives you API-wise the behaviour of the device getting physically removed. So I think you need a device-specific solution anyway, where you might as well use bind/unbind if you want device removal or wmiconfig (or the AR6000_IOCTL_EXTENDED/AR6000_XIOCTRL_WMI_SET_WLAN_STATE ioctl) for now if you don't. (I'll write about whether we should support rfkill in the first place in a reply to Andy's mail in this thread.) > Heh, "recently" was like month ago, introduce-gta02-pm-wlan.patch :) Okay, you can just ignore that one ;-) This is not the mechanism you're looking for. > 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 think the only common denominator you would find is global suspend/resume, which doesn't really answer your question. We're doing fine in that case, so that's good. You could use bind/unbind also on their own, with the same effect as suspend/resume. The interface would be removed while the device is unbound. If you limit userspace to mean "wpa_supplicant", that may be your solution. - Werner
