linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Larry Finger <larry.finger@lwfinger.net>
To: Michael Buesch <mb@bu3sch.de>
Cc: bcm43xx-dev@lists.berlios.de,
	John Linville <linville@tuxdriver.com>,
	linux-wireless@vger.kernel.org
Subject: Re: [PATCH] b43: Simple 'fix' for radio switch LED regression
Date: Wed, 28 Nov 2007 10:18:53 -0600	[thread overview]
Message-ID: <474D94ED.6050403@lwfinger.net> (raw)
In-Reply-To: <200711281652.05627.mb@bu3sch.de>

Michael Buesch wrote:
> On Wednesday 28 November 2007 16:38:27 Larry Finger wrote:
>> Since addition of the rfkill callback, the LED associated with the off/on
>> switch on the radio has not worked because essential data in the rfkill
>> structure is missing. When that problem was fixed, difficulties in circular
>> locking surfaced. This patch fixes part of the regression in that the LED
>> is turned on if the radio switch is on at startup. Adding the code to toggle
>> the LED with the switch will be more involved and would likely miss the 2.6.24
>> window.
>>
>> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>> ---
>>
>> John and Michael,
>>
>> I was able to get the full functionality working, but with two significant
>> problems: (1) the LED toggled only with a switch off-on sequence, not with
>> each switch change and (2) the module would no longer unload cleanly due to
>> circular locking. I will be essentually off-line after today, and I hope that
>> this hack, which will make the LED appear to work correctly, can be pushed
>> into 2.6.24 as it is a fix, but has minimal code impact. Nearly all of the
>> changes are needed just to make the LED on routine available to startup.
>> Furthermore, I'm certain these changes will be needed when the complete fix
>> is available.
> 
> That completely shortcuts the "behaviour" logic.
> This patch trades one bug for another.
> It will get other people upset, because their LEDs don't work as expected anymore.
> 
> This is not a showstopper bug and there is no need to introduce dirty
> fixes that trade one bug for another.
> I'm pretty sure that this patch will break LEDs on my asus card. I didn't
> try that, though.

Please try the patch at least enough to see if it breaks the LEDs on your card. I don't think it
will. The reason that part was needed in the more complete code is that there is no key event to
turn the rfkill LED on otherwise.

I agree that this is not a showstopper, but it is annoying. It is, however, your call.

Larry

  reply	other threads:[~2007-11-28 16:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-28 15:38 [PATCH] b43: Simple 'fix' for radio switch LED regression Larry Finger
2007-11-28 15:52 ` Michael Buesch
2007-11-28 16:18   ` Larry Finger [this message]
2007-11-28 16:29     ` 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=474D94ED.6050403@lwfinger.net \
    --to=larry.finger@lwfinger.net \
    --cc=bcm43xx-dev@lists.berlios.de \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=mb@bu3sch.de \
    /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).