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

Werner Almesberger werner at openmoko.org
Thu Dec 18 20:37:34 CET 2008

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
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

- Werner

More information about the openmoko-kernel mailing list