From: "Michael Büsch" <m@bues.ch>
To: Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
Cc: Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
b43-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH RFC] b43: stop hardcoding LED behavior
Date: Mon, 25 Apr 2016 17:53:26 +0200 [thread overview]
Message-ID: <20160425175326.407eba27@wiggum> (raw)
In-Reply-To: <1461570051-3950-1-git-send-email-dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3183 bytes --]
On Mon, 25 Apr 2016 09:40:51 +0200
Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org> wrote:
> On my system the SPROM correctly defines the only wired LED (radio) but
> skips all others, leading to the hardcode to register LEDs with RX and TX
> triggers.
Hm ok. It probably is a good idea to change the condition from
if (sprom[led_index] == 0xFF)
to
if ((sprom[0] & sprom[1] & sprom[2] & sprom[3]) == 0xFF)
So the hardcoding only happens if there is no LED configured in the
SPROM. (I think my card does this (see below), but I can check that
later)
> These triggers cause many uneccesary CPU wakeups to drive LEDs
> that aren't even present in the system, reducing battery runtime.
Numbers please. Did you measure that is actually causes more _wakeups_?
How many?
The led work is placed in the mac80211 workqueue and LED updates only
happen on behalf of mac80211 activities (by default). It only causes
additional wakeups, if there's nothing else scheduled on the workqueue
anyways (which might well be the case. So we need numbers. :)
> Remove the hardcode to stop it from doing any harm. If this code is useful
> for others it should probably be reworked as a quirk table triggering only
> for individual systems that need it.
There are cards that need it. I don't know how many that are, but I own
an older 4306 PC-Card card that needs this.
So this effectively is a regression for this card.
So I don't think this is acceptable.
You should at least make this configurable via module parameter or such.
Or maybe the change from above already is enough. It should work for
your case.
> Signed-off-by: Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
> ---
> drivers/net/wireless/broadcom/b43/leds.c | 26 ++------------------------
> 1 file changed, 2 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/b43/leds.c b/drivers/net/wireless/broadcom/b43/leds.c
> index d79ab2a..77d2dad 100644
> --- a/drivers/net/wireless/broadcom/b43/leds.c
> +++ b/drivers/net/wireless/broadcom/b43/leds.c
> @@ -224,31 +224,9 @@ static void b43_led_get_sprominfo(struct b43_wldev *dev,
>
> if (sprom[led_index] == 0xFF) {
> /* There is no LED information in the SPROM
> - * for this LED. Hardcode it here. */
> + * for this LED. Keep it disabled. */
> *activelow = false;
> - switch (led_index) {
> - case 0:
> - *behaviour = B43_LED_ACTIVITY;
> - *activelow = true;
> - if (dev->dev->board_vendor == PCI_VENDOR_ID_COMPAQ)
> - *behaviour = B43_LED_RADIO_ALL;
> - break;
> - case 1:
> - *behaviour = B43_LED_RADIO_B;
> - if (dev->dev->board_vendor == PCI_VENDOR_ID_ASUSTEK)
> - *behaviour = B43_LED_ASSOC;
> - break;
> - case 2:
> - *behaviour = B43_LED_RADIO_A;
> - break;
> - case 3:
> - *behaviour = B43_LED_OFF;
> - break;
> - default:
> - *behaviour = B43_LED_OFF;
> - B43_WARN_ON(1);
> - return;
> - }
> + *behaviour = B43_LED_OFF;
> } else {
> *behaviour = sprom[led_index] & B43_LED_BEHAVIOUR;
> *activelow = !!(sprom[led_index] & B43_LED_ACTIVELOW);
--
Michael
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2016-04-25 15:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-25 7:40 [PATCH RFC] b43: stop hardcoding LED behavior Lucas Stach
[not found] ` <1461570051-3950-1-git-send-email-dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
2016-04-25 15:53 ` Michael Büsch [this message]
2016-04-25 18:21 ` Lucas Stach
2016-04-25 18:32 ` Michael Büsch
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=20160425175326.407eba27@wiggum \
--to=m@bues.ch \
--cc=b43-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org \
--cc=kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.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).