linux-kernel - Re: [PATCH 0/3] Dell Airplane Mode Switch driver

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: <201412052223.25059@pali>
Date:	Fri, 5 Dec 2014 22:23:25 +0100
From:	Pali Rohár <pali.rohar@...il.com>
To:	Gabriele Mazzotta <gabriele.mzt@...il.com>
Cc:	Darren Hart <dvhart@...radead.org>,
	Alex Hung <alex.hung@...onical.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	"platform-driver-x86@...r.kernel.org" 
	<platform-driver-x86@...r.kernel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] Dell Airplane Mode Switch driver

On Friday 05 December 2014 22:12:42 Gabriele Mazzotta wrote:
> On Friday 05 December 2014 22:03:24 Pali Rohár wrote:
> > On Friday 05 December 2014 21:53:10 Gabriele Mazzotta wrote:
> > > On Friday 05 December 2014 21:38:17 Pali Rohár wrote:
> > > > On Wednesday 03 December 2014 14:00:23 Darren Hart wrote:
> > > > > On Thu, Dec 04, 2014 at 10:55:32AM +0100, Pali Rohár 
wrote:
> > > > > > Darren, I think that if we do not solve problem with
> > > > > > duplicate key events (in dell-wireless.c) we should
> > > > > > postpone these patches to later kernel version. It
> > > > > > is better to not have such regression as it confuse
> > > > > > software like NetworkManager which is widely used.
> > > > > 
> > > > > OK, that's what I needed. Thanks. Ignore my previous
> > > > > request, you answered it here. I will drop
> > > > > dell-wireless.c and look for a combined solution from
> > > > > you and Alex for the next release.
> > > > > 
> > > > > Thanks,
> > > > 
> > > > And according to discussion about Side effect of
> > > > pressing special keys at [1] [2] we should not report
> > > > this wireless key event (as input device) to userspace.
> > > > And Alex's driver is doing that.
> > > > 
> > > > [1] -
> > > > http://www.spinics.net/lists/platform-driver-x86/msg0592
> > > > 2.h tml [2] -
> > > > http://www.spinics.net/lists/platform-driver-x86/msg0592
> > > > 4.h tml
> > > 
> > > Alex's patch is for those laptop whose BIOS only sends a
> > > notification to DELLABCE when Fn keys are pressed. His
> > > patch simply translates these ACPI notifications to
> > > KEY_RFKILL keypresses.
> > 
> > Yes, and your last patch disables sending such KEY events to
> > userspace (in dell-wmi driver). BIOS already handle changes,
> > so key press should not be reported to userspace... [1]
> > (from previous email).
> 
> This is not true if ARBT (with 1 as parameter) is called. When
> this is done, the BIOS stops managing the radio devices
> completely and reporting KEY_RFKILL to userspace becomes a
> necessity. I guess that the laptops on which this patch was
> tested behaved like mine after ARBT is called, given that the
> call was missing completely in the original patch.
> 

Ok. It means that at least original Alex patch needs to be 
reworked (so we will do not see duplicate events problem and 
problem described in previous email).

But my other question is... If ARBT(1) is called then it disables 
BIOS support for managing radio devices on your laptop. Why we 
need patch which disabling useful functionality (= ability to 
disable wifi rfkill)? We still do not have patch which can 
correctly set rfkill state by software on laptops of your fn key 
type.

> > > Correct if I'm wrong, but shouldn't his patch have no
> > > effects on your laptop? If I'm not wrong, CRBT returns 2
> > > on your laptop, so the input device is not even created.
> > > Am I missing something?
> > > 
> > > Gabriele
> > 
> > Yes, it has no effect for my laptop.

-- 
Pali Rohár
pali.rohar@...il.com

Download attachment "signature.asc " of type "application/pgp-signature" (199 bytes)