linux-kernel - Re: [PATCH v2 1/3] platform: x86: dell-rbtn: 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: <20150506074922.GB30910@pali>
Date:	Wed, 6 May 2015 09:49:22 +0200
From:	Pali Rohár <pali.rohar@...il.com>
To:	Darren Hart <dvhart@...radead.org>
Cc:	Gabriele Mazzotta <gabriele.mzt@...il.com>,
	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 v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode
 Switch driver

On Tuesday 05 May 2015 22:55:46 Darren Hart wrote:
> On Tue, May 05, 2015 at 11:23:05PM +0200, Gabriele Mazzotta wrote:
> > On Thursday 30 April 2015 09:44:29 Pali Rohár wrote:
> > > On Thursday 30 April 2015 14:06:27 Alex Hung wrote:
> > > > Method ABRT is to be used by driver to disable BIOS handling of radio
> > > > button. So the changes in behaviours observed by Gabriele is expected.
> > > > I have seen other systems behave the same way.
> > > > 
> > > 
> > > Right, that after that ARBT call operating system get full control over
> > > radio devices and ACPI/BIOS will not automatically enable/disable them.
> > > I think this is OK.
> > > 
> > > But for that we need also support for manually enable/disable radio
> > > devices and code for this support is missing. Or do DELLABCE/RBTN acpi
> > > devices somehow support enabling/disabling it via system/kernel request?
> > > 
> > > > I do also see firmware only sends Notify(RBTN, 0x80) and no hard block
> > > > whether ABRT(1) is called or not.  Thus keycode are the only option on
> > > > those machines.
> > > > 
> > > 
> > > Key is ok, but we *must* have ability to hard block it via some
> > > ACPI/WMI/BIOS/FW/etc... call. Otherwise ARBT(1) is no go as users should
> > > be able to enable/disable their radio devices (bluetooth for powersave)
> > 
> > Does it really matter in the end? As I understand it, radio devices are
> > off either way.
> 
> As a point of reference for consideration, we recently dropped the Thinkpad
> hardware mute button because it seriously complicated everything in what appears
> to be a similar sort of situation. By eliminating the hardware mute and relying
> purely on software mute, we were able to provide a much more consistently
> functional driver.
> 
> Also note that this driver provided a "software_mute" module parameter to allow
> the user to control this.
> 
> I believe this provides some relevant precedent for your consideration. I don't
> want to add parameters casually, but it could be one is warranted here.
> 

Yes, this driver transfter hardware function (implemented in EC ACPI
firmware) into software kernel solution. But my point was that software
solution must be able to call all those "functions" which was called
previously by ACPI/firmware.

-- 
Pali Rohár
pali.rohar@...il.com
--
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/