On Tuesday 16 September 2008 23:09:20 Matthew Garrett wrote:
quoted text
> 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.
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/