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]
Date:	Mon, 14 Apr 2008 23:04:42 +0200
From:	Ivo van Doorn <ivdoorn@...il.com>
To:	Carlos Corbacho <carlos@...angeworlds.co.uk>
Cc:	Henrique de Moraes Holschuh <hmh@....eng.br>,
	linux-kernel@...r.kernel.org,
	"John W. Linville" <linville@...driver.com>,
	Dmitry Torokhov <dtor@...l.ru>
Subject: Re: [PATCH 4/8] rfkill: add read-write rfkill switch support

On Monday 14 April 2008, Carlos Corbacho wrote:
> On Monday 14 April 2008 13:00:41 Ivo van Doorn wrote:
> > > > See rt2x00 and b43 in driver-wireless for an example implementation
> > > > of pollable input device and rfkill
> > >
> > > They're broken by design, at least in b43's case.  Someone (Carlos, I
> > > believe?) posted an example of a ping-pong scenario using b43.
> >
> > Thats true. But was that a scenario where there were 2 keys for the same
> > radio type? Or was that a matter of the driver indicating a key pressed
> > event while it has no attached key to it, and only checked the register for
> > the key status and the current radio status and saw it was different?
> 
> Two part problem:
> 
> 1) Bug in rfkill; rfkill is toggling all devices in the same state, and not 
> actually checking the type.
> 
> (I submitted a patch for this on Sunday, although I sent it to linux-wireless 
> before you sent the MAINTAINERS patch with netdev as the official list; but I 
> did CC you on it regardless so you should have seen this. If not, let me know 
> and I'll resend it).

Completely overlooked the patch.
I found it in my archives and just acked it. :)

Ivo

> 2) The cycle-of-doom bug, as described earlier.
> 
> This still applies.
> 
> Yes, b43 can also be fixed not to emit a keycode if it cannot control the 
> rfkill switch; but that doesn't solve the case of what happens if both the 
> wireless driver and the platform driver can control the radio.
> 
> I agree wholeheartedly with Henrique here though - wireless drivers should 
> _not_ be using key press events as a reporting mechanism.
> 
> -Carlos


--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