Henrique de Moraes Holschuh wrote: > There is one screening rule that does help: > > Is that a way you can program the device that *ENSURES* without any doubt, > that it will never emit energy off the transmitter? Heh, I knew there would be a catch :-) All the magic happens in the firmware black box on the module. I'll ask Atheros if it's really safe or if there's perhaps a better way to do this. > If your rfkill controller has been set to "block the radio", you must NOT > allow any energy to be emmited by the transmitter. This is all that > matters. Hmm, so are you saying that the behaviour of the device is unspecified while rfkill is blocking ? That's not the impression I got from reading Documentation/rfkill.txt E.g., if I rfkill the transmitter and then user space issues an ioctl, say, to set the ESSID, is it okay if the ioctl fails because rfkill is in force ? Continuing the above example, once rfkill unblocks the transmitter, should the device's state reflect any configuration changes made while the transmitter was shut down ? I.e., in the example, the MAC would use the new ESSID (as opposed to the previous one or perhaps even having been reset completely). What I'm currently doing is to add yet another layer of blocking (on top of SIWTXPOW and the Atheros-specific AR6000_XIOCTRL_WMI_SET_WLAN_STATE), transparent to the others, and then decide on the combined state what needs to be done when unblocking, plus plug the holes created by a few other ioctls that could also cause the MAC to unblock behind our back. Thanks, - Werner -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
