Date: Tue, 5 May 2015 13:31:16 -0700
From: Darren Hart <dvhart@infradead.org>
To: Pali =?iso-8859-1?Q?Roh=E1r?= <pali.rohar@gmail.com>
Cc: Alex Hung <alex.hung@canonical.com>,
        Gabriele Mazzotta <gabriele.mzt@gmail.com>,
        Matthew Garrett <mjg59@srcf.ucam.org>,
        "platform-driver-x86@vger.kernel.org" 
	<platform-driver-x86@vger.kernel.org>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode
 Switch driver
Message-ID: <20150505203116.GB33977@fury.dvhart.com>
References: <1416755361-17357-1-git-send-email-pali.rohar@gmail.com>
 <20150429181606.GR24346@pali>
 <1662732.6WCXK4FVmN@xps13>
 <201504292059.26585@pali>
 <CAJ=jquYEEZ928A=eL158p38s4EEX32BZB5mOv5-841bRkKr_UQ@mail.gmail.com>
 <20150430074429.GT24346@pali>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20150430074429.GT24346@pali>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2939
Lines: 67

On Thu, Apr 30, 2015 at 09:44:29AM +0200, 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 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...
> 
> Darren, I do not know what is better, but it looks like that some dell
> machines working fine now and some not (since begining). And after
> loading this driver some machines are fixed, but some which worked are
> broken... What do you think as maintainer?

We work with a challenging space that forces us to consider doing abnormal
things to support product firmware, I do understand that I try to support it.

I agree with your statement above, the kernel parameter, if used at all, should
be used in special cases as a workaround, not as the normal case.

While I'm happy to take incremental improvements, even if they aren't 100%
perfect, we can't fix some laptops by breaking others.


-- 
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/