From: Michael Buesch <mb@bu3sch.de>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Larry Finger <Larry.Finger@lwfinger.net>,
Adel Gadllah <adel.gadllah@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
wireless <linux-wireless@vger.kernel.org>,
bcm43xx-dev@lists.berlios.de
Subject: Re: Regression in 2.6.27-rcX caused by commit bc19d6e0b74ef03a3baf035412c95192b54dfc6f
Date: Wed, 17 Sep 2008 16:19:33 +0200 [thread overview]
Message-ID: <200809171619.33377.mb@bu3sch.de> (raw)
In-Reply-To: <20080916210920.GC16470@srcf.ucam.org>
On Tuesday 16 September 2008 23:09:20 Matthew Garrett wrote:
> Oh, hey, I suck. This one might stand a better chance of not falling
> over.
>
> diff --git a/drivers/net/wireless/b43/rfkill.c b/drivers/net/wireless/b43/rfkill.c
> index fec5645..991e318 100644
> --- a/drivers/net/wireless/b43/rfkill.c
> +++ b/drivers/net/wireless/b43/rfkill.c
> @@ -49,21 +49,18 @@ static void b43_rfkill_update_state(struct b43_wldev *dev)
> struct b43_rfkill *rfk = &(dev->wl->rfkill);
>
> if (!dev->radio_hw_enable) {
> - rfk->rfkill->state = RFKILL_STATE_HARD_BLOCKED;
> + rfkill_force_state(rfk->rfkill, RFKILL_STATE_HARD_BLOCKED);
> return;
> }
>
> if (!dev->phy.radio_on)
> - rfk->rfkill->state = RFKILL_STATE_SOFT_BLOCKED;
> + rfkill_force_state(rfk->rfkill, RFKILL_STATE_SOFT_BLOCKED);
> else
> - rfk->rfkill->state = RFKILL_STATE_UNBLOCKED;
> -
> + rfkill_force_state(rfk->rfkill, RFKILL_STATE_UNBLOCKED);
> }
I still thing that it is really wrong to check and change the software
rfkill state from within the _hardware_ rfkill state handler.
So let's say this handler sets the state to SOFT_BLOCKED. Who is going
to set it back to unblocked, if the user unblocks the radio?
We can turn the radio on/off from the mac80211 config callback. Possibly
we must tell rfkill about it (I'm not sure. I don't understand the API).
I think this is pretty hard to get right, actually. HW-block and SW-block
are two completely independent states in b43. You can HW-block and SW-block
the device at the same time. So one must make sure that at any time the rfkill
is in a sane state if _either_ HW-block or SW-block changes. Currently I think
we only change rfkill state if HW-block state changes. Which is wrong.
In the end, I do not care about this crap anymore.
Feel free to remove my copyright notice from that file and put yours in
there. So feel free to send any patch to the rfkill code to john, but please
handle any regressions resulting from it. If not, I will handle them by reverting
patches until it starts to work again. ;)
--
Greetings Michael.
next prev parent reply other threads:[~2008-09-17 14:19 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-16 14:18 Regression in 2.6.27-rcX caused by commit bc19d6e0b74ef03a3baf035412c95192b54dfc6f Larry Finger
2008-09-16 15:42 ` Michael Buesch
2008-09-16 17:08 ` Larry Finger
2008-09-16 19:18 ` Carlos Corbacho
2008-09-16 19:25 ` Michael Buesch
2008-09-16 22:37 ` Henrique de Moraes Holschuh
2008-09-17 14:26 ` Michael Buesch
2008-09-17 14:29 ` John W. Linville
2008-09-17 14:33 ` Michael Buesch
2008-09-16 19:30 ` Larry Finger
2008-09-16 23:32 ` Matthew Garrett
2008-09-17 2:33 ` Henrique de Moraes Holschuh
2008-09-17 2:52 ` Larry Finger
2008-09-17 13:23 ` John W. Linville
2008-09-17 20:07 ` [PATCH] rfkill: update LEDs for all state changes Henrique de Moraes Holschuh
2008-09-17 20:55 ` Larry Finger
2008-09-18 12:43 ` Henrique de Moraes Holschuh
2008-09-18 13:09 ` Larry Finger
2008-09-18 13:18 ` Henrique de Moraes Holschuh
2008-09-18 12:49 ` Ivo van Doorn
2008-09-17 14:22 ` Regression in 2.6.27-rcX caused by commit bc19d6e0b74ef03a3baf035412c95192b54dfc6f Michael Buesch
2008-09-17 14:50 ` Henrique de Moraes Holschuh
2008-09-17 15:28 ` Larry Finger
2008-09-17 15:36 ` Henrique de Moraes Holschuh
2008-09-17 15:47 ` Larry Finger
2008-09-16 19:51 ` Matthew Garrett
2008-09-16 20:34 ` Larry Finger
2008-09-16 21:09 ` Matthew Garrett
2008-09-17 14:19 ` Michael Buesch [this message]
2008-09-17 15:18 ` Henrique de Moraes Holschuh
2008-09-17 15:59 ` Michael Buesch
2008-09-17 20:51 ` Tomas Winkler
2008-09-18 13:16 ` Henrique de Moraes Holschuh
2008-09-16 20:44 ` Carlos Corbacho
2008-09-16 21:07 ` Larry Finger
2008-09-16 22:40 ` Henrique de Moraes Holschuh
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=200809171619.33377.mb@bu3sch.de \
--to=mb@bu3sch.de \
--cc=Larry.Finger@lwfinger.net \
--cc=adel.gadllah@gmail.com \
--cc=bcm43xx-dev@lists.berlios.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=mjg59@srcf.ucam.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).