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.
next prev parent 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).