AR6k: to rfkill or not to rfkill ?

AR6k: to rfkill or not to rfkill ?

[Werner Almesberger]

In Openmoko, we're wondering whether we should make the Atheros AR6k
driver register as an rfkill controller or not, and if we do it,
what semantics this should have. I'm looking for advice here.

The issue is that there's no real rfkill hardware in the sense of a
simple switch that cuts power to the transmitter. At least nothing
like this is visible from the kernel. Instead, there is a "fat" and
opaque firmware in the module that decides on such low-level actions
on its own.

There are currently two mechanisms which would fall into the domain
of WLAN APIs that control three operations:

- the possible operations are
  1) associate/de-associate with access point
  2) scan for access points
  3) return -EIO when attempting WLAN ioctls

- when 1) and 2) are applied together, the transmitter is supposed
  to be silent

- the mechanisms present so far are
  1) SIOCSIWTXPOW
  2) an Atheros-specific ioctl (AR6000_IOCTL_EXTENDED, sub-function
     AR6000_XIOCTRL_WMI_SET_WLAN_STATE)

- both mechanisms de-associate and stop scanning
- in the case of SIOCSIWTXPOW, setting the ESSID will re-associate
- in the case of AR6000_XIOCTRL_WMI_SET_WLAN_STATE, most ioctls will
  return -EIO until another AR6000_XIOCTRL_WMI_SET_WLAN_STATE is
  issued that re-enables WLAN

So, first of all, given that TX power is controlled only indirectly
anyway, should we implement rfkill control or not ? There is no kill
switch, so there would be no rfkill input.

If the answer is "yes", would the following semantics be right for
the disabled state ?

- we de-associate
- we stop scanning
- all ioctls still work as usual, but they have no effect on
  association and scanning until rfkill re-enables the device

Thanks,
- Werner

Re: AR6k: to rfkill or not to rfkill ?

[Michael Buesch]

On Thursday 18 December 2008 22:22:34 Werner Almesberger wrote:
> So, first of all, given that TX power is controlled only indirectly
> anyway, should we implement rfkill control or not ? There is no kill
> switch, so there would be no rfkill input.
> 
> If the answer is "yes", would the following semantics be right for
> the disabled state ?

I think you should probably implement it.
Rfkill is supposed to be a central place for userspace to turn the radios
off. So if your radio doesn't register an rfkill device, it will result in
inconsistent userspace state. Userspace (network manager, or whatever app)
thinks that it disabled all radios, but it didn't, in fact.

So yes, I think you should implement rfkill by stopping any TX actions
immediately if it hits. The state callback would simply be emulated in software.

> - we de-associate

Rfkill is supposed to stop TX _immediately_.
So no MAC cleanup, etc...

> - we stop scanning
> - all ioctls still work as usual, but they have no effect on
>   association and scanning until rfkill re-enables the device

basically, yes.


Note that current rfkill subsystem implementation is not that nice and you
might get some headache from it. ;)

-- 
Greetings, Michael.

Re: AR6k: to rfkill or not to rfkill ?

[Werner Almesberger]

Michael Buesch wrote:
> I think you should probably implement it.

Okay, thanks for the explanation !

> Rfkill is supposed to stop TX _immediately_.
> So no MAC cleanup, etc...

Hmm, I'll have to measure how quick this really gets. All this happens
in the "black box" that is the firmware. A few ms for sure, already
for SDIO communication. Hopefully faster than hundreds of milliseconds.

> Note that current rfkill subsystem implementation is not that nice and you
> might get some headache from it. ;)

Ah, that'll be the least of my worries :-)

Thanks,
- Werner

Re: AR6k: to rfkill or not to rfkill ?

[Michael Buesch]

