Return-path: Received: from cavan.codon.org.uk ([93.93.128.6]:55077 "EHLO vavatch.codon.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752272AbYIPXcr (ORCPT ); Tue, 16 Sep 2008 19:32:47 -0400 Date: Wed, 17 Sep 2008 00:32:40 +0100 From: Matthew Garrett To: Larry Finger Cc: Carlos Corbacho , Adel Gadllah , wireless , bcm43xx-dev@lists.berlios.de, Michael Buesch , LKML Subject: Re: Regression in 2.6.27-rcX caused by commit bc19d6e0b74ef03a3baf035412c95192b54dfc6f Message-ID: <20080916233240.GA18574@srcf.ucam.org> (sfid-20080917_013251_534166_7D53CCC9) References: <48CFC03A.8020708@lwfinger.net> <200809161742.15527.mb@bu3sch.de> <48CFE820.7010305@lwfinger.net> <200809162018.28548.carlos@strangeworlds.co.uk> <48D0095B.40403@lwfinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <48D0095B.40403@lwfinger.net> Sender: linux-wireless-owner@vger.kernel.org List-ID: On Tue, Sep 16, 2008 at 02:30:35PM -0500, Larry Finger wrote: > I didn't say it was not possible. What I said is that _ONLY_ the > operator's finger could change the state, just like in your laptop. > Thus it makes absolutely no difference what state RFKILL thinks it is > in. Of course it makes a difference. The reason why two states are provided is to allow userspace to distinguish whether it can unblock the device or not. It's clear that b43's rfkill code is astonishingly broken (and that's not a criticism of anyone involved - the documentation's confusing and there weren't any good examples of how it should be implemented). The real question is how the LED state is supposed to be being toggled, and what that's got to do with rfkill. I /think/ that the current state of events is: 1) User toggles state 2) State toggle is used by b43 to generate KEY_WLAN (this is broken) 3) rfkill-input toggles the rfkill state, changing the LED state in the process What *should* be happening is: 1) User toggles state 2) b43 changes rfkill state (by using rfkill_force_state). The LED state should also be changed in the process. It looks like the commit in question gets part of the way to implementing the second of these situations, but will now change the rfkill state at the same time that rfkill-input tries to. I agree that it should be reverted for now, but because it's (a) broken (changing the state member directly is wrong) and (b) potentially open to strange states being generated by rfkill-input trying to change the state after it's already been changed. The general intent is correct. -- Matthew Garrett | mjg59@srcf.ucam.org