Re: AR6k: to rfkill or not to rfkill ?

[Werner Almesberger <werner@openmoko.org>]

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