From: Michael Buesch <mb@bu3sch.de>
To: Larry Finger <Larry.Finger@lwfinger.net>
Subject: Re: [RFC V2] b43/legacy: port to cfg80211 rfkill
Date: Sat, 6 Jun 2009 11:38:02 +0200
Cc: Johannes Berg <johannes@sipsolutions.net>,
	linux-wireless@vger.kernel.org
References: <4a2961a7.RxVbjEA4JdOf01BF%Larry.Finger@lwfinger.net> <200906052338.05653.mb@bu3sch.de> <4A299E57.4020007@lwfinger.net>
In-Reply-To: <4A299E57.4020007@lwfinger.net>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Message-Id: <200906061138.02636.mb@bu3sch.de>
Sender: linux-wireless-owner@vger.kernel.org

On Saturday 06 June 2009 00:38:15 Larry Finger wrote:
> Michael Buesch wrote:
> > On Friday 05 June 2009 23:20:55 Larry Finger wrote:
> >> 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.
> 
> But in the current driver, turning the radio switch off only shuts
> down the radio. The rest of the interface is still up.

This is not what I'm talking about.
I was talking about bringing the device up just for the purpose of checking the bit.

> >>> 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.
> 
> An "unknown" state would be OK, but I don't know how to get the state
> of the switch to the rfkill system.
> 
> > 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.
> 
> 
> > +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.
> 
> I understand that this is the part that you do not like. I don't like
> it either, but unless we can read the switch-state bit, the interface
> will never come back up. I do not find rmmod/insmod a suitable
> recovery mechanism.

Huh? We cannot do a simple  ifconfig wlan0 up  anymore to bring the interface up?
Is that overridden by rfkill now?

-- 
Greetings, Michael.