-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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? - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAklrCOQACgkQOjLpvpq7dMr85QCfaH51DfZ0SD+zUJ59KKqxgWc5 NagAn2+W6ob6FLoFdWV32BkAYUndHez6 =cD44 -----END PGP SIGNATURE----- _______________________________________________ devel mailing list devel@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/devel
