linux-kernel - Re: [PATCH] rfkill: update LEDs for all state changes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080918124318.GB1583@khazad-dum.debian.net>
Date:	Thu, 18 Sep 2008 09:43:18 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Larry Finger <Larry.Finger@...inger.net>
Cc:	John Linville <linville@...driver.com>,
	linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Michael Buesch <mb@...sch.de>,
	Ivo van Doorn <IvDoorn@...il.com>
Subject: Re: [PATCH] rfkill: update LEDs for all state changes

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@....eng.br>
> > Cc: Ivo van Doorn <IvDoorn@...il.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.
> 
> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/