All of lore.kernel.org
 help / color / mirror / Atom feed
From: Larry Finger <Larry.Finger@lwfinger.net>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: wireless <linux-wireless@vger.kernel.org>
Subject: Re: How does rfkill work?
Date: Thu, 02 Apr 2009 16:24:55 -0500	[thread overview]
Message-ID: <49D52D27.4010607@lwfinger.net> (raw)
In-Reply-To: <1238705420.8363.14.camel@johannes.local>

Johannes Berg wrote:

> Ah, yes. Using a shorter name is probably a good idea then. I don't
> think changing that define makes too much sense.
> 
> On my test with iwlwifi the rfkill LED trigger is definitely called -- I
> cannot pinpoint why it shouldn't be on your setup. :(
> 
> Actually. Are you positive it works without my patch? The confusing this
> is that this code never seems to call led_trigger_event() outside of
> rfkill_led_trigger_activate() which is only called once... Can you try
> this patch please?

No, it hasn't worked for some time, but until you rationalized the rfkill code,
I didn't want to mess with it. :)

>  net/rfkill/core.c |   22 +++++++++++++++++++---
>  1 file changed, 19 insertions(+), 3 deletions(-)
> 
> --- wireless-testing.orig/net/rfkill/core.c	2009-04-02 22:47:05.000000000 +0200
> +++ wireless-testing/net/rfkill/core.c	2009-04-02 22:49:53.000000000 +0200
> @@ -83,12 +83,10 @@ static bool rfkill_epo_lock_active;
>  
>  
>  #ifdef CONFIG_RFKILL_LEDS
> -static void rfkill_led_trigger_activate(struct led_classdev *led)
> +static void rfkill_led_trigger_event(struct rfkill *rfkill)
>  {
> -	struct rfkill *rfkill;
>  	struct led_trigger *trigger;
>  
> -	rfkill = container_of(led->trigger, struct rfkill, led_trigger);
>  	trigger = &rfkill->led_trigger;
>  
>  	if (rfkill->blocked)
> @@ -97,6 +95,15 @@ static void rfkill_led_trigger_activate(
>  		led_trigger_event(trigger, LED_FULL);
>  }
>  
> +static void rfkill_led_trigger_activate(struct led_classdev *led)
> +{
> +	struct rfkill *rfkill;
> +
> +	rfkill = container_of(led->trigger, struct rfkill, led_trigger);
> +
> +	rfkill_led_trigger_event(rfkill);
> +}
> +
>  const char *rfkill_get_led_trigger_name(struct rfkill *rfkill)
>  {
>  	return rfkill->led_trigger.name;
> @@ -124,6 +131,10 @@ static void rfkill_led_trigger_unregiste
>  	led_trigger_unregister(&rfkill->led_trigger);
>  }
>  #else
> +static void rfkill_led_trigger_event(struct rfkill *rfkill)
> +{
> +}
> +
>  static inline int rfkill_led_trigger_register(struct rfkill *rfkill)
>  {
>  	return 0;
> @@ -158,6 +169,8 @@ static bool __rfkill_set_hw_state(struct
>  
>  	*change = prev != blocked;
>  
> +	rfkill_led_trigger_event(rfkill);
> +
>  	return blocked || !!test_bit(RFKILL_BLOCK_SW_BIT, &rfkill->blocked);
>  }
>  
> @@ -214,6 +227,7 @@ static void rfkill_set_block(struct rfki
>  			clear_bit(RFKILL_BLOCK_SW_BIT, &rfkill->blocked);
>  	}
>  
> +	rfkill_led_trigger_event(rfkill);
>  	rfkill_uevent(rfkill);
>  }
>  
> @@ -400,6 +414,8 @@ bool rfkill_set_sw_state(struct rfkill *
>  	if (prev != blocked && !hwblock)
>  		schedule_work(&rfkill->uevent_work);
>  
> +	rfkill_led_trigger_event(rfkill);
> +
>  	return blocked || hwblock;
>  }
>  EXPORT_SYMBOL(rfkill_set_sw_state);

This patch does the trick. Not only is the set brightness callback routine being
called, but the LED is going on/off as expected. It even ends up in the off
state when the module is loaded with the switch off. It toggles on/off in that
case, but I'm not going to complain as long as it ends up off. That part broke
first, then everything broke later..

Thanks for the help.


Larry

  reply	other threads:[~2009-04-02 21:25 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-02  4:59 How does rfkill work? Larry Finger
2009-04-02  9:56 ` Johannes Berg
2009-04-02 14:44   ` Larry Finger
2009-04-02 15:02     ` Johannes Berg
2009-04-02 15:22       ` Larry Finger
2009-04-02 15:55         ` Johannes Berg
2009-04-02 16:27         ` Johannes Berg
2009-04-02 18:18           ` Larry Finger
2009-04-02 18:28             ` Johannes Berg
2009-04-03 15:15               ` Richard Purdie
2009-04-03 19:22                 ` Johannes Berg
2009-04-02 18:29             ` Johannes Berg
2009-04-02 18:42               ` Larry Finger
2009-04-02 18:48                 ` Johannes Berg
2009-04-02 18:57                   ` Johannes Berg
2009-04-02 20:36                     ` Larry Finger
2009-04-02 20:50                       ` Johannes Berg
2009-04-02 21:24                         ` Larry Finger [this message]
2009-04-02 21:39                           ` Johannes Berg
2009-04-02 21:59                             ` Larry Finger
2009-04-02 22:09                               ` Johannes Berg
2009-04-03  4:37                       ` Marcel Holtmann
2009-04-03  4:57                         ` Larry Finger
2009-04-03  5:09                         ` Kay Sievers
2009-04-03  4:35       ` Marcel Holtmann
2009-04-03  9:01         ` Johannes Berg

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=49D52D27.4010607@lwfinger.net \
    --to=larry.finger@lwfinger.net \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.