On Friday 19 December 2008 00:59:16 Werner Almesberger wrote:
> Michael Buesch wrote:
> > I think you should probably implement it.
> 
> Okay, thanks for the explanation !
> 
> > Rfkill is supposed to stop TX _immediately_.
> > So no MAC cleanup, etc...
> 
> Hmm, I'll have to measure how quick this really gets. All this happens
> in the "black box" that is the firmware. A few ms for sure, already
> for SDIO communication. Hopefully faster than hundreds of milliseconds.

Yeah, it doesn't really matter, if it's within, say 100-200ms.
I just wanted to say, you should not _generate_ new traffic (disassoc, etc..)
if you get a kill signal. Instead you should immediately drop any connection
and kill the radio.

> > Note that current rfkill subsystem implementation is not that nice and you
> > might get some headache from it. ;)
> 
> Ah, that'll be the least of my worries :-)

My head is still burning for over the last couple of months. ;)

-- 
Greetings, Michael.

Re: AR6k: to rfkill

[Andy Green]

Somebody in the thread at some point said:

> In Openmoko, we're wondering whether we should make the Atheros AR6k

Let me put that simpler for you Werner :-)

"In Openmoko" we already use the nice rfkill interface to turn our USB 
bluetooth device on and off... it certainly stops RF emissions from it.

Now we plan to do the same for our AR6001 implementation... it has no 
switched power to the module, it is "always on".  It seems the only way 
to get it to a low power state is an IOCTL that currently needs to be 
set by a userspace app.

In the same manner as we switch bluetooth, I have asked Werner to write 
a patch that will use rfkill to issue the IOCTL to switch the AR6001 
into low power / no RF mode.

Does that raise any eyebrows?

-Andy

Re: AR6k: to rfkill

[Michael Buesch]

On Thursday 18 December 2008 23:28:43 Andy Green wrote:
> Somebody in the thread at some point said:
> 
> > In Openmoko, we're wondering whether we should make the Atheros AR6k
> 
> Let me put that simpler for you Werner :-)
> 
> "In Openmoko" we already use the nice rfkill interface to turn our USB 
> bluetooth device on and off... it certainly stops RF emissions from it.
> 
> Now we plan to do the same for our AR6001 implementation... it has no 
> switched power to the module, it is "always on".  It seems the only way 
> to get it to a low power state is an IOCTL that currently needs to be 
> set by a userspace app.
> 
> In the same manner as we switch bluetooth, I have asked Werner to write 
> a patch that will use rfkill to issue the IOCTL to switch the AR6001 
> into low power / no RF mode.
> 
> Does that raise any eyebrows?

Is the wireless kernel driver a binary blob?

-- 
Greetings, Michael.

Re: AR6k: to rfkill

[Andy Green]

Somebody in the thread at some point said:
> On Thursday 18 December 2008 23:28:43 Andy Green wrote:
>> Somebody in the thread at some point said:
>>
>>> In Openmoko, we're wondering whether we should make the Atheros AR6k
>> Let me put that simpler for you Werner :-)
>>
>> "In Openmoko" we already use the nice rfkill interface to turn our USB 
>> bluetooth device on and off... it certainly stops RF emissions from it.
>>
>> Now we plan to do the same for our AR6001 implementation... it has no 
>> switched power to the module, it is "always on".  It seems the only way 
>> to get it to a low power state is an IOCTL that currently needs to be 
>> set by a userspace app.
>>
>> In the same manner as we switch bluetooth, I have asked Werner to write 
>> a patch that will use rfkill to issue the IOCTL to switch the AR6001 
>> into low power / no RF mode.
>>
>> Does that raise any eyebrows?
> 
> Is the wireless kernel driver a binary blob?

No, Openmoko won't have anything to do with in-kernel binary blobs. 
There is binary firmware in it in flash though.

It's not very kernel style C:

http://git.openmoko.org/?p=kernel.git;a=tree;f=drivers/ar6000;h=ab7abd9222054919a3cd0ce6ecbec64b6057cbed;hb=andy-tracking

-Andy

Re: AR6k: to rfkill

