linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Buesch <mb@bu3sch.de>
To: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	linux-wireless@vger.kernel.org
Subject: Re: [RFC V2] b43/legacy: port to cfg80211 rfkill
Date: Sat, 6 Jun 2009 11:38:02 +0200	[thread overview]
Message-ID: <200906061138.02636.mb@bu3sch.de> (raw)
In-Reply-To: <4A299E57.4020007@lwfinger.net>

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.

  reply	other threads:[~2009-06-06  9:38 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-05 18:19 [RFC V2] b43/legacy: port to cfg80211 rfkill Larry Finger
2009-06-05 19:01 ` Michael Buesch
2009-06-05 21:20   ` Larry Finger
2009-06-05 21:38     ` Michael Buesch
2009-06-05 22:32       ` Johannes Berg
2009-06-06  9:34         ` Michael Buesch
2009-06-06 17:38           ` Johannes Berg
2009-06-05 22:38       ` Larry Finger
2009-06-06  9:38         ` Michael Buesch [this message]
2009-06-06 17:38           ` Johannes Berg
2009-06-06 17:37         ` Johannes Berg
2009-06-06 17:44     ` Johannes Berg
2009-06-06 18:00     ` Michael Buesch
2009-06-07 12:55       ` Larry Finger
2009-06-06 17:42   ` Johannes Berg
2009-06-06 17:49     ` Michael Buesch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200906061138.02636.mb@bu3sch.de \
    --to=mb@bu3sch.de \
    --cc=Larry.Finger@lwfinger.net \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).