login
Search
The LED state was not being updated by rfkill_force_state(), which will
cause regressions in wireless drivers that had old-style rfkill support and
are updated to use rfkill_force_state().
The LED state was not being updated when a change was detected through the
rfkill->get_state() hook, either.
Move the LED trigger update calls into notify_rfkill_state_change(), where
it should have been in the first place. This takes care of both issues.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Ivo van Doorn <IvDoorn@gmail.com>
---
net/rfkill/rfkill.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
John, this one is quite likely something that should be sent for
merge in mainline BEFORE 2.6.27 is released.
I am NOT sure it fixes regressions, that depends on whether the drivers
using rfkill that are in 2.6.27 had working LED support before rfkill
support was added to them. Unfortunately, it cannot fix the b43
regression by itself.
diff --git a/net/rfkill/rfkill.c b/net/rfkill/rfkill.c
index ea0dc04..f949a48 100644
--- a/net/rfkill/rfkill.c
+++ b/net/rfkill/rfkill.c
@@ -125,6 +125,7 @@ static void rfkill_led_trigger_activate(struct led_classdev *led)
static void notify_rfkill_state_change(struct rfkill *rfkill)
{
+ rfkill_led_trigger(rfkill, rfkill->state);
blocking_notifier_call_chain(&rfkill_notifier_list,
RFKILL_STATE_CHANGED,
rfkill);
@@ -217,10 +218,8 @@ static int rfkill_toggle_radio(struct rfkill *rfkill,
rfkill->state = state;
}
- if (force || rfkill->state != oldstate) {
- rfkill_led_trigger(rfkill, rfkill->state);
+ if (force || rfkill->state != oldstate)
notify_rfkill_state_change(rfkill);
- }
return retval;
}
--
1.5.6.5
--