[Michael Buesch]

On Thursday 18 December 2008 23:44:19 Andy Green wrote:
> Somebody in the thread at some point said:
> > On Thursday 18 December 2008 23:28:43 Andy Green wrote:
> >> Somebody in the thread at some point said:
> >>
> >>> In Openmoko, we're wondering whether we should make the Atheros AR6k
> >> Let me put that simpler for you Werner :-)
> >>
> >> "In Openmoko" we already use the nice rfkill interface to turn our USB 
> >> bluetooth device on and off... it certainly stops RF emissions from it.
> >>
> >> Now we plan to do the same for our AR6001 implementation... it has no 
> >> switched power to the module, it is "always on".  It seems the only way 
> >> to get it to a low power state is an IOCTL that currently needs to be 
> >> set by a userspace app.
> >>
> >> In the same manner as we switch bluetooth, I have asked Werner to write 
> >> a patch that will use rfkill to issue the IOCTL to switch the AR6001 
> >> into low power / no RF mode.
> >>
> >> Does that raise any eyebrows?
> > 
> > Is the wireless kernel driver a binary blob?
> 
> No, Openmoko won't have anything to do with in-kernel binary blobs. 
> There is binary firmware in it in flash though.

Ok, it just sounded like this, because you were talking about ioctl and stuff...

So if you receive a kill event, just send the command that puts the device into
low power state to the device. I think that's perfectly fine.

-- 
Greetings, Michael.

Re: AR6k: to rfkill

[Andy Green]

Somebody in the thread at some point said:

>>>> In the same manner as we switch bluetooth, I have asked Werner to write 
>>>> a patch that will use rfkill to issue the IOCTL to switch the AR6001 
>>>> into low power / no RF mode.
>>>>
>>>> Does that raise any eyebrows?
>>> Is the wireless kernel driver a binary blob?
>> No, Openmoko won't have anything to do with in-kernel binary blobs. 
>> There is binary firmware in it in flash though.
> 
> Ok, it just sounded like this, because you were talking about ioctl and stuff...
> 
> So if you receive a kill event, just send the command that puts the device into
> low power state to the device. I think that's perfectly fine.

That's what I figured... Okie Werner, look forward to your patch.  Sorry 
for the noise.

-Andy

Re: AR6k: to rfkill or not to rfkill ?

[Henrique de Moraes Holschuh]

On Thu, 18 Dec 2008, Werner Almesberger wrote:
> In Openmoko, we're wondering whether we should make the Atheros AR6k
> driver register as an rfkill controller or not, and if we do it,
> what semantics this should have. I'm looking for advice here.

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?

If the answer is no, you are not to add an rfkill controller. It is that
simple (at least with the current rfkill core).

If the answer is yes, then you can consider adding an rfkill controller.

> If the answer is "yes", would the following semantics be right for
> the disabled state ?
> 
> - we de-associate
> - we stop scanning
> - all ioctls still work as usual, but they have no effect on
>   association and scanning until rfkill re-enables the device

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.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: AR6k: to rfkill or not to rfkill ?

[Werner Almesberger]

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

Re: AR6k: to rfkill or not to rfkill ?

[Henrique de Moraes Holschuh]

On Mon, 22 Dec 2008, Werner Almesberger wrote:
> 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 Atheros gives you the magic needed to ensure it won't emit energy,
you're all set :)

> 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

It has not been specified yet, AFAIK.  Other than the fact that the
rfkill status for the core is not to be confused with other device
status that could cause it to stop transmitting (like tx power), so it
needs to be tracked separatedly.

> 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 ?

I suggest that you guys should get together and define these
requirements, and then add it to the rfkill.txt documentation, so that
user experience can be enhanced...

> 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).

IMHO, that is an easy one: if you accepted any config changes in the
first place, they are what should be used.  Less surprise path for the
user and all that.

> 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.

I think that's the proper way to go about it, yes.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh