Re: AR6k: to rfkill or not to rfkill ?

[Michael Buesch <mb@bu3sch.de>]

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.