On Wed, 17 Sep 2008, Larry Finger wrote: > Henrique de Moraes Holschuh wrote: > > 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@xxxxxxxxxx> > > Cc: Ivo van Doorn <IvDoorn@xxxxxxxxx> > > --- > > 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. > > The b43 regression is not fixed with this patch and the one from > Matthew that starts out with "Oh, hey, I suck. This one might stand a > better chance of not falling over." Curious. My patch to rfkill WAS tested, and it DOES fix the same issue you reported (hardware state changes to HARD_BLOCKED do not update the LEDs) in thinkpad-acpi. It is also an "obviously correct" patch. What this probably means is that b43 would need a little more rfkill surgery than what Matthew's patch already did. I will look over Matthew's patch, but my guess is that Michael's comments about the need to add some extra code to b43 to actually synthesize the rfkill state from the separate HW and SW rfkill input lines are a strong hint of where the problem might be. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
