Re: [RFC V2] b43/legacy: port to cfg80211 rfkill

[Michael Buesch <mb@bu3sch.de>]

On Friday 05 June 2009 23:20:55 Larry Finger wrote:
> Michael Buesch wrote:
> > 
> > This is pretty silly behavior IMO. Just to bring it to the point:
> > We initialize a huge wireless MAC, PHY and Radio that consume several watts of power
> > just to poll a silly RF-kill bit.
> 
> That is what the driver already does.

No. If the device is down, then it _is_ down. There won't be an rfkill thing
trying to bring it up again although the interface is down.

> > We can't we just accept that the RF-kill status is unknown while the device is down?
> 
> The problem is that while the interface is down the switch status
> cannot be interrogated. If you try, you get a fatal SSB error. Thus
> the only way to bring it back up is to flip the switch, then
> rmmod/insmod the driver. If you want hardware rfkill to be one-way,
> then take Johannes's patch. We would save a little power by calling
> b43_wireless_exit() if we brought it up to test the switch, and the
> switch was still off. That would leave everything off most of the time.

Yeah well. We cannot read the rfkill status while the device is down. That is
a hardware limitation. I think we should _live_ with that limitation instead of
working around it by always keeping the device initialized.
Can't we teach the rfkill subsystem about an "unknown" state? Because that's what we're in.

> > I really do hate all that rfkill crap and I'm still refusing to sign off on anything that's
> > related to rfkill (like I did for the past year or so). If people want this merged,
> > somebody else maintain and sign it off, please.
> 
> I'm sick of rfkill as well and really detest the endless discussions
> that have taken place; however, I do want the stuff to work.

Yeah. But wasting huge amounts of power to keep polling a bit that's not even used
most of the time is not really what I like.

> 1. We switch to the cfg80211 rfkill and use this patch modified to
> turn the interface back off if the switch is still off.

+void b43_rfkill_poll(struct ieee80211_hw *hw)
 {
-       struct b43_wldev *dev = data;
-       struct b43_wl *wl = dev->wl;
+       struct b43_wl *wl = hw_to_b43_wl(hw);
+       struct b43_wldev *dev = wl->current_dev;
        bool enabled;
 
        mutex_lock(&wl->mutex);
        if (unlikely(b43_status(dev) < B43_STAT_INITIALIZED)) {
-               mutex_unlock(&wl->mutex);
-               return;
+               if (b43_wireless_core_init(dev)) {
+                       mutex_unlock(&wl->mutex);
+                       return;
+               }
        }

This is the part of the code which I really really really dislike.
Hell, just return a freaking error from b43_rfkill_poll(), if the interface
is down. If rfkill can't handle that, it should probably be taught to handle it.
Especially as there can be other errors as well, like memory allocation failures.

> 2. We continue to use the old rfkill mechanism. It works just fine,
> but this method runs the risk of the old method being deprecated and
> eliminated.

I agree that this is not really an option.

> 3. We get new callbacks that will only power down/up the radio when it
> is blocked. That saves a little power.

What is wrong with the current mechanism to power up the radio, if the interface is up
and powering it down if the interface is down? I think the power of the PHY/Radio should
not be affected by rfkill. It should work the other way around instead. Rfkill should
be tolerant to a radio that is down and simply live with an unknown switch state.

-- 
Greetings, Michael.