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". - 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.) > Sure it's a hack. But, it is simple to explain to a user with the issue > in the meanwhile. Yup. I'm glad that we have a work-around at all. It's just not the end of the story. - Werner _______________________________________________ devel mailing list devel@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/devel
