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