Message-ID: <10520902.uqZDZn6tkf@xps13>
Date:	Sat, 02 May 2015 15:51:50 +0200
From:	Gabriele Mazzotta <gabriele.mzt@...il.com>
To:	Pali Rohár <pali.rohar@...il.com>,
	Alex Hung <alex.hung@...onical.com>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	Darren Hart <dvhart@...radead.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 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)
> 
> > The idea to have an option (kernel parameter) for calling ABRT is
> > great. I can help verify on more machines. Is Gabriele's patch above a
> > final version that I should test?
> > 
> 
> No, I do not think so. This looks like hack or pure design. Kernel
> option could be there, but just for buggy BIOSes (and future changed
> design).
> 
> But now it looks like for correct work is specifying that param
> required -- which is bad.
> 
> Alex, can you ask Dell people how should system turn off e.g bluetooth
> or wifi device if ARTB(1) is called and system/kernel (instead ACPI) is
> expected to turn off/on blueooth (and wifi) devices?

I completely forgot that libsmbios comes with smbios-wireless-ctl.
It allows me to control the hardware slider.

> I think that without this information (and working driver for it) we
> should not enable ARTB(1) or including this driver into kernel tree as
> it will break some existing machines...

Alex, could you test smbios-wireless-ctl and see what it says about the
laptops with no hardware slider? For instance on mine it says:

Radio Status for WLAN:
        WLAN enabled at boot
        WLAN supported
        WLAN enabled
        WLAN installed
        WLAN boot-time wireless switch setting not present
        WLAN runtime switch control currently enabled
        Status Code: 0

You can find the utility here: http://linux.dell.com/git/libsmbios.git

The code to check for the presence of an hardware slider is even
already implemented in dell-laptop and works on my laptop, it says the
slider is present.


Pali, you have a Latitude, right? Is "whitelisted" true when you load
dell-laptop? I'm asking because when I load dell-laptop with
force_rfkill, my function key stops working. Radio devices get disabled
the moment dell-laptop is loaded and I must use smbios-wireless-ctl to
re-enable them. Once I re-enabled them, the function keys starts
working again.
I don't know exactly what happens on your laptop, but I was wondering
if dell-laptop is messing things up on your laptop too.
--
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