WLAN status update
andy at openmoko.com
Mon Jan 12 10:09:56 CET 2009
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
| Andy Green wrote:
|> It seems like it is turning off ieee80211 powersaving mode (the AP
|> beacon dropbox system) in order to have that kind of impact.
| You mean the synchronized wakeups ? Yes, it could be that.
|> I don't think rfkill itself has much expectation except to stop the
|> transmission action. It doesn't care how we're doing that or what
|> residual power is pulled at DC.
| The expectations are as follows:
| - explicitly, it has to be bullet-proof. rfkill attempts to achieve
| this reliability through simplicity (i.e., just "throw a switch"),
| but our interface to the firmware is way more abstract.
| - in the discussion on linux-wireless, Michael Buesch also mentioned
| that rfkill is expected to act "immediately".
Yeah I take it to mean when you return from the rfkill action, the
stopping of RF TX is done already. That sounds doable?
| - implicitly, rfkill is also not expected to mess up any other
| configuration, but the documentation doesn't state this (yet).
| This follows naturally if you assume that what you have is a simple
| switch, but if you don't, these are not trivial semantics. (I.e.,
| the closes thing the original Atheros code has, --wlan disable,
| does interfere with concurrent configuration.)
Well killing TX kills association, kills any connectivity lying around,
etc. It inherently affects everything on top of the network interface.
~ I think maybe we can just do it and the sky won't fall?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the devel