All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.