[PATCH 0/3] Dell Airplane Mode Switch driver

[PATCH 0/3] Dell Airplane Mode Switch driver

[Pali Rohár]

This patch series add new acpi Dell Airplane Mode Switch driver (DELLABCE and
DELRBTN acpi devices). It provides radio HW switch events (together with current
state of radio devices) and export them via rfkill interface. These events are
also used in dell-laptop driver instead i8042 filter hook function (when acpi
device is available).

Pali Rohár (3):
  platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
  platform: x86: dell-rbtn: Export notifier for other kernel modules
  platform: x86: dell-laptop: Use dell-rbtn instead i8042 filter when
    possible

 drivers/platform/x86/Kconfig       |   14 ++
 drivers/platform/x86/Makefile      |    1 +
 drivers/platform/x86/dell-laptop.c |   67 +++++++++-
 drivers/platform/x86/dell-rbtn.c   |  260 ++++++++++++++++++++++++++++++++++++
 drivers/platform/x86/dell-rbtn.h   |   35 +++++
 5 files changed, 372 insertions(+), 5 deletions(-)
 create mode 100644 drivers/platform/x86/dell-rbtn.c
 create mode 100644 drivers/platform/x86/dell-rbtn.h

-- 
1.7.9.5

[PATCH 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Pali Rohár]

This is an ACPI driver for Dell laptops which receive HW switch events.
It exports rfkill device dell-rbtn which provide correct hard rfkill state.

It does not provide support for setting soft rfkill state yet.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
---
 drivers/platform/x86/Kconfig     |   13 +++
 drivers/platform/x86/Makefile    |    1 +
 drivers/platform/x86/dell-rbtn.c |  179 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 193 insertions(+)
 create mode 100644 drivers/platform/x86/dell-rbtn.c

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 4dcfb71..5a2ba64 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -137,6 +137,19 @@ config DELL_SMO8800
 	  To compile this driver as a module, choose M here: the module will
 	  be called dell-smo8800.
 
+config DELL_RBTN
+	tristate "Dell Airplane Mode Switch driver"
+	depends on ACPI
+	depends on RFKILL
+	---help---
+	  Say Y here if you want to support Dell Airplane Mode Switch ACPI
+	  device on Dell laptops. Sometimes it has names: DELLABCE or DELRBTN.
+	  This driver register rfkill device and receives HW rfkill events
+	  (when wifi/bluetooth was enabled) and set correct hard rfkill state.
+
+	  To compile this driver as a module, choose M here: the module will
+	  be called dell-rbtn.
+
 
 config FUJITSU_LAPTOP
 	tristate "Fujitsu Laptop Extras"
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index f82232b..b3e54ed 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_DELL_LAPTOP)	+= dell-laptop.o
 obj-$(CONFIG_DELL_WMI)		+= dell-wmi.o
 obj-$(CONFIG_DELL_WMI_AIO)	+= dell-wmi-aio.o
 obj-$(CONFIG_DELL_SMO8800)	+= dell-smo8800.o
+obj-$(CONFIG_DELL_RBTN)		+= dell-rbtn.o
 obj-$(CONFIG_ACER_WMI)		+= acer-wmi.o
 obj-$(CONFIG_ACERHDF)		+= acerhdf.o
 obj-$(CONFIG_HP_ACCEL)		+= hp_accel.o
diff --git a/drivers/platform/x86/dell-rbtn.c b/drivers/platform/x86/dell-rbtn.c
new file mode 100644
index 0000000..f1f039a
--- /dev/null
+++ b/drivers/platform/x86/dell-rbtn.c
@@ -0,0 +1,179 @@
+/*
+    Dell Airplane Mode Switch driver
+    Copyright (C) 2014  Pali Rohár <pali.rohar@gmail.com>
+
+    This program is free software; you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+*/
+
+#include <linux/module.h>
+#include <linux/acpi.h>
+#include <linux/rfkill.h>
+
+/*** helper functions ***/
+
+static int rbtn_check(struct acpi_device *device)
+{
+	acpi_status status;
+	unsigned long long output;
+
+	status = acpi_evaluate_integer(device->handle, "CRBT", NULL, &output);
+	if (ACPI_FAILURE(status))
+		return -EINVAL;
+
+	if (output > 3)
+		return -EINVAL;
+
+	return 0;
+}
+
+
+/*** rfkill ops ***/
+
+static void rbtn_query(struct rfkill *rfkill, void *data)
+{
+	struct acpi_device *device = data;
+	acpi_status status;
+	unsigned long long output;
+
+	status = acpi_evaluate_integer(device->handle, "GRBT", NULL, &output);
+	if (ACPI_FAILURE(status))
+		return;
+
+	rfkill_set_states(rfkill, !output, !output);
+}
+
+static int rbtn_set_block(void *data, bool blocked)
+{
+	/* FIXME: setting soft rfkill cause problems, so disable it for now */
+	return -EINVAL;
+}
+
+struct rfkill_ops rbtn_ops = {
+	.query = rbtn_query,
+	.set_block = rbtn_set_block,
+};
+
+
+/*** acpi driver ***/
+
+static int rbtn_add(struct acpi_device *device);
+static int rbtn_remove(struct acpi_device *device);
+static void rbtn_notify(struct acpi_device *device, u32 event);
+
+static const struct acpi_device_id rbtn_ids[] = {
+	{ "DELRBTN", 0 },
+	{ "DELLABCE", 0 },
+	{ "", 0 },
+};
+
+static struct acpi_driver rbtn_driver = {
+	.name = "dell-rbtn",
+	.ids = rbtn_ids,
+	.ops = {
+		.add = rbtn_add,
+		.remove = rbtn_remove,
+		.notify = rbtn_notify,
+	},
+	.owner = THIS_MODULE,
+};
+
+
+/*** rfkill enable/disable ***/
+
+static int rbtn_enable(struct acpi_device *device)
+{
+	struct rfkill *rfkill = device->driver_data;
+	int ret;
+
+	if (rfkill)
+		return 0;
+
+	/* NOTE: rbtn controls all radio devices, not only WLAN
+	         but rfkill interface does not support "ANY" type
+	         so "WLAN" type is used
+	 */
+	rfkill = rfkill_alloc("dell-rbtn", &device->dev, RFKILL_TYPE_WLAN,
+			      &rbtn_ops, device);
+	if (!rfkill)
+		return -ENOMEM;
+
+	ret = rfkill_register(rfkill);
+	if (ret) {
+		rfkill_destroy(rfkill);
+		return ret;
+	}
+
+	device->driver_data = rfkill;
+	return 0;
+}
+
+static void rbtn_disable(struct acpi_device *device)
+{
+	struct rfkill *rfkill = device->driver_data;
+
+	if (!rfkill)
+		return;
+
+	rfkill_unregister(rfkill);
+	rfkill_destroy(rfkill);
+	device->driver_data = NULL;
+}
+
+
+/*** acpi driver functions ***/
+
+static int rbtn_add(struct acpi_device *device)
+{
+	int ret;
+
+	ret = rbtn_check(device);
+	if (ret < 0)
+		return ret;
+
+	return rbtn_enable(device);
+}
+
+static int rbtn_remove(struct acpi_device *device)
+{
+	rbtn_disable(device);
+	return 0;
+}
+
+static void rbtn_notify(struct acpi_device *device, u32 event)
+{
+	struct rfkill *rfkill = device->driver_data;
+
+	if (event == 0x80)
+		rbtn_query(rfkill, device);
+	else
+		dev_info(&device->dev, "Received unknown event (0x%x)\n", event);
+}
+
+
+/*** module functions ***/
+
+static int __init rbtn_init(void)
+{
+	return acpi_bus_register_driver(&rbtn_driver);
+}
+
+static void __exit rbtn_exit(void)
+{
+	acpi_bus_unregister_driver(&rbtn_driver);
+}
+
+module_init(rbtn_init);
+module_exit(rbtn_exit);
+
+MODULE_DEVICE_TABLE(acpi, rbtn_ids);
+MODULE_DESCRIPTION("Dell Airplane Mode Switch driver");
+MODULE_AUTHOR("Pali Rohár <pali.rohar@gmail.com>");
+MODULE_LICENSE("GPL");
-- 
1.7.9.5

Re: [PATCH 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Matthew Garrett]

On Sun, Nov 23, 2014 at 04:09:19PM +0100, Pali Rohár wrote:

> +	/* NOTE: rbtn controls all radio devices, not only WLAN
> +	         but rfkill interface does not support "ANY" type
> +	         so "WLAN" type is used
> +	 */

If it controls multiple radio types then you should register multiple 
rfkill devices.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 726 bytes --]

On Monday 24 November 2014 21:09:05 Matthew Garrett wrote:
> On Sun, Nov 23, 2014 at 04:09:19PM +0100, Pali Rohár wrote:
> > +	/* NOTE: rbtn controls all radio devices, not only WLAN
> > +	         but rfkill interface does not support "ANY" type
> > +	         so "WLAN" type is used
> > +	 */
> 
> If it controls multiple radio types then you should register
> multiple rfkill devices.

This is complicated. HW switch controls all radio devices and you 
do not know which are present in specified running machine. Also 
list of devices which HW switch controls can be edited in BIOS 
(on some machines). So what to do? We only know that it controls 
some devices...

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Matthew Garrett]

On Mon, Nov 24, 2014 at 09:55:47PM +0100, Pali Rohár wrote:

> This is complicated. HW switch controls all radio devices and you 
> do not know which are present in specified running machine. Also 
> list of devices which HW switch controls can be edited in BIOS 
> (on some machines). So what to do? We only know that it controls 
> some devices...

Typically there'll be a firmware method that provides a mask of the 
controlled devices. Do you have the ACPI tables for a device that 
implements this? Registering an rfkill interface that claims to only 
control wifi but which also kills other devices is likely to confuse 
userspace - it would probably be better to avoid registering the rfkill 
interface at all in that case.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 1029 bytes --]

On Monday 24 November 2014 22:50:26 Matthew Garrett wrote:
> On Mon, Nov 24, 2014 at 09:55:47PM +0100, Pali Rohár wrote:
> > This is complicated. HW switch controls all radio devices
> > and you do not know which are present in specified running
> > machine. Also list of devices which HW switch controls can
> > be edited in BIOS (on some machines). So what to do? We
> > only know that it controls some devices...
> 
> Typically there'll be a firmware method that provides a mask
> of the controlled devices. Do you have the ACPI tables for a
> device that implements this? Registering an rfkill interface
> that claims to only control wifi but which also kills other
> devices is likely to confuse userspace - it would probably be
> better to avoid registering the rfkill interface at all in
> that case.

Currently you cannot control soft state of rfkill. It receive 
events when hard state was changed and update hard rfkill status 
(if is enabled or disabled).

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Mika Westerberg]

On Sun, Nov 23, 2014 at 04:09:19PM +0100, Pali Rohár wrote:
> This is an ACPI driver for Dell laptops which receive HW switch events.
> It exports rfkill device dell-rbtn which provide correct hard rfkill state.
> 
> It does not provide support for setting soft rfkill state yet.
> 
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> ---
>  drivers/platform/x86/Kconfig     |   13 +++
>  drivers/platform/x86/Makefile    |    1 +
>  drivers/platform/x86/dell-rbtn.c |  179 ++++++++++++++++++++++++++++++++++++++
>  3 files changed, 193 insertions(+)
>  create mode 100644 drivers/platform/x86/dell-rbtn.c
> 
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index 4dcfb71..5a2ba64 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -137,6 +137,19 @@ config DELL_SMO8800
>  	  To compile this driver as a module, choose M here: the module will
>  	  be called dell-smo8800.
>  
> +config DELL_RBTN
> +	tristate "Dell Airplane Mode Switch driver"
> +	depends on ACPI
> +	depends on RFKILL
> +	---help---
> +	  Say Y here if you want to support Dell Airplane Mode Switch ACPI
> +	  device on Dell laptops. Sometimes it has names: DELLABCE or DELRBTN.
> +	  This driver register rfkill device and receives HW rfkill events
> +	  (when wifi/bluetooth was enabled) and set correct hard rfkill state.
> +
> +	  To compile this driver as a module, choose M here: the module will
> +	  be called dell-rbtn.
> +
>  
>  config FUJITSU_LAPTOP
>  	tristate "Fujitsu Laptop Extras"
> diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
> index f82232b..b3e54ed 100644
> --- a/drivers/platform/x86/Makefile
> +++ b/drivers/platform/x86/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_DELL_LAPTOP)	+= dell-laptop.o
>  obj-$(CONFIG_DELL_WMI)		+= dell-wmi.o
>  obj-$(CONFIG_DELL_WMI_AIO)	+= dell-wmi-aio.o
>  obj-$(CONFIG_DELL_SMO8800)	+= dell-smo8800.o
> +obj-$(CONFIG_DELL_RBTN)		+= dell-rbtn.o
>  obj-$(CONFIG_ACER_WMI)		+= acer-wmi.o
>  obj-$(CONFIG_ACERHDF)		+= acerhdf.o
>  obj-$(CONFIG_HP_ACCEL)		+= hp_accel.o
> diff --git a/drivers/platform/x86/dell-rbtn.c b/drivers/platform/x86/dell-rbtn.c
> new file mode 100644
> index 0000000..f1f039a
> --- /dev/null
> +++ b/drivers/platform/x86/dell-rbtn.c
> @@ -0,0 +1,179 @@
> +/*
> +    Dell Airplane Mode Switch driver
> +    Copyright (C) 2014  Pali Rohár <pali.rohar@gmail.com>
> +
> +    This program is free software; you can redistribute it and/or modify
> +    it under the terms of the GNU General Public License as published by
> +    the Free Software Foundation; either version 2 of the License, or
> +    (at your option) any later version.
> +
> +    This program is distributed in the hope that it will be useful,
> +    but WITHOUT ANY WARRANTY; without even the implied warranty of
> +    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +    GNU General Public License for more details.

Please check Documentation/CodingStyle, block comments look like this

 /*
  * This is block comment.
  */

> +*/
> +
> +#include <linux/module.h>
> +#include <linux/acpi.h>
> +#include <linux/rfkill.h>
> +
> +/*** helper functions ***/
> +
> +static int rbtn_check(struct acpi_device *device)
> +{
> +	acpi_status status;
> +	unsigned long long output;
> +
> +	status = acpi_evaluate_integer(device->handle, "CRBT", NULL, &output);

Do you think it is worth documenting what CRBT is supposed to do? Why
return value <= 3 is OK and > 3 is not?

> +	if (ACPI_FAILURE(status))
> +		return -EINVAL;
> +
> +	if (output > 3)
> +		return -EINVAL;
> +
> +	return 0;
> +}
> +
> +

Delete the second blank line.

> +/*** rfkill ops ***/
> +
> +static void rbtn_query(struct rfkill *rfkill, void *data)
> +{
> +	struct acpi_device *device = data;
> +	acpi_status status;
> +	unsigned long long output;
> +
> +	status = acpi_evaluate_integer(device->handle, "GRBT", NULL, &output);

Same comment here about the documentation.

> +	if (ACPI_FAILURE(status))
> +		return;
> +
> +	rfkill_set_states(rfkill, !output, !output);

You can also write it like:

	if (ACPI_SUCCESS(status))
		rfkill_set_states(rfkill, !output, !output);

which looks better to me at least.

> +}
> +
> +static int rbtn_set_block(void *data, bool blocked)
> +{
> +	/* FIXME: setting soft rfkill cause problems, so disable it for now */
> +	return -EINVAL;
> +}
> +
> +struct rfkill_ops rbtn_ops = {

static? const?

> +	.query = rbtn_query,
> +	.set_block = rbtn_set_block,
> +};
> +
> +

Delete the second blank line.

> +/*** acpi driver ***/
> +
> +static int rbtn_add(struct acpi_device *device);
> +static int rbtn_remove(struct acpi_device *device);
> +static void rbtn_notify(struct acpi_device *device, u32 event);
> +
> +static const struct acpi_device_id rbtn_ids[] = {
> +	{ "DELRBTN", 0 },
> +	{ "DELLABCE", 0 },
> +	{ "", 0 },
> +};
> +
> +static struct acpi_driver rbtn_driver = {
> +	.name = "dell-rbtn",
> +	.ids = rbtn_ids,
> +	.ops = {
> +		.add = rbtn_add,
> +		.remove = rbtn_remove,
> +		.notify = rbtn_notify,
> +	},
> +	.owner = THIS_MODULE,
> +};
> +
> +

Ditto.

> +/*** rfkill enable/disable ***/
> +
> +static int rbtn_enable(struct acpi_device *device)
> +{
> +	struct rfkill *rfkill = device->driver_data;
> +	int ret;
> +
> +	if (rfkill)
> +		return 0;
> +
> +	/* NOTE: rbtn controls all radio devices, not only WLAN
> +	         but rfkill interface does not support "ANY" type
> +	         so "WLAN" type is used
> +	 */

Block comment style.

> +	rfkill = rfkill_alloc("dell-rbtn", &device->dev, RFKILL_TYPE_WLAN,
> +			      &rbtn_ops, device);
> +	if (!rfkill)
> +		return -ENOMEM;
> +
> +	ret = rfkill_register(rfkill);
> +	if (ret) {
> +		rfkill_destroy(rfkill);
> +		return ret;
> +	}
> +
> +	device->driver_data = rfkill;
> +	return 0;
> +}
> +
> +static void rbtn_disable(struct acpi_device *device)
> +{
> +	struct rfkill *rfkill = device->driver_data;
> +
> +	if (!rfkill)
> +		return;
> +
> +	rfkill_unregister(rfkill);
> +	rfkill_destroy(rfkill);
> +	device->driver_data = NULL;
> +}
> +
> +

Extra blank line.

> +/*** acpi driver functions ***/
> +
> +static int rbtn_add(struct acpi_device *device)
> +{
> +	int ret;
> +
> +	ret = rbtn_check(device);
> +	if (ret < 0)
> +		return ret;
> +
> +	return rbtn_enable(device);
> +}
> +
> +static int rbtn_remove(struct acpi_device *device)
> +{
> +	rbtn_disable(device);
> +	return 0;
> +}
> +
> +static void rbtn_notify(struct acpi_device *device, u32 event)
> +{
> +	struct rfkill *rfkill = device->driver_data;
> +
> +	if (event == 0x80)
> +		rbtn_query(rfkill, device);
> +	else
> +		dev_info(&device->dev, "Received unknown event (0x%x)\n", event);
> +}
> +
> +

Extra blank line.

> +/*** module functions ***/
> +
> +static int __init rbtn_init(void)
> +{
> +	return acpi_bus_register_driver(&rbtn_driver);
> +}
> +
> +static void __exit rbtn_exit(void)
> +{
> +	acpi_bus_unregister_driver(&rbtn_driver);
> +}
> +
> +module_init(rbtn_init);
> +module_exit(rbtn_exit);

module_acpi_driver()?

> +
> +MODULE_DEVICE_TABLE(acpi, rbtn_ids);
> +MODULE_DESCRIPTION("Dell Airplane Mode Switch driver");
> +MODULE_AUTHOR("Pali Rohár <pali.rohar@gmail.com>");
> +MODULE_LICENSE("GPL");
> -- 
> 1.7.9.5
> 
> --
> 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/

Re: [PATCH 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 1299 bytes --]

Hello,

I will fix all those style problems and add some comments.

On Friday 28 November 2014 12:33:28 Mika Westerberg wrote:
> > +	if (ACPI_FAILURE(status))
> > +		return;
> > +
> > +	rfkill_set_states(rfkill, !output, !output);
> 
> You can also write it like:
> 
> 	if (ACPI_SUCCESS(status))
> 		rfkill_set_states(rfkill, !output, !output);
> 
> which looks better to me at least.
> 

In whole module I'm using this style:

f1();
if (f1_failed)
	return;
f2()
if (f2_failed)
	return;

So I would like not to change it for one function.

> > +}
> > +
> > +static int rbtn_set_block(void *data, bool blocked)
> > +{
> > +	/* FIXME: setting soft rfkill cause problems, so disable
> > it for now */ +	return -EINVAL;
> > +}
> > +
> > +struct rfkill_ops rbtn_ops = {
> 
> static? const?
> 

Yes, static const should be used.

> 
> > +/*** module functions ***/
> > +
> > +static int __init rbtn_init(void)
> > +{
> > +	return acpi_bus_register_driver(&rbtn_driver);
> > +}
> > +
> > +static void __exit rbtn_exit(void)
> > +{
> > +	acpi_bus_unregister_driver(&rbtn_driver);
> > +}
> > +
> > +module_init(rbtn_init);
> > +module_exit(rbtn_exit);
> 
> module_acpi_driver()?
> 

No, see PATCH 2/3.

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Mika Westerberg]

On Fri, Nov 28, 2014 at 12:45:55PM +0100, Pali Rohár wrote:
> Hello,
> 
> I will fix all those style problems and add some comments.
> 
> On Friday 28 November 2014 12:33:28 Mika Westerberg wrote:
> > > +	if (ACPI_FAILURE(status))
> > > +		return;
> > > +
> > > +	rfkill_set_states(rfkill, !output, !output);
> > 
> > You can also write it like:
> > 
> > 	if (ACPI_SUCCESS(status))
> > 		rfkill_set_states(rfkill, !output, !output);
> > 
> > which looks better to me at least.
> > 
> 
> In whole module I'm using this style:
> 
> f1();
> if (f1_failed)
> 	return;
> f2()
> if (f2_failed)
> 	return;
> 
> So I would like not to change it for one function.

Fair enough.

> > > +}
> > > +
> > > +static int rbtn_set_block(void *data, bool blocked)
> > > +{
> > > +	/* FIXME: setting soft rfkill cause problems, so disable
> > > it for now */ +	return -EINVAL;
> > > +}
> > > +
> > > +struct rfkill_ops rbtn_ops = {
> > 
> > static? const?
> > 
> 
> Yes, static const should be used.
> 
> > 
> > > +/*** module functions ***/
> > > +
> > > +static int __init rbtn_init(void)
> > > +{
> > > +	return acpi_bus_register_driver(&rbtn_driver);
> > > +}
> > > +
> > > +static void __exit rbtn_exit(void)
> > > +{
> > > +	acpi_bus_unregister_driver(&rbtn_driver);
> > > +}
> > > +
> > > +module_init(rbtn_init);
> > > +module_exit(rbtn_exit);
> > 
> > module_acpi_driver()?
> > 
> 
> No, see PATCH 2/3.

Yeah, I noticed it after I wrote the comment.

Re: [PATCH 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Darren Hart]

On Fri, Nov 28, 2014 at 01:54:57PM +0200, Mika Westerberg wrote:
> On Fri, Nov 28, 2014 at 12:45:55PM +0100, Pali Rohár wrote:
> > Hello,
> > 
> > I will fix all those style problems and add some comments.
> > 
> > On Friday 28 November 2014 12:33:28 Mika Westerberg wrote:
> > > > +	if (ACPI_FAILURE(status))
> > > > +		return;
> > > > +
> > > > +	rfkill_set_states(rfkill, !output, !output);
> > > 
> > > You can also write it like:
> > > 
> > > 	if (ACPI_SUCCESS(status))
> > > 		rfkill_set_states(rfkill, !output, !output);
> > > 
> > > which looks better to me at least.
> > > 
> > 
> > In whole module I'm using this style:
> > 
> > f1();
> > if (f1_failed)
> > 	return;
> > f2()
> > if (f2_failed)
> > 	return;
> > 
> > So I would like not to change it for one function.
> 
> Fair enough.

And, in my opinion, it is better to test for errors than to test for success.
This keeps the main logic out of a nested block. Not so critical here, but a
good rule of thumb.

-- 
Darren Hart
Intel Open Source Technology Center

[PATCH 2/3] platform: x86: dell-rbtn: Export notifier for other kernel modules

[Pali Rohár]

This patch exports notifier functions so other modules can receive HW switch
events. By default when some module register notifier, dell-rbtn driver
automatically remove rfkill interfaces from system (it is expected that other
module will use events for other rfkill interface). This behaviour can be
changed with new module parameter "auto_remove_rfkill".

This patch is designed for dell-laptop module for receiving those events.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
---
 drivers/platform/x86/dell-rbtn.c |   87 ++++++++++++++++++++++++++++++++++++--
 drivers/platform/x86/dell-rbtn.h |   35 +++++++++++++++
 2 files changed, 119 insertions(+), 3 deletions(-)
 create mode 100644 drivers/platform/x86/dell-rbtn.h

diff --git a/drivers/platform/x86/dell-rbtn.c b/drivers/platform/x86/dell-rbtn.c
index f1f039a..69c17e8 100644
--- a/drivers/platform/x86/dell-rbtn.c
+++ b/drivers/platform/x86/dell-rbtn.c
@@ -128,6 +128,74 @@ static void rbtn_disable(struct acpi_device *device)
 }
 
 
+/*** notifier export functions ***/
+
+static bool auto_remove_rfkill = true;
+
+static ATOMIC_NOTIFIER_HEAD(rbtn_chain_head);
+
+static int rbtn_inc_count(struct device *dev, void *data)
+{
+	int *count = data;
+
+	(*count)++;
+	return 0;
+}
+
+static int rbtn_switch_dev(struct device *dev, void *data)
+{
+	struct acpi_device *device = to_acpi_device(dev);
+	bool enable = data;
+
+	if (enable)
+		rbtn_enable(device);
+	else
+		rbtn_disable(device);
+
+	return 0;
+}
+
+int dell_rbtn_notifier_register(struct notifier_block *nb)
+{
+	int ret;
+	bool first;
+
+	ret = 0;
+	driver_for_each_device(&rbtn_driver.drv, NULL, &ret, rbtn_inc_count);
+	if (ret == 0)
+		return -ENODEV;
+
+	first = !rbtn_chain_head.head;
+
+	ret = atomic_notifier_chain_register(&rbtn_chain_head, nb);
+	if (ret != 0)
+		return ret;
+
+	if (auto_remove_rfkill && first)
+		driver_for_each_device(&rbtn_driver.drv, NULL, (void *)false,
+				       rbtn_switch_dev);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(dell_rbtn_notifier_register);
+
+int dell_rbtn_notifier_unregister(struct notifier_block *nb)
+{
+	int ret;
+
+	ret = atomic_notifier_chain_unregister(&rbtn_chain_head, nb);
+	if (ret != 0)
+		return ret;
+
+	if (auto_remove_rfkill && !rbtn_chain_head.head)
+		driver_for_each_device(&rbtn_driver.drv, NULL, (void *)true,
+				       rbtn_switch_dev);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(dell_rbtn_notifier_unregister);
+
+
 /*** acpi driver functions ***/
 
 static int rbtn_add(struct acpi_device *device)
@@ -138,6 +206,9 @@ static int rbtn_add(struct acpi_device *device)
 	if (ret < 0)
 		return ret;
 
+	if (auto_remove_rfkill && rbtn_chain_head.head)
+		return 0;
+
 	return rbtn_enable(device);
 }
 
@@ -151,10 +222,13 @@ static void rbtn_notify(struct acpi_device *device, u32 event)
 {
 	struct rfkill *rfkill = device->driver_data;
 
-	if (event == 0x80)
+	if (rfkill && event == 0x80)
 		rbtn_query(rfkill, device);
-	else
+
+	if (!rbtn_chain_head.head && event != 0x80)
 		dev_info(&device->dev, "Received unknown event (0x%x)\n", event);
+
+	atomic_notifier_call_chain(&rbtn_chain_head, event, device);
 }
 
 
@@ -162,7 +236,9 @@ static void rbtn_notify(struct acpi_device *device, u32 event)
 
 static int __init rbtn_init(void)
 {
-	return acpi_bus_register_driver(&rbtn_driver);
+	/* ignore errors so module always loads and exports needed functions */
+	acpi_bus_register_driver(&rbtn_driver);
+	return 0;
 }
 
 static void __exit rbtn_exit(void)
@@ -170,9 +246,14 @@ static void __exit rbtn_exit(void)
 	acpi_bus_unregister_driver(&rbtn_driver);
 }
 
+module_param(auto_remove_rfkill, bool, 0444);
 module_init(rbtn_init);
 module_exit(rbtn_exit);
 
+MODULE_PARM_DESC(auto_remove_rfkill, "automatically remove rfkill devices when "
+				     "other module start receiving events from "
+				     "this module and re-add them when last "
+				     "module stop receving events");
 MODULE_DEVICE_TABLE(acpi, rbtn_ids);
 MODULE_DESCRIPTION("Dell Airplane Mode Switch driver");
 MODULE_AUTHOR("Pali Rohár <pali.rohar@gmail.com>");
diff --git a/drivers/platform/x86/dell-rbtn.h b/drivers/platform/x86/dell-rbtn.h
new file mode 100644
index 0000000..41ffbc8
--- /dev/null
+++ b/drivers/platform/x86/dell-rbtn.h
@@ -0,0 +1,35 @@
+/*
+    Dell Airplane Mode Switch driver
+    Copyright (C) 2014  Pali Rohár <pali.rohar@gmail.com>
+
+    This program is free software; you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+*/
+
+#ifndef _DELL_RBTN_H_
+#define _DELL_RBTN_H_
+
+struct notifier_block;
+
+#if defined(CONFIG_DELL_RBTN) || defined(CONFIG_DELL_RBTN_MODULE)
+int dell_rbtn_notifier_register(struct notifier_block *nb);
+int dell_rbtn_notifier_unregister(struct notifier_block *nb);
+#else
+static inline int dell_rbtn_notifier_register(struct notifier_block *nb)
+{
+	return -ENODEV;
+}
+static inline int dell_rbtn_notifier_unregister(struct notifier_block *nb)
+{
+	return -ENODEV;
+}
+#endif
+
+#endif
-- 
1.7.9.5

Re: [PATCH 2/3] platform: x86: dell-rbtn: Export notifier for other kernel modules

[Darren Hart]

On Sun, Nov 23, 2014 at 04:09:20PM +0100, Pali Rohár wrote:
> This patch exports notifier functions so other modules can receive HW switch
> events. By default when some module register notifier, dell-rbtn driver

The commit message needs to describe the problem being addressed as well. Why is
this necessary?

> automatically remove rfkill interfaces from system (it is expected that other
> module will use events for other rfkill interface). This behaviour can be
> changed with new module parameter "auto_remove_rfkill".

We try to avoid using such parameters to define behavior when possible.

Why is it justified to use auto_remove_rfkill here? When is it needed? As
opposed to doing something that works based on the detected hardware? (It could
be this is the right thing, but we have to justify it).

> 
> This patch is designed for dell-laptop module for receiving those events.
> 
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> ---
>  drivers/platform/x86/dell-rbtn.c |   87 ++++++++++++++++++++++++++++++++++++--
>  drivers/platform/x86/dell-rbtn.h |   35 +++++++++++++++
>  2 files changed, 119 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/platform/x86/dell-rbtn.h
> 
> diff --git a/drivers/platform/x86/dell-rbtn.c b/drivers/platform/x86/dell-rbtn.c
> index f1f039a..69c17e8 100644
> --- a/drivers/platform/x86/dell-rbtn.c
> +++ b/drivers/platform/x86/dell-rbtn.c
> @@ -128,6 +128,74 @@ static void rbtn_disable(struct acpi_device *device)
>  }
>  
>  
> +/*** notifier export functions ***/
> +

If you want to emphasize a comment, use a block comment. Apply throughout.

/*
 * notifier export functions
 */

> +static bool auto_remove_rfkill = true;
> +
> +static ATOMIC_NOTIFIER_HEAD(rbtn_chain_head);
> +
> +static int rbtn_inc_count(struct device *dev, void *data)
> +{
> +	int *count = data;
> +
> +	(*count)++;
> +	return 0;
> +}
> +
> +static int rbtn_switch_dev(struct device *dev, void *data)
> +{
> +	struct acpi_device *device = to_acpi_device(dev);
> +	bool enable = data;
> +
> +	if (enable)
> +		rbtn_enable(device);
> +	else
> +		rbtn_disable(device);
> +
> +	return 0;
> +}
> +
> +int dell_rbtn_notifier_register(struct notifier_block *nb)
> +{
> +	int ret;
> +	bool first;

Descending line length order. Apply throughout where feasible.

	bool first;
	int ret;

> +
> +	ret = 0;
> +	driver_for_each_device(&rbtn_driver.drv, NULL, &ret, rbtn_inc_count);
> +	if (ret == 0)
> +		return -ENODEV;
> +
> +	first = !rbtn_chain_head.head;

Maybe it's just late... but "first" what?

> +
> +	ret = atomic_notifier_chain_register(&rbtn_chain_head, nb);
> +	if (ret != 0)
> +		return ret;
> +
> +	if (auto_remove_rfkill && first)
> +		driver_for_each_device(&rbtn_driver.drv, NULL, (void *)false,
> +				       rbtn_switch_dev);
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(dell_rbtn_notifier_register);
> +
> +int dell_rbtn_notifier_unregister(struct notifier_block *nb)
> +{
> +	int ret;
> +
> +	ret = atomic_notifier_chain_unregister(&rbtn_chain_head, nb);
> +	if (ret != 0)
> +		return ret;
> +
> +	if (auto_remove_rfkill && !rbtn_chain_head.head)
> +		driver_for_each_device(&rbtn_driver.drv, NULL, (void *)true,
> +				       rbtn_switch_dev);
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(dell_rbtn_notifier_unregister);
> +
> +
>  /*** acpi driver functions ***/
>  
>  static int rbtn_add(struct acpi_device *device)
> @@ -138,6 +206,9 @@ static int rbtn_add(struct acpi_device *device)
>  	if (ret < 0)
>  		return ret;
>  
> +	if (auto_remove_rfkill && rbtn_chain_head.head)
> +		return 0;
> +
>  	return rbtn_enable(device);
>  }
>  
> @@ -151,10 +222,13 @@ static void rbtn_notify(struct acpi_device *device, u32 event)
>  {
>  	struct rfkill *rfkill = device->driver_data;
>  
> -	if (event == 0x80)
> +	if (rfkill && event == 0x80)
>  		rbtn_query(rfkill, device);
> -	else
> +
> +	if (!rbtn_chain_head.head && event != 0x80)
>  		dev_info(&device->dev, "Received unknown event (0x%x)\n", event);
> +
> +	atomic_notifier_call_chain(&rbtn_chain_head, event, device);
>  }
>  
>  
> @@ -162,7 +236,9 @@ static void rbtn_notify(struct acpi_device *device, u32 event)
>  
>  static int __init rbtn_init(void)
>  {
> -	return acpi_bus_register_driver(&rbtn_driver);
> +	/* ignore errors so module always loads and exports needed functions */
> +	acpi_bus_register_driver(&rbtn_driver);
> +	return 0;
>  }
>  
>  static void __exit rbtn_exit(void)
> @@ -170,9 +246,14 @@ static void __exit rbtn_exit(void)
>  	acpi_bus_unregister_driver(&rbtn_driver);
>  }
>  
> +module_param(auto_remove_rfkill, bool, 0444);
>  module_init(rbtn_init);
>  module_exit(rbtn_exit);
>  
> +MODULE_PARM_DESC(auto_remove_rfkill, "automatically remove rfkill devices when "
> +				     "other module start receiving events from "

another module starts

> +				     "this module and re-add them when last "

when the last

> +				     "module stop receving events");

stops

>  MODULE_DEVICE_TABLE(acpi, rbtn_ids);
>  MODULE_DESCRIPTION("Dell Airplane Mode Switch driver");
>  MODULE_AUTHOR("Pali Rohár <pali.rohar@gmail.com>");
> diff --git a/drivers/platform/x86/dell-rbtn.h b/drivers/platform/x86/dell-rbtn.h
> new file mode 100644
> index 0000000..41ffbc8
> --- /dev/null
> +++ b/drivers/platform/x86/dell-rbtn.h
> @@ -0,0 +1,35 @@
> +/*
> +    Dell Airplane Mode Switch driver
> +    Copyright (C) 2014  Pali Rohár <pali.rohar@gmail.com>
> +
> +    This program is free software; you can redistribute it and/or modify
> +    it under the terms of the GNU General Public License as published by
> +    the Free Software Foundation; either version 2 of the License, or
> +    (at your option) any later version.
> +
> +    This program is distributed in the hope that it will be useful,
> +    but WITHOUT ANY WARRANTY; without even the implied warranty of
> +    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +    GNU General Public License for more details.
> +*/

See Mika's comments on block quote formatting.

> +
> +#ifndef _DELL_RBTN_H_
> +#define _DELL_RBTN_H_
> +
> +struct notifier_block;
> +
> +#if defined(CONFIG_DELL_RBTN) || defined(CONFIG_DELL_RBTN_MODULE)
> +int dell_rbtn_notifier_register(struct notifier_block *nb);
> +int dell_rbtn_notifier_unregister(struct notifier_block *nb);
> +#else
> +static inline int dell_rbtn_notifier_register(struct notifier_block *nb)
> +{
> +	return -ENODEV;
> +}
> +static inline int dell_rbtn_notifier_unregister(struct notifier_block *nb)
> +{
> +	return -ENODEV;
> +}
> +#endif
> +
> +#endif
> -- 
> 1.7.9.5
> 
> 

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH 2/3] platform: x86: dell-rbtn: Export notifier for other kernel modules

[Pali Rohár]

On Tuesday 25 November 2014 14:39:37 Darren Hart wrote:
> On Sun, Nov 23, 2014 at 04:09:20PM +0100, Pali Rohár wrote:
> > This patch exports notifier functions so other modules can receive HW switch
> > events. By default when some module register notifier, dell-rbtn driver
> 
> The commit message needs to describe the problem being addressed as well. Why is
> this necessary?
> 

Needed for next patch (3/3). All 3 patches are one series, so I do no
think that everything is needed to describe...

> > automatically remove rfkill interfaces from system (it is expected that other
> > module will use events for other rfkill interface). This behaviour can be
> > changed with new module parameter "auto_remove_rfkill".
> 
> We try to avoid using such parameters to define behavior when possible.
> 
> Why is it justified to use auto_remove_rfkill here? When is it needed? As
> opposed to doing something that works based on the detected hardware? (It could
> be this is the right thing, but we have to justify it).
> 

Just for future if something goes wrong and new Dell BIOS stopped
working. So users would be able to "hotfix" unexpected problems.

As Alex wrote, some machine has already BIOS bug...

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

[PATCH 3/3] platform: x86: dell-laptop: Use dell-rbtn instead i8042 filter when possible

[Pali Rohár]

Until now module dell-laptop registered rfkill device which used i8042 filter
function for receiving HW switch rfkill events (handling special keycode).

But for some dell laptops there is native ACPI driver dell-rbtn which can
receive rfkill events (without i8042 hacks). On some machines it can also
control rfkill devices, but can turn on/off all radio devices.

So this patch will combine best from both sides. It will use native ACPI driver
dell-rbtn for receiving events and dell-laptop SMBIOS interface for enabling or
disabling radio devices. If ACPI driver or device will not be available fallback
to i8042 filter function will be used.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
---
 drivers/platform/x86/Kconfig       |    1 +
 drivers/platform/x86/dell-laptop.c |   67 +++++++++++++++++++++++++++++++++---
 2 files changed, 63 insertions(+), 5 deletions(-)

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 5a2ba64..6fbbbbb 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -96,6 +96,7 @@ config DELL_LAPTOP
 	depends on BACKLIGHT_CLASS_DEVICE
 	depends on RFKILL || RFKILL = n
 	depends on SERIO_I8042
+	select DELL_RBTN
 	select POWER_SUPPLY
 	select LEDS_CLASS
 	select NEW_LEDS
diff --git a/drivers/platform/x86/dell-laptop.c b/drivers/platform/x86/dell-laptop.c
index 233d2ee..5d08c81 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -30,6 +30,7 @@
 #include <linux/debugfs.h>
 #include <linux/seq_file.h>
 #include "../../firmware/dcdbas.h"
+#include "dell-rbtn.h"
 
 #define BRIGHTNESS_TOKEN 0x7d
 
@@ -583,6 +584,20 @@ static bool dell_laptop_i8042_filter(unsigned char data, unsigned char str,
 	return false;
 }
 
+static bool dell_laptop_use_rbtn;
+
+static int dell_laptop_rbtn_notifier_call(struct notifier_block *nb,
+					  unsigned long action, void *data)
+{
+	schedule_delayed_work(&dell_rfkill_work,
+			      round_jiffies_relative(HZ / 4));
+	return NOTIFY_OK;
+}
+
+static struct notifier_block dell_laptop_rbtn_notifier = {
+	.notifier_call = dell_laptop_rbtn_notifier_call,
+};
+
 static int __init dell_setup_rfkill(void)
 {
 	int status, ret, whitelisted;
@@ -659,10 +674,46 @@ static int __init dell_setup_rfkill(void)
 			goto err_wwan;
 	}
 
-	ret = i8042_install_filter(dell_laptop_i8042_filter);
-	if (ret) {
-		pr_warn("Unable to install key filter\n");
+	/*
+	 * Dell Airplane Mode Switch driver (dell-rbtn) supports ACPI devices
+	 * which can receive HW button switch events and also can control radio
+	 * devices. Somtimes ACPI device supports only reciving events (without
+	 * enable/disable software control).
+	 *
+	 * Dell SMBIOS on whitelisted models supports controlling radio devices
+	 * but does not support receiving HW button switch events. We can use
+	 * i8042 filter hook function to receive keyboard data and handle
+	 * keycode for HW button.
+	 *
+	 * Dell Airplane Mode Switch driver supports only one rfkill switch
+	 * which enable/disable all radio devices. But Dell SMBIOS supports more
+	 * granularity and can enable/disable also one type of radio device
+	 * (e.g disable only bluetooth device without touching wifi device).
+	 *
+	 * So if it is possible we will use Dell Airplane Mode Switch ACPI
+	 * driver for receiving HW events and Dell SMBIOS for setting rfkill
+	 * states. If ACPI driver or device is not available we will fallback to
+	 * i8042 filter hook function.
+	 *
+	 * To prevent duplicate rfkill devices which control and do same thing,
+	 * dell-rbtn driver will automatically remove its own rfkill devices
+	 * once function dell_rbtn_notifier_register() is called.
+	 */
+
+	ret = dell_rbtn_notifier_register(&dell_laptop_rbtn_notifier);
+	if (ret == 0) {
+		pr_info("Using dell-rbtn acpi driver for receiving events\n");
+		dell_laptop_use_rbtn = true;
+	} else if (ret != -ENODEV) {
+		pr_warn("Unable to register dell rbtn notifier\n");
 		goto err_filter;
+	} else {
+		ret = i8042_install_filter(dell_laptop_i8042_filter);
+		if (ret) {
+			pr_warn("Unable to install key filter\n");
+			goto err_filter;
+		}
+		pr_info("Using i8042 filter function for receiving events\n");
 	}
 
 	return 0;
@@ -888,7 +939,10 @@ static int __init dell_init(void)
 	return 0;
 
 fail_backlight:
-	i8042_remove_filter(dell_laptop_i8042_filter);
+	if (dell_laptop_use_rbtn)
+		dell_rbtn_notifier_unregister(&dell_laptop_rbtn_notifier);
+	else
+		i8042_remove_filter(dell_laptop_i8042_filter);
 	cancel_delayed_work_sync(&dell_rfkill_work);
 	dell_cleanup_rfkill();
 fail_rfkill:
@@ -909,7 +963,10 @@ static void __exit dell_exit(void)
 	debugfs_remove_recursive(dell_laptop_dir);
 	if (quirks && quirks->touchpad_led)
 		touchpad_led_exit();
-	i8042_remove_filter(dell_laptop_i8042_filter);
+	if (dell_laptop_use_rbtn)
+		dell_rbtn_notifier_unregister(&dell_laptop_rbtn_notifier);
+	else
+		i8042_remove_filter(dell_laptop_i8042_filter);
 	cancel_delayed_work_sync(&dell_rfkill_work);
 	backlight_device_unregister(dell_backlight_device);
 	dell_cleanup_rfkill();
-- 
1.7.9.5

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

[Darren Hart]

On Sun, Nov 23, 2014 at 04:09:18PM +0100, Pali Rohár wrote:
> This patch series add new acpi Dell Airplane Mode Switch driver (DELLABCE and
> DELRBTN acpi devices). It provides radio HW switch events (together with current
> state of radio devices) and export them via rfkill interface. These events are
> also used in dell-laptop driver instead i8042 filter hook function (when acpi
> device is available).
> 
> Pali Rohár (3):
>   platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
>   platform: x86: dell-rbtn: Export notifier for other kernel modules
>   platform: x86: dell-laptop: Use dell-rbtn instead i8042 filter when
>     possible
> 
>  drivers/platform/x86/Kconfig       |   14 ++
>  drivers/platform/x86/Makefile      |    1 +
>  drivers/platform/x86/dell-laptop.c |   67 +++++++++-
>  drivers/platform/x86/dell-rbtn.c   |  260 ++++++++++++++++++++++++++++++++++++
>  drivers/platform/x86/dell-rbtn.h   |   35 +++++
>  5 files changed, 372 insertions(+), 5 deletions(-)
>  create mode 100644 drivers/platform/x86/dell-rbtn.c
>  create mode 100644 drivers/platform/x86/dell-rbtn.h

Alex, it is my understanding that this solution from Pali is a more complete
solution to dealing with the variety of dell wireless buttons and rfkill
mechanisms in the world today.

I currently have:
7c4d961 dell-wireless: new driver for dell wireless button for Windows 8
queued in for-next. If I have read your responses on this correctly, are we all
in agreement that I should drop the above patch, and apply these?

-- 
Darren Hart
Intel Open Source Technology Center

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

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 2201 bytes --]

On Wednesday 26 November 2014 00:05:28 Darren Hart wrote:
> On Sun, Nov 23, 2014 at 04:09:18PM +0100, Pali Rohár wrote:
> > This patch series add new acpi Dell Airplane Mode Switch
> > driver (DELLABCE and DELRBTN acpi devices). It provides
> > radio HW switch events (together with current state of
> > radio devices) and export them via rfkill interface. These
> > events are also used in dell-laptop driver instead i8042
> > filter hook function (when acpi device is available).
> > 
> > Pali Rohár (3):
> >   platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
> >   platform: x86: dell-rbtn: Export notifier for other kernel
> >   modules platform: x86: dell-laptop: Use dell-rbtn instead
> >   i8042 filter when
> >   
> >     possible
> >  
> >  drivers/platform/x86/Kconfig       |   14 ++
> >  drivers/platform/x86/Makefile      |    1 +
> >  drivers/platform/x86/dell-laptop.c |   67 +++++++++-
> >  drivers/platform/x86/dell-rbtn.c   |  260
> >  ++++++++++++++++++++++++++++++++++++
> >  drivers/platform/x86/dell-rbtn.h   |   35 +++++
> >  5 files changed, 372 insertions(+), 5 deletions(-)
> >  create mode 100644 drivers/platform/x86/dell-rbtn.c
> >  create mode 100644 drivers/platform/x86/dell-rbtn.h
> 
> Alex, it is my understanding that this solution from Pali is a
> more complete solution to dealing with the variety of dell
> wireless buttons and rfkill mechanisms in the world today.
> 
> I currently have:
> 7c4d961 dell-wireless: new driver for dell wireless button for
> Windows 8 queued in for-next. If I have read your responses
> on this correctly, are we all in agreement that I should drop
> the above patch, and apply these?

Darren, it it truth that some laptops does not send keypress 
event when Fn+wifi key is pressed (but only send ACPI event), 
then really Alex's patch for input device is needed. But it could 
be integrated into my driver. Also Alex wrote something about 
ACPI events for laptops which have wifi key instead HW switch. So 
before including this patch into tree, I would like to hear what 
is problem with my patch for laptops which have wifi key...

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Alex Hung]

HI Darren and Pali,

It was great that we had a lot of discussion but it seems Dell BIOS
implementation varies from one series to another. Both work looks good
either one is fine with me.

But I think I can do a little more: I am collecting a number of
systems to try out these patches. This should help us determine which
one work better and probably we can integrate.

Currently I have found four systems (including two Latitude, an
Inspiron and a XPS with working method(ARBT) that Gabriele suggested).
I can get other, ex. a Vostro, if needed.

I will test dell-wireless.c with Gabriele's suggestion and Pali's
dell-rbtn.c (btw, will there be updates?). However, I will need a few
days to do the comparison.

Any suggested test cases?

Cheers,
Alex Hung


On Tue, Dec 2, 2014 at 4:42 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Wednesday 26 November 2014 00:05:28 Darren Hart wrote:
>> On Sun, Nov 23, 2014 at 04:09:18PM +0100, Pali Rohár wrote:
>> > This patch series add new acpi Dell Airplane Mode Switch
>> > driver (DELLABCE and DELRBTN acpi devices). It provides
>> > radio HW switch events (together with current state of
>> > radio devices) and export them via rfkill interface. These
>> > events are also used in dell-laptop driver instead i8042
>> > filter hook function (when acpi device is available).
>> >
>> > Pali Rohár (3):
>> >   platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
>> >   platform: x86: dell-rbtn: Export notifier for other kernel
>> >   modules platform: x86: dell-laptop: Use dell-rbtn instead
>> >   i8042 filter when
>> >
>> >     possible
>> >
>> >  drivers/platform/x86/Kconfig       |   14 ++
>> >  drivers/platform/x86/Makefile      |    1 +
>> >  drivers/platform/x86/dell-laptop.c |   67 +++++++++-
>> >  drivers/platform/x86/dell-rbtn.c   |  260
>> >  ++++++++++++++++++++++++++++++++++++
>> >  drivers/platform/x86/dell-rbtn.h   |   35 +++++
>> >  5 files changed, 372 insertions(+), 5 deletions(-)
>> >  create mode 100644 drivers/platform/x86/dell-rbtn.c
>> >  create mode 100644 drivers/platform/x86/dell-rbtn.h
>>
>> Alex, it is my understanding that this solution from Pali is a
>> more complete solution to dealing with the variety of dell
>> wireless buttons and rfkill mechanisms in the world today.
>>
>> I currently have:
>> 7c4d961 dell-wireless: new driver for dell wireless button for
>> Windows 8 queued in for-next. If I have read your responses
>> on this correctly, are we all in agreement that I should drop
>> the above patch, and apply these?
>
> Darren, it it truth that some laptops does not send keypress
> event when Fn+wifi key is pressed (but only send ACPI event),
> then really Alex's patch for input device is needed. But it could
> be integrated into my driver. Also Alex wrote something about
> ACPI events for laptops which have wifi key instead HW switch. So
> before including this patch into tree, I would like to hear what
> is problem with my patch for laptops which have wifi key...
>
> --
> Pali Rohár
> pali.rohar@gmail.com



-- 
Cheers,
Alex Hung

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

[Alex Hung]

HI Darren and Pali,

It was great that we had a lot of discussion but it seems Dell BIOS
implementation varies from one series to another. Both work looks good
either one is fine with me.

But I think I can do a little more: I am collecting a number of
systems to try out these patches. This should help us determine which
one work better and probably we can integrate.

Currently I have found four systems (including two Latitude, an
Inspiron and a XPS with working method(ARBT) that Gabriele suggested).
I can get other, ex. a Vostro, if needed.

I will test dell-wireless.c with Gabriele's suggestion and Pali's
dell-rbtn.c (btw, will there be updates?). However, I will need a few
days to do the comparison.

Any suggested test cases?

Cheers,
Alex Hung


On Tue, Dec 2, 2014 at 4:42 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Wednesday 26 November 2014 00:05:28 Darren Hart wrote:
>> On Sun, Nov 23, 2014 at 04:09:18PM +0100, Pali Rohár wrote:
>> > This patch series add new acpi Dell Airplane Mode Switch
>> > driver (DELLABCE and DELRBTN acpi devices). It provides
>> > radio HW switch events (together with current state of
>> > radio devices) and export them via rfkill interface. These
>> > events are also used in dell-laptop driver instead i8042
>> > filter hook function (when acpi device is available).
>> >
>> > Pali Rohár (3):
>> >   platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
>> >   platform: x86: dell-rbtn: Export notifier for other kernel
>> >   modules platform: x86: dell-laptop: Use dell-rbtn instead
>> >   i8042 filter when
>> >
>> >     possible
>> >
>> >  drivers/platform/x86/Kconfig       |   14 ++
>> >  drivers/platform/x86/Makefile      |    1 +
>> >  drivers/platform/x86/dell-laptop.c |   67 +++++++++-
>> >  drivers/platform/x86/dell-rbtn.c   |  260
>> >  ++++++++++++++++++++++++++++++++++++
>> >  drivers/platform/x86/dell-rbtn.h   |   35 +++++
>> >  5 files changed, 372 insertions(+), 5 deletions(-)
>> >  create mode 100644 drivers/platform/x86/dell-rbtn.c
>> >  create mode 100644 drivers/platform/x86/dell-rbtn.h
>>
>> Alex, it is my understanding that this solution from Pali is a
>> more complete solution to dealing with the variety of dell
>> wireless buttons and rfkill mechanisms in the world today.
>>
>> I currently have:
>> 7c4d961 dell-wireless: new driver for dell wireless button for
>> Windows 8 queued in for-next. If I have read your responses
>> on this correctly, are we all in agreement that I should drop
>> the above patch, and apply these?
>
> Darren, it it truth that some laptops does not send keypress
> event when Fn+wifi key is pressed (but only send ACPI event),
> then really Alex's patch for input device is needed. But it could
> be integrated into my driver. Also Alex wrote something about
> ACPI events for laptops which have wifi key instead HW switch. So
> before including this patch into tree, I would like to hear what
> is problem with my patch for laptops which have wifi key...
>
> --
> Pali Rohár
> pali.rohar@gmail.com



-- 
Cheers,
Alex Hung

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

[Darren Hart]

On Thu, Dec 04, 2014 at 04:16:25PM +0800, Alex Hung wrote:
> HI Darren and Pali,
> 
> It was great that we had a lot of discussion but it seems Dell BIOS
> implementation varies from one series to another. Both work looks good
> either one is fine with me.
> 
> But I think I can do a little more: I am collecting a number of
> systems to try out these patches. This should help us determine which
> one work better and probably we can integrate.
> 
> Currently I have found four systems (including two Latitude, an
> Inspiron and a XPS with working method(ARBT) that Gabriele suggested).
> I can get other, ex. a Vostro, if needed.
> 
> I will test dell-wireless.c with Gabriele's suggestion and Pali's
> dell-rbtn.c (btw, will there be updates?). However, I will need a few
> days to do the comparison.

OK, this is great, thanks for working together on this.

Pali - if I merge Alex's dell-wireless driver, does it BREAK your systems, or
does it just not fully support them? If it BREAKS them, I'll drop Alex's patch
from for-next and from the 3.19 pull requeust. If it just doesn't fully support
them, I'll leave his patch in for-next and look forward to a set of patches from
you both that completes support for the 3.20 merge window.

Please let me know as soon as you can.

If I don't hear back, I'll have to err on the side of caution and drop
dell-wireless from for-next for this window.

-- 
Darren Hart
Intel Open Source Technology Center

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

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 4338 bytes --]

On Thursday 04 December 2014 09:16:25 Alex Hung wrote:
> HI Darren and Pali,
> 
> It was great that we had a lot of discussion but it seems Dell
> BIOS implementation varies from one series to another. Both
> work looks good either one is fine with me.
> 

Alex, am I right that your dell-wireless.c do nothing for laptops 
with HW switch (when CRBT returns 2 or 3)?

If yes, then for these laptops we do not need dell-wireless.c and 
my dell-rbtn.c is better.

> But I think I can do a little more: I am collecting a number
> of systems to try out these patches. This should help us
> determine which one work better and probably we can
> integrate.
> 

Yes, sure.

> Currently I have found four systems (including two Latitude,
> an Inspiron and a XPS with working method(ARBT) that Gabriele
> suggested). I can get other, ex. a Vostro, if needed.
> 

Do you know what should ARBT method do?

> I will test dell-wireless.c with Gabriele's suggestion and
> Pali's dell-rbtn.c (btw, will there be updates?). However, I
> will need a few days to do the comparison.
> 

Until we would know how to *properly* set soft rfkill state and 
what ARBT is doing on more machines, I'm not going to update my 
dell-rbtn.c (as it is for now complete).

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.

> Any suggested test cases?
> 

Check if wlan key is reported via WMI or AT Keyboard also without 
dell-wireless.c.

Check if dell-rbtn.c show correct hard rfkill state (on all 
tested machines) when pressing wlan key more times (or switching 
HW-slide switch).

> Cheers,
> Alex Hung
> 
> On Tue, Dec 2, 2014 at 4:42 PM, Pali Rohár 
<pali.rohar@gmail.com> wrote:
> > On Wednesday 26 November 2014 00:05:28 Darren Hart wrote:
> >> On Sun, Nov 23, 2014 at 04:09:18PM +0100, Pali Rohár wrote:
> >> > This patch series add new acpi Dell Airplane Mode Switch
> >> > driver (DELLABCE and DELRBTN acpi devices). It provides
> >> > radio HW switch events (together with current state of
> >> > radio devices) and export them via rfkill interface.
> >> > These events are also used in dell-laptop driver instead
> >> > i8042 filter hook function (when acpi device is
> >> > available).
> >> > 
> >> > Pali Rohár (3):
> >> >   platform: x86: dell-rbtn: Dell Airplane Mode Switch
> >> >   driver platform: x86: dell-rbtn: Export notifier for
> >> >   other kernel modules platform: x86: dell-laptop: Use
> >> >   dell-rbtn instead i8042 filter when
> >> >   
> >> >     possible
> >> >  
> >> >  drivers/platform/x86/Kconfig       |   14 ++
> >> >  drivers/platform/x86/Makefile      |    1 +
> >> >  drivers/platform/x86/dell-laptop.c |   67 +++++++++-
> >> >  drivers/platform/x86/dell-rbtn.c   |  260
> >> >  ++++++++++++++++++++++++++++++++++++
> >> >  drivers/platform/x86/dell-rbtn.h   |   35 +++++
> >> >  5 files changed, 372 insertions(+), 5 deletions(-)
> >> >  create mode 100644 drivers/platform/x86/dell-rbtn.c
> >> >  create mode 100644 drivers/platform/x86/dell-rbtn.h
> >> 
> >> Alex, it is my understanding that this solution from Pali
> >> is a more complete solution to dealing with the variety of
> >> dell wireless buttons and rfkill mechanisms in the world
> >> today.
> >> 
> >> I currently have:
> >> 7c4d961 dell-wireless: new driver for dell wireless button
> >> for Windows 8 queued in for-next. If I have read your
> >> responses on this correctly, are we all in agreement that
> >> I should drop the above patch, and apply these?
> > 
> > Darren, it it truth that some laptops does not send keypress
> > event when Fn+wifi key is pressed (but only send ACPI
> > event), then really Alex's patch for input device is
> > needed. But it could be integrated into my driver. Also
> > Alex wrote something about ACPI events for laptops which
> > have wifi key instead HW switch. So before including this
> > patch into tree, I would like to hear what is problem with
> > my patch for laptops which have wifi key...
> > 
> > --
> > Pali Rohár
> > pali.rohar@gmail.com

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 4338 bytes --]

On Thursday 04 December 2014 09:16:25 Alex Hung wrote:
> HI Darren and Pali,
> 
> It was great that we had a lot of discussion but it seems Dell
> BIOS implementation varies from one series to another. Both
> work looks good either one is fine with me.
> 

Alex, am I right that your dell-wireless.c do nothing for laptops 
with HW switch (when CRBT returns 2 or 3)?

If yes, then for these laptops we do not need dell-wireless.c and 
my dell-rbtn.c is better.

> But I think I can do a little more: I am collecting a number
> of systems to try out these patches. This should help us
> determine which one work better and probably we can
> integrate.
> 

Yes, sure.

> Currently I have found four systems (including two Latitude,
> an Inspiron and a XPS with working method(ARBT) that Gabriele
> suggested). I can get other, ex. a Vostro, if needed.
> 

Do you know what should ARBT method do?

> I will test dell-wireless.c with Gabriele's suggestion and
> Pali's dell-rbtn.c (btw, will there be updates?). However, I
> will need a few days to do the comparison.
> 

Until we would know how to *properly* set soft rfkill state and 
what ARBT is doing on more machines, I'm not going to update my 
dell-rbtn.c (as it is for now complete).

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.

> Any suggested test cases?
> 

Check if wlan key is reported via WMI or AT Keyboard also without 
dell-wireless.c.

Check if dell-rbtn.c show correct hard rfkill state (on all 
tested machines) when pressing wlan key more times (or switching 
HW-slide switch).

> Cheers,
> Alex Hung
> 
> On Tue, Dec 2, 2014 at 4:42 PM, Pali Rohár 
<pali.rohar@gmail.com> wrote:
> > On Wednesday 26 November 2014 00:05:28 Darren Hart wrote:
> >> On Sun, Nov 23, 2014 at 04:09:18PM +0100, Pali Rohár wrote:
> >> > This patch series add new acpi Dell Airplane Mode Switch
> >> > driver (DELLABCE and DELRBTN acpi devices). It provides
> >> > radio HW switch events (together with current state of
> >> > radio devices) and export them via rfkill interface.
> >> > These events are also used in dell-laptop driver instead
> >> > i8042 filter hook function (when acpi device is
> >> > available).
> >> > 
> >> > Pali Rohár (3):
> >> >   platform: x86: dell-rbtn: Dell Airplane Mode Switch
> >> >   driver platform: x86: dell-rbtn: Export notifier for
> >> >   other kernel modules platform: x86: dell-laptop: Use
> >> >   dell-rbtn instead i8042 filter when
> >> >   
> >> >     possible
> >> >  
> >> >  drivers/platform/x86/Kconfig       |   14 ++
> >> >  drivers/platform/x86/Makefile      |    1 +
> >> >  drivers/platform/x86/dell-laptop.c |   67 +++++++++-
> >> >  drivers/platform/x86/dell-rbtn.c   |  260
> >> >  ++++++++++++++++++++++++++++++++++++
> >> >  drivers/platform/x86/dell-rbtn.h   |   35 +++++
> >> >  5 files changed, 372 insertions(+), 5 deletions(-)
> >> >  create mode 100644 drivers/platform/x86/dell-rbtn.c
> >> >  create mode 100644 drivers/platform/x86/dell-rbtn.h
> >> 
> >> Alex, it is my understanding that this solution from Pali
> >> is a more complete solution to dealing with the variety of
> >> dell wireless buttons and rfkill mechanisms in the world
> >> today.
> >> 
> >> I currently have:
> >> 7c4d961 dell-wireless: new driver for dell wireless button
> >> for Windows 8 queued in for-next. If I have read your
> >> responses on this correctly, are we all in agreement that
> >> I should drop the above patch, and apply these?
> > 
> > Darren, it it truth that some laptops does not send keypress
> > event when Fn+wifi key is pressed (but only send ACPI
> > event), then really Alex's patch for input device is
> > needed. But it could be integrated into my driver. Also
> > Alex wrote something about ACPI events for laptops which
> > have wifi key instead HW switch. So before including this
> > patch into tree, I would like to hear what is problem with
> > my patch for laptops which have wifi key...
> > 
> > --
> > Pali Rohár
> > pali.rohar@gmail.com

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Darren Hart]

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,
-- 
Darren Hart
Intel Open Source Technology Center

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

[Darren Hart]

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,
-- 
Darren Hart
Intel Open Source Technology Center

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

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 1004 bytes --]

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/msg05922.html
[2] - http://www.spinics.net/lists/platform-driver-x86/msg05924.html

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 1004 bytes --]

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/msg05922.html
[2] - http://www.spinics.net/lists/platform-driver-x86/msg05924.html

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Gabriele Mazzotta]

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/msg05922.html
> [2] - http://www.spinics.net/lists/platform-driver-x86/msg05924.html

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.

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

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

[Gabriele Mazzotta]

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/msg05922.html
> [2] - http://www.spinics.net/lists/platform-driver-x86/msg05924.html

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.

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

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

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 1909 bytes --]

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/msg05922.h
> > tml [2] -
> > http://www.spinics.net/lists/platform-driver-x86/msg05924.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).

> 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@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 1909 bytes --]

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/msg05922.h
> > tml [2] -
> > http://www.spinics.net/lists/platform-driver-x86/msg05924.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).

> 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@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Gabriele Mazzotta]

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/msg05922.h
> > > tml [2] -
> > > http://www.spinics.net/lists/platform-driver-x86/msg05924.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.

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

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

[Gabriele Mazzotta]

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/msg05922.h
> > > tml [2] -
> > > http://www.spinics.net/lists/platform-driver-x86/msg05924.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.

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

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

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 3082 bytes --]

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@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 3082 bytes --]

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@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Gabriele Mazzotta]

On Friday 05 December 2014 22:23:25 Pali Rohár wrote:
> 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.

That's what happens on my laptop, but Alex said that the laptops on
which he worked, ARBT was empty, so I guess it's not always a choice.
In order not to break things, all the laptops that support both the
methods must be set to the correct mode through ARBT when the module
is loaded. If this is not done, then what you say is correct, we should
not report KEY_RFKILL, or at least do it selectively, but I guess that
this is not be possible without a whitelist (that we don't have).

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

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

[Gabriele Mazzotta]

On Friday 05 December 2014 22:23:25 Pali Rohár wrote:
> 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.

That's what happens on my laptop, but Alex said that the laptops on
which he worked, ARBT was empty, so I guess it's not always a choice.
In order not to break things, all the laptops that support both the
methods must be set to the correct mode through ARBT when the module
is loaded. If this is not done, then what you say is correct, we should
not report KEY_RFKILL, or at least do it selectively, but I guess that
this is not be possible without a whitelist (that we don't have).

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

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

[Alex Hung]

= Testing =

I tested six Dell systems for two sets of patches for dell radio
button - two system with radio slider and four with radio hotkey.
There are also two systems with working ARBT method.

== Basic Information ==
Based OS: Ubuntu 14.10 (kernel 3.16 [1]) and kernel 3.18 [2]

Patches:
1. dell-wireless v3 = original v2 + Gabriele's suggestion [3]
2. dell-rbtn [4]

Method:
1. run "rfkill list" and press hotkey / toggle slider during runtime
2. run "rfkill list" and toggle slider during S3

== Results ==

I summarized the tests in Google sheet as below. Please advise if
anyone has problem reading it.

https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSGh3UmG__UAO2qfZ829CkJLPo06aI/edit?usp=sharing

PS. The document will stay as long as possible for future references.

== Summary ==

1. I did not observed a duplicated event. However, keycode 240
(unknown) is generated on many UUT. It is not issued by dell-laptop or
del-wmi. I am suspecting it is the other event Pali observes but it
can be the result of different distro.

2. Some system issues scancode "0xe0 0x73 0xe0 0xf3". It can also be
used toggle wireless state but this can also be distro-dependent. This
scancode does nothing on Ubuntu 14.10.

2. There are two systems with working ARBT (XPS 13 9333 and Inspiron
7447). Calling ARBT(1) changes BIOS behaviours, and this matches to
Dell's document. We should include it in the patch for maximum
capability.


[1] dell-wireless is only tested 3.16.
[2] dell-rbtn is tested on 3.16 and 3.18, but no differences are observed.
[3] http://people.canonical.com/~alexhung/dell-wireless/
[4] http://people.canonical.com/~alexhung/dell-rbtn/

On Sat, Dec 6, 2014 at 5:49 AM, Gabriele Mazzotta
<gabriele.mzt@gmail.com> wrote:
> On Friday 05 December 2014 22:23:25 Pali Rohár wrote:
>> 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.
>
> That's what happens on my laptop, but Alex said that the laptops on
> which he worked, ARBT was empty, so I guess it's not always a choice.
> In order not to break things, all the laptops that support both the
> methods must be set to the correct mode through ARBT when the module
> is loaded. If this is not done, then what you say is correct, we should
> not report KEY_RFKILL, or at least do it selectively, but I guess that
> this is not be possible without a whitelist (that we don't have).
>
>> > > > 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.
>>
>>
>



-- 
Cheers,
Alex Hung

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

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 3647 bytes --]

Hello, thank you very much for testing.

On Monday 22 December 2014 08:27:57 Alex Hung wrote:
> = Testing =
> 
> I tested six Dell systems for two sets of patches for dell
> radio button - two system with radio slider and four with
> radio hotkey. There are also two systems with working ARBT
> method.
> 
> == Basic Information ==
> Based OS: Ubuntu 14.10 (kernel 3.16 [1]) and kernel 3.18 [2]
> 
> Patches:
> 1. dell-wireless v3 = original v2 + Gabriele's suggestion [3]
> 2. dell-rbtn [4]
> 
> Method:
> 1. run "rfkill list" and press hotkey / toggle slider during
> runtime 2. run "rfkill list" and toggle slider during S3
> 

If there is problem with my patch series which does not reflect 
correct state after resume from S3, I can add pm hook which will 
try to re-read rfkill state (via GRBT) after system wake up from 
S3.

> == Results ==
> 
> I summarized the tests in Google sheet as below. Please advise
> if anyone has problem reading it.
> 
> https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSGh3UmG_
> _UAO2qfZ829CkJLPo06aI/edit?usp=sharing
> 
> PS. The document will stay as long as possible for future
> references.
> 
> == Summary ==
> 
> 1. I did not observed a duplicated event. However, keycode 240
> (unknown) is generated on many UUT. It is not issued by
> dell-laptop or del-wmi. I am suspecting it is the other event
> Pali observes but it can be the result of different distro.
> 

It comes from i8042 bus via internal AT keyboard (not from WMI). 
In userspace you can assign correct keycode (e.g. KEY_WLAN or 
KEY_RFKILL) so it does not show as unknown. Its scancode is 136 
(0x88) and default keycode 240 (0xF0).

Some other distributions or other software automatically map this 
unknown 240 keycode to some key, so you will see duplicate event 
even in X applications.

> 2. Some system issues scancode "0xe0 0x73 0xe0 0xf3". It can
> also be used toggle wireless state but this can also be
> distro-dependent. This scancode does nothing on Ubuntu 14.10.
> 

I would suggest you to use program input-events for reading 
pressed keys as it show all key events from kernel and it is 
working per input device (so it is possible to check if event 
comes from AT keyboard, WMI or other driver). If there is problem 
with WMI driver (it reports both key press and BIOS do some 
change) we can patch WMI driver to prevent another looping 
problem...

> 2. There are two systems with working ARBT (XPS 13 9333 and
> Inspiron 7447). Calling ARBT(1) changes BIOS behaviours, and
> this matches to Dell's document. We should include it in the
> patch for maximum capability.
> 

How it change BIOS behaviour?

> 
> [1] dell-wireless is only tested 3.16.
> [2] dell-rbtn is tested on 3.16 and 3.18, but no differences
> are observed. [3]
> http://people.canonical.com/~alexhung/dell-wireless/ [4]
> http://people.canonical.com/~alexhung/dell-rbtn/
> 

Next I would suggest you to test clean system without fanny 
software like NetworkManager. Previously we saw that 
NetworkManager change state of network devices and rfkill 
softstates so it can interact with kernel. I think that new 
driver in kernel should work also without NetworkManager and also 
there are people who use alternative software (and not 
NetworkManager). I know that Ubuntu has installed & enabled 
NetworkManager by default, so some results in your table could 
have values changed by NetworkManager and not by kernel.

And I have one question: Does Inspirion 5721 have ACPI DELRBTN 
device (instead DELLABCE).

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 3647 bytes --]

Hello, thank you very much for testing.

On Monday 22 December 2014 08:27:57 Alex Hung wrote:
> = Testing =
> 
> I tested six Dell systems for two sets of patches for dell
> radio button - two system with radio slider and four with
> radio hotkey. There are also two systems with working ARBT
> method.
> 
> == Basic Information ==
> Based OS: Ubuntu 14.10 (kernel 3.16 [1]) and kernel 3.18 [2]
> 
> Patches:
> 1. dell-wireless v3 = original v2 + Gabriele's suggestion [3]
> 2. dell-rbtn [4]
> 
> Method:
> 1. run "rfkill list" and press hotkey / toggle slider during
> runtime 2. run "rfkill list" and toggle slider during S3
> 

If there is problem with my patch series which does not reflect 
correct state after resume from S3, I can add pm hook which will 
try to re-read rfkill state (via GRBT) after system wake up from 
S3.

> == Results ==
> 
> I summarized the tests in Google sheet as below. Please advise
> if anyone has problem reading it.
> 
> https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSGh3UmG_
> _UAO2qfZ829CkJLPo06aI/edit?usp=sharing
> 
> PS. The document will stay as long as possible for future
> references.
> 
> == Summary ==
> 
> 1. I did not observed a duplicated event. However, keycode 240
> (unknown) is generated on many UUT. It is not issued by
> dell-laptop or del-wmi. I am suspecting it is the other event
> Pali observes but it can be the result of different distro.
> 

It comes from i8042 bus via internal AT keyboard (not from WMI). 
In userspace you can assign correct keycode (e.g. KEY_WLAN or 
KEY_RFKILL) so it does not show as unknown. Its scancode is 136 
(0x88) and default keycode 240 (0xF0).

Some other distributions or other software automatically map this 
unknown 240 keycode to some key, so you will see duplicate event 
even in X applications.

> 2. Some system issues scancode "0xe0 0x73 0xe0 0xf3". It can
> also be used toggle wireless state but this can also be
> distro-dependent. This scancode does nothing on Ubuntu 14.10.
> 

I would suggest you to use program input-events for reading 
pressed keys as it show all key events from kernel and it is 
working per input device (so it is possible to check if event 
comes from AT keyboard, WMI or other driver). If there is problem 
with WMI driver (it reports both key press and BIOS do some 
change) we can patch WMI driver to prevent another looping 
problem...

> 2. There are two systems with working ARBT (XPS 13 9333 and
> Inspiron 7447). Calling ARBT(1) changes BIOS behaviours, and
> this matches to Dell's document. We should include it in the
> patch for maximum capability.
> 

How it change BIOS behaviour?

> 
> [1] dell-wireless is only tested 3.16.
> [2] dell-rbtn is tested on 3.16 and 3.18, but no differences
> are observed. [3]
> http://people.canonical.com/~alexhung/dell-wireless/ [4]
> http://people.canonical.com/~alexhung/dell-rbtn/
> 

Next I would suggest you to test clean system without fanny 
software like NetworkManager. Previously we saw that 
NetworkManager change state of network devices and rfkill 
softstates so it can interact with kernel. I think that new 
driver in kernel should work also without NetworkManager and also 
there are people who use alternative software (and not 
NetworkManager). I know that Ubuntu has installed & enabled 
NetworkManager by default, so some results in your table could 
have values changed by NetworkManager and not by kernel.

And I have one question: Does Inspirion 5721 have ACPI DELRBTN 
device (instead DELLABCE).

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Gabriele Mazzotta]

On Monday 22 December 2014 15:27:57 Alex Hung wrote:
> = Testing =
> 
> I tested six Dell systems for two sets of patches for dell radio
> button - two system with radio slider and four with radio hotkey.
> There are also two systems with working ARBT method.
> 
> == Basic Information ==
> Based OS: Ubuntu 14.10 (kernel 3.16 [1]) and kernel 3.18 [2]
> 
> Patches:
> 1. dell-wireless v3 = original v2 + Gabriele's suggestion [3]
> 2. dell-rbtn [4]
> 
> Method:
> 1. run "rfkill list" and press hotkey / toggle slider during runtime
> 2. run "rfkill list" and toggle slider during S3
> 
> == Results ==
> 
> I summarized the tests in Google sheet as below. Please advise if
> anyone has problem reading it.
> 
> https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSGh3UmG__UAO2qfZ829CkJLPo06aI/edit?usp=sharing
> 
> PS. The document will stay as long as possible for future references.
> 
> == Summary ==
> 
> 1. I did not observed a duplicated event. However, keycode 240
> (unknown) is generated on many UUT. It is not issued by dell-laptop or
> del-wmi. I am suspecting it is the other event Pali observes but it
> can be the result of different distro.
> 
> 2. Some system issues scancode "0xe0 0x73 0xe0 0xf3". It can also be
> used toggle wireless state but this can also be distro-dependent. This
> scancode does nothing on Ubuntu 14.10.
> 
> 2. There are two systems with working ARBT (XPS 13 9333 and Inspiron
> 7447). Calling ARBT(1) changes BIOS behaviours, and this matches to
> Dell's document. We should include it in the patch for maximum
> capability.
> 
> 
> [1] dell-wireless is only tested 3.16.
> [2] dell-rbtn is tested on 3.16 and 3.18, but no differences are observed.
> [3] http://people.canonical.com/~alexhung/dell-wireless/
> [4] http://people.canonical.com/~alexhung/dell-rbtn/

Thanks for the detailed report.

Note that the results might be different for some laptops with 3.19. See
8f8d75ebf0 ("dell-wmi: Don't report keypresses for radio state changes")
for more details. Basically "238 (rfkill wlan)" should never be reported
with 3.19. Looking at the results of your tests I can see that key 238
is never necessary, confirming that not reporting it is the right thing
to do.

Gabriele

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

[Gabriele Mazzotta]

On Monday 22 December 2014 15:27:57 Alex Hung wrote:
> = Testing =
> 
> I tested six Dell systems for two sets of patches for dell radio
> button - two system with radio slider and four with radio hotkey.
> There are also two systems with working ARBT method.
> 
> == Basic Information ==
> Based OS: Ubuntu 14.10 (kernel 3.16 [1]) and kernel 3.18 [2]
> 
> Patches:
> 1. dell-wireless v3 = original v2 + Gabriele's suggestion [3]
> 2. dell-rbtn [4]
> 
> Method:
> 1. run "rfkill list" and press hotkey / toggle slider during runtime
> 2. run "rfkill list" and toggle slider during S3
> 
> == Results ==
> 
> I summarized the tests in Google sheet as below. Please advise if
> anyone has problem reading it.
> 
> https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSGh3UmG__UAO2qfZ829CkJLPo06aI/edit?usp=sharing
> 
> PS. The document will stay as long as possible for future references.
> 
> == Summary ==
> 
> 1. I did not observed a duplicated event. However, keycode 240
> (unknown) is generated on many UUT. It is not issued by dell-laptop or
> del-wmi. I am suspecting it is the other event Pali observes but it
> can be the result of different distro.
> 
> 2. Some system issues scancode "0xe0 0x73 0xe0 0xf3". It can also be
> used toggle wireless state but this can also be distro-dependent. This
> scancode does nothing on Ubuntu 14.10.
> 
> 2. There are two systems with working ARBT (XPS 13 9333 and Inspiron
> 7447). Calling ARBT(1) changes BIOS behaviours, and this matches to
> Dell's document. We should include it in the patch for maximum
> capability.
> 
> 
> [1] dell-wireless is only tested 3.16.
> [2] dell-rbtn is tested on 3.16 and 3.18, but no differences are observed.
> [3] http://people.canonical.com/~alexhung/dell-wireless/
> [4] http://people.canonical.com/~alexhung/dell-rbtn/

I've just tried the last revision of dell-wireless and noticed that a
notification (0x80) is sent to DELLABCE after a transition from S3 to
S0, causing dell-wireless to send KEY_RFKILL. This shouldn't happen.
Same thing for transitions from S4 to S0.

Gabriele

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

[Alex Hung]

I uploaded acpidump files [1] (except for XPS 13 which is not
available), and this should help clarify what has been tested.

Does Inspirion 5721 does not have either DELLABCE or DELRBTN. It is
used for comparison. My apologies that I did not point this out in
previous email.

When calling ARBT(1), BIOS will no longer issue scancode and will not
pull low hardware pin "W_DISABLE#" on mini card. This essentially
gives all wireless control to OS. This is likely the answer to
Microsoft's Windows Certification Program
System.Client.RadioManagement.HardwareButton [2] as below:

=============================================
If a PC has a physical (hardware) button switch on a PC that turns
wireless radios on and off, it must be software controllable and
interact appropriately with the Radio Management UI
=============================================

Dell's BIOS does issue a notify(RBTN, 0x80). This is done purposely to
re-enumerate the state of radio switch which may be changed when
system is in S3 or S4. I think this should not occur when CRBT returns
0 or 1 (for hotkey that cannot be changed during S3 or S4), but that's
how it is done currently.

dell-wireless does not handle this notification in S3 or S4 for
following reasons:

1. dell-wireless does not handle slider (i.e. CRBT = 2 or 3). Device
drivers should read the hardware pin, "W_DISABLE#" on mini spec and
change hard block accordingly. This pin is commonly used by OEM today.

2. it is not possible to distinguish the notification (0x80) from
hotkey press or S3/S4. I also concerned this may mis-trigger state
change when resuming from S3 or S4, but it does not. Does any know how
to ignore this notification during resume only?

dell-rbtn can use this notification + method (GRBT) [2] to solve the
problem that slider state.

[1] http://people.canonical.com/~alexhung/dell-acpidump/
[2] http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256.aspx
[3] It seems GRBT may not always be implemented...

I'd love to do more tests and share the results on any particular
systems, but I may need some more detailed instructions.



On Tue, Dec 23, 2014 at 3:16 AM, Gabriele Mazzotta
<gabriele.mzt@gmail.com> wrote:
> On Monday 22 December 2014 15:27:57 Alex Hung wrote:
>> = Testing =
>>
>> I tested six Dell systems for two sets of patches for dell radio
>> button - two system with radio slider and four with radio hotkey.
>> There are also two systems with working ARBT method.
>>
>> == Basic Information ==
>> Based OS: Ubuntu 14.10 (kernel 3.16 [1]) and kernel 3.18 [2]
>>
>> Patches:
>> 1. dell-wireless v3 = original v2 + Gabriele's suggestion [3]
>> 2. dell-rbtn [4]
>>
>> Method:
>> 1. run "rfkill list" and press hotkey / toggle slider during runtime
>> 2. run "rfkill list" and toggle slider during S3
>>
>> == Results ==
>>
>> I summarized the tests in Google sheet as below. Please advise if
>> anyone has problem reading it.
>>
>> https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSGh3UmG__UAO2qfZ829CkJLPo06aI/edit?usp=sharing
>>
>> PS. The document will stay as long as possible for future references.
>>
>> == Summary ==
>>
>> 1. I did not observed a duplicated event. However, keycode 240
>> (unknown) is generated on many UUT. It is not issued by dell-laptop or
>> del-wmi. I am suspecting it is the other event Pali observes but it
>> can be the result of different distro.
>>
>> 2. Some system issues scancode "0xe0 0x73 0xe0 0xf3". It can also be
>> used toggle wireless state but this can also be distro-dependent. This
>> scancode does nothing on Ubuntu 14.10.
>>
>> 2. There are two systems with working ARBT (XPS 13 9333 and Inspiron
>> 7447). Calling ARBT(1) changes BIOS behaviours, and this matches to
>> Dell's document. We should include it in the patch for maximum
>> capability.
>>
>>
>> [1] dell-wireless is only tested 3.16.
>> [2] dell-rbtn is tested on 3.16 and 3.18, but no differences are observed.
>> [3] http://people.canonical.com/~alexhung/dell-wireless/
>> [4] http://people.canonical.com/~alexhung/dell-rbtn/
>
> I've just tried the last revision of dell-wireless and noticed that a
> notification (0x80) is sent to DELLABCE after a transition from S3 to
> S0, causing dell-wireless to send KEY_RFKILL. This shouldn't happen.
> Same thing for transitions from S4 to S0.
>
> Gabriele



-- 
Cheers,
Alex Hung

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

[Gabriele Mazzotta]

On Wednesday 24 December 2014 17:13:45 Alex Hung wrote:
> I uploaded acpidump files [1] (except for XPS 13 which is not
> available), and this should help clarify what has been tested.
> 
> Does Inspirion 5721 does not have either DELLABCE or DELRBTN. It is
> used for comparison. My apologies that I did not point this out in
> previous email.
> 
> When calling ARBT(1), BIOS will no longer issue scancode and will not
> pull low hardware pin "W_DISABLE#" on mini card. This essentially
> gives all wireless control to OS. This is likely the answer to
> Microsoft's Windows Certification Program
> System.Client.RadioManagement.HardwareButton [2] as below:
> 
> =============================================
> If a PC has a physical (hardware) button switch on a PC that turns
> wireless radios on and off, it must be software controllable and
> interact appropriately with the Radio Management UI
> =============================================
> 
> Dell's BIOS does issue a notify(RBTN, 0x80). This is done purposely to
> re-enumerate the state of radio switch which may be changed when
> system is in S3 or S4. I think this should not occur when CRBT returns
> 0 or 1 (for hotkey that cannot be changed during S3 or S4), but that's
> how it is done currently.

The notification is sent on my XPS13 (CRBT returns 0), toggling the WiFi
state on resume.

> dell-wireless does not handle this notification in S3 or S4 for
> following reasons:
> 
> 1. dell-wireless does not handle slider (i.e. CRBT = 2 or 3). Device
> drivers should read the hardware pin, "W_DISABLE#" on mini spec and
> change hard block accordingly. This pin is commonly used by OEM today.
> 
> 2. it is not possible to distinguish the notification (0x80) from
> hotkey press or S3/S4. I also concerned this may mis-trigger state
> change when resuming from S3 or S4, but it does not. Does any know how
> to ignore this notification during resume only?
> 
> dell-rbtn can use this notification + method (GRBT) [2] to solve the
> problem that slider state.

Unfortunately this won't solve the problem for me. After ARBT is called
with 1 as parameter, it seems that GRBT always returns 1.

I don't know how to ignore the notification on resume, if not through
a flag set by a PM callback.

Given that all the tested laptops reported a keypress on the i8042
bus, isn't it better to rely on that instead?

> [1] http://people.canonical.com/~alexhung/dell-acpidump/
> [2] http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256.aspx
> [3] It seems GRBT may not always be implemented...
> 
> I'd love to do more tests and share the results on any particular
> systems, but I may need some more detailed instructions.
> 
> 
> 
> On Tue, Dec 23, 2014 at 3:16 AM, Gabriele Mazzotta
> <gabriele.mzt@gmail.com> wrote:
> > On Monday 22 December 2014 15:27:57 Alex Hung wrote:
> >> = Testing =
> >>
> >> I tested six Dell systems for two sets of patches for dell radio
> >> button - two system with radio slider and four with radio hotkey.
> >> There are also two systems with working ARBT method.
> >>
> >> == Basic Information ==
> >> Based OS: Ubuntu 14.10 (kernel 3.16 [1]) and kernel 3.18 [2]
> >>
> >> Patches:
> >> 1. dell-wireless v3 = original v2 + Gabriele's suggestion [3]
> >> 2. dell-rbtn [4]
> >>
> >> Method:
> >> 1. run "rfkill list" and press hotkey / toggle slider during runtime
> >> 2. run "rfkill list" and toggle slider during S3
> >>
> >> == Results ==
> >>
> >> I summarized the tests in Google sheet as below. Please advise if
> >> anyone has problem reading it.
> >>
> >> https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSGh3UmG__UAO2qfZ829CkJLPo06aI/edit?usp=sharing
> >>
> >> PS. The document will stay as long as possible for future references.
> >>
> >> == Summary ==
> >>
> >> 1. I did not observed a duplicated event. However, keycode 240
> >> (unknown) is generated on many UUT. It is not issued by dell-laptop or
> >> del-wmi. I am suspecting it is the other event Pali observes but it
> >> can be the result of different distro.
> >>
> >> 2. Some system issues scancode "0xe0 0x73 0xe0 0xf3". It can also be
> >> used toggle wireless state but this can also be distro-dependent. This
> >> scancode does nothing on Ubuntu 14.10.
> >>
> >> 2. There are two systems with working ARBT (XPS 13 9333 and Inspiron
> >> 7447). Calling ARBT(1) changes BIOS behaviours, and this matches to
> >> Dell's document. We should include it in the patch for maximum
> >> capability.
> >>
> >>
> >> [1] dell-wireless is only tested 3.16.
> >> [2] dell-rbtn is tested on 3.16 and 3.18, but no differences are observed.
> >> [3] http://people.canonical.com/~alexhung/dell-wireless/
> >> [4] http://people.canonical.com/~alexhung/dell-rbtn/
> >
> > I've just tried the last revision of dell-wireless and noticed that a
> > notification (0x80) is sent to DELLABCE after a transition from S3 to
> > S0, causing dell-wireless to send KEY_RFKILL. This shouldn't happen.
> > Same thing for transitions from S4 to S0.
> >
> > Gabriele
> 
> 
> 
> 

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

[Alex Hung]

I usually prefer to stick with formal document as everything else can
be changed without reasons.

I am not certain whether the keypress is defined in Dell's document,
and I will confirm with Dell. If this keypress is well defined, it is
a good idea to use it.


On Wed, Dec 24, 2014 at 7:40 PM, Gabriele Mazzotta
<gabriele.mzt@gmail.com> wrote:
> On Wednesday 24 December 2014 17:13:45 Alex Hung wrote:
>> I uploaded acpidump files [1] (except for XPS 13 which is not
>> available), and this should help clarify what has been tested.
>>
>> Does Inspirion 5721 does not have either DELLABCE or DELRBTN. It is
>> used for comparison. My apologies that I did not point this out in
>> previous email.
>>
>> When calling ARBT(1), BIOS will no longer issue scancode and will not
>> pull low hardware pin "W_DISABLE#" on mini card. This essentially
>> gives all wireless control to OS. This is likely the answer to
>> Microsoft's Windows Certification Program
>> System.Client.RadioManagement.HardwareButton [2] as below:
>>
>> =============================================
>> If a PC has a physical (hardware) button switch on a PC that turns
>> wireless radios on and off, it must be software controllable and
>> interact appropriately with the Radio Management UI
>> =============================================
>>
>> Dell's BIOS does issue a notify(RBTN, 0x80). This is done purposely to
>> re-enumerate the state of radio switch which may be changed when
>> system is in S3 or S4. I think this should not occur when CRBT returns
>> 0 or 1 (for hotkey that cannot be changed during S3 or S4), but that's
>> how it is done currently.
>
> The notification is sent on my XPS13 (CRBT returns 0), toggling the WiFi
> state on resume.
>
>> dell-wireless does not handle this notification in S3 or S4 for
>> following reasons:
>>
>> 1. dell-wireless does not handle slider (i.e. CRBT = 2 or 3). Device
>> drivers should read the hardware pin, "W_DISABLE#" on mini spec and
>> change hard block accordingly. This pin is commonly used by OEM today.
>>
>> 2. it is not possible to distinguish the notification (0x80) from
>> hotkey press or S3/S4. I also concerned this may mis-trigger state
>> change when resuming from S3 or S4, but it does not. Does any know how
>> to ignore this notification during resume only?
>>
>> dell-rbtn can use this notification + method (GRBT) [2] to solve the
>> problem that slider state.
>
> Unfortunately this won't solve the problem for me. After ARBT is called
> with 1 as parameter, it seems that GRBT always returns 1.
>
> I don't know how to ignore the notification on resume, if not through
> a flag set by a PM callback.
>
> Given that all the tested laptops reported a keypress on the i8042
> bus, isn't it better to rely on that instead?
>
>> [1] http://people.canonical.com/~alexhung/dell-acpidump/
>> [2] http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256.aspx
>> [3] It seems GRBT may not always be implemented...
>>
>> I'd love to do more tests and share the results on any particular
>> systems, but I may need some more detailed instructions.
>>
>>
>>
>> On Tue, Dec 23, 2014 at 3:16 AM, Gabriele Mazzotta
>> <gabriele.mzt@gmail.com> wrote:
>> > On Monday 22 December 2014 15:27:57 Alex Hung wrote:
>> >> = Testing =
>> >>
>> >> I tested six Dell systems for two sets of patches for dell radio
>> >> button - two system with radio slider and four with radio hotkey.
>> >> There are also two systems with working ARBT method.
>> >>
>> >> == Basic Information ==
>> >> Based OS: Ubuntu 14.10 (kernel 3.16 [1]) and kernel 3.18 [2]
>> >>
>> >> Patches:
>> >> 1. dell-wireless v3 = original v2 + Gabriele's suggestion [3]
>> >> 2. dell-rbtn [4]
>> >>
>> >> Method:
>> >> 1. run "rfkill list" and press hotkey / toggle slider during runtime
>> >> 2. run "rfkill list" and toggle slider during S3
>> >>
>> >> == Results ==
>> >>
>> >> I summarized the tests in Google sheet as below. Please advise if
>> >> anyone has problem reading it.
>> >>
>> >> https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSGh3UmG__UAO2qfZ829CkJLPo06aI/edit?usp=sharing
>> >>
>> >> PS. The document will stay as long as possible for future references.
>> >>
>> >> == Summary ==
>> >>
>> >> 1. I did not observed a duplicated event. However, keycode 240
>> >> (unknown) is generated on many UUT. It is not issued by dell-laptop or
>> >> del-wmi. I am suspecting it is the other event Pali observes but it
>> >> can be the result of different distro.
>> >>
>> >> 2. Some system issues scancode "0xe0 0x73 0xe0 0xf3". It can also be
>> >> used toggle wireless state but this can also be distro-dependent. This
>> >> scancode does nothing on Ubuntu 14.10.
>> >>
>> >> 2. There are two systems with working ARBT (XPS 13 9333 and Inspiron
>> >> 7447). Calling ARBT(1) changes BIOS behaviours, and this matches to
>> >> Dell's document. We should include it in the patch for maximum
>> >> capability.
>> >>
>> >>
>> >> [1] dell-wireless is only tested 3.16.
>> >> [2] dell-rbtn is tested on 3.16 and 3.18, but no differences are observed.
>> >> [3] http://people.canonical.com/~alexhung/dell-wireless/
>> >> [4] http://people.canonical.com/~alexhung/dell-rbtn/
>> >
>> > I've just tried the last revision of dell-wireless and noticed that a
>> > notification (0x80) is sent to DELLABCE after a transition from S3 to
>> > S0, causing dell-wireless to send KEY_RFKILL. This shouldn't happen.
>> > Same thing for transitions from S4 to S0.
>> >
>> > Gabriele
>>
>>
>>
>>



-- 
Cheers,
Alex Hung

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

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 7869 bytes --]

I will try to recap all information which we have...

*) We should not send wireless key press to userspace when BIOS 
already handles wireless state (and enable/disable wifi): 
http://www.spinics.net/lists/platform-driver-x86/msg05922.html

*) some tested dell machines does not implement GRBT method (or 
report constant value) which could return state of wireless 
(enabled/disabled) -- e.g. Inspiron 7447

*) dell-wireless driver is doing nothing on devices which have 
wireless slider switch (except calling CRBT/ARBT methods)

*) all tested machines emit key with keycode 240 (scancode is 
probably 136 = 0x88) to userspace via i8042 bus/AT keyboard when 
wireless button/slider is pressed/switched

*) both drivers dell-wireless and dell-rbtn do not implement 
setting soft rfkill state (or change wifi state)

So in my opinion: if we decide to use driver for acpi DELLABCE 
device we should use dell-rbnt for devices with hw slider switch 
and dell-wireless for devices with fn button. I think it does not 
make sense to use dell-wireless for devices with hw slider 
because it do nothing and dell-rbtn for devices with fn key 
button as GRBT does not working properly.

And second note: Do we need some driver for acpi DELLABCE device? 
Which problem is trying acpi DELLABCE device to solve? Is not 
everything working fine without driver for DELLABCE device?

My dell-rbtn approach is trying to export rfkill interface from 
DELLABCE device and eliminate using i8042 hook function in smbios 
dell-laptop driver.

Alex, can you check if scancode of wireless change generated by 
BIOS is on all machines same: 136 (0x88)? And is send by keyboard 
controller (not acpi/wmi)?

On Thursday 25 December 2014 04:13:02 Alex Hung wrote:
> I usually prefer to stick with formal document as everything
> else can be changed without reasons.
> 
> I am not certain whether the keypress is defined in Dell's
> document, and I will confirm with Dell. If this keypress is
> well defined, it is a good idea to use it.
> 
> 
> On Wed, Dec 24, 2014 at 7:40 PM, Gabriele Mazzotta
> 
> <gabriele.mzt@gmail.com> wrote:
> > On Wednesday 24 December 2014 17:13:45 Alex Hung wrote:
> >> I uploaded acpidump files [1] (except for XPS 13 which is
> >> not available), and this should help clarify what has been
> >> tested.
> >> 
> >> Does Inspirion 5721 does not have either DELLABCE or
> >> DELRBTN. It is used for comparison. My apologies that I
> >> did not point this out in previous email.
> >> 
> >> When calling ARBT(1), BIOS will no longer issue scancode
> >> and will not pull low hardware pin "W_DISABLE#" on mini
> >> card. This essentially gives all wireless control to OS.
> >> This is likely the answer to Microsoft's Windows
> >> Certification Program
> >> System.Client.RadioManagement.HardwareButton [2] as below:
> >> 
> >> =============================================
> >> If a PC has a physical (hardware) button switch on a PC
> >> that turns wireless radios on and off, it must be software
> >> controllable and interact appropriately with the Radio
> >> Management UI
> >> =============================================
> >> 
> >> Dell's BIOS does issue a notify(RBTN, 0x80). This is done
> >> purposely to re-enumerate the state of radio switch which
> >> may be changed when system is in S3 or S4. I think this
> >> should not occur when CRBT returns 0 or 1 (for hotkey that
> >> cannot be changed during S3 or S4), but that's how it is
> >> done currently.
> > 
> > The notification is sent on my XPS13 (CRBT returns 0),
> > toggling the WiFi state on resume.
> > 
> >> dell-wireless does not handle this notification in S3 or S4
> >> for following reasons:
> >> 
> >> 1. dell-wireless does not handle slider (i.e. CRBT = 2 or
> >> 3). Device drivers should read the hardware pin,
> >> "W_DISABLE#" on mini spec and change hard block
> >> accordingly. This pin is commonly used by OEM today.
> >> 
> >> 2. it is not possible to distinguish the notification
> >> (0x80) from hotkey press or S3/S4. I also concerned this
> >> may mis-trigger state change when resuming from S3 or S4,
> >> but it does not. Does any know how to ignore this
> >> notification during resume only?
> >> 
> >> dell-rbtn can use this notification + method (GRBT) [2] to
> >> solve the problem that slider state.
> > 
> > Unfortunately this won't solve the problem for me. After
> > ARBT is called with 1 as parameter, it seems that GRBT
> > always returns 1.
> > 
> > I don't know how to ignore the notification on resume, if
> > not through a flag set by a PM callback.
> > 
> > Given that all the tested laptops reported a keypress on the
> > i8042 bus, isn't it better to rely on that instead?
> > 
> >> [1] http://people.canonical.com/~alexhung/dell-acpidump/
> >> [2]
> >> http://msdn.microsoft.com/en-us/library/windows/hardware/j
> >> j128256.aspx [3] It seems GRBT may not always be
> >> implemented...
> >> 
> >> I'd love to do more tests and share the results on any
> >> particular systems, but I may need some more detailed
> >> instructions.
> >> 
> >> 
> >> 
> >> On Tue, Dec 23, 2014 at 3:16 AM, Gabriele Mazzotta
> >> 
> >> <gabriele.mzt@gmail.com> wrote:
> >> > On Monday 22 December 2014 15:27:57 Alex Hung wrote:
> >> >> = Testing =
> >> >> 
> >> >> I tested six Dell systems for two sets of patches for
> >> >> dell radio button - two system with radio slider and
> >> >> four with radio hotkey. There are also two systems with
> >> >> working ARBT method.
> >> >> 
> >> >> == Basic Information ==
> >> >> Based OS: Ubuntu 14.10 (kernel 3.16 [1]) and kernel 3.18
> >> >> [2]
> >> >> 
> >> >> Patches:
> >> >> 1. dell-wireless v3 = original v2 + Gabriele's
> >> >> suggestion [3] 2. dell-rbtn [4]
> >> >> 
> >> >> Method:
> >> >> 1. run "rfkill list" and press hotkey / toggle slider
> >> >> during runtime 2. run "rfkill list" and toggle slider
> >> >> during S3
> >> >> 
> >> >> == Results ==
> >> >> 
> >> >> I summarized the tests in Google sheet as below. Please
> >> >> advise if anyone has problem reading it.
> >> >> 
> >> >> https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSG
> >> >> h3UmG__UAO2qfZ829CkJLPo06aI/edit?usp=sharing
> >> >> 
> >> >> PS. The document will stay as long as possible for
> >> >> future references.
> >> >> 
> >> >> == Summary ==
> >> >> 
> >> >> 1. I did not observed a duplicated event. However,
> >> >> keycode 240 (unknown) is generated on many UUT. It is
> >> >> not issued by dell-laptop or del-wmi. I am suspecting
> >> >> it is the other event Pali observes but it can be the
> >> >> result of different distro.
> >> >> 
> >> >> 2. Some system issues scancode "0xe0 0x73 0xe0 0xf3". It
> >> >> can also be used toggle wireless state but this can
> >> >> also be distro-dependent. This scancode does nothing on
> >> >> Ubuntu 14.10.
> >> >> 
> >> >> 2. There are two systems with working ARBT (XPS 13 9333
> >> >> and Inspiron 7447). Calling ARBT(1) changes BIOS
> >> >> behaviours, and this matches to Dell's document. We
> >> >> should include it in the patch for maximum capability.
> >> >> 
> >> >> 
> >> >> [1] dell-wireless is only tested 3.16.
> >> >> [2] dell-rbtn is tested on 3.16 and 3.18, but no
> >> >> differences are observed. [3]
> >> >> http://people.canonical.com/~alexhung/dell-wireless/
> >> >> [4] http://people.canonical.com/~alexhung/dell-rbtn/
> >> > 
> >> > I've just tried the last revision of dell-wireless and
> >> > noticed that a notification (0x80) is sent to DELLABCE
> >> > after a transition from S3 to S0, causing dell-wireless
> >> > to send KEY_RFKILL. This shouldn't happen. Same thing
> >> > for transitions from S4 to S0.
> >> > 
> >> > Gabriele

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 7869 bytes --]

I will try to recap all information which we have...

*) We should not send wireless key press to userspace when BIOS 
already handles wireless state (and enable/disable wifi): 
http://www.spinics.net/lists/platform-driver-x86/msg05922.html

*) some tested dell machines does not implement GRBT method (or 
report constant value) which could return state of wireless 
(enabled/disabled) -- e.g. Inspiron 7447

*) dell-wireless driver is doing nothing on devices which have 
wireless slider switch (except calling CRBT/ARBT methods)

*) all tested machines emit key with keycode 240 (scancode is 
probably 136 = 0x88) to userspace via i8042 bus/AT keyboard when 
wireless button/slider is pressed/switched

*) both drivers dell-wireless and dell-rbtn do not implement 
setting soft rfkill state (or change wifi state)

So in my opinion: if we decide to use driver for acpi DELLABCE 
device we should use dell-rbnt for devices with hw slider switch 
and dell-wireless for devices with fn button. I think it does not 
make sense to use dell-wireless for devices with hw slider 
because it do nothing and dell-rbtn for devices with fn key 
button as GRBT does not working properly.

And second note: Do we need some driver for acpi DELLABCE device? 
Which problem is trying acpi DELLABCE device to solve? Is not 
everything working fine without driver for DELLABCE device?

My dell-rbtn approach is trying to export rfkill interface from 
DELLABCE device and eliminate using i8042 hook function in smbios 
dell-laptop driver.

Alex, can you check if scancode of wireless change generated by 
BIOS is on all machines same: 136 (0x88)? And is send by keyboard 
controller (not acpi/wmi)?

On Thursday 25 December 2014 04:13:02 Alex Hung wrote:
> I usually prefer to stick with formal document as everything
> else can be changed without reasons.
> 
> I am not certain whether the keypress is defined in Dell's
> document, and I will confirm with Dell. If this keypress is
> well defined, it is a good idea to use it.
> 
> 
> On Wed, Dec 24, 2014 at 7:40 PM, Gabriele Mazzotta
> 
> <gabriele.mzt@gmail.com> wrote:
> > On Wednesday 24 December 2014 17:13:45 Alex Hung wrote:
> >> I uploaded acpidump files [1] (except for XPS 13 which is
> >> not available), and this should help clarify what has been
> >> tested.
> >> 
> >> Does Inspirion 5721 does not have either DELLABCE or
> >> DELRBTN. It is used for comparison. My apologies that I
> >> did not point this out in previous email.
> >> 
> >> When calling ARBT(1), BIOS will no longer issue scancode
> >> and will not pull low hardware pin "W_DISABLE#" on mini
> >> card. This essentially gives all wireless control to OS.
> >> This is likely the answer to Microsoft's Windows
> >> Certification Program
> >> System.Client.RadioManagement.HardwareButton [2] as below:
> >> 
> >> =============================================
> >> If a PC has a physical (hardware) button switch on a PC
> >> that turns wireless radios on and off, it must be software
> >> controllable and interact appropriately with the Radio
> >> Management UI
> >> =============================================
> >> 
> >> Dell's BIOS does issue a notify(RBTN, 0x80). This is done
> >> purposely to re-enumerate the state of radio switch which
> >> may be changed when system is in S3 or S4. I think this
> >> should not occur when CRBT returns 0 or 1 (for hotkey that
> >> cannot be changed during S3 or S4), but that's how it is
> >> done currently.
> > 
> > The notification is sent on my XPS13 (CRBT returns 0),
> > toggling the WiFi state on resume.
> > 
> >> dell-wireless does not handle this notification in S3 or S4
> >> for following reasons:
> >> 
> >> 1. dell-wireless does not handle slider (i.e. CRBT = 2 or
> >> 3). Device drivers should read the hardware pin,
> >> "W_DISABLE#" on mini spec and change hard block
> >> accordingly. This pin is commonly used by OEM today.
> >> 
> >> 2. it is not possible to distinguish the notification
> >> (0x80) from hotkey press or S3/S4. I also concerned this
> >> may mis-trigger state change when resuming from S3 or S4,
> >> but it does not. Does any know how to ignore this
> >> notification during resume only?
> >> 
> >> dell-rbtn can use this notification + method (GRBT) [2] to
> >> solve the problem that slider state.
> > 
> > Unfortunately this won't solve the problem for me. After
> > ARBT is called with 1 as parameter, it seems that GRBT
> > always returns 1.
> > 
> > I don't know how to ignore the notification on resume, if
> > not through a flag set by a PM callback.
> > 
> > Given that all the tested laptops reported a keypress on the
> > i8042 bus, isn't it better to rely on that instead?
> > 
> >> [1] http://people.canonical.com/~alexhung/dell-acpidump/
> >> [2]
> >> http://msdn.microsoft.com/en-us/library/windows/hardware/j
> >> j128256.aspx [3] It seems GRBT may not always be
> >> implemented...
> >> 
> >> I'd love to do more tests and share the results on any
> >> particular systems, but I may need some more detailed
> >> instructions.
> >> 
> >> 
> >> 
> >> On Tue, Dec 23, 2014 at 3:16 AM, Gabriele Mazzotta
> >> 
> >> <gabriele.mzt@gmail.com> wrote:
> >> > On Monday 22 December 2014 15:27:57 Alex Hung wrote:
> >> >> = Testing =
> >> >> 
> >> >> I tested six Dell systems for two sets of patches for
> >> >> dell radio button - two system with radio slider and
> >> >> four with radio hotkey. There are also two systems with
> >> >> working ARBT method.
> >> >> 
> >> >> == Basic Information ==
> >> >> Based OS: Ubuntu 14.10 (kernel 3.16 [1]) and kernel 3.18
> >> >> [2]
> >> >> 
> >> >> Patches:
> >> >> 1. dell-wireless v3 = original v2 + Gabriele's
> >> >> suggestion [3] 2. dell-rbtn [4]
> >> >> 
> >> >> Method:
> >> >> 1. run "rfkill list" and press hotkey / toggle slider
> >> >> during runtime 2. run "rfkill list" and toggle slider
> >> >> during S3
> >> >> 
> >> >> == Results ==
> >> >> 
> >> >> I summarized the tests in Google sheet as below. Please
> >> >> advise if anyone has problem reading it.
> >> >> 
> >> >> https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSG
> >> >> h3UmG__UAO2qfZ829CkJLPo06aI/edit?usp=sharing
> >> >> 
> >> >> PS. The document will stay as long as possible for
> >> >> future references.
> >> >> 
> >> >> == Summary ==
> >> >> 
> >> >> 1. I did not observed a duplicated event. However,
> >> >> keycode 240 (unknown) is generated on many UUT. It is
> >> >> not issued by dell-laptop or del-wmi. I am suspecting
> >> >> it is the other event Pali observes but it can be the
> >> >> result of different distro.
> >> >> 
> >> >> 2. Some system issues scancode "0xe0 0x73 0xe0 0xf3". It
> >> >> can also be used toggle wireless state but this can
> >> >> also be distro-dependent. This scancode does nothing on
> >> >> Ubuntu 14.10.
> >> >> 
> >> >> 2. There are two systems with working ARBT (XPS 13 9333
> >> >> and Inspiron 7447). Calling ARBT(1) changes BIOS
> >> >> behaviours, and this matches to Dell's document. We
> >> >> should include it in the patch for maximum capability.
> >> >> 
> >> >> 
> >> >> [1] dell-wireless is only tested 3.16.
> >> >> [2] dell-rbtn is tested on 3.16 and 3.18, but no
> >> >> differences are observed. [3]
> >> >> http://people.canonical.com/~alexhung/dell-wireless/
> >> >> [4] http://people.canonical.com/~alexhung/dell-rbtn/
> >> > 
> >> > I've just tried the last revision of dell-wireless and
> >> > noticed that a notification (0x80) is sent to DELLABCE
> >> > after a transition from S3 to S0, causing dell-wireless
> >> > to send KEY_RFKILL. This shouldn't happen. Same thing
> >> > for transitions from S4 to S0.
> >> > 
> >> > Gabriele

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Gabriele Mazzotta]

On Thursday 25 December 2014 21:11:05 Pali Rohár wrote:
> I will try to recap all information which we have...
> 
> *) We should not send wireless key press to userspace when BIOS 
> already handles wireless state (and enable/disable wifi): 
> http://www.spinics.net/lists/platform-driver-x86/msg05922.html
> 
> *) some tested dell machines does not implement GRBT method (or 
> report constant value) which could return state of wireless 
> (enabled/disabled) -- e.g. Inspiron 7447
> 
> *) dell-wireless driver is doing nothing on devices which have 
> wireless slider switch (except calling CRBT/ARBT methods)
> 
> *) all tested machines emit key with keycode 240 (scancode is 
> probably 136 = 0x88) to userspace via i8042 bus/AT keyboard when 
> wireless button/slider is pressed/switched
> 
> *) both drivers dell-wireless and dell-rbtn do not implement 
> setting soft rfkill state (or change wifi state)
> 
> So in my opinion: if we decide to use driver for acpi DELLABCE 
> device we should use dell-rbnt for devices with hw slider switch 
> and dell-wireless for devices with fn button. I think it does not 
> make sense to use dell-wireless for devices with hw slider 
> because it do nothing and dell-rbtn for devices with fn key 
> button as GRBT does not working properly.

Here the problem. We are determining which laptop has an hardware
slider and which doesn't calling CRBT. If the returned value is 2
or 3, then the laptop has an hardware slider. However, it cannot be
assumed the opposite if the returned value is 0 or 1.

See the acpidumps Alex uploaded. The Inspiron 3543 returns 0 when
CRBT is called and so does the Inspiron 7447. However, the former
doesn't have a working ARBT method and, if I'm not wrong, its BIOS
doesn't handle radio devices. The BIOS of the latter can handle
radio and has a working ARBT method to make it stop from doing that.

Since we determine when the BIOS might not be able to control radio
devices through CRBT and we can't say it for sure (in the example
above, CRBT returned the same value), we make sure that the BIOS
doesn't handle radio devices by calling ARBT. We can ensure this
(e.g. Inspirong 7447), but we can't ensure the opposite (e.g.
Inspiron 3453).

If there was a way to determine which laptop really needs
dell-wireless, calling ARBT wouldn't have been necessary, but that's
not the case. Users can always blacklist the module if they know
their laptop can work as expected without it, but we have to ensure
that everything always works.

This is what I understood by looking at the acpidumps, so I could
be wrong.

> And second note: Do we need some driver for acpi DELLABCE device? 
> Which problem is trying acpi DELLABCE device to solve? Is not 
> everything working fine without driver for DELLABCE device?

As I wrote above, DELLABCE is for those systems whose BIOS doesn't
handle radio devices and expects the OS do everything when Fn keys
are pressed.
(Well, it actually seems that something is done by the keyboard
controller, but this is not certain yet)

> My dell-rbtn approach is trying to export rfkill interface from 
> DELLABCE device and eliminate using i8042 hook function in smbios 
> dell-laptop driver.
> 
> Alex, can you check if scancode of wireless change generated by 
> BIOS is on all machines same: 136 (0x88)? And is send by keyboard 
> controller (not acpi/wmi)?

I can say that on my XPS13 the scancode is 0x88 and it is sent by
the keyboard controller.

Gabriele

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

[Gabriele Mazzotta]

On Thursday 25 December 2014 21:11:05 Pali Rohár wrote:
> I will try to recap all information which we have...
> 
> *) We should not send wireless key press to userspace when BIOS 
> already handles wireless state (and enable/disable wifi): 
> http://www.spinics.net/lists/platform-driver-x86/msg05922.html
> 
> *) some tested dell machines does not implement GRBT method (or 
> report constant value) which could return state of wireless 
> (enabled/disabled) -- e.g. Inspiron 7447
> 
> *) dell-wireless driver is doing nothing on devices which have 
> wireless slider switch (except calling CRBT/ARBT methods)
> 
> *) all tested machines emit key with keycode 240 (scancode is 
> probably 136 = 0x88) to userspace via i8042 bus/AT keyboard when 
> wireless button/slider is pressed/switched
> 
> *) both drivers dell-wireless and dell-rbtn do not implement 
> setting soft rfkill state (or change wifi state)
> 
> So in my opinion: if we decide to use driver for acpi DELLABCE 
> device we should use dell-rbnt for devices with hw slider switch 
> and dell-wireless for devices with fn button. I think it does not 
> make sense to use dell-wireless for devices with hw slider 
> because it do nothing and dell-rbtn for devices with fn key 
> button as GRBT does not working properly.

Here the problem. We are determining which laptop has an hardware
slider and which doesn't calling CRBT. If the returned value is 2
or 3, then the laptop has an hardware slider. However, it cannot be
assumed the opposite if the returned value is 0 or 1.

See the acpidumps Alex uploaded. The Inspiron 3543 returns 0 when
CRBT is called and so does the Inspiron 7447. However, the former
doesn't have a working ARBT method and, if I'm not wrong, its BIOS
doesn't handle radio devices. The BIOS of the latter can handle
radio and has a working ARBT method to make it stop from doing that.

Since we determine when the BIOS might not be able to control radio
devices through CRBT and we can't say it for sure (in the example
above, CRBT returned the same value), we make sure that the BIOS
doesn't handle radio devices by calling ARBT. We can ensure this
(e.g. Inspirong 7447), but we can't ensure the opposite (e.g.
Inspiron 3453).

If there was a way to determine which laptop really needs
dell-wireless, calling ARBT wouldn't have been necessary, but that's
not the case. Users can always blacklist the module if they know
their laptop can work as expected without it, but we have to ensure
that everything always works.

This is what I understood by looking at the acpidumps, so I could
be wrong.

> And second note: Do we need some driver for acpi DELLABCE device? 
> Which problem is trying acpi DELLABCE device to solve? Is not 
> everything working fine without driver for DELLABCE device?

As I wrote above, DELLABCE is for those systems whose BIOS doesn't
handle radio devices and expects the OS do everything when Fn keys
are pressed.
(Well, it actually seems that something is done by the keyboard
controller, but this is not certain yet)

> My dell-rbtn approach is trying to export rfkill interface from 
> DELLABCE device and eliminate using i8042 hook function in smbios 
> dell-laptop driver.
> 
> Alex, can you check if scancode of wireless change generated by 
> BIOS is on all machines same: 136 (0x88)? And is send by keyboard 
> controller (not acpi/wmi)?

I can say that on my XPS13 the scancode is 0x88 and it is sent by
the keyboard controller.

Gabriele

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

[Alex Hung]

On Fri, Dec 26, 2014 at 5:55 AM, Gabriele Mazzotta
<gabriele.mzt@gmail.com> wrote:
> On Thursday 25 December 2014 21:11:05 Pali Rohár wrote:
>> I will try to recap all information which we have...
>>
>> *) We should not send wireless key press to userspace when BIOS
>> already handles wireless state (and enable/disable wifi):
>> http://www.spinics.net/lists/platform-driver-x86/msg05922.html
>>
>> *) some tested dell machines does not implement GRBT method (or
>> report constant value) which could return state of wireless
>> (enabled/disabled) -- e.g. Inspiron 7447
>>
>> *) dell-wireless driver is doing nothing on devices which have
>> wireless slider switch (except calling CRBT/ARBT methods)
>>
>> *) all tested machines emit key with keycode 240 (scancode is
>> probably 136 = 0x88) to userspace via i8042 bus/AT keyboard when
>> wireless button/slider is pressed/switched
>>
>> *) both drivers dell-wireless and dell-rbtn do not implement
>> setting soft rfkill state (or change wifi state)
>>
>> So in my opinion: if we decide to use driver for acpi DELLABCE
>> device we should use dell-rbnt for devices with hw slider switch
>> and dell-wireless for devices with fn button. I think it does not
>> make sense to use dell-wireless for devices with hw slider
>> because it do nothing and dell-rbtn for devices with fn key
>> button as GRBT does not working properly.
>
> Here the problem. We are determining which laptop has an hardware
> slider and which doesn't calling CRBT. If the returned value is 2
> or 3, then the laptop has an hardware slider. However, it cannot be
> assumed the opposite if the returned value is 0 or 1.

The spec defines as below:
1. When CRBT returns 0 or 1, a system has a toggle, ex. hotkey, radio button.
2. When CRBT returns 2 or 3, a system has a slider switch

The only difference of 0 and 1 (or 2 and 3) is the presence of a
wireless LED. However I believe this is defined according to
Microsoft's hardware requirement.


>
> See the acpidumps Alex uploaded. The Inspiron 3543 returns 0 when
> CRBT is called and so does the Inspiron 7447. However, the former
> doesn't have a working ARBT method and, if I'm not wrong, its BIOS
> doesn't handle radio devices. The BIOS of the latter can handle
> radio and has a working ARBT method to make it stop from doing that.
>
> Since we determine when the BIOS might not be able to control radio
> devices through CRBT and we can't say it for sure (in the example
> above, CRBT returned the same value), we make sure that the BIOS
> doesn't handle radio devices by calling ARBT. We can ensure this
> (e.g. Inspirong 7447), but we can't ensure the opposite (e.g.
> Inspiron 3453).
>
> If there was a way to determine which laptop really needs
> dell-wireless, calling ARBT wouldn't have been necessary, but that's
> not the case. Users can always blacklist the module if they know
> their laptop can work as expected without it, but we have to ensure
> that everything always works.
>
> This is what I understood by looking at the acpidumps, so I could
> be wrong.
>

I think ARBT acts as a switch for changing BIOS behaviours:

When ARBT is not called or is called with ARBT(0), BIOS's default
behaviour is to change wireless states by hardware pin. When ARBT(1)
is called by driver or userspace application (ex. required in Windows
8), wireless state is controlled by OS. Similar functions are defined
in ASUS ATK and HP WMI. Such implementation will provide maximum
capability for different OS with / without dedicate drivers.

The reality is never such wonderful; especially many systems are only
tested with Win8 + driver (some may tested with Win7 - and
acpi_osi=!Windows 2012 / 2013 will probably work). In this case, we
probably need to be more compatible with Windows 8 / 8.1.

>> And second note: Do we need some driver for acpi DELLABCE device?
>> Which problem is trying acpi DELLABCE device to solve? Is not
>> everything working fine without driver for DELLABCE device?
>
> As I wrote above, DELLABCE is for those systems whose BIOS doesn't
> handle radio devices and expects the OS do everything when Fn keys
> are pressed.
> (Well, it actually seems that something is done by the keyboard
> controller, but this is not certain yet)
>
>> My dell-rbtn approach is trying to export rfkill interface from
>> DELLABCE device and eliminate using i8042 hook function in smbios
>> dell-laptop driver.
>>
>> Alex, can you check if scancode of wireless change generated by
>> BIOS is on all machines same: 136 (0x88)? And is send by keyboard
>> controller (not acpi/wmi)?
>
> I can say that on my XPS13 the scancode is 0x88 and it is sent by
> the keyboard controller.
>
> Gabriele

Just before I check the scancode, I looked up the scancode table
(http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/translate.pdf)
and found 0x88 is already used - it is the "break" ("release" in Linux
term) code for "7" (the one above Y/U, not number pad). It can be
verified by "showkey -s": 0x08 for press and 0x88 for release. It is
not the best idea to map this scancode to anything else.

I also sent emails for this scancode last week but it is a holiday
season but I don't expect to receive any feedback this year...

-- 
Cheers,
Alex Hung

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

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 6397 bytes --]

On Monday 29 December 2014 08:27:21 Alex Hung wrote:
> On Fri, Dec 26, 2014 at 5:55 AM, Gabriele Mazzotta
> 
> <gabriele.mzt@gmail.com> wrote:
> > On Thursday 25 December 2014 21:11:05 Pali Rohár wrote:
> >> I will try to recap all information which we have...
> >> 
> >> *) We should not send wireless key press to userspace when
> >> BIOS already handles wireless state (and enable/disable
> >> wifi):
> >> http://www.spinics.net/lists/platform-driver-x86/msg05922.
> >> html
> >> 
> >> *) some tested dell machines does not implement GRBT method
> >> (or report constant value) which could return state of
> >> wireless (enabled/disabled) -- e.g. Inspiron 7447
> >> 
> >> *) dell-wireless driver is doing nothing on devices which
> >> have wireless slider switch (except calling CRBT/ARBT
> >> methods)
> >> 
> >> *) all tested machines emit key with keycode 240 (scancode
> >> is probably 136 = 0x88) to userspace via i8042 bus/AT
> >> keyboard when wireless button/slider is pressed/switched
> >> 
> >> *) both drivers dell-wireless and dell-rbtn do not
> >> implement setting soft rfkill state (or change wifi state)
> >> 
> >> So in my opinion: if we decide to use driver for acpi
> >> DELLABCE device we should use dell-rbnt for devices with
> >> hw slider switch and dell-wireless for devices with fn
> >> button. I think it does not make sense to use
> >> dell-wireless for devices with hw slider because it do
> >> nothing and dell-rbtn for devices with fn key button as
> >> GRBT does not working properly.
> > 
> > Here the problem. We are determining which laptop has an
> > hardware slider and which doesn't calling CRBT. If the
> > returned value is 2 or 3, then the laptop has an hardware
> > slider. However, it cannot be assumed the opposite if the
> > returned value is 0 or 1.
> 
> The spec defines as below:
> 1. When CRBT returns 0 or 1, a system has a toggle, ex.
> hotkey, radio button. 2. When CRBT returns 2 or 3, a system
> has a slider switch
> 
> The only difference of 0 and 1 (or 2 and 3) is the presence of
> a wireless LED. However I believe this is defined according
> to Microsoft's hardware requirement.
> 
> > See the acpidumps Alex uploaded. The Inspiron 3543 returns 0
> > when CRBT is called and so does the Inspiron 7447. However,
> > the former doesn't have a working ARBT method and, if I'm
> > not wrong, its BIOS doesn't handle radio devices. The BIOS
> > of the latter can handle radio and has a working ARBT
> > method to make it stop from doing that.
> > 
> > Since we determine when the BIOS might not be able to
> > control radio devices through CRBT and we can't say it for
> > sure (in the example above, CRBT returned the same value),
> > we make sure that the BIOS doesn't handle radio devices by
> > calling ARBT. We can ensure this (e.g. Inspirong 7447), but
> > we can't ensure the opposite (e.g. Inspiron 3453).
> > 
> > If there was a way to determine which laptop really needs
> > dell-wireless, calling ARBT wouldn't have been necessary,
> > but that's not the case. Users can always blacklist the
> > module if they know their laptop can work as expected
> > without it, but we have to ensure that everything always
> > works.
> > 
> > This is what I understood by looking at the acpidumps, so I
> > could be wrong.
> 
> I think ARBT acts as a switch for changing BIOS behaviours:
> 
> When ARBT is not called or is called with ARBT(0), BIOS's
> default behaviour is to change wireless states by hardware
> pin. When ARBT(1) is called by driver or userspace
> application (ex. required in Windows 8), wireless state is
> controlled by OS. Similar functions are defined in ASUS ATK
> and HP WMI. Such implementation will provide maximum
> capability for different OS with / without dedicate drivers.
> 
> The reality is never such wonderful; especially many systems
> are only tested with Win8 + driver (some may tested with Win7
> - and acpi_osi=!Windows 2012 / 2013 will probably work). In
> this case, we probably need to be more compatible with
> Windows 8 / 8.1.
> 
> >> And second note: Do we need some driver for acpi DELLABCE
> >> device? Which problem is trying acpi DELLABCE device to
> >> solve? Is not everything working fine without driver for
> >> DELLABCE device?
> > 
> > As I wrote above, DELLABCE is for those systems whose BIOS
> > doesn't handle radio devices and expects the OS do
> > everything when Fn keys are pressed.
> > (Well, it actually seems that something is done by the
> > keyboard controller, but this is not certain yet)
> > 
> >> My dell-rbtn approach is trying to export rfkill interface
> >> from DELLABCE device and eliminate using i8042 hook
> >> function in smbios dell-laptop driver.
> >> 
> >> Alex, can you check if scancode of wireless change
> >> generated by BIOS is on all machines same: 136 (0x88)? And
> >> is send by keyboard controller (not acpi/wmi)?
> > 
> > I can say that on my XPS13 the scancode is 0x88 and it is
> > sent by the keyboard controller.
> > 
> > Gabriele
> 
> Just before I check the scancode, I looked up the scancode
> table
> (http://download.microsoft.com/download/1/6/1/161ba512-40e2-4
> cc9-843a-923143f3456c/translate.pdf) and found 0x88 is already
> used - it is the "break" ("release" in Linux term) code for
> "7" (the one above Y/U, not number pad). It can be verified
> by "showkey -s": 0x08 for press and 0x88 for release. It is
> not the best idea to map this scancode to anything else.
> 
> I also sent emails for this scancode last week but it is a
> holiday season but I don't expect to receive any feedback
> this year...

Just to note, that there is only press key event with scancode 
136 (0x88). Release event is not sent to AT keyboard which cause 
problems (if you map this scancode to some well known keycode).

Alex, but I wrote you about this problem (in private email which 
you forwarded) together with other bios/fw problems for latitude 
machines...

Anyway I sent email to Matthew Garrett before Christmas and linux 
kernel could generate proper release event by fixing commit 
61579ba83934d397a4fa2bb7372de9ae112587d5 (adding also 9 and 10 to 
chassis_type). I believe Matthew Garrett will kernel provide 
workaround until Dell fix their BIOSes...

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 6397 bytes --]

On Monday 29 December 2014 08:27:21 Alex Hung wrote:
> On Fri, Dec 26, 2014 at 5:55 AM, Gabriele Mazzotta
> 
> <gabriele.mzt@gmail.com> wrote:
> > On Thursday 25 December 2014 21:11:05 Pali Rohár wrote:
> >> I will try to recap all information which we have...
> >> 
> >> *) We should not send wireless key press to userspace when
> >> BIOS already handles wireless state (and enable/disable
> >> wifi):
> >> http://www.spinics.net/lists/platform-driver-x86/msg05922.
> >> html
> >> 
> >> *) some tested dell machines does not implement GRBT method
> >> (or report constant value) which could return state of
> >> wireless (enabled/disabled) -- e.g. Inspiron 7447
> >> 
> >> *) dell-wireless driver is doing nothing on devices which
> >> have wireless slider switch (except calling CRBT/ARBT
> >> methods)
> >> 
> >> *) all tested machines emit key with keycode 240 (scancode
> >> is probably 136 = 0x88) to userspace via i8042 bus/AT
> >> keyboard when wireless button/slider is pressed/switched
> >> 
> >> *) both drivers dell-wireless and dell-rbtn do not
> >> implement setting soft rfkill state (or change wifi state)
> >> 
> >> So in my opinion: if we decide to use driver for acpi
> >> DELLABCE device we should use dell-rbnt for devices with
> >> hw slider switch and dell-wireless for devices with fn
> >> button. I think it does not make sense to use
> >> dell-wireless for devices with hw slider because it do
> >> nothing and dell-rbtn for devices with fn key button as
> >> GRBT does not working properly.
> > 
> > Here the problem. We are determining which laptop has an
> > hardware slider and which doesn't calling CRBT. If the
> > returned value is 2 or 3, then the laptop has an hardware
> > slider. However, it cannot be assumed the opposite if the
> > returned value is 0 or 1.
> 
> The spec defines as below:
> 1. When CRBT returns 0 or 1, a system has a toggle, ex.
> hotkey, radio button. 2. When CRBT returns 2 or 3, a system
> has a slider switch
> 
> The only difference of 0 and 1 (or 2 and 3) is the presence of
> a wireless LED. However I believe this is defined according
> to Microsoft's hardware requirement.
> 
> > See the acpidumps Alex uploaded. The Inspiron 3543 returns 0
> > when CRBT is called and so does the Inspiron 7447. However,
> > the former doesn't have a working ARBT method and, if I'm
> > not wrong, its BIOS doesn't handle radio devices. The BIOS
> > of the latter can handle radio and has a working ARBT
> > method to make it stop from doing that.
> > 
> > Since we determine when the BIOS might not be able to
> > control radio devices through CRBT and we can't say it for
> > sure (in the example above, CRBT returned the same value),
> > we make sure that the BIOS doesn't handle radio devices by
> > calling ARBT. We can ensure this (e.g. Inspirong 7447), but
> > we can't ensure the opposite (e.g. Inspiron 3453).
> > 
> > If there was a way to determine which laptop really needs
> > dell-wireless, calling ARBT wouldn't have been necessary,
> > but that's not the case. Users can always blacklist the
> > module if they know their laptop can work as expected
> > without it, but we have to ensure that everything always
> > works.
> > 
> > This is what I understood by looking at the acpidumps, so I
> > could be wrong.
> 
> I think ARBT acts as a switch for changing BIOS behaviours:
> 
> When ARBT is not called or is called with ARBT(0), BIOS's
> default behaviour is to change wireless states by hardware
> pin. When ARBT(1) is called by driver or userspace
> application (ex. required in Windows 8), wireless state is
> controlled by OS. Similar functions are defined in ASUS ATK
> and HP WMI. Such implementation will provide maximum
> capability for different OS with / without dedicate drivers.
> 
> The reality is never such wonderful; especially many systems
> are only tested with Win8 + driver (some may tested with Win7
> - and acpi_osi=!Windows 2012 / 2013 will probably work). In
> this case, we probably need to be more compatible with
> Windows 8 / 8.1.
> 
> >> And second note: Do we need some driver for acpi DELLABCE
> >> device? Which problem is trying acpi DELLABCE device to
> >> solve? Is not everything working fine without driver for
> >> DELLABCE device?
> > 
> > As I wrote above, DELLABCE is for those systems whose BIOS
> > doesn't handle radio devices and expects the OS do
> > everything when Fn keys are pressed.
> > (Well, it actually seems that something is done by the
> > keyboard controller, but this is not certain yet)
> > 
> >> My dell-rbtn approach is trying to export rfkill interface
> >> from DELLABCE device and eliminate using i8042 hook
> >> function in smbios dell-laptop driver.
> >> 
> >> Alex, can you check if scancode of wireless change
> >> generated by BIOS is on all machines same: 136 (0x88)? And
> >> is send by keyboard controller (not acpi/wmi)?
> > 
> > I can say that on my XPS13 the scancode is 0x88 and it is
> > sent by the keyboard controller.
> > 
> > Gabriele
> 
> Just before I check the scancode, I looked up the scancode
> table
> (http://download.microsoft.com/download/1/6/1/161ba512-40e2-4
> cc9-843a-923143f3456c/translate.pdf) and found 0x88 is already
> used - it is the "break" ("release" in Linux term) code for
> "7" (the one above Y/U, not number pad). It can be verified
> by "showkey -s": 0x08 for press and 0x88 for release. It is
> not the best idea to map this scancode to anything else.
> 
> I also sent emails for this scancode last week but it is a
> holiday season but I don't expect to receive any feedback
> this year...

Just to note, that there is only press key event with scancode 
136 (0x88). Release event is not sent to AT keyboard which cause 
problems (if you map this scancode to some well known keycode).

Alex, but I wrote you about this problem (in private email which 
you forwarded) together with other bios/fw problems for latitude 
machines...

Anyway I sent email to Matthew Garrett before Christmas and linux 
kernel could generate proper release event by fixing commit 
61579ba83934d397a4fa2bb7372de9ae112587d5 (adding also 9 and 10 to 
chassis_type). I believe Matthew Garrett will kernel provide 
workaround until Dell fix their BIOSes...

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Alex Hung]

When a key is pressed and released, KBC sends a pair of corresponding
scancode - a make and a break. In normal case, a make code and a break
code differ in one bit - break = make | BIT7. Therefore, a scancode
with BIT7 set is a break. There are special cases such as super key
that maps to "0xe0 0x5b" and "0xe0 0xdb" where 0xe0 is present for
both make and break, but 0x5b and 0xdb follow the same pattern.

Scancode 0x88 is a break code (i.e. release), and each scancode must
be unique and should not used for different purposes.

I have not received any feedbacks but I don't think holiday is quite
over for everybody. I will send updates when there is any.


On Mon, Dec 29, 2014 at 4:32 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Monday 29 December 2014 08:27:21 Alex Hung wrote:
>> On Fri, Dec 26, 2014 at 5:55 AM, Gabriele Mazzotta
>>
>> <gabriele.mzt@gmail.com> wrote:
>> > On Thursday 25 December 2014 21:11:05 Pali Rohár wrote:
>> >> I will try to recap all information which we have...
>> >>
>> >> *) We should not send wireless key press to userspace when
>> >> BIOS already handles wireless state (and enable/disable
>> >> wifi):
>> >> http://www.spinics.net/lists/platform-driver-x86/msg05922.
>> >> html
>> >>
>> >> *) some tested dell machines does not implement GRBT method
>> >> (or report constant value) which could return state of
>> >> wireless (enabled/disabled) -- e.g. Inspiron 7447
>> >>
>> >> *) dell-wireless driver is doing nothing on devices which
>> >> have wireless slider switch (except calling CRBT/ARBT
>> >> methods)
>> >>
>> >> *) all tested machines emit key with keycode 240 (scancode
>> >> is probably 136 = 0x88) to userspace via i8042 bus/AT
>> >> keyboard when wireless button/slider is pressed/switched
>> >>
>> >> *) both drivers dell-wireless and dell-rbtn do not
>> >> implement setting soft rfkill state (or change wifi state)
>> >>
>> >> So in my opinion: if we decide to use driver for acpi
>> >> DELLABCE device we should use dell-rbnt for devices with
>> >> hw slider switch and dell-wireless for devices with fn
>> >> button. I think it does not make sense to use
>> >> dell-wireless for devices with hw slider because it do
>> >> nothing and dell-rbtn for devices with fn key button as
>> >> GRBT does not working properly.
>> >
>> > Here the problem. We are determining which laptop has an
>> > hardware slider and which doesn't calling CRBT. If the
>> > returned value is 2 or 3, then the laptop has an hardware
>> > slider. However, it cannot be assumed the opposite if the
>> > returned value is 0 or 1.
>>
>> The spec defines as below:
>> 1. When CRBT returns 0 or 1, a system has a toggle, ex.
>> hotkey, radio button. 2. When CRBT returns 2 or 3, a system
>> has a slider switch
>>
>> The only difference of 0 and 1 (or 2 and 3) is the presence of
>> a wireless LED. However I believe this is defined according
>> to Microsoft's hardware requirement.
>>
>> > See the acpidumps Alex uploaded. The Inspiron 3543 returns 0
>> > when CRBT is called and so does the Inspiron 7447. However,
>> > the former doesn't have a working ARBT method and, if I'm
>> > not wrong, its BIOS doesn't handle radio devices. The BIOS
>> > of the latter can handle radio and has a working ARBT
>> > method to make it stop from doing that.
>> >
>> > Since we determine when the BIOS might not be able to
>> > control radio devices through CRBT and we can't say it for
>> > sure (in the example above, CRBT returned the same value),
>> > we make sure that the BIOS doesn't handle radio devices by
>> > calling ARBT. We can ensure this (e.g. Inspirong 7447), but
>> > we can't ensure the opposite (e.g. Inspiron 3453).
>> >
>> > If there was a way to determine which laptop really needs
>> > dell-wireless, calling ARBT wouldn't have been necessary,
>> > but that's not the case. Users can always blacklist the
>> > module if they know their laptop can work as expected
>> > without it, but we have to ensure that everything always
>> > works.
>> >
>> > This is what I understood by looking at the acpidumps, so I
>> > could be wrong.
>>
>> I think ARBT acts as a switch for changing BIOS behaviours:
>>
>> When ARBT is not called or is called with ARBT(0), BIOS's
>> default behaviour is to change wireless states by hardware
>> pin. When ARBT(1) is called by driver or userspace
>> application (ex. required in Windows 8), wireless state is
>> controlled by OS. Similar functions are defined in ASUS ATK
>> and HP WMI. Such implementation will provide maximum
>> capability for different OS with / without dedicate drivers.
>>
>> The reality is never such wonderful; especially many systems
>> are only tested with Win8 + driver (some may tested with Win7
>> - and acpi_osi=!Windows 2012 / 2013 will probably work). In
>> this case, we probably need to be more compatible with
>> Windows 8 / 8.1.
>>
>> >> And second note: Do we need some driver for acpi DELLABCE
>> >> device? Which problem is trying acpi DELLABCE device to
>> >> solve? Is not everything working fine without driver for
>> >> DELLABCE device?
>> >
>> > As I wrote above, DELLABCE is for those systems whose BIOS
>> > doesn't handle radio devices and expects the OS do
>> > everything when Fn keys are pressed.
>> > (Well, it actually seems that something is done by the
>> > keyboard controller, but this is not certain yet)
>> >
>> >> My dell-rbtn approach is trying to export rfkill interface
>> >> from DELLABCE device and eliminate using i8042 hook
>> >> function in smbios dell-laptop driver.
>> >>
>> >> Alex, can you check if scancode of wireless change
>> >> generated by BIOS is on all machines same: 136 (0x88)? And
>> >> is send by keyboard controller (not acpi/wmi)?
>> >
>> > I can say that on my XPS13 the scancode is 0x88 and it is
>> > sent by the keyboard controller.
>> >
>> > Gabriele
>>
>> Just before I check the scancode, I looked up the scancode
>> table
>> (http://download.microsoft.com/download/1/6/1/161ba512-40e2-4
>> cc9-843a-923143f3456c/translate.pdf) and found 0x88 is already
>> used - it is the "break" ("release" in Linux term) code for
>> "7" (the one above Y/U, not number pad). It can be verified
>> by "showkey -s": 0x08 for press and 0x88 for release. It is
>> not the best idea to map this scancode to anything else.
>>
>> I also sent emails for this scancode last week but it is a
>> holiday season but I don't expect to receive any feedback
>> this year...
>
> Just to note, that there is only press key event with scancode
> 136 (0x88). Release event is not sent to AT keyboard which cause
> problems (if you map this scancode to some well known keycode).
>
> Alex, but I wrote you about this problem (in private email which
> you forwarded) together with other bios/fw problems for latitude
> machines...
>
> Anyway I sent email to Matthew Garrett before Christmas and linux
> kernel could generate proper release event by fixing commit
> 61579ba83934d397a4fa2bb7372de9ae112587d5 (adding also 9 and 10 to
> chassis_type). I believe Matthew Garrett will kernel provide
> workaround until Dell fix their BIOSes...
>
> --
> Pali Rohár
> pali.rohar@gmail.com



-- 
Cheers,
Alex Hung

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

[Alex Hung]

When a key is pressed and released, KBC sends a pair of corresponding
scancode - a make and a break. In normal case, a make code and a break
code differ in one bit - break = make | BIT7. Therefore, a scancode
with BIT7 set is a break. There are special cases such as super key
that maps to "0xe0 0x5b" and "0xe0 0xdb" where 0xe0 is present for
both make and break, but 0x5b and 0xdb follow the same pattern.

Scancode 0x88 is a break code (i.e. release), and each scancode must
be unique and should not used for different purposes.

I have not received any feedbacks but I don't think holiday is quite
over for everybody. I will send updates when there is any.


On Mon, Dec 29, 2014 at 4:32 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Monday 29 December 2014 08:27:21 Alex Hung wrote:
>> On Fri, Dec 26, 2014 at 5:55 AM, Gabriele Mazzotta
>>
>> <gabriele.mzt@gmail.com> wrote:
>> > On Thursday 25 December 2014 21:11:05 Pali Rohár wrote:
>> >> I will try to recap all information which we have...
>> >>
>> >> *) We should not send wireless key press to userspace when
>> >> BIOS already handles wireless state (and enable/disable
>> >> wifi):
>> >> http://www.spinics.net/lists/platform-driver-x86/msg05922.
>> >> html
>> >>
>> >> *) some tested dell machines does not implement GRBT method
>> >> (or report constant value) which could return state of
>> >> wireless (enabled/disabled) -- e.g. Inspiron 7447
>> >>
>> >> *) dell-wireless driver is doing nothing on devices which
>> >> have wireless slider switch (except calling CRBT/ARBT
>> >> methods)
>> >>
>> >> *) all tested machines emit key with keycode 240 (scancode
>> >> is probably 136 = 0x88) to userspace via i8042 bus/AT
>> >> keyboard when wireless button/slider is pressed/switched
>> >>
>> >> *) both drivers dell-wireless and dell-rbtn do not
>> >> implement setting soft rfkill state (or change wifi state)
>> >>
>> >> So in my opinion: if we decide to use driver for acpi
>> >> DELLABCE device we should use dell-rbnt for devices with
>> >> hw slider switch and dell-wireless for devices with fn
>> >> button. I think it does not make sense to use
>> >> dell-wireless for devices with hw slider because it do
>> >> nothing and dell-rbtn for devices with fn key button as
>> >> GRBT does not working properly.
>> >
>> > Here the problem. We are determining which laptop has an
>> > hardware slider and which doesn't calling CRBT. If the
>> > returned value is 2 or 3, then the laptop has an hardware
>> > slider. However, it cannot be assumed the opposite if the
>> > returned value is 0 or 1.
>>
>> The spec defines as below:
>> 1. When CRBT returns 0 or 1, a system has a toggle, ex.
>> hotkey, radio button. 2. When CRBT returns 2 or 3, a system
>> has a slider switch
>>
>> The only difference of 0 and 1 (or 2 and 3) is the presence of
>> a wireless LED. However I believe this is defined according
>> to Microsoft's hardware requirement.
>>
>> > See the acpidumps Alex uploaded. The Inspiron 3543 returns 0
>> > when CRBT is called and so does the Inspiron 7447. However,
>> > the former doesn't have a working ARBT method and, if I'm
>> > not wrong, its BIOS doesn't handle radio devices. The BIOS
>> > of the latter can handle radio and has a working ARBT
>> > method to make it stop from doing that.
>> >
>> > Since we determine when the BIOS might not be able to
>> > control radio devices through CRBT and we can't say it for
>> > sure (in the example above, CRBT returned the same value),
>> > we make sure that the BIOS doesn't handle radio devices by
>> > calling ARBT. We can ensure this (e.g. Inspirong 7447), but
>> > we can't ensure the opposite (e.g. Inspiron 3453).
>> >
>> > If there was a way to determine which laptop really needs
>> > dell-wireless, calling ARBT wouldn't have been necessary,
>> > but that's not the case. Users can always blacklist the
>> > module if they know their laptop can work as expected
>> > without it, but we have to ensure that everything always
>> > works.
>> >
>> > This is what I understood by looking at the acpidumps, so I
>> > could be wrong.
>>
>> I think ARBT acts as a switch for changing BIOS behaviours:
>>
>> When ARBT is not called or is called with ARBT(0), BIOS's
>> default behaviour is to change wireless states by hardware
>> pin. When ARBT(1) is called by driver or userspace
>> application (ex. required in Windows 8), wireless state is
>> controlled by OS. Similar functions are defined in ASUS ATK
>> and HP WMI. Such implementation will provide maximum
>> capability for different OS with / without dedicate drivers.
>>
>> The reality is never such wonderful; especially many systems
>> are only tested with Win8 + driver (some may tested with Win7
>> - and acpi_osi=!Windows 2012 / 2013 will probably work). In
>> this case, we probably need to be more compatible with
>> Windows 8 / 8.1.
>>
>> >> And second note: Do we need some driver for acpi DELLABCE
>> >> device? Which problem is trying acpi DELLABCE device to
>> >> solve? Is not everything working fine without driver for
>> >> DELLABCE device?
>> >
>> > As I wrote above, DELLABCE is for those systems whose BIOS
>> > doesn't handle radio devices and expects the OS do
>> > everything when Fn keys are pressed.
>> > (Well, it actually seems that something is done by the
>> > keyboard controller, but this is not certain yet)
>> >
>> >> My dell-rbtn approach is trying to export rfkill interface
>> >> from DELLABCE device and eliminate using i8042 hook
>> >> function in smbios dell-laptop driver.
>> >>
>> >> Alex, can you check if scancode of wireless change
>> >> generated by BIOS is on all machines same: 136 (0x88)? And
>> >> is send by keyboard controller (not acpi/wmi)?
>> >
>> > I can say that on my XPS13 the scancode is 0x88 and it is
>> > sent by the keyboard controller.
>> >
>> > Gabriele
>>
>> Just before I check the scancode, I looked up the scancode
>> table
>> (http://download.microsoft.com/download/1/6/1/161ba512-40e2-4
>> cc9-843a-923143f3456c/translate.pdf) and found 0x88 is already
>> used - it is the "break" ("release" in Linux term) code for
>> "7" (the one above Y/U, not number pad). It can be verified
>> by "showkey -s": 0x08 for press and 0x88 for release. It is
>> not the best idea to map this scancode to anything else.
>>
>> I also sent emails for this scancode last week but it is a
>> holiday season but I don't expect to receive any feedback
>> this year...
>
> Just to note, that there is only press key event with scancode
> 136 (0x88). Release event is not sent to AT keyboard which cause
> problems (if you map this scancode to some well known keycode).
>
> Alex, but I wrote you about this problem (in private email which
> you forwarded) together with other bios/fw problems for latitude
> machines...
>
> Anyway I sent email to Matthew Garrett before Christmas and linux
> kernel could generate proper release event by fixing commit
> 61579ba83934d397a4fa2bb7372de9ae112587d5 (adding also 9 and 10 to
> chassis_type). I believe Matthew Garrett will kernel provide
> workaround until Dell fix their BIOSes...
>
> --
> Pali Rohár
> pali.rohar@gmail.com



-- 
Cheers,
Alex Hung

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

[Alex Hung]

I encountered a Dell Latitude machine whose wireless hotkey will not
work with dell-rbtn alone, and therefore I merged functions from
dell-wireless and it worked quite well.  I also tested it on 7 other
Dell machines, and only Inspiron 7437 failed because of a firmware bug
(see http://permalink.gmane.org/gmane.linux.acpi.devel/74915)

I am going to send the new patch for review.

On Fri, Dec 26, 2014 at 4:11 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> I will try to recap all information which we have...
>
> *) We should not send wireless key press to userspace when BIOS
> already handles wireless state (and enable/disable wifi):
> http://www.spinics.net/lists/platform-driver-x86/msg05922.html
>
> *) some tested dell machines does not implement GRBT method (or
> report constant value) which could return state of wireless
> (enabled/disabled) -- e.g. Inspiron 7447
>
> *) dell-wireless driver is doing nothing on devices which have
> wireless slider switch (except calling CRBT/ARBT methods)
>
> *) all tested machines emit key with keycode 240 (scancode is
> probably 136 = 0x88) to userspace via i8042 bus/AT keyboard when
> wireless button/slider is pressed/switched
>
> *) both drivers dell-wireless and dell-rbtn do not implement
> setting soft rfkill state (or change wifi state)
>
> So in my opinion: if we decide to use driver for acpi DELLABCE
> device we should use dell-rbnt for devices with hw slider switch
> and dell-wireless for devices with fn button. I think it does not
> make sense to use dell-wireless for devices with hw slider
> because it do nothing and dell-rbtn for devices with fn key
> button as GRBT does not working properly.
>
> And second note: Do we need some driver for acpi DELLABCE device?
> Which problem is trying acpi DELLABCE device to solve? Is not
> everything working fine without driver for DELLABCE device?
>
> My dell-rbtn approach is trying to export rfkill interface from
> DELLABCE device and eliminate using i8042 hook function in smbios
> dell-laptop driver.
>
> Alex, can you check if scancode of wireless change generated by
> BIOS is on all machines same: 136 (0x88)? And is send by keyboard
> controller (not acpi/wmi)?
>
> On Thursday 25 December 2014 04:13:02 Alex Hung wrote:
>> I usually prefer to stick with formal document as everything
>> else can be changed without reasons.
>>
>> I am not certain whether the keypress is defined in Dell's
>> document, and I will confirm with Dell. If this keypress is
>> well defined, it is a good idea to use it.
>>
>>
>> On Wed, Dec 24, 2014 at 7:40 PM, Gabriele Mazzotta
>>
>> <gabriele.mzt@gmail.com> wrote:
>> > On Wednesday 24 December 2014 17:13:45 Alex Hung wrote:
>> >> I uploaded acpidump files [1] (except for XPS 13 which is
>> >> not available), and this should help clarify what has been
>> >> tested.
>> >>
>> >> Does Inspirion 5721 does not have either DELLABCE or
>> >> DELRBTN. It is used for comparison. My apologies that I
>> >> did not point this out in previous email.
>> >>
>> >> When calling ARBT(1), BIOS will no longer issue scancode
>> >> and will not pull low hardware pin "W_DISABLE#" on mini
>> >> card. This essentially gives all wireless control to OS.
>> >> This is likely the answer to Microsoft's Windows
>> >> Certification Program
>> >> System.Client.RadioManagement.HardwareButton [2] as below:
>> >>
>> >> =============================================
>> >> If a PC has a physical (hardware) button switch on a PC
>> >> that turns wireless radios on and off, it must be software
>> >> controllable and interact appropriately with the Radio
>> >> Management UI
>> >> =============================================
>> >>
>> >> Dell's BIOS does issue a notify(RBTN, 0x80). This is done
>> >> purposely to re-enumerate the state of radio switch which
>> >> may be changed when system is in S3 or S4. I think this
>> >> should not occur when CRBT returns 0 or 1 (for hotkey that
>> >> cannot be changed during S3 or S4), but that's how it is
>> >> done currently.
>> >
>> > The notification is sent on my XPS13 (CRBT returns 0),
>> > toggling the WiFi state on resume.
>> >
>> >> dell-wireless does not handle this notification in S3 or S4
>> >> for following reasons:
>> >>
>> >> 1. dell-wireless does not handle slider (i.e. CRBT = 2 or
>> >> 3). Device drivers should read the hardware pin,
>> >> "W_DISABLE#" on mini spec and change hard block
>> >> accordingly. This pin is commonly used by OEM today.
>> >>
>> >> 2. it is not possible to distinguish the notification
>> >> (0x80) from hotkey press or S3/S4. I also concerned this
>> >> may mis-trigger state change when resuming from S3 or S4,
>> >> but it does not. Does any know how to ignore this
>> >> notification during resume only?
>> >>
>> >> dell-rbtn can use this notification + method (GRBT) [2] to
>> >> solve the problem that slider state.
>> >
>> > Unfortunately this won't solve the problem for me. After
>> > ARBT is called with 1 as parameter, it seems that GRBT
>> > always returns 1.
>> >
>> > I don't know how to ignore the notification on resume, if
>> > not through a flag set by a PM callback.
>> >
>> > Given that all the tested laptops reported a keypress on the
>> > i8042 bus, isn't it better to rely on that instead?
>> >
>> >> [1] http://people.canonical.com/~alexhung/dell-acpidump/
>> >> [2]
>> >> http://msdn.microsoft.com/en-us/library/windows/hardware/j
>> >> j128256.aspx [3] It seems GRBT may not always be
>> >> implemented...
>> >>
>> >> I'd love to do more tests and share the results on any
>> >> particular systems, but I may need some more detailed
>> >> instructions.
>> >>
>> >>
>> >>
>> >> On Tue, Dec 23, 2014 at 3:16 AM, Gabriele Mazzotta
>> >>
>> >> <gabriele.mzt@gmail.com> wrote:
>> >> > On Monday 22 December 2014 15:27:57 Alex Hung wrote:
>> >> >> = Testing =
>> >> >>
>> >> >> I tested six Dell systems for two sets of patches for
>> >> >> dell radio button - two system with radio slider and
>> >> >> four with radio hotkey. There are also two systems with
>> >> >> working ARBT method.
>> >> >>
>> >> >> == Basic Information ==
>> >> >> Based OS: Ubuntu 14.10 (kernel 3.16 [1]) and kernel 3.18
>> >> >> [2]
>> >> >>
>> >> >> Patches:
>> >> >> 1. dell-wireless v3 = original v2 + Gabriele's
>> >> >> suggestion [3] 2. dell-rbtn [4]
>> >> >>
>> >> >> Method:
>> >> >> 1. run "rfkill list" and press hotkey / toggle slider
>> >> >> during runtime 2. run "rfkill list" and toggle slider
>> >> >> during S3
>> >> >>
>> >> >> == Results ==
>> >> >>
>> >> >> I summarized the tests in Google sheet as below. Please
>> >> >> advise if anyone has problem reading it.
>> >> >>
>> >> >> https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSG
>> >> >> h3UmG__UAO2qfZ829CkJLPo06aI/edit?usp=sharing
>> >> >>
>> >> >> PS. The document will stay as long as possible for
>> >> >> future references.
>> >> >>
>> >> >> == Summary ==
>> >> >>
>> >> >> 1. I did not observed a duplicated event. However,
>> >> >> keycode 240 (unknown) is generated on many UUT. It is
>> >> >> not issued by dell-laptop or del-wmi. I am suspecting
>> >> >> it is the other event Pali observes but it can be the
>> >> >> result of different distro.
>> >> >>
>> >> >> 2. Some system issues scancode "0xe0 0x73 0xe0 0xf3". It
>> >> >> can also be used toggle wireless state but this can
>> >> >> also be distro-dependent. This scancode does nothing on
>> >> >> Ubuntu 14.10.
>> >> >>
>> >> >> 2. There are two systems with working ARBT (XPS 13 9333
>> >> >> and Inspiron 7447). Calling ARBT(1) changes BIOS
>> >> >> behaviours, and this matches to Dell's document. We
>> >> >> should include it in the patch for maximum capability.
>> >> >>
>> >> >>
>> >> >> [1] dell-wireless is only tested 3.16.
>> >> >> [2] dell-rbtn is tested on 3.16 and 3.18, but no
>> >> >> differences are observed. [3]
>> >> >> http://people.canonical.com/~alexhung/dell-wireless/
>> >> >> [4] http://people.canonical.com/~alexhung/dell-rbtn/
>> >> >
>> >> > I've just tried the last revision of dell-wireless and
>> >> > noticed that a notification (0x80) is sent to DELLABCE
>> >> > after a transition from S3 to S0, causing dell-wireless
>> >> > to send KEY_RFKILL. This shouldn't happen. Same thing
>> >> > for transitions from S4 to S0.
>> >> >
>> >> > Gabriele
>
> --
> Pali Rohár
> pali.rohar@gmail.com



-- 
Cheers,
Alex Hung

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

[Alex Hung]

I encountered a Dell Latitude machine whose wireless hotkey will not
work with dell-rbtn alone, and therefore I merged functions from
dell-wireless and it worked quite well.  I also tested it on 7 other
Dell machines, and only Inspiron 7437 failed because of a firmware bug
(see http://permalink.gmane.org/gmane.linux.acpi.devel/74915)

I am going to send the new patch for review.

On Fri, Dec 26, 2014 at 4:11 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> I will try to recap all information which we have...
>
> *) We should not send wireless key press to userspace when BIOS
> already handles wireless state (and enable/disable wifi):
> http://www.spinics.net/lists/platform-driver-x86/msg05922.html
>
> *) some tested dell machines does not implement GRBT method (or
> report constant value) which could return state of wireless
> (enabled/disabled) -- e.g. Inspiron 7447
>
> *) dell-wireless driver is doing nothing on devices which have
> wireless slider switch (except calling CRBT/ARBT methods)
>
> *) all tested machines emit key with keycode 240 (scancode is
> probably 136 = 0x88) to userspace via i8042 bus/AT keyboard when
> wireless button/slider is pressed/switched
>
> *) both drivers dell-wireless and dell-rbtn do not implement
> setting soft rfkill state (or change wifi state)
>
> So in my opinion: if we decide to use driver for acpi DELLABCE
> device we should use dell-rbnt for devices with hw slider switch
> and dell-wireless for devices with fn button. I think it does not
> make sense to use dell-wireless for devices with hw slider
> because it do nothing and dell-rbtn for devices with fn key
> button as GRBT does not working properly.
>
> And second note: Do we need some driver for acpi DELLABCE device?
> Which problem is trying acpi DELLABCE device to solve? Is not
> everything working fine without driver for DELLABCE device?
>
> My dell-rbtn approach is trying to export rfkill interface from
> DELLABCE device and eliminate using i8042 hook function in smbios
> dell-laptop driver.
>
> Alex, can you check if scancode of wireless change generated by
> BIOS is on all machines same: 136 (0x88)? And is send by keyboard
> controller (not acpi/wmi)?
>
> On Thursday 25 December 2014 04:13:02 Alex Hung wrote:
>> I usually prefer to stick with formal document as everything
>> else can be changed without reasons.
>>
>> I am not certain whether the keypress is defined in Dell's
>> document, and I will confirm with Dell. If this keypress is
>> well defined, it is a good idea to use it.
>>
>>
>> On Wed, Dec 24, 2014 at 7:40 PM, Gabriele Mazzotta
>>
>> <gabriele.mzt@gmail.com> wrote:
>> > On Wednesday 24 December 2014 17:13:45 Alex Hung wrote:
>> >> I uploaded acpidump files [1] (except for XPS 13 which is
>> >> not available), and this should help clarify what has been
>> >> tested.
>> >>
>> >> Does Inspirion 5721 does not have either DELLABCE or
>> >> DELRBTN. It is used for comparison. My apologies that I
>> >> did not point this out in previous email.
>> >>
>> >> When calling ARBT(1), BIOS will no longer issue scancode
>> >> and will not pull low hardware pin "W_DISABLE#" on mini
>> >> card. This essentially gives all wireless control to OS.
>> >> This is likely the answer to Microsoft's Windows
>> >> Certification Program
>> >> System.Client.RadioManagement.HardwareButton [2] as below:
>> >>
>> >> =============================================
>> >> If a PC has a physical (hardware) button switch on a PC
>> >> that turns wireless radios on and off, it must be software
>> >> controllable and interact appropriately with the Radio
>> >> Management UI
>> >> =============================================
>> >>
>> >> Dell's BIOS does issue a notify(RBTN, 0x80). This is done
>> >> purposely to re-enumerate the state of radio switch which
>> >> may be changed when system is in S3 or S4. I think this
>> >> should not occur when CRBT returns 0 or 1 (for hotkey that
>> >> cannot be changed during S3 or S4), but that's how it is
>> >> done currently.
>> >
>> > The notification is sent on my XPS13 (CRBT returns 0),
>> > toggling the WiFi state on resume.
>> >
>> >> dell-wireless does not handle this notification in S3 or S4
>> >> for following reasons:
>> >>
>> >> 1. dell-wireless does not handle slider (i.e. CRBT = 2 or
>> >> 3). Device drivers should read the hardware pin,
>> >> "W_DISABLE#" on mini spec and change hard block
>> >> accordingly. This pin is commonly used by OEM today.
>> >>
>> >> 2. it is not possible to distinguish the notification
>> >> (0x80) from hotkey press or S3/S4. I also concerned this
>> >> may mis-trigger state change when resuming from S3 or S4,
>> >> but it does not. Does any know how to ignore this
>> >> notification during resume only?
>> >>
>> >> dell-rbtn can use this notification + method (GRBT) [2] to
>> >> solve the problem that slider state.
>> >
>> > Unfortunately this won't solve the problem for me. After
>> > ARBT is called with 1 as parameter, it seems that GRBT
>> > always returns 1.
>> >
>> > I don't know how to ignore the notification on resume, if
>> > not through a flag set by a PM callback.
>> >
>> > Given that all the tested laptops reported a keypress on the
>> > i8042 bus, isn't it better to rely on that instead?
>> >
>> >> [1] http://people.canonical.com/~alexhung/dell-acpidump/
>> >> [2]
>> >> http://msdn.microsoft.com/en-us/library/windows/hardware/j
>> >> j128256.aspx [3] It seems GRBT may not always be
>> >> implemented...
>> >>
>> >> I'd love to do more tests and share the results on any
>> >> particular systems, but I may need some more detailed
>> >> instructions.
>> >>
>> >>
>> >>
>> >> On Tue, Dec 23, 2014 at 3:16 AM, Gabriele Mazzotta
>> >>
>> >> <gabriele.mzt@gmail.com> wrote:
>> >> > On Monday 22 December 2014 15:27:57 Alex Hung wrote:
>> >> >> = Testing =
>> >> >>
>> >> >> I tested six Dell systems for two sets of patches for
>> >> >> dell radio button - two system with radio slider and
>> >> >> four with radio hotkey. There are also two systems with
>> >> >> working ARBT method.
>> >> >>
>> >> >> == Basic Information ==
>> >> >> Based OS: Ubuntu 14.10 (kernel 3.16 [1]) and kernel 3.18
>> >> >> [2]
>> >> >>
>> >> >> Patches:
>> >> >> 1. dell-wireless v3 = original v2 + Gabriele's
>> >> >> suggestion [3] 2. dell-rbtn [4]
>> >> >>
>> >> >> Method:
>> >> >> 1. run "rfkill list" and press hotkey / toggle slider
>> >> >> during runtime 2. run "rfkill list" and toggle slider
>> >> >> during S3
>> >> >>
>> >> >> == Results ==
>> >> >>
>> >> >> I summarized the tests in Google sheet as below. Please
>> >> >> advise if anyone has problem reading it.
>> >> >>
>> >> >> https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSG
>> >> >> h3UmG__UAO2qfZ829CkJLPo06aI/edit?usp=sharing
>> >> >>
>> >> >> PS. The document will stay as long as possible for
>> >> >> future references.
>> >> >>
>> >> >> == Summary ==
>> >> >>
>> >> >> 1. I did not observed a duplicated event. However,
>> >> >> keycode 240 (unknown) is generated on many UUT. It is
>> >> >> not issued by dell-laptop or del-wmi. I am suspecting
>> >> >> it is the other event Pali observes but it can be the
>> >> >> result of different distro.
>> >> >>
>> >> >> 2. Some system issues scancode "0xe0 0x73 0xe0 0xf3". It
>> >> >> can also be used toggle wireless state but this can
>> >> >> also be distro-dependent. This scancode does nothing on
>> >> >> Ubuntu 14.10.
>> >> >>
>> >> >> 2. There are two systems with working ARBT (XPS 13 9333
>> >> >> and Inspiron 7447). Calling ARBT(1) changes BIOS
>> >> >> behaviours, and this matches to Dell's document. We
>> >> >> should include it in the patch for maximum capability.
>> >> >>
>> >> >>
>> >> >> [1] dell-wireless is only tested 3.16.
>> >> >> [2] dell-rbtn is tested on 3.16 and 3.18, but no
>> >> >> differences are observed. [3]
>> >> >> http://people.canonical.com/~alexhung/dell-wireless/
>> >> >> [4] http://people.canonical.com/~alexhung/dell-rbtn/
>> >> >
>> >> > I've just tried the last revision of dell-wireless and
>> >> > noticed that a notification (0x80) is sent to DELLABCE
>> >> > after a transition from S3 to S0, causing dell-wireless
>> >> > to send KEY_RFKILL. This shouldn't happen. Same thing
>> >> > for transitions from S4 to S0.
>> >> >
>> >> > Gabriele
>
> --
> Pali Rohár
> pali.rohar@gmail.com



-- 
Cheers,
Alex Hung

[PATCH v2 0/3] Dell Airplane Mode Switch driver

[Pali Rohár]

This patch series add new acpi Dell Airplane Mode Switch driver (DELLABCE and
DELRBTN acpi devices). It provides radio HW switch events (together with current
state of radio devices) and export them via rfkill interface. These events are
also used in dell-laptop driver instead i8042 filter hook function (when acpi
device is available).

In v2 was added support for laptops which have toggle button instead HW slider
switch. For that I reused code done by Alex Hung.

Pali Rohár (3):
  platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
  platform: x86: dell-rbtn: Export notifier for other kernel modules
  platform: x86: dell-laptop: Use dell-rbtn instead i8042 filter when
    possible

 drivers/platform/x86/Kconfig       |   14 ++
 drivers/platform/x86/Makefile      |    1 +
 drivers/platform/x86/dell-laptop.c |   67 +++++-
 drivers/platform/x86/dell-rbtn.c   |  430 ++++++++++++++++++++++++++++++++++++
 drivers/platform/x86/dell-rbtn.h   |   35 +++
 5 files changed, 542 insertions(+), 5 deletions(-)
 create mode 100644 drivers/platform/x86/dell-rbtn.c
 create mode 100644 drivers/platform/x86/dell-rbtn.h

-- 
1.7.9.5

[PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Pali Rohár]

This is an ACPI driver for Dell laptops which receive HW switch events.
It exports rfkill device dell-rbtn which provide correct hard rfkill state.

Alex Hung added code for supporting Dell laptops which have toggle button
instead HW slider switch. On these laptops toggle button event is reported
by new input device (instead rfkill) as they do not have hw radio switch.

It looks like those are two different functions (rfkill, input device), but
Dell BIOS exports them via same ACPI device and uses same ACPI functions.
So code is in one kernel driver.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Cc: Alex Hung <alex.hung@canonical.com>
---
 drivers/platform/x86/Kconfig     |   13 ++
 drivers/platform/x86/Makefile    |    1 +
 drivers/platform/x86/dell-rbtn.c |  344 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 358 insertions(+)
 create mode 100644 drivers/platform/x86/dell-rbtn.c

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index f9f205c..9d065c2 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -138,6 +138,19 @@ config DELL_SMO8800
 	  To compile this driver as a module, choose M here: the module will
 	  be called dell-smo8800.
 
+config DELL_RBTN
+	tristate "Dell Airplane Mode Switch driver"
+	depends on ACPI
+	depends on RFKILL
+	---help---
+	  Say Y here if you want to support Dell Airplane Mode Switch ACPI
+	  device on Dell laptops. Sometimes it has names: DELLABCE or DELRBTN.
+	  This driver register rfkill device and receives HW rfkill events
+	  (when wifi/bluetooth was enabled) and set correct hard rfkill state.
+
+	  To compile this driver as a module, choose M here: the module will
+	  be called dell-rbtn.
+
 
 config FUJITSU_LAPTOP
 	tristate "Fujitsu Laptop Extras"
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index f82232b..b3e54ed 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_DELL_LAPTOP)	+= dell-laptop.o
 obj-$(CONFIG_DELL_WMI)		+= dell-wmi.o
 obj-$(CONFIG_DELL_WMI_AIO)	+= dell-wmi-aio.o
 obj-$(CONFIG_DELL_SMO8800)	+= dell-smo8800.o
+obj-$(CONFIG_DELL_RBTN)		+= dell-rbtn.o
 obj-$(CONFIG_ACER_WMI)		+= acer-wmi.o
 obj-$(CONFIG_ACERHDF)		+= acerhdf.o
 obj-$(CONFIG_HP_ACCEL)		+= hp_accel.o
diff --git a/drivers/platform/x86/dell-rbtn.c b/drivers/platform/x86/dell-rbtn.c
new file mode 100644
index 0000000..894cd9a
--- /dev/null
+++ b/drivers/platform/x86/dell-rbtn.c
@@ -0,0 +1,344 @@
+/*
+    Dell Airplane Mode Switch driver
+    Copyright (C) 2014-2015  Pali Rohár <pali.rohar@gmail.com>
+
+    This program is free software; you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+*/
+
+#include <linux/module.h>
+#include <linux/acpi.h>
+#include <linux/rfkill.h>
+#include <linux/input.h>
+
+enum rbtn_type {
+	RBTN_UNKNOWN,
+	RBTN_TOGGLE,
+	RBTN_SLIDER,
+};
+
+struct rbtn_data {
+	enum rbtn_type type;
+	struct rfkill *rfkill;
+	struct input_dev *input_dev;
+};
+
+
+/*
+ * acpi functions
+ */
+
+static enum rbtn_type rbtn_check(struct acpi_device *device)
+{
+	unsigned long long output;
+	acpi_status status;
+
+	status = acpi_evaluate_integer(device->handle, "CRBT", NULL, &output);
+	if (ACPI_FAILURE(status))
+		return RBTN_UNKNOWN;
+
+	switch (output) {
+	case 0:
+	case 1:
+		return RBTN_TOGGLE;
+	case 2:
+	case 3:
+		return RBTN_SLIDER;
+	default:
+		return RBTN_UNKNOWN;
+	}
+}
+
+static int rbtn_get(struct acpi_device *device)
+{
+	unsigned long long output;
+	acpi_status status;
+
+	status = acpi_evaluate_integer(device->handle, "GRBT", NULL, &output);
+	if (ACPI_FAILURE(status))
+		return -EINVAL;
+
+	return !output;
+}
+
+static int rbtn_radio_enable(struct acpi_device *device, bool enable)
+{
+	struct acpi_object_list input;
+	union acpi_object param;
+	acpi_status status;
+
+	param.type = ACPI_TYPE_INTEGER;
+	param.integer.value = enable;
+	input.count = 1;
+	input.pointer = &param;
+
+	status = acpi_evaluate_object(device->handle, "ARBT", &input, NULL);
+	if (ACPI_FAILURE(status))
+		return -EINVAL;
+
+	return 0;
+}
+
+
+/*
+ * rfkill device
+ */
+
+static void rbtn_rfkill_query(struct rfkill *rfkill, void *data)
+{
+	struct acpi_device *device = data;
+	int state;
+
+	state = rbtn_get(device);
+	if (state < 0)
+		return;
+
+	rfkill_set_states(rfkill, state, state);
+}
+
+static int rbtn_rfkill_set_block(void *data, bool blocked)
+{
+	/* NOTE: setting soft rfkill state is not supported */
+	return -EINVAL;
+}
+
+struct rfkill_ops rbtn_ops = {
+	.query = rbtn_rfkill_query,
+	.set_block = rbtn_rfkill_set_block,
+};
+
+static int rbtn_rfkill_init(struct acpi_device *device)
+{
+	struct rbtn_data *rbtn_data = device->driver_data;
+	int ret;
+
+	if (rbtn_data->rfkill)
+		return 0;
+
+	/* NOTE: rbtn controls all radio devices, not only WLAN
+	         but rfkill interface does not support "ANY" type
+	         so "WLAN" type is used
+	 */
+	rbtn_data->rfkill = rfkill_alloc("dell-rbtn", &device->dev,
+					 RFKILL_TYPE_WLAN, &rbtn_ops, device);
+	if (!rbtn_data->rfkill)
+		return -ENOMEM;
+
+	ret = rfkill_register(rbtn_data->rfkill);
+	if (ret) {
+		rfkill_destroy(rbtn_data->rfkill);
+		rbtn_data->rfkill = NULL;
+		return ret;
+	}
+
+	return 0;
+}
+
+static void rbtn_rfkill_exit(struct acpi_device *device)
+{
+	struct rbtn_data *rbtn_data = device->driver_data;
+
+	if (!rbtn_data->rfkill)
+		return;
+
+	rfkill_unregister(rbtn_data->rfkill);
+	rfkill_destroy(rbtn_data->rfkill);
+	rbtn_data->rfkill = NULL;
+}
+
+static void rbtn_rfkill_event(struct acpi_device *device)
+{
+	struct rbtn_data *rbtn_data = device->driver_data;
+
+	if (rbtn_data->rfkill)
+		rbtn_rfkill_query(rbtn_data->rfkill, device);
+}
+
+
+/*
+ * input device
+ */
+
+static int rbtn_input_init(struct rbtn_data *rbtn_data)
+{
+	int ret;
+
+	rbtn_data->input_dev = input_allocate_device();
+	if (!rbtn_data->input_dev)
+		return -ENOMEM;
+
+	rbtn_data->input_dev->name = "DELL Wireless hotkeys";
+	rbtn_data->input_dev->phys = "dellabce/input0";
+	rbtn_data->input_dev->id.bustype = BUS_HOST;
+	rbtn_data->input_dev->evbit[0] = BIT(EV_KEY);
+	set_bit(KEY_RFKILL, rbtn_data->input_dev->keybit);
+
+	ret = input_register_device(rbtn_data->input_dev);
+	if (ret) {
+		input_free_device(rbtn_data->input_dev);
+		rbtn_data->input_dev = NULL;
+		return ret;
+	}
+
+	return 0;
+}
+
+static void rbtn_input_exit(struct rbtn_data *rbtn_data)
+{
+	input_unregister_device(rbtn_data->input_dev);
+	rbtn_data->input_dev = NULL;
+}
+
+static void rbtn_input_event(struct rbtn_data *rbtn_data)
+{
+	input_report_key(rbtn_data->input_dev, KEY_RFKILL, 1);
+	input_sync(rbtn_data->input_dev);
+	input_report_key(rbtn_data->input_dev, KEY_RFKILL, 0);
+	input_sync(rbtn_data->input_dev);
+}
+
+
+/*
+ * acpi driver
+ */
+
+static int rbtn_add(struct acpi_device *device);
+static int rbtn_remove(struct acpi_device *device);
+static void rbtn_notify(struct acpi_device *device, u32 event);
+
+static const struct acpi_device_id rbtn_ids[] = {
+	{ "DELRBTN", 0 },
+	{ "DELLABCE", 0 },
+	{ "", 0 },
+};
+
+static struct acpi_driver rbtn_driver = {
+	.name = "dell-rbtn",
+	.ids = rbtn_ids,
+	.ops = {
+		.add = rbtn_add,
+		.remove = rbtn_remove,
+		.notify = rbtn_notify,
+	},
+	.owner = THIS_MODULE,
+};
+
+
+/*
+ * acpi driver functions
+ */
+
+static int rbtn_add(struct acpi_device *device)
+{
+	struct rbtn_data *rbtn_data;
+	enum rbtn_type type;
+	int ret = 0;
+
+	type = rbtn_check(device);
+	if (type == RBTN_UNKNOWN) {
+		dev_info(&device->dev, "Unknown device type\n");
+		return -EINVAL;
+	}
+
+	ret = rbtn_radio_enable(device, true);
+	if (ret < 0) {
+		dev_err(&device->dev, "Cannot enable device\n");
+		return ret;
+	}
+
+	rbtn_data = devm_kzalloc(&device->dev, sizeof(*rbtn_data), GFP_KERNEL);
+	if (!rbtn_data)
+		return -ENOMEM;
+
+	rbtn_data->type = type;
+	device->driver_data = rbtn_data;
+
+	switch (rbtn_data->type) {
+	case RBTN_TOGGLE:
+		ret = rbtn_input_init(rbtn_data);
+		break;
+	case RBTN_SLIDER:
+		ret = rbtn_rfkill_init(device);
+		break;
+	default:
+		ret = -EINVAL;
+	}
+
+	return ret;
+
+}
+
+static int rbtn_remove(struct acpi_device *device)
+{
+	struct rbtn_data *rbtn_data = device->driver_data;
+	int ret;
+
+	switch (rbtn_data->type) {
+	case RBTN_TOGGLE:
+		rbtn_input_exit(rbtn_data);
+		break;
+	case RBTN_SLIDER:
+		rbtn_rfkill_exit(device);
+		break;
+	default:
+		break;
+	}
+
+	ret = rbtn_radio_enable(device, false);
+	if (ret < 0)
+		return ret;
+
+	device->driver_data = NULL;
+	return 0;
+}
+
+static void rbtn_notify(struct acpi_device *device, u32 event)
+{
+	struct rbtn_data *rbtn_data = device->driver_data;
+
+	if (event != 0x80) {
+		dev_info(&device->dev, "Received unknown event (0x%x)\n", event);
+		return;
+	}
+
+	switch (rbtn_data->type) {
+	case RBTN_TOGGLE:
+		rbtn_input_event(rbtn_data);
+		break;
+	case RBTN_SLIDER:
+		rbtn_rfkill_event(device);
+		break;
+	default:
+		break;
+	}
+}
+
+
+/*
+ * module functions
+ */
+
+static int __init rbtn_init(void)
+{
+	return acpi_bus_register_driver(&rbtn_driver);
+}
+
+static void __exit rbtn_exit(void)
+{
+	acpi_bus_unregister_driver(&rbtn_driver);
+}
+
+module_init(rbtn_init);
+module_exit(rbtn_exit);
+
+MODULE_DEVICE_TABLE(acpi, rbtn_ids);
+MODULE_DESCRIPTION("Dell Airplane Mode Switch driver");
+MODULE_AUTHOR("Pali Rohár <pali.rohar@gmail.com>");
+MODULE_LICENSE("GPL");
-- 
1.7.9.5

Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Gabriele Mazzotta]

On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote:
> This is an ACPI driver for Dell laptops which receive HW switch events.
> It exports rfkill device dell-rbtn which provide correct hard rfkill state.
> 
> Alex Hung added code for supporting Dell laptops which have toggle button
> instead HW slider switch. On these laptops toggle button event is reported
> by new input device (instead rfkill) as they do not have hw radio switch.
> 
> It looks like those are two different functions (rfkill, input device), but
> Dell BIOS exports them via same ACPI device and uses same ACPI functions.
> So code is in one kernel driver.

I made a patch some time ago that I've just adapted. It allows to
prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd like to
have the hardware switch is that the BIOS doesn't alter the soft state
of the devices. This comes in handy when the function key controls
multiple radio devices.

Here below the simple patch. Maybe I could improve it and allow a
dynamic switch between RBTN_TOGGLE and RBTN_SLIDER.


>From 35d39a4ad079489147b4ce22651c5e4e18856cf0 Mon Sep 17 00:00:00 2001
From: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Date: Wed, 29 Apr 2015 12:24:52 +0200
Subject: [PATCH] dell-rbtn: Add module param to force the radio hardware
 switch

dell-rbtn determines whether the BIOS controls the radio devices when
function keys are pressed by calling the ACPI method CRBT. As long as
the ACPI method ARBT is called with 1 as argument, we are sure that
what is returned by CRBT holds.

This patch adds the possibility to pass a parameter that will make
dell-rbtn ignore the value returned by CRBT and call ARBT with 0 as
argument. This will allow users to have the BIOS control the radio
devices. Since there is no way to know when this is possible, it's
up to the user to force the mode. This guarantees the correct
functionality of the driver except when the user forces the mode.
---
 drivers/platform/x86/dell-rbtn.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/dell-rbtn.c b/drivers/platform/x86/dell-rbtn.c
index 07dfd8f..8f8d62b 100644
--- a/drivers/platform/x86/dell-rbtn.c
+++ b/drivers/platform/x86/dell-rbtn.c
@@ -30,6 +30,8 @@ struct rbtn_data {
 	struct input_dev *input_dev;
 };
 
+static bool force_hw_switch;
+module_param(force_hw_switch, bool, S_IRUGO);
 
 /*
  * acpi functions
@@ -44,6 +46,9 @@ static enum rbtn_type rbtn_check(struct acpi_device *device)
 	if (ACPI_FAILURE(status))
 		return RBTN_UNKNOWN;
 
+	if (force_hw_switch)
+		return RBTN_SLIDER;
+
 	switch (output) {
 	case 0:
 	case 1:
@@ -321,7 +326,7 @@ static int rbtn_add(struct acpi_device *device)
 		return -EINVAL;
 	}
 
-	ret = rbtn_radio_enable(device, true);
+	ret = rbtn_radio_enable(device, !force_hw_switch);
 	if (ret < 0) {
 		dev_err(&device->dev, "Cannot enable device\n");
 		return ret;
-- 
2.1.4

Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Gabriele Mazzotta]

On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote:
> This is an ACPI driver for Dell laptops which receive HW switch events.
> It exports rfkill device dell-rbtn which provide correct hard rfkill state.
> 
> Alex Hung added code for supporting Dell laptops which have toggle button
> instead HW slider switch. On these laptops toggle button event is reported
> by new input device (instead rfkill) as they do not have hw radio switch.
> 
> It looks like those are two different functions (rfkill, input device), but
> Dell BIOS exports them via same ACPI device and uses same ACPI functions.
> So code is in one kernel driver.

I made a patch some time ago that I've just adapted. It allows to
prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd like to
have the hardware switch is that the BIOS doesn't alter the soft state
of the devices. This comes in handy when the function key controls
multiple radio devices.

Here below the simple patch. Maybe I could improve it and allow a
dynamic switch between RBTN_TOGGLE and RBTN_SLIDER.


From 35d39a4ad079489147b4ce22651c5e4e18856cf0 Mon Sep 17 00:00:00 2001
From: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Date: Wed, 29 Apr 2015 12:24:52 +0200
Subject: [PATCH] dell-rbtn: Add module param to force the radio hardware
 switch

dell-rbtn determines whether the BIOS controls the radio devices when
function keys are pressed by calling the ACPI method CRBT. As long as
the ACPI method ARBT is called with 1 as argument, we are sure that
what is returned by CRBT holds.

This patch adds the possibility to pass a parameter that will make
dell-rbtn ignore the value returned by CRBT and call ARBT with 0 as
argument. This will allow users to have the BIOS control the radio
devices. Since there is no way to know when this is possible, it's
up to the user to force the mode. This guarantees the correct
functionality of the driver except when the user forces the mode.
---
 drivers/platform/x86/dell-rbtn.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/dell-rbtn.c b/drivers/platform/x86/dell-rbtn.c
index 07dfd8f..8f8d62b 100644
--- a/drivers/platform/x86/dell-rbtn.c
+++ b/drivers/platform/x86/dell-rbtn.c
@@ -30,6 +30,8 @@ struct rbtn_data {
 	struct input_dev *input_dev;
 };
 
+static bool force_hw_switch;
+module_param(force_hw_switch, bool, S_IRUGO);
 
 /*
  * acpi functions
@@ -44,6 +46,9 @@ static enum rbtn_type rbtn_check(struct acpi_device *device)
 	if (ACPI_FAILURE(status))
 		return RBTN_UNKNOWN;
 
+	if (force_hw_switch)
+		return RBTN_SLIDER;
+
 	switch (output) {
 	case 0:
 	case 1:
@@ -321,7 +326,7 @@ static int rbtn_add(struct acpi_device *device)
 		return -EINVAL;
 	}
 
-	ret = rbtn_radio_enable(device, true);
+	ret = rbtn_radio_enable(device, !force_hw_switch);
 	if (ret < 0) {
 		dev_err(&device->dev, "Cannot enable device\n");
 		return ret;
-- 
2.1.4

Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Pali Rohár]

On Wednesday 29 April 2015 12:30:32 Gabriele Mazzotta wrote:
> On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote:
> > This is an ACPI driver for Dell laptops which receive HW switch events.
> > It exports rfkill device dell-rbtn which provide correct hard rfkill state.
> > 
> > Alex Hung added code for supporting Dell laptops which have toggle button
> > instead HW slider switch. On these laptops toggle button event is reported
> > by new input device (instead rfkill) as they do not have hw radio switch.
> > 
> > It looks like those are two different functions (rfkill, input device), but
> > Dell BIOS exports them via same ACPI device and uses same ACPI functions.
> > So code is in one kernel driver.
> 
> I made a patch some time ago that I've just adapted. It allows to
> prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd like to
> have the hardware switch is that the BIOS doesn't alter the soft state
> of the devices. This comes in handy when the function key controls
> multiple radio devices.
> 

Now I'm thinking... is't this bug in wifi kernel driver (which exports
phy rfkill)? Or problem somewhere else (userspace or kernel)?

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

Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Gabriele Mazzotta]

On Wednesday 29 April 2015 15:08:40 Pali Rohár wrote:
> On Wednesday 29 April 2015 12:30:32 Gabriele Mazzotta wrote:
> > On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote:
> > > This is an ACPI driver for Dell laptops which receive HW switch events.
> > > It exports rfkill device dell-rbtn which provide correct hard rfkill state.
> > > 
> > > Alex Hung added code for supporting Dell laptops which have toggle button
> > > instead HW slider switch. On these laptops toggle button event is reported
> > > by new input device (instead rfkill) as they do not have hw radio switch.
> > > 
> > > It looks like those are two different functions (rfkill, input device), but
> > > Dell BIOS exports them via same ACPI device and uses same ACPI functions.
> > > So code is in one kernel driver.
> > 
> > I made a patch some time ago that I've just adapted. It allows to
> > prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd like to
> > have the hardware switch is that the BIOS doesn't alter the soft state
> > of the devices. This comes in handy when the function key controls
> > multiple radio devices.
> > 
> 
> Now I'm thinking... is't this bug in wifi kernel driver (which exports
> phy rfkill)? Or problem somewhere else (userspace or kernel)?

What is the presumed bug you are referring to? The fact that the soft state
doesn't change?

Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Pali Rohár]

On Wednesday 29 April 2015 15:57:58 Gabriele Mazzotta wrote:
> On Wednesday 29 April 2015 15:08:40 Pali Rohár wrote:
> > On Wednesday 29 April 2015 12:30:32 Gabriele Mazzotta wrote:
> > > On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote:
> > > > This is an ACPI driver for Dell laptops which receive HW switch events.
> > > > It exports rfkill device dell-rbtn which provide correct hard rfkill state.
> > > > 
> > > > Alex Hung added code for supporting Dell laptops which have toggle button
> > > > instead HW slider switch. On these laptops toggle button event is reported
> > > > by new input device (instead rfkill) as they do not have hw radio switch.
> > > > 
> > > > It looks like those are two different functions (rfkill, input device), but
> > > > Dell BIOS exports them via same ACPI device and uses same ACPI functions.
> > > > So code is in one kernel driver.
> > > 
> > > I made a patch some time ago that I've just adapted. It allows to
> > > prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd like to
> > > have the hardware switch is that the BIOS doesn't alter the soft state
> > > of the devices. This comes in handy when the function key controls
> > > multiple radio devices.
> > > 
> > 
> > Now I'm thinking... is't this bug in wifi kernel driver (which exports
> > phy rfkill)? Or problem somewhere else (userspace or kernel)?
> 
> What is the presumed bug you are referring to? The fact that the soft state
> doesn't change?

Can you remind me whats the problem on your laptop?

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

Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Gabriele Mazzotta]

On Wednesday 29 April 2015 18:28:40 Pali Rohár wrote:
> On Wednesday 29 April 2015 15:57:58 Gabriele Mazzotta wrote:
> > On Wednesday 29 April 2015 15:08:40 Pali Rohár wrote:
> > > On Wednesday 29 April 2015 12:30:32 Gabriele Mazzotta wrote:
> > > > On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote:
> > > > > This is an ACPI driver for Dell laptops which receive HW switch events.
> > > > > It exports rfkill device dell-rbtn which provide correct hard rfkill state.
> > > > > 
> > > > > Alex Hung added code for supporting Dell laptops which have toggle button
> > > > > instead HW slider switch. On these laptops toggle button event is reported
> > > > > by new input device (instead rfkill) as they do not have hw radio switch.
> > > > > 
> > > > > It looks like those are two different functions (rfkill, input device), but
> > > > > Dell BIOS exports them via same ACPI device and uses same ACPI functions.
> > > > > So code is in one kernel driver.
> > > > 
> > > > I made a patch some time ago that I've just adapted. It allows to
> > > > prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd like to
> > > > have the hardware switch is that the BIOS doesn't alter the soft state
> > > > of the devices. This comes in handy when the function key controls
> > > > multiple radio devices.
> > > > 
> > > 
> > > Now I'm thinking... is't this bug in wifi kernel driver (which exports
> > > phy rfkill)? Or problem somewhere else (userspace or kernel)?
> > 
> > What is the presumed bug you are referring to? The fact that the soft state
> > doesn't change?
> 
> Can you remind me whats the problem on your laptop?

CRBT returns 0 (so RBTN_TOGGLE), but by default my laptop acts as if
it returned 2 or 3, so we have to call ARBT.

As said before, there's no way to know when a platform whose CRBT
method returns 0 or 1 also has the hardware switch, so to be sure that
all the platforms have working function keys, some of them (such as
mine) have to give up on the hardware switch.

Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Pali Rohár]

On Wednesday 29 April 2015 19:54:43 Gabriele Mazzotta wrote:
> On Wednesday 29 April 2015 18:28:40 Pali Rohár wrote:
> > On Wednesday 29 April 2015 15:57:58 Gabriele Mazzotta wrote:
> > > On Wednesday 29 April 2015 15:08:40 Pali Rohár wrote:
> > > > On Wednesday 29 April 2015 12:30:32 Gabriele Mazzotta wrote:
> > > > > On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote:
> > > > > > This is an ACPI driver for Dell laptops which receive HW switch events.
> > > > > > It exports rfkill device dell-rbtn which provide correct hard rfkill state.
> > > > > > 
> > > > > > Alex Hung added code for supporting Dell laptops which have toggle button
> > > > > > instead HW slider switch. On these laptops toggle button event is reported
> > > > > > by new input device (instead rfkill) as they do not have hw radio switch.
> > > > > > 
> > > > > > It looks like those are two different functions (rfkill, input device), but
> > > > > > Dell BIOS exports them via same ACPI device and uses same ACPI functions.
> > > > > > So code is in one kernel driver.
> > > > > 
> > > > > I made a patch some time ago that I've just adapted. It allows to
> > > > > prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd like to
> > > > > have the hardware switch is that the BIOS doesn't alter the soft state
> > > > > of the devices. This comes in handy when the function key controls
> > > > > multiple radio devices.
> > > > > 
> > > > 
> > > > Now I'm thinking... is't this bug in wifi kernel driver (which exports
> > > > phy rfkill)? Or problem somewhere else (userspace or kernel)?
> > > 
> > > What is the presumed bug you are referring to? The fact that the soft state
> > > doesn't change?
> > 
> > Can you remind me whats the problem on your laptop?
> 
> CRBT returns 0 (so RBTN_TOGGLE), but by default my laptop acts as if
> it returned 2 or 3, so we have to call ARBT.
> 
> As said before, there's no way to know when a platform whose CRBT
> method returns 0 or 1 also has the hardware switch, so to be sure that
> all the platforms have working function keys, some of them (such as
> mine) have to give up on the hardware switch.

Ok, and what happens when you load this v2 version? What stopped working
on your laptop?

Alex, can you help? Code for toggle laptop version is originally yours.

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

Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Gabriele Mazzotta]

On Wednesday 29 April 2015 20:00:18 Pali Rohár wrote:
> On Wednesday 29 April 2015 19:54:43 Gabriele Mazzotta wrote:
> > On Wednesday 29 April 2015 18:28:40 Pali Rohár wrote:
> > > On Wednesday 29 April 2015 15:57:58 Gabriele Mazzotta wrote:
> > > > On Wednesday 29 April 2015 15:08:40 Pali Rohár wrote:
> > > > > On Wednesday 29 April 2015 12:30:32 Gabriele Mazzotta wrote:
> > > > > > On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote:
> > > > > > > This is an ACPI driver for Dell laptops which receive HW switch events.
> > > > > > > It exports rfkill device dell-rbtn which provide correct hard rfkill state.
> > > > > > > 
> > > > > > > Alex Hung added code for supporting Dell laptops which have toggle button
> > > > > > > instead HW slider switch. On these laptops toggle button event is reported
> > > > > > > by new input device (instead rfkill) as they do not have hw radio switch.
> > > > > > > 
> > > > > > > It looks like those are two different functions (rfkill, input device), but
> > > > > > > Dell BIOS exports them via same ACPI device and uses same ACPI functions.
> > > > > > > So code is in one kernel driver.
> > > > > > 
> > > > > > I made a patch some time ago that I've just adapted. It allows to
> > > > > > prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd like to
> > > > > > have the hardware switch is that the BIOS doesn't alter the soft state
> > > > > > of the devices. This comes in handy when the function key controls
> > > > > > multiple radio devices.
> > > > > > 
> > > > > 
> > > > > Now I'm thinking... is't this bug in wifi kernel driver (which exports
> > > > > phy rfkill)? Or problem somewhere else (userspace or kernel)?
> > > > 
> > > > What is the presumed bug you are referring to? The fact that the soft state
> > > > doesn't change?
> > > 
> > > Can you remind me whats the problem on your laptop?
> > 
> > CRBT returns 0 (so RBTN_TOGGLE), but by default my laptop acts as if
> > it returned 2 or 3, so we have to call ARBT.
> > 
> > As said before, there's no way to know when a platform whose CRBT
> > method returns 0 or 1 also has the hardware switch, so to be sure that
> > all the platforms have working function keys, some of them (such as
> > mine) have to give up on the hardware switch.
> 
> Ok, and what happens when you load this v2 version? What stopped working
> on your laptop?
> 
> Alex, can you help? Code for toggle laptop version is originally yours.

When I press the Fn key, a _Qxx EC method is executed. The code path
of this method depends on a variable set by ARBT.

When you call ARBT with 1 as argument, the variable is set to 1 and the
_Qxx method does nothing but sending a notification (0x80) to RBTN
whenever the function key is pressed.

When you call ARBT with 0 as argument, the variable is set to 0 and
the _Qxx method both sends 0x80 to RBTN _and_ toggle the state of the
radio devices whenever the function key is pressed.

So in the end nothing _really_ breaks.

Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Pali Rohár]

On Wednesday 29 April 2015 20:11:38 Gabriele Mazzotta wrote:
> On Wednesday 29 April 2015 20:00:18 Pali Rohár wrote:
> > On Wednesday 29 April 2015 19:54:43 Gabriele Mazzotta wrote:
> > > On Wednesday 29 April 2015 18:28:40 Pali Rohár wrote:
> > > > On Wednesday 29 April 2015 15:57:58 Gabriele Mazzotta wrote:
> > > > > On Wednesday 29 April 2015 15:08:40 Pali Rohár wrote:
> > > > > > On Wednesday 29 April 2015 12:30:32 Gabriele Mazzotta wrote:
> > > > > > > On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote:
> > > > > > > > This is an ACPI driver for Dell laptops which receive HW switch events.
> > > > > > > > It exports rfkill device dell-rbtn which provide correct hard rfkill state.
> > > > > > > > 
> > > > > > > > Alex Hung added code for supporting Dell laptops which have toggle button
> > > > > > > > instead HW slider switch. On these laptops toggle button event is reported
> > > > > > > > by new input device (instead rfkill) as they do not have hw radio switch.
> > > > > > > > 
> > > > > > > > It looks like those are two different functions (rfkill, input device), but
> > > > > > > > Dell BIOS exports them via same ACPI device and uses same ACPI functions.
> > > > > > > > So code is in one kernel driver.
> > > > > > > 
> > > > > > > I made a patch some time ago that I've just adapted. It allows to
> > > > > > > prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd like to
> > > > > > > have the hardware switch is that the BIOS doesn't alter the soft state
> > > > > > > of the devices. This comes in handy when the function key controls
> > > > > > > multiple radio devices.
> > > > > > > 
> > > > > > 
> > > > > > Now I'm thinking... is't this bug in wifi kernel driver (which exports
> > > > > > phy rfkill)? Or problem somewhere else (userspace or kernel)?
> > > > > 
> > > > > What is the presumed bug you are referring to? The fact that the soft state
> > > > > doesn't change?
> > > > 
> > > > Can you remind me whats the problem on your laptop?
> > > 
> > > CRBT returns 0 (so RBTN_TOGGLE), but by default my laptop acts as if
> > > it returned 2 or 3, so we have to call ARBT.
> > > 
> > > As said before, there's no way to know when a platform whose CRBT
> > > method returns 0 or 1 also has the hardware switch, so to be sure that
> > > all the platforms have working function keys, some of them (such as
> > > mine) have to give up on the hardware switch.
> > 
> > Ok, and what happens when you load this v2 version? What stopped working
> > on your laptop?
> > 
> > Alex, can you help? Code for toggle laptop version is originally yours.
> 
> When I press the Fn key, a _Qxx EC method is executed. The code path
> of this method depends on a variable set by ARBT.
> 
> When you call ARBT with 1 as argument, the variable is set to 1 and the
> _Qxx method does nothing but sending a notification (0x80) to RBTN
> whenever the function key is pressed.
> 
> When you call ARBT with 0 as argument, the variable is set to 0 and
> the _Qxx method both sends 0x80 to RBTN _and_ toggle the state of the
> radio devices whenever the function key is pressed.
> 
> So in the end nothing _really_ breaks.

So in linux kernel is missing code for toggling state of radio devices?
And you can do that only by ACPI when ARBT is called with 0, right?

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

Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Gabriele Mazzotta]

On Wednesday 29 April 2015 20:16:06 Pali Rohár wrote:
> On Wednesday 29 April 2015 20:11:38 Gabriele Mazzotta wrote:
> > On Wednesday 29 April 2015 20:00:18 Pali Rohár wrote:
> > > On Wednesday 29 April 2015 19:54:43 Gabriele Mazzotta wrote:
> > > > On Wednesday 29 April 2015 18:28:40 Pali Rohár wrote:
> > > > > On Wednesday 29 April 2015 15:57:58 Gabriele Mazzotta wrote:
> > > > > > On Wednesday 29 April 2015 15:08:40 Pali Rohár wrote:
> > > > > > > On Wednesday 29 April 2015 12:30:32 Gabriele Mazzotta wrote:
> > > > > > > > On Wednesday 29 April 2015 11:51:04 Pali Rohár wrote:
> > > > > > > > > This is an ACPI driver for Dell laptops which receive HW switch events.
> > > > > > > > > It exports rfkill device dell-rbtn which provide correct hard rfkill state.
> > > > > > > > > 
> > > > > > > > > Alex Hung added code for supporting Dell laptops which have toggle button
> > > > > > > > > instead HW slider switch. On these laptops toggle button event is reported
> > > > > > > > > by new input device (instead rfkill) as they do not have hw radio switch.
> > > > > > > > > 
> > > > > > > > > It looks like those are two different functions (rfkill, input device), but
> > > > > > > > > Dell BIOS exports them via same ACPI device and uses same ACPI functions.
> > > > > > > > > So code is in one kernel driver.
> > > > > > > > 
> > > > > > > > I made a patch some time ago that I've just adapted. It allows to
> > > > > > > > prefer RBTN_SLIDER over RBTN_TOGGLE. The main reason why I'd like to
> > > > > > > > have the hardware switch is that the BIOS doesn't alter the soft state
> > > > > > > > of the devices. This comes in handy when the function key controls
> > > > > > > > multiple radio devices.
> > > > > > > > 
> > > > > > > 
> > > > > > > Now I'm thinking... is't this bug in wifi kernel driver (which exports
> > > > > > > phy rfkill)? Or problem somewhere else (userspace or kernel)?
> > > > > > 
> > > > > > What is the presumed bug you are referring to? The fact that the soft state
> > > > > > doesn't change?
> > > > > 
> > > > > Can you remind me whats the problem on your laptop?
> > > > 
> > > > CRBT returns 0 (so RBTN_TOGGLE), but by default my laptop acts as if
> > > > it returned 2 or 3, so we have to call ARBT.
> > > > 
> > > > As said before, there's no way to know when a platform whose CRBT
> > > > method returns 0 or 1 also has the hardware switch, so to be sure that
> > > > all the platforms have working function keys, some of them (such as
> > > > mine) have to give up on the hardware switch.
> > > 
> > > Ok, and what happens when you load this v2 version? What stopped working
> > > on your laptop?
> > > 
> > > Alex, can you help? Code for toggle laptop version is originally yours.
> > 
> > When I press the Fn key, a _Qxx EC method is executed. The code path
> > of this method depends on a variable set by ARBT.
> > 
> > When you call ARBT with 1 as argument, the variable is set to 1 and the
> > _Qxx method does nothing but sending a notification (0x80) to RBTN
> > whenever the function key is pressed.
> > 
> > When you call ARBT with 0 as argument, the variable is set to 0 and
> > the _Qxx method both sends 0x80 to RBTN _and_ toggle the state of the
> > radio devices whenever the function key is pressed.
> > 
> > So in the end nothing _really_ breaks.
> 
> So in linux kernel is missing code for toggling state of radio devices?
> And you can do that only by ACPI when ARBT is called with 0, right?

Yes.

With Alex's code the kernel sends keypresses to userspace and userspace
takes care of toggling the state of radio devices.

Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 4405 bytes --]

On Wednesday 29 April 2015 20:41:38 Gabriele Mazzotta wrote:
> On Wednesday 29 April 2015 20:16:06 Pali Rohár wrote:
> > On Wednesday 29 April 2015 20:11:38 Gabriele Mazzotta wrote:
> > > On Wednesday 29 April 2015 20:00:18 Pali Rohár wrote:
> > > > On Wednesday 29 April 2015 19:54:43 Gabriele Mazzotta
> > > > wrote:
> > > > > On Wednesday 29 April 2015 18:28:40 Pali Rohár wrote:
> > > > > > On Wednesday 29 April 2015 15:57:58 Gabriele Mazzotta
> > > > > > wrote:
> > > > > > > On Wednesday 29 April 2015 15:08:40 Pali Rohár
> > > > > > > wrote:
> > > > > > > > On Wednesday 29 April 2015 12:30:32 Gabriele
> > > > > > > > Mazzotta wrote:
> > > > > > > > > On Wednesday 29 April 2015 11:51:04 Pali Rohár
> > > > > > > > > wrote:
> > > > > > > > > > This is an ACPI driver for Dell laptops
> > > > > > > > > > which receive HW switch events. It exports
> > > > > > > > > > rfkill device dell-rbtn which provide
> > > > > > > > > > correct hard rfkill state.
> > > > > > > > > > 
> > > > > > > > > > Alex Hung added code for supporting Dell
> > > > > > > > > > laptops which have toggle button instead HW
> > > > > > > > > > slider switch. On these laptops toggle
> > > > > > > > > > button event is reported by new input
> > > > > > > > > > device (instead rfkill) as they do not have
> > > > > > > > > > hw radio switch.
> > > > > > > > > > 
> > > > > > > > > > It looks like those are two different
> > > > > > > > > > functions (rfkill, input device), but Dell
> > > > > > > > > > BIOS exports them via same ACPI device and
> > > > > > > > > > uses same ACPI functions. So code is in one
> > > > > > > > > > kernel driver.
> > > > > > > > > 
> > > > > > > > > I made a patch some time ago that I've just
> > > > > > > > > adapted. It allows to prefer RBTN_SLIDER over
> > > > > > > > > RBTN_TOGGLE. The main reason why I'd like to
> > > > > > > > > have the hardware switch is that the BIOS
> > > > > > > > > doesn't alter the soft state of the devices.
> > > > > > > > > This comes in handy when the function key
> > > > > > > > > controls multiple radio devices.
> > > > > > > > 
> > > > > > > > Now I'm thinking... is't this bug in wifi kernel
> > > > > > > > driver (which exports phy rfkill)? Or problem
> > > > > > > > somewhere else (userspace or kernel)?
> > > > > > > 
> > > > > > > What is the presumed bug you are referring to? The
> > > > > > > fact that the soft state doesn't change?
> > > > > > 
> > > > > > Can you remind me whats the problem on your laptop?
> > > > > 
> > > > > CRBT returns 0 (so RBTN_TOGGLE), but by default my
> > > > > laptop acts as if it returned 2 or 3, so we have to
> > > > > call ARBT.
> > > > > 
> > > > > As said before, there's no way to know when a platform
> > > > > whose CRBT method returns 0 or 1 also has the
> > > > > hardware switch, so to be sure that all the platforms
> > > > > have working function keys, some of them (such as
> > > > > mine) have to give up on the hardware switch.
> > > > 
> > > > Ok, and what happens when you load this v2 version? What
> > > > stopped working on your laptop?
> > > > 
> > > > Alex, can you help? Code for toggle laptop version is
> > > > originally yours.
> > > 
> > > When I press the Fn key, a _Qxx EC method is executed. The
> > > code path of this method depends on a variable set by
> > > ARBT.
> > > 
> > > When you call ARBT with 1 as argument, the variable is set
> > > to 1 and the _Qxx method does nothing but sending a
> > > notification (0x80) to RBTN whenever the function key is
> > > pressed.
> > > 
> > > When you call ARBT with 0 as argument, the variable is set
> > > to 0 and the _Qxx method both sends 0x80 to RBTN _and_
> > > toggle the state of the radio devices whenever the
> > > function key is pressed.
> > > 
> > > So in the end nothing _really_ breaks.
> > 
> > So in linux kernel is missing code for toggling state of
> > radio devices? And you can do that only by ACPI when ARBT
> > is called with 0, right?
> 
> Yes.
> 
> With Alex's code the kernel sends keypresses to userspace and
> userspace takes care of toggling the state of radio devices.

Alex, can you ask Dell for documentation how to enable/disable 
radio devices? Because when ARBT is set to 1, then system must 
take care of it but, linux does not support it yet...

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Alex Hung]

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.

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.

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?



On Thu, Apr 30, 2015 at 2:59 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Wednesday 29 April 2015 20:41:38 Gabriele Mazzotta wrote:
>> On Wednesday 29 April 2015 20:16:06 Pali Rohár wrote:
>> > On Wednesday 29 April 2015 20:11:38 Gabriele Mazzotta wrote:
>> > > On Wednesday 29 April 2015 20:00:18 Pali Rohár wrote:
>> > > > On Wednesday 29 April 2015 19:54:43 Gabriele Mazzotta
>> > > > wrote:
>> > > > > On Wednesday 29 April 2015 18:28:40 Pali Rohár wrote:
>> > > > > > On Wednesday 29 April 2015 15:57:58 Gabriele Mazzotta
>> > > > > > wrote:
>> > > > > > > On Wednesday 29 April 2015 15:08:40 Pali Rohár
>> > > > > > > wrote:
>> > > > > > > > On Wednesday 29 April 2015 12:30:32 Gabriele
>> > > > > > > > Mazzotta wrote:
>> > > > > > > > > On Wednesday 29 April 2015 11:51:04 Pali Rohár
>> > > > > > > > > wrote:
>> > > > > > > > > > This is an ACPI driver for Dell laptops
>> > > > > > > > > > which receive HW switch events. It exports
>> > > > > > > > > > rfkill device dell-rbtn which provide
>> > > > > > > > > > correct hard rfkill state.
>> > > > > > > > > >
>> > > > > > > > > > Alex Hung added code for supporting Dell
>> > > > > > > > > > laptops which have toggle button instead HW
>> > > > > > > > > > slider switch. On these laptops toggle
>> > > > > > > > > > button event is reported by new input
>> > > > > > > > > > device (instead rfkill) as they do not have
>> > > > > > > > > > hw radio switch.
>> > > > > > > > > >
>> > > > > > > > > > It looks like those are two different
>> > > > > > > > > > functions (rfkill, input device), but Dell
>> > > > > > > > > > BIOS exports them via same ACPI device and
>> > > > > > > > > > uses same ACPI functions. So code is in one
>> > > > > > > > > > kernel driver.
>> > > > > > > > >
>> > > > > > > > > I made a patch some time ago that I've just
>> > > > > > > > > adapted. It allows to prefer RBTN_SLIDER over
>> > > > > > > > > RBTN_TOGGLE. The main reason why I'd like to
>> > > > > > > > > have the hardware switch is that the BIOS
>> > > > > > > > > doesn't alter the soft state of the devices.
>> > > > > > > > > This comes in handy when the function key
>> > > > > > > > > controls multiple radio devices.
>> > > > > > > >
>> > > > > > > > Now I'm thinking... is't this bug in wifi kernel
>> > > > > > > > driver (which exports phy rfkill)? Or problem
>> > > > > > > > somewhere else (userspace or kernel)?
>> > > > > > >
>> > > > > > > What is the presumed bug you are referring to? The
>> > > > > > > fact that the soft state doesn't change?
>> > > > > >
>> > > > > > Can you remind me whats the problem on your laptop?
>> > > > >
>> > > > > CRBT returns 0 (so RBTN_TOGGLE), but by default my
>> > > > > laptop acts as if it returned 2 or 3, so we have to
>> > > > > call ARBT.
>> > > > >
>> > > > > As said before, there's no way to know when a platform
>> > > > > whose CRBT method returns 0 or 1 also has the
>> > > > > hardware switch, so to be sure that all the platforms
>> > > > > have working function keys, some of them (such as
>> > > > > mine) have to give up on the hardware switch.
>> > > >
>> > > > Ok, and what happens when you load this v2 version? What
>> > > > stopped working on your laptop?
>> > > >
>> > > > Alex, can you help? Code for toggle laptop version is
>> > > > originally yours.
>> > >
>> > > When I press the Fn key, a _Qxx EC method is executed. The
>> > > code path of this method depends on a variable set by
>> > > ARBT.
>> > >
>> > > When you call ARBT with 1 as argument, the variable is set
>> > > to 1 and the _Qxx method does nothing but sending a
>> > > notification (0x80) to RBTN whenever the function key is
>> > > pressed.
>> > >
>> > > When you call ARBT with 0 as argument, the variable is set
>> > > to 0 and the _Qxx method both sends 0x80 to RBTN _and_
>> > > toggle the state of the radio devices whenever the
>> > > function key is pressed.
>> > >
>> > > So in the end nothing _really_ breaks.
>> >
>> > So in linux kernel is missing code for toggling state of
>> > radio devices? And you can do that only by ACPI when ARBT
>> > is called with 0, right?
>>
>> Yes.
>>
>> With Alex's code the kernel sends keypresses to userspace and
>> userspace takes care of toggling the state of radio devices.
>
> Alex, can you ask Dell for documentation how to enable/disable
> radio devices? Because when ARBT is set to 1, then system must
> take care of it but, linux does not support it yet...
>
> --
> Pali Rohár
> pali.rohar@gmail.com



-- 
Cheers,
Alex Hung

Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Alex Hung]

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.

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.

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?



On Thu, Apr 30, 2015 at 2:59 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Wednesday 29 April 2015 20:41:38 Gabriele Mazzotta wrote:
>> On Wednesday 29 April 2015 20:16:06 Pali Rohár wrote:
>> > On Wednesday 29 April 2015 20:11:38 Gabriele Mazzotta wrote:
>> > > On Wednesday 29 April 2015 20:00:18 Pali Rohár wrote:
>> > > > On Wednesday 29 April 2015 19:54:43 Gabriele Mazzotta
>> > > > wrote:
>> > > > > On Wednesday 29 April 2015 18:28:40 Pali Rohár wrote:
>> > > > > > On Wednesday 29 April 2015 15:57:58 Gabriele Mazzotta
>> > > > > > wrote:
>> > > > > > > On Wednesday 29 April 2015 15:08:40 Pali Rohár
>> > > > > > > wrote:
>> > > > > > > > On Wednesday 29 April 2015 12:30:32 Gabriele
>> > > > > > > > Mazzotta wrote:
>> > > > > > > > > On Wednesday 29 April 2015 11:51:04 Pali Rohár
>> > > > > > > > > wrote:
>> > > > > > > > > > This is an ACPI driver for Dell laptops
>> > > > > > > > > > which receive HW switch events. It exports
>> > > > > > > > > > rfkill device dell-rbtn which provide
>> > > > > > > > > > correct hard rfkill state.
>> > > > > > > > > >
>> > > > > > > > > > Alex Hung added code for supporting Dell
>> > > > > > > > > > laptops which have toggle button instead HW
>> > > > > > > > > > slider switch. On these laptops toggle
>> > > > > > > > > > button event is reported by new input
>> > > > > > > > > > device (instead rfkill) as they do not have
>> > > > > > > > > > hw radio switch.
>> > > > > > > > > >
>> > > > > > > > > > It looks like those are two different
>> > > > > > > > > > functions (rfkill, input device), but Dell
>> > > > > > > > > > BIOS exports them via same ACPI device and
>> > > > > > > > > > uses same ACPI functions. So code is in one
>> > > > > > > > > > kernel driver.
>> > > > > > > > >
>> > > > > > > > > I made a patch some time ago that I've just
>> > > > > > > > > adapted. It allows to prefer RBTN_SLIDER over
>> > > > > > > > > RBTN_TOGGLE. The main reason why I'd like to
>> > > > > > > > > have the hardware switch is that the BIOS
>> > > > > > > > > doesn't alter the soft state of the devices.
>> > > > > > > > > This comes in handy when the function key
>> > > > > > > > > controls multiple radio devices.
>> > > > > > > >
>> > > > > > > > Now I'm thinking... is't this bug in wifi kernel
>> > > > > > > > driver (which exports phy rfkill)? Or problem
>> > > > > > > > somewhere else (userspace or kernel)?
>> > > > > > >
>> > > > > > > What is the presumed bug you are referring to? The
>> > > > > > > fact that the soft state doesn't change?
>> > > > > >
>> > > > > > Can you remind me whats the problem on your laptop?
>> > > > >
>> > > > > CRBT returns 0 (so RBTN_TOGGLE), but by default my
>> > > > > laptop acts as if it returned 2 or 3, so we have to
>> > > > > call ARBT.
>> > > > >
>> > > > > As said before, there's no way to know when a platform
>> > > > > whose CRBT method returns 0 or 1 also has the
>> > > > > hardware switch, so to be sure that all the platforms
>> > > > > have working function keys, some of them (such as
>> > > > > mine) have to give up on the hardware switch.
>> > > >
>> > > > Ok, and what happens when you load this v2 version? What
>> > > > stopped working on your laptop?
>> > > >
>> > > > Alex, can you help? Code for toggle laptop version is
>> > > > originally yours.
>> > >
>> > > When I press the Fn key, a _Qxx EC method is executed. The
>> > > code path of this method depends on a variable set by
>> > > ARBT.
>> > >
>> > > When you call ARBT with 1 as argument, the variable is set
>> > > to 1 and the _Qxx method does nothing but sending a
>> > > notification (0x80) to RBTN whenever the function key is
>> > > pressed.
>> > >
>> > > When you call ARBT with 0 as argument, the variable is set
>> > > to 0 and the _Qxx method both sends 0x80 to RBTN _and_
>> > > toggle the state of the radio devices whenever the
>> > > function key is pressed.
>> > >
>> > > So in the end nothing _really_ breaks.
>> >
>> > So in linux kernel is missing code for toggling state of
>> > radio devices? And you can do that only by ACPI when ARBT
>> > is called with 0, right?
>>
>> Yes.
>>
>> With Alex's code the kernel sends keypresses to userspace and
>> userspace takes care of toggling the state of radio devices.
>
> Alex, can you ask Dell for documentation how to enable/disable
> radio devices? Because when ARBT is set to 1, then system must
> take care of it but, linux does not support it yet...
>
> --
> Pali Rohár
> pali.rohar@gmail.com



-- 
Cheers,
Alex Hung

Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Pali Rohár]

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?

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

Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Pali Rohár]

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?

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

Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Gabriele Mazzotta]

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.

Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Gabriele Mazzotta]

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.

Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 3604 bytes --]

On Saturday 02 May 2015 15:51:50 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)
> > 
> > > 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.

Hi, on my Latitude E6440 machine dell-laptop (with rfkill) 
working fine. There is no problem with it.

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 3604 bytes --]

On Saturday 02 May 2015 15:51:50 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)
> > 
> > > 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.

Hi, on my Latitude E6440 machine dell-laptop (with rfkill) 
working fine. There is no problem with it.

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Darren Hart]

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

Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Darren Hart]

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

Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Gabriele Mazzotta]

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.

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

I disagree. If we skip ARBT(1), userspace will get confused on laptops
like mine as it would receive two events: an rfkill event (because of
the BIOS shutting down radios) and a keypress (because of Alex's patch).
If we call ARBT(1), userspace will only receive the keypress and
userspace will correctly handle the devices.

That's why I suggested the use of a kernel parameter. It was just a way
to allow users to choose one mode over another when they know they're
both available. It's not something users are required to do.

I believe that in the end what really matters is that when function
keys are pressed something happens, be it the BIOS turning off radio
devices or the kernel telling userspace to do it, but not both.

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

Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Gabriele Mazzotta]

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.

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

I disagree. If we skip ARBT(1), userspace will get confused on laptops
like mine as it would receive two events: an rfkill event (because of
the BIOS shutting down radios) and a keypress (because of Alex's patch).
If we call ARBT(1), userspace will only receive the keypress and
userspace will correctly handle the devices.

That's why I suggested the use of a kernel parameter. It was just a way
to allow users to choose one mode over another when they know they're
both available. It's not something users are required to do.

I believe that in the end what really matters is that when function
keys are pressed something happens, be it the BIOS turning off radio
devices or the kernel telling userspace to do it, but not both.

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

Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Darren Hart]

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.

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Pali Rohár]

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@gmail.com

Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Pali Rohár]

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@gmail.com

Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver

[Alex Hung]

Since Windows 8 requirement asks  below, I see a trend that OEM is
moving wireless to HW-control to SW-control. That's also why some new
systems never trigger hard-blocks. I was also told that there may be
no "HW-GPIO" (my translation -> no hard-block) to control wireless in
some of future systems. I do not have any details but will share /
submit patches if this is going to impact Linux kernel.

============================================
System.Client.RadioManagement.HardwareButton
If a PC has a physical (hardware) button switch on a PC that turns
wireless radios on and off, it must be software controllable and
interact appropriately with the Radio Management UI
============================================

I don't see the kernel parameter as a workaround, either. I agree with
Gabriele that it is giving users an second option to choose how to use
the hardware they purchased.


On Wed, May 6, 2015 at 5:23 AM, Gabriele Mazzotta
<gabriele.mzt@gmail.com> 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.
>
>> > 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...
>
> I disagree. If we skip ARBT(1), userspace will get confused on laptops
> like mine as it would receive two events: an rfkill event (because of
> the BIOS shutting down radios) and a keypress (because of Alex's patch).
> If we call ARBT(1), userspace will only receive the keypress and
> userspace will correctly handle the devices.
>
> That's why I suggested the use of a kernel parameter. It was just a way
> to allow users to choose one mode over another when they know they're
> both available. It's not something users are required to do.
>
> I believe that in the end what really matters is that when function
> keys are pressed something happens, be it the BIOS turning off radio
> devices or the kernel telling userspace to do it, but not both.
>
>> 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?



-- 
Cheers,
Alex Hung

[PATCH v2 2/3] platform: x86: dell-rbtn: Export notifier for other kernel modules

[Pali Rohár]

This patch exports notifier functions so other modules can receive HW switch
events. By default when some module register notifier, dell-rbtn driver
automatically remove rfkill interfaces from system (it is expected that other
module will use events for other rfkill interface). This behaviour can be
changed with new module parameter "auto_remove_rfkill".

This patch is designed for dell-laptop module for receiving those events.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
---
 drivers/platform/x86/dell-rbtn.c |   90 +++++++++++++++++++++++++++++++++++++-
 drivers/platform/x86/dell-rbtn.h |   35 +++++++++++++++
 2 files changed, 123 insertions(+), 2 deletions(-)
 create mode 100644 drivers/platform/x86/dell-rbtn.h

diff --git a/drivers/platform/x86/dell-rbtn.c b/drivers/platform/x86/dell-rbtn.c
index 894cd9a..07dfd8f 100644
--- a/drivers/platform/x86/dell-rbtn.c
+++ b/drivers/platform/x86/dell-rbtn.c
@@ -232,6 +232,80 @@ static struct acpi_driver rbtn_driver = {
 
 
 /*
+ * notifier export functions
+ */
+
+static bool auto_remove_rfkill = true;
+
+static ATOMIC_NOTIFIER_HEAD(rbtn_chain_head);
+
+static int rbtn_inc_count(struct device *dev, void *data)
+{
+	struct acpi_device *device = to_acpi_device(dev);
+	struct rbtn_data *rbtn_data = device->driver_data;
+	int *count = data;
+
+	if (rbtn_data->type == RBTN_SLIDER)
+		(*count)++;
+
+	return 0;
+}
+
+static int rbtn_switch_dev(struct device *dev, void *data)
+{
+	struct acpi_device *device = to_acpi_device(dev);
+	bool enable = data;
+
+	if (enable)
+		rbtn_rfkill_init(device);
+	else
+		rbtn_rfkill_exit(device);
+
+	return 0;
+}
+
+int dell_rbtn_notifier_register(struct notifier_block *nb)
+{
+	bool first;
+	int ret;
+
+	ret = 0;
+	driver_for_each_device(&rbtn_driver.drv, NULL, &ret, rbtn_inc_count);
+	if (ret == 0)
+		return -ENODEV;
+
+	first = !rbtn_chain_head.head;
+
+	ret = atomic_notifier_chain_register(&rbtn_chain_head, nb);
+	if (ret != 0)
+		return ret;
+
+	if (auto_remove_rfkill && first)
+		driver_for_each_device(&rbtn_driver.drv, NULL, (void *)false,
+				       rbtn_switch_dev);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(dell_rbtn_notifier_register);
+
+int dell_rbtn_notifier_unregister(struct notifier_block *nb)
+{
+	int ret;
+
+	ret = atomic_notifier_chain_unregister(&rbtn_chain_head, nb);
+	if (ret != 0)
+		return ret;
+
+	if (auto_remove_rfkill && !rbtn_chain_head.head)
+		driver_for_each_device(&rbtn_driver.drv, NULL, (void *)true,
+				       rbtn_switch_dev);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(dell_rbtn_notifier_unregister);
+
+
+/*
  * acpi driver functions
  */
 
@@ -265,7 +339,10 @@ static int rbtn_add(struct acpi_device *device)
 		ret = rbtn_input_init(rbtn_data);
 		break;
 	case RBTN_SLIDER:
-		ret = rbtn_rfkill_init(device);
+		if (auto_remove_rfkill && rbtn_chain_head.head)
+			ret = 0;
+		else
+			ret = rbtn_rfkill_init(device);
 		break;
 	default:
 		ret = -EINVAL;
@@ -314,6 +391,7 @@ static void rbtn_notify(struct acpi_device *device, u32 event)
 		break;
 	case RBTN_SLIDER:
 		rbtn_rfkill_event(device);
+		atomic_notifier_call_chain(&rbtn_chain_head, event, device);
 		break;
 	default:
 		break;
@@ -327,7 +405,9 @@ static void rbtn_notify(struct acpi_device *device, u32 event)
 
 static int __init rbtn_init(void)
 {
-	return acpi_bus_register_driver(&rbtn_driver);
+	/* ignore errors so module always loads and exports needed functions */
+	acpi_bus_register_driver(&rbtn_driver);
+	return 0;
 }
 
 static void __exit rbtn_exit(void)
@@ -335,9 +415,15 @@ static void __exit rbtn_exit(void)
 	acpi_bus_unregister_driver(&rbtn_driver);
 }
 
+module_param(auto_remove_rfkill, bool, 0444);
 module_init(rbtn_init);
 module_exit(rbtn_exit);
 
+MODULE_PARM_DESC(auto_remove_rfkill, "automatically remove rfkill devices when "
+				     "other module start receiving events from "
+				     "this module and re-add them when last "
+				     "module stop receving events "
+				     "(default true)");
 MODULE_DEVICE_TABLE(acpi, rbtn_ids);
 MODULE_DESCRIPTION("Dell Airplane Mode Switch driver");
 MODULE_AUTHOR("Pali Rohár <pali.rohar@gmail.com>");
diff --git a/drivers/platform/x86/dell-rbtn.h b/drivers/platform/x86/dell-rbtn.h
new file mode 100644
index 0000000..d6b44b0
--- /dev/null
+++ b/drivers/platform/x86/dell-rbtn.h
@@ -0,0 +1,35 @@
+/*
+    Dell Airplane Mode Switch driver
+    Copyright (C) 2014-2015  Pali Rohár <pali.rohar@gmail.com>
+
+    This program is free software; you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+*/
+
+#ifndef _DELL_RBTN_H_
+#define _DELL_RBTN_H_
+
+struct notifier_block;
+
+#if defined(CONFIG_DELL_RBTN) || defined(CONFIG_DELL_RBTN_MODULE)
+int dell_rbtn_notifier_register(struct notifier_block *nb);
+int dell_rbtn_notifier_unregister(struct notifier_block *nb);
+#else
+static inline int dell_rbtn_notifier_register(struct notifier_block *nb)
+{
+	return -ENODEV;
+}
+static inline int dell_rbtn_notifier_unregister(struct notifier_block *nb)
+{
+	return -ENODEV;
+}
+#endif
+
+#endif
-- 
1.7.9.5

[PATCH v2 3/3] platform: x86: dell-laptop: Use dell-rbtn instead i8042 filter when possible

[Pali Rohár]

Until now module dell-laptop registered rfkill device which used i8042 filter
function for receiving HW switch rfkill events (handling special keycode).

But for some dell laptops there is native ACPI driver dell-rbtn which can
receive rfkill events (without i8042 hacks). On some machines it can also
control rfkill devices, but can turn on/off all radio devices.

So this patch will combine best from both sides. It will use native ACPI driver
dell-rbtn for receiving events and dell-laptop SMBIOS interface for enabling or
disabling radio devices. If ACPI driver or device will not be available fallback
to i8042 filter function will be used.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
---
 drivers/platform/x86/Kconfig       |    1 +
 drivers/platform/x86/dell-laptop.c |   67 +++++++++++++++++++++++++++++++++---
 2 files changed, 63 insertions(+), 5 deletions(-)

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 9d065c2..357e17f 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -97,6 +97,7 @@ config DELL_LAPTOP
 	depends on BACKLIGHT_CLASS_DEVICE
 	depends on RFKILL || RFKILL = n
 	depends on SERIO_I8042
+	select DELL_RBTN
 	select POWER_SUPPLY
 	select LEDS_CLASS
 	select NEW_LEDS
diff --git a/drivers/platform/x86/dell-laptop.c b/drivers/platform/x86/dell-laptop.c
index d688d80..c9ea0f8 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -32,6 +32,7 @@
 #include <linux/debugfs.h>
 #include <linux/seq_file.h>
 #include "../../firmware/dcdbas.h"
+#include "dell-rbtn.h"
 
 #define BRIGHTNESS_TOKEN 0x7d
 #define KBD_LED_OFF_TOKEN 0x01E1
@@ -642,6 +643,20 @@ static bool dell_laptop_i8042_filter(unsigned char data, unsigned char str,
 	return false;
 }
 
+static bool dell_laptop_use_rbtn;
+
+static int dell_laptop_rbtn_notifier_call(struct notifier_block *nb,
+					  unsigned long action, void *data)
+{
+	schedule_delayed_work(&dell_rfkill_work,
+			      round_jiffies_relative(HZ / 4));
+	return NOTIFY_OK;
+}
+
+static struct notifier_block dell_laptop_rbtn_notifier = {
+	.notifier_call = dell_laptop_rbtn_notifier_call,
+};
+
 static int __init dell_setup_rfkill(void)
 {
 	int status, ret, whitelisted;
@@ -718,10 +733,46 @@ static int __init dell_setup_rfkill(void)
 			goto err_wwan;
 	}
 
-	ret = i8042_install_filter(dell_laptop_i8042_filter);
-	if (ret) {
-		pr_warn("Unable to install key filter\n");
+	/*
+	 * Dell Airplane Mode Switch driver (dell-rbtn) supports ACPI devices
+	 * which can receive HW button switch events and also can control radio
+	 * devices. Somtimes ACPI device supports only reciving events (without
+	 * enable/disable software control).
+	 *
+	 * Dell SMBIOS on whitelisted models supports controlling radio devices
+	 * but does not support receiving HW button switch events. We can use
+	 * i8042 filter hook function to receive keyboard data and handle
+	 * keycode for HW button.
+	 *
+	 * Dell Airplane Mode Switch driver supports only one rfkill switch
+	 * which enable/disable all radio devices. But Dell SMBIOS supports more
+	 * granularity and can enable/disable also one type of radio device
+	 * (e.g disable only bluetooth device without touching wifi device).
+	 *
+	 * So if it is possible we will use Dell Airplane Mode Switch ACPI
+	 * driver for receiving HW events and Dell SMBIOS for setting rfkill
+	 * states. If ACPI driver or device is not available we will fallback to
+	 * i8042 filter hook function.
+	 *
+	 * To prevent duplicate rfkill devices which control and do same thing,
+	 * dell-rbtn driver will automatically remove its own rfkill devices
+	 * once function dell_rbtn_notifier_register() is called.
+	 */
+
+	ret = dell_rbtn_notifier_register(&dell_laptop_rbtn_notifier);
+	if (ret == 0) {
+		pr_info("Using dell-rbtn acpi driver for receiving events\n");
+		dell_laptop_use_rbtn = true;
+	} else if (ret != -ENODEV) {
+		pr_warn("Unable to register dell rbtn notifier\n");
 		goto err_filter;
+	} else {
+		ret = i8042_install_filter(dell_laptop_i8042_filter);
+		if (ret) {
+			pr_warn("Unable to install key filter\n");
+			goto err_filter;
+		}
+		pr_info("Using i8042 filter function for receiving events\n");
 	}
 
 	return 0;
@@ -1961,7 +2012,10 @@ static int __init dell_init(void)
 	return 0;
 
 fail_backlight:
-	i8042_remove_filter(dell_laptop_i8042_filter);
+	if (dell_laptop_use_rbtn)
+		dell_rbtn_notifier_unregister(&dell_laptop_rbtn_notifier);
+	else
+		i8042_remove_filter(dell_laptop_i8042_filter);
 	cancel_delayed_work_sync(&dell_rfkill_work);
 	dell_cleanup_rfkill();
 fail_rfkill:
@@ -1983,7 +2037,10 @@ static void __exit dell_exit(void)
 	if (quirks && quirks->touchpad_led)
 		touchpad_led_exit();
 	kbd_led_exit();
-	i8042_remove_filter(dell_laptop_i8042_filter);
+	if (dell_laptop_use_rbtn)
+		dell_rbtn_notifier_unregister(&dell_laptop_rbtn_notifier);
+	else
+		i8042_remove_filter(dell_laptop_i8042_filter);
 	cancel_delayed_work_sync(&dell_rfkill_work);
 	backlight_device_unregister(dell_backlight_device);
 	dell_cleanup_rfkill();
-- 
1.7.9.5

Re: [PATCH v2 0/3] Dell Airplane Mode Switch driver

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 1995 bytes --]

On Wednesday 29 April 2015 11:51:03 Pali Rohár wrote:
> This patch series add new acpi Dell Airplane Mode Switch
> driver (DELLABCE and DELRBTN acpi devices). It provides radio
> HW switch events (together with current state of radio
> devices) and export them via rfkill interface. These events
> are also used in dell-laptop driver instead i8042 filter hook
> function (when acpi device is available).
> 
> In v2 was added support for laptops which have toggle button
> instead HW slider switch. For that I reused code done by Alex
> Hung.
> 
> Pali Rohár (3):
>   platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
>   platform: x86: dell-rbtn: Export notifier for other kernel
> modules platform: x86: dell-laptop: Use dell-rbtn instead
> i8042 filter when possible
> 
>  drivers/platform/x86/Kconfig       |   14 ++
>  drivers/platform/x86/Makefile      |    1 +
>  drivers/platform/x86/dell-laptop.c |   67 +++++-
>  drivers/platform/x86/dell-rbtn.c   |  430
> ++++++++++++++++++++++++++++++++++++
> drivers/platform/x86/dell-rbtn.h   |   35 +++
>  5 files changed, 542 insertions(+), 5 deletions(-)
>  create mode 100644 drivers/platform/x86/dell-rbtn.c
>  create mode 100644 drivers/platform/x86/dell-rbtn.h

Alex, can you rested this patch series on all your machines like 
you did previous in this sheet?

https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSGh3UmG__UAO2qfZ829CkJLPo06aI/edit?usp=sharing

Ideally do more tests:
1) only with first patch 1/3
2) with full patch series 1/3, 2/3, 3/3 *with* loaded dell-laptop
3) same as 2) but without loaded dell-laptop

If everything pass then this patch series is OK from my side.

Looks like Gabriele's problem is irrelevant to this patch series, 
but we probably hit some rfkill bug in dell-laptop.ko :-(

Matthew or Darren, can you review code in this patch series? So 
if everything will be fine, dell-rbtn could be ready for 4.2.

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH v2 0/3] Dell Airplane Mode Switch driver

[Darren Hart]

On Sun, May 03, 2015 at 12:38:14PM +0200, Pali Rohár wrote:
> On Wednesday 29 April 2015 11:51:03 Pali Rohár wrote:
> > This patch series add new acpi Dell Airplane Mode Switch
> > driver (DELLABCE and DELRBTN acpi devices). It provides radio
> > HW switch events (together with current state of radio
> > devices) and export them via rfkill interface. These events
> > are also used in dell-laptop driver instead i8042 filter hook
> > function (when acpi device is available).
> > 
> > In v2 was added support for laptops which have toggle button
> > instead HW slider switch. For that I reused code done by Alex
> > Hung.
> > 
> > Pali Rohár (3):
> >   platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
> >   platform: x86: dell-rbtn: Export notifier for other kernel
> > modules platform: x86: dell-laptop: Use dell-rbtn instead
> > i8042 filter when possible
> > 
> >  drivers/platform/x86/Kconfig       |   14 ++
> >  drivers/platform/x86/Makefile      |    1 +
> >  drivers/platform/x86/dell-laptop.c |   67 +++++-
> >  drivers/platform/x86/dell-rbtn.c   |  430
> > ++++++++++++++++++++++++++++++++++++
> > drivers/platform/x86/dell-rbtn.h   |   35 +++
> >  5 files changed, 542 insertions(+), 5 deletions(-)
> >  create mode 100644 drivers/platform/x86/dell-rbtn.c
> >  create mode 100644 drivers/platform/x86/dell-rbtn.h
> 
> Alex, can you rested this patch series on all your machines like 
> you did previous in this sheet?
> 
> https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSGh3UmG__UAO2qfZ829CkJLPo06aI/edit?usp=sharing
> 
> Ideally do more tests:
> 1) only with first patch 1/3
> 2) with full patch series 1/3, 2/3, 3/3 *with* loaded dell-laptop
> 3) same as 2) but without loaded dell-laptop
> 
> If everything pass then this patch series is OK from my side.
> 
> Looks like Gabriele's problem is irrelevant to this patch series, 
> but we probably hit some rfkill bug in dell-laptop.ko :-(
> 
> Matthew or Darren, can you review code in this patch series? So 
> if everything will be fine, dell-rbtn could be ready for 4.2.

Yes - but I need some additional context.

There wasn't a "Since v1..." changelog below the --- line in the patches. It's
always good practice to include it - but especially after this much time has
passed - it really helps page back in all the relevant issues.

After the discussion on this list, I'm not sure where we are with how this patch
series impacts the machines that Alex and Garbiele are working on.

What I would like is this: amongst yourselves, please agree on a solution and
provide a patch series with a Signed-off-by from the author(s) and at least a
Tested-by from the others.

If this is it, each of you please reply here stating as much.

Thanks,

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH v2 0/3] Dell Airplane Mode Switch driver

[Gabriele Mazzotta]

On Tuesday 05 May 2015 13:37:10 Darren Hart wrote:
> On Sun, May 03, 2015 at 12:38:14PM +0200, Pali Rohár wrote:
> > On Wednesday 29 April 2015 11:51:03 Pali Rohár wrote:
> > > This patch series add new acpi Dell Airplane Mode Switch
> > > driver (DELLABCE and DELRBTN acpi devices). It provides radio
> > > HW switch events (together with current state of radio
> > > devices) and export them via rfkill interface. These events
> > > are also used in dell-laptop driver instead i8042 filter hook
> > > function (when acpi device is available).
> > > 
> > > In v2 was added support for laptops which have toggle button
> > > instead HW slider switch. For that I reused code done by Alex
> > > Hung.
> > > 
> > > Pali Rohár (3):
> > >   platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
> > >   platform: x86: dell-rbtn: Export notifier for other kernel
> > > modules platform: x86: dell-laptop: Use dell-rbtn instead
> > > i8042 filter when possible
> > > 
> > >  drivers/platform/x86/Kconfig       |   14 ++
> > >  drivers/platform/x86/Makefile      |    1 +
> > >  drivers/platform/x86/dell-laptop.c |   67 +++++-
> > >  drivers/platform/x86/dell-rbtn.c   |  430
> > > ++++++++++++++++++++++++++++++++++++
> > > drivers/platform/x86/dell-rbtn.h   |   35 +++
> > >  5 files changed, 542 insertions(+), 5 deletions(-)
> > >  create mode 100644 drivers/platform/x86/dell-rbtn.c
> > >  create mode 100644 drivers/platform/x86/dell-rbtn.h
> > 
> > Alex, can you rested this patch series on all your machines like 
> > you did previous in this sheet?
> > 
> > https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSGh3UmG__UAO2qfZ829CkJLPo06aI/edit?usp=sharing
> > 
> > Ideally do more tests:
> > 1) only with first patch 1/3
> > 2) with full patch series 1/3, 2/3, 3/3 *with* loaded dell-laptop
> > 3) same as 2) but without loaded dell-laptop
> > 
> > If everything pass then this patch series is OK from my side.
> > 
> > Looks like Gabriele's problem is irrelevant to this patch series, 
> > but we probably hit some rfkill bug in dell-laptop.ko :-(
> > 
> > Matthew or Darren, can you review code in this patch series? So 
> > if everything will be fine, dell-rbtn could be ready for 4.2.
> 
> Yes - but I need some additional context.
> 
> There wasn't a "Since v1..." changelog below the --- line in the patches. It's
> always good practice to include it - but especially after this much time has
> passed - it really helps page back in all the relevant issues.
> 
> After the discussion on this list, I'm not sure where we are with how this patch
> series impacts the machines that Alex and Garbiele are working on.
> 
> What I would like is this: amongst yourselves, please agree on a solution and
> provide a patch series with a Signed-off-by from the author(s) and at least a
> Tested-by from the others.
> 
> If this is it, each of you please reply here stating as much.

Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>

There's room for improvement, but I think the proposed patches are
good as they are.

Re: [PATCH v2 0/3] Dell Airplane Mode Switch driver

[Pali Rohár]

On Tuesday 05 May 2015 13:37:10 Darren Hart wrote:
> On Sun, May 03, 2015 at 12:38:14PM +0200, Pali Rohár wrote:
> > On Wednesday 29 April 2015 11:51:03 Pali Rohár wrote:
> > > This patch series add new acpi Dell Airplane Mode Switch
> > > driver (DELLABCE and DELRBTN acpi devices). It provides radio
> > > HW switch events (together with current state of radio
> > > devices) and export them via rfkill interface. These events
> > > are also used in dell-laptop driver instead i8042 filter hook
> > > function (when acpi device is available).
> > > 
> > > In v2 was added support for laptops which have toggle button
> > > instead HW slider switch. For that I reused code done by Alex
> > > Hung.
> > > 
> > > Pali Rohár (3):
> > >   platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
> > >   platform: x86: dell-rbtn: Export notifier for other kernel
> > > modules platform: x86: dell-laptop: Use dell-rbtn instead
> > > i8042 filter when possible
> > > 
> > >  drivers/platform/x86/Kconfig       |   14 ++
> > >  drivers/platform/x86/Makefile      |    1 +
> > >  drivers/platform/x86/dell-laptop.c |   67 +++++-
> > >  drivers/platform/x86/dell-rbtn.c   |  430
> > > ++++++++++++++++++++++++++++++++++++
> > > drivers/platform/x86/dell-rbtn.h   |   35 +++
> > >  5 files changed, 542 insertions(+), 5 deletions(-)
> > >  create mode 100644 drivers/platform/x86/dell-rbtn.c
> > >  create mode 100644 drivers/platform/x86/dell-rbtn.h
> > 
> > Alex, can you rested this patch series on all your machines like 
> > you did previous in this sheet?
> > 
> > https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSGh3UmG__UAO2qfZ829CkJLPo06aI/edit?usp=sharing
> > 
> > Ideally do more tests:
> > 1) only with first patch 1/3
> > 2) with full patch series 1/3, 2/3, 3/3 *with* loaded dell-laptop
> > 3) same as 2) but without loaded dell-laptop
> > 
> > If everything pass then this patch series is OK from my side.
> > 
> > Looks like Gabriele's problem is irrelevant to this patch series, 
> > but we probably hit some rfkill bug in dell-laptop.ko :-(
> > 
> > Matthew or Darren, can you review code in this patch series? So 
> > if everything will be fine, dell-rbtn could be ready for 4.2.
> 
> Yes - but I need some additional context.
> 
> There wasn't a "Since v1..." changelog below the --- line in the patches. It's
> always good practice to include it - but especially after this much time has
> passed - it really helps page back in all the relevant issues.
> 

2/3 and 3/3 patches were not changed (just rebased). And to patch 1/3
was added input device for reporting wireless toggle button (for laptops
which have toggle button instead hw slider switch). Plus patch contains
some code cleanup.

> After the discussion on this list, I'm not sure where we are with how this patch
> series impacts the machines that Alex and Garbiele are working on.
> 

As wrote in previous email, now we are waiting for Alex's tests to make
sure that everything is working fine as expected.

> What I would like is this: amongst yourselves, please agree on a solution and
> provide a patch series with a Signed-off-by from the author(s) and at least a
> Tested-by from the others.
> 
> If this is it, each of you please reply here stating as much.
> 
> Thanks,
> 

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

Re: [PATCH v2 0/3] Dell Airplane Mode Switch driver

[Alex Hung]

The test was updated @
https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSGh3UmG__UAO2qfZ829CkJLPo06aI/edit?usp=sharing.
Please check the tab "Dell-rbtnv2"

Notes:
1. The systems come and go and I can find some of original ones but I
tests some others
2. Test 3 was done by Test 2 + "rmmod dell-laptop". All were run with
all wireless devices are ON

Summary:
>From external behaves such as Desktop's viewpoint (Unity was used and
hope that's not surprising), the wireless devices are ON/OFF
correctly. Other details are listed in the report.

On Sun, May 3, 2015 at 6:38 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Wednesday 29 April 2015 11:51:03 Pali Rohár wrote:
>> This patch series add new acpi Dell Airplane Mode Switch
>> driver (DELLABCE and DELRBTN acpi devices). It provides radio
>> HW switch events (together with current state of radio
>> devices) and export them via rfkill interface. These events
>> are also used in dell-laptop driver instead i8042 filter hook
>> function (when acpi device is available).
>>
>> In v2 was added support for laptops which have toggle button
>> instead HW slider switch. For that I reused code done by Alex
>> Hung.
>>
>> Pali Rohár (3):
>>   platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
>>   platform: x86: dell-rbtn: Export notifier for other kernel
>> modules platform: x86: dell-laptop: Use dell-rbtn instead
>> i8042 filter when possible
>>
>>  drivers/platform/x86/Kconfig       |   14 ++
>>  drivers/platform/x86/Makefile      |    1 +
>>  drivers/platform/x86/dell-laptop.c |   67 +++++-
>>  drivers/platform/x86/dell-rbtn.c   |  430
>> ++++++++++++++++++++++++++++++++++++
>> drivers/platform/x86/dell-rbtn.h   |   35 +++
>>  5 files changed, 542 insertions(+), 5 deletions(-)
>>  create mode 100644 drivers/platform/x86/dell-rbtn.c
>>  create mode 100644 drivers/platform/x86/dell-rbtn.h
>
> Alex, can you rested this patch series on all your machines like
> you did previous in this sheet?
>
> https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSGh3UmG__UAO2qfZ829CkJLPo06aI/edit?usp=sharing
>
> Ideally do more tests:
> 1) only with first patch 1/3
> 2) with full patch series 1/3, 2/3, 3/3 *with* loaded dell-laptop
> 3) same as 2) but without loaded dell-laptop
>
> If everything pass then this patch series is OK from my side.
>
> Looks like Gabriele's problem is irrelevant to this patch series,
> but we probably hit some rfkill bug in dell-laptop.ko :-(
>
> Matthew or Darren, can you review code in this patch series? So
> if everything will be fine, dell-rbtn could be ready for 4.2.
>
> --
> Pali Rohár
> pali.rohar@gmail.com



-- 
Cheers,
Alex Hung

Re: [PATCH v2 0/3] Dell Airplane Mode Switch driver

[Alex Hung]

The test was updated @
https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSGh3UmG__UAO2qfZ829CkJLPo06aI/edit?usp=sharing.
Please check the tab "Dell-rbtnv2"

Notes:
1. The systems come and go and I can find some of original ones but I
tests some others
2. Test 3 was done by Test 2 + "rmmod dell-laptop". All were run with
all wireless devices are ON

Summary:
From external behaves such as Desktop's viewpoint (Unity was used and
hope that's not surprising), the wireless devices are ON/OFF
correctly. Other details are listed in the report.

On Sun, May 3, 2015 at 6:38 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Wednesday 29 April 2015 11:51:03 Pali Rohár wrote:
>> This patch series add new acpi Dell Airplane Mode Switch
>> driver (DELLABCE and DELRBTN acpi devices). It provides radio
>> HW switch events (together with current state of radio
>> devices) and export them via rfkill interface. These events
>> are also used in dell-laptop driver instead i8042 filter hook
>> function (when acpi device is available).
>>
>> In v2 was added support for laptops which have toggle button
>> instead HW slider switch. For that I reused code done by Alex
>> Hung.
>>
>> Pali Rohár (3):
>>   platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
>>   platform: x86: dell-rbtn: Export notifier for other kernel
>> modules platform: x86: dell-laptop: Use dell-rbtn instead
>> i8042 filter when possible
>>
>>  drivers/platform/x86/Kconfig       |   14 ++
>>  drivers/platform/x86/Makefile      |    1 +
>>  drivers/platform/x86/dell-laptop.c |   67 +++++-
>>  drivers/platform/x86/dell-rbtn.c   |  430
>> ++++++++++++++++++++++++++++++++++++
>> drivers/platform/x86/dell-rbtn.h   |   35 +++
>>  5 files changed, 542 insertions(+), 5 deletions(-)
>>  create mode 100644 drivers/platform/x86/dell-rbtn.c
>>  create mode 100644 drivers/platform/x86/dell-rbtn.h
>
> Alex, can you rested this patch series on all your machines like
> you did previous in this sheet?
>
> https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSGh3UmG__UAO2qfZ829CkJLPo06aI/edit?usp=sharing
>
> Ideally do more tests:
> 1) only with first patch 1/3
> 2) with full patch series 1/3, 2/3, 3/3 *with* loaded dell-laptop
> 3) same as 2) but without loaded dell-laptop
>
> If everything pass then this patch series is OK from my side.
>
> Looks like Gabriele's problem is irrelevant to this patch series,
> but we probably hit some rfkill bug in dell-laptop.ko :-(
>
> Matthew or Darren, can you review code in this patch series? So
> if everything will be fine, dell-rbtn could be ready for 4.2.
>
> --
> Pali Rohár
> pali.rohar@gmail.com



-- 
Cheers,
Alex Hung

Re: [PATCH v2 0/3] Dell Airplane Mode Switch driver

[Pali Rohár]

Looks like everything is OK. Test3 is expected to not work correctly as
driver is not loaded...

On Wednesday 06 May 2015 17:11:08 Alex Hung wrote:
> The test was updated @
> https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSGh3UmG__UAO2qfZ829CkJLPo06aI/edit?usp=sharing.
> Please check the tab "Dell-rbtnv2"
> 
> Notes:
> 1. The systems come and go and I can find some of original ones but I
> tests some others
> 2. Test 3 was done by Test 2 + "rmmod dell-laptop". All were run with
> all wireless devices are ON
> 
> Summary:
> From external behaves such as Desktop's viewpoint (Unity was used and
> hope that's not surprising), the wireless devices are ON/OFF
> correctly. Other details are listed in the report.
> 
> On Sun, May 3, 2015 at 6:38 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > On Wednesday 29 April 2015 11:51:03 Pali Rohár wrote:
> >> This patch series add new acpi Dell Airplane Mode Switch
> >> driver (DELLABCE and DELRBTN acpi devices). It provides radio
> >> HW switch events (together with current state of radio
> >> devices) and export them via rfkill interface. These events
> >> are also used in dell-laptop driver instead i8042 filter hook
> >> function (when acpi device is available).
> >>
> >> In v2 was added support for laptops which have toggle button
> >> instead HW slider switch. For that I reused code done by Alex
> >> Hung.
> >>
> >> Pali Rohár (3):
> >>   platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
> >>   platform: x86: dell-rbtn: Export notifier for other kernel
> >> modules platform: x86: dell-laptop: Use dell-rbtn instead
> >> i8042 filter when possible
> >>
> >>  drivers/platform/x86/Kconfig       |   14 ++
> >>  drivers/platform/x86/Makefile      |    1 +
> >>  drivers/platform/x86/dell-laptop.c |   67 +++++-
> >>  drivers/platform/x86/dell-rbtn.c   |  430
> >> ++++++++++++++++++++++++++++++++++++
> >> drivers/platform/x86/dell-rbtn.h   |   35 +++
> >>  5 files changed, 542 insertions(+), 5 deletions(-)
> >>  create mode 100644 drivers/platform/x86/dell-rbtn.c
> >>  create mode 100644 drivers/platform/x86/dell-rbtn.h
> >
> > Alex, can you rested this patch series on all your machines like
> > you did previous in this sheet?
> >
> > https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSGh3UmG__UAO2qfZ829CkJLPo06aI/edit?usp=sharing
> >
> > Ideally do more tests:
> > 1) only with first patch 1/3
> > 2) with full patch series 1/3, 2/3, 3/3 *with* loaded dell-laptop
> > 3) same as 2) but without loaded dell-laptop
> >
> > If everything pass then this patch series is OK from my side.
> >
> > Looks like Gabriele's problem is irrelevant to this patch series,
> > but we probably hit some rfkill bug in dell-laptop.ko :-(
> >
> > Matthew or Darren, can you review code in this patch series? So
> > if everything will be fine, dell-rbtn could be ready for 4.2.
> >
> > --
> > Pali Rohár
> > pali.rohar@gmail.com
> 
> 
> 

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

Re: [PATCH v2 0/3] Dell Airplane Mode Switch driver

[Pali Rohár]

Looks like everything is OK. Test3 is expected to not work correctly as
driver is not loaded...

On Wednesday 06 May 2015 17:11:08 Alex Hung wrote:
> The test was updated @
> https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSGh3UmG__UAO2qfZ829CkJLPo06aI/edit?usp=sharing.
> Please check the tab "Dell-rbtnv2"
> 
> Notes:
> 1. The systems come and go and I can find some of original ones but I
> tests some others
> 2. Test 3 was done by Test 2 + "rmmod dell-laptop". All were run with
> all wireless devices are ON
> 
> Summary:
> From external behaves such as Desktop's viewpoint (Unity was used and
> hope that's not surprising), the wireless devices are ON/OFF
> correctly. Other details are listed in the report.
> 
> On Sun, May 3, 2015 at 6:38 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > On Wednesday 29 April 2015 11:51:03 Pali Rohár wrote:
> >> This patch series add new acpi Dell Airplane Mode Switch
> >> driver (DELLABCE and DELRBTN acpi devices). It provides radio
> >> HW switch events (together with current state of radio
> >> devices) and export them via rfkill interface. These events
> >> are also used in dell-laptop driver instead i8042 filter hook
> >> function (when acpi device is available).
> >>
> >> In v2 was added support for laptops which have toggle button
> >> instead HW slider switch. For that I reused code done by Alex
> >> Hung.
> >>
> >> Pali Rohár (3):
> >>   platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
> >>   platform: x86: dell-rbtn: Export notifier for other kernel
> >> modules platform: x86: dell-laptop: Use dell-rbtn instead
> >> i8042 filter when possible
> >>
> >>  drivers/platform/x86/Kconfig       |   14 ++
> >>  drivers/platform/x86/Makefile      |    1 +
> >>  drivers/platform/x86/dell-laptop.c |   67 +++++-
> >>  drivers/platform/x86/dell-rbtn.c   |  430
> >> ++++++++++++++++++++++++++++++++++++
> >> drivers/platform/x86/dell-rbtn.h   |   35 +++
> >>  5 files changed, 542 insertions(+), 5 deletions(-)
> >>  create mode 100644 drivers/platform/x86/dell-rbtn.c
> >>  create mode 100644 drivers/platform/x86/dell-rbtn.h
> >
> > Alex, can you rested this patch series on all your machines like
> > you did previous in this sheet?
> >
> > https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSGh3UmG__UAO2qfZ829CkJLPo06aI/edit?usp=sharing
> >
> > Ideally do more tests:
> > 1) only with first patch 1/3
> > 2) with full patch series 1/3, 2/3, 3/3 *with* loaded dell-laptop
> > 3) same as 2) but without loaded dell-laptop
> >
> > If everything pass then this patch series is OK from my side.
> >
> > Looks like Gabriele's problem is irrelevant to this patch series,
> > but we probably hit some rfkill bug in dell-laptop.ko :-(
> >
> > Matthew or Darren, can you review code in this patch series? So
> > if everything will be fine, dell-rbtn could be ready for 4.2.
> >
> > --
> > Pali Rohár
> > pali.rohar@gmail.com
> 
> 
> 

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

Re: [PATCH v2 0/3] Dell Airplane Mode Switch driver

[Darren Hart]

On Wed, May 06, 2015 at 01:31:19PM +0200, Pali Rohár wrote:
> Looks like everything is OK. Test3 is expected to not work correctly as
> driver is not loaded...
> 
> On Wednesday 06 May 2015 17:11:08 Alex Hung wrote:
> > The test was updated @
> > https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSGh3UmG__UAO2qfZ829CkJLPo06aI/edit?usp=sharing.
> > Please check the tab "Dell-rbtnv2"
> > 
> > Notes:
> > 1. The systems come and go and I can find some of original ones but I
> > tests some others
> > 2. Test 3 was done by Test 2 + "rmmod dell-laptop". All were run with
> > all wireless devices are ON
> > 
> > Summary:
> > From external behaves such as Desktop's viewpoint (Unity was used and
> > hope that's not surprising), the wireless devices are ON/OFF
> > correctly. Other details are listed in the report.

What am I to make of Sheet1:Row25 vs. Row27?
This appears to me that for the Inspiron 3542, Dell Wireless for 3.16 has a
functional soft block, while there is no change for Dell RBNT.

Rows36 and 37... these are tellin gme that the ARBT method is broken on this
machine?

> -- 
> Pali Rohár
> pali.rohar@gmail.com
> 

Re: [PATCH v2 0/3] Dell Airplane Mode Switch driver

[Darren Hart]

On Wed, May 06, 2015 at 01:31:19PM +0200, Pali Rohár wrote:
> Looks like everything is OK. Test3 is expected to not work correctly as
> driver is not loaded...
> 
> On Wednesday 06 May 2015 17:11:08 Alex Hung wrote:
> > The test was updated @
> > https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSGh3UmG__UAO2qfZ829CkJLPo06aI/edit?usp=sharing.
> > Please check the tab "Dell-rbtnv2"
> > 
> > Notes:
> > 1. The systems come and go and I can find some of original ones but I
> > tests some others
> > 2. Test 3 was done by Test 2 + "rmmod dell-laptop". All were run with
> > all wireless devices are ON
> > 
> > Summary:
> > From external behaves such as Desktop's viewpoint (Unity was used and
> > hope that's not surprising), the wireless devices are ON/OFF
> > correctly. Other details are listed in the report.

What am I to make of Sheet1:Row25 vs. Row27?
This appears to me that for the Inspiron 3542, Dell Wireless for 3.16 has a
functional soft block, while there is no change for Dell RBNT.

Rows36 and 37... these are tellin gme that the ARBT method is broken on this
machine?

> -- 
> Pali Rohár
> pali.rohar@gmail.com
> 

Re: [PATCH v2 0/3] Dell Airplane Mode Switch driver

[Alex Hung]

Darren,

I guess you were looking at "Sheet1" that was comparison between
dell-rbtn and dell-wireless quite a while ago. The updated results for
dell-rbtn v2 are in the tab of "Dell-rbtnv2"

On Thu, May 7, 2015 at 5:57 AM, Darren Hart <dvhart@infradead.org> wrote:
> On Wed, May 06, 2015 at 01:31:19PM +0200, Pali Rohár wrote:
>> Looks like everything is OK. Test3 is expected to not work correctly as
>> driver is not loaded...
>>
>> On Wednesday 06 May 2015 17:11:08 Alex Hung wrote:
>> > The test was updated @
>> > https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSGh3UmG__UAO2qfZ829CkJLPo06aI/edit?usp=sharing.
>> > Please check the tab "Dell-rbtnv2"
>> >
>> > Notes:
>> > 1. The systems come and go and I can find some of original ones but I
>> > tests some others
>> > 2. Test 3 was done by Test 2 + "rmmod dell-laptop". All were run with
>> > all wireless devices are ON
>> >
>> > Summary:
>> > From external behaves such as Desktop's viewpoint (Unity was used and
>> > hope that's not surprising), the wireless devices are ON/OFF
>> > correctly. Other details are listed in the report.
>
> What am I to make of Sheet1:Row25 vs. Row27?
> This appears to me that for the Inspiron 3542, Dell Wireless for 3.16 has a
> functional soft block, while there is no change for Dell RBNT.
>
> Rows36 and 37... these are tellin gme that the ARBT method is broken on this
> machine?
>
>> --
>> Pali Rohár
>> pali.rohar@gmail.com
>>



-- 
Cheers,
Alex Hung

Re: [PATCH v2 0/3] Dell Airplane Mode Switch driver

[Pali Rohár]

Darren, can you review/comment this v2 series? It is OK for 4.2 now?

On Thursday 07 May 2015 10:24:37 Alex Hung wrote:
> Darren,
> 
> I guess you were looking at "Sheet1" that was comparison between
> dell-rbtn and dell-wireless quite a while ago. The updated results for
> dell-rbtn v2 are in the tab of "Dell-rbtnv2"
> 
> On Thu, May 7, 2015 at 5:57 AM, Darren Hart <dvhart@infradead.org> wrote:
> > On Wed, May 06, 2015 at 01:31:19PM +0200, Pali Rohár wrote:
> >> Looks like everything is OK. Test3 is expected to not work correctly as
> >> driver is not loaded...
> >>
> >> On Wednesday 06 May 2015 17:11:08 Alex Hung wrote:
> >> > The test was updated @
> >> > https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSGh3UmG__UAO2qfZ829CkJLPo06aI/edit?usp=sharing.
> >> > Please check the tab "Dell-rbtnv2"
> >> >
> >> > Notes:
> >> > 1. The systems come and go and I can find some of original ones but I
> >> > tests some others
> >> > 2. Test 3 was done by Test 2 + "rmmod dell-laptop". All were run with
> >> > all wireless devices are ON
> >> >
> >> > Summary:
> >> > From external behaves such as Desktop's viewpoint (Unity was used and
> >> > hope that's not surprising), the wireless devices are ON/OFF
> >> > correctly. Other details are listed in the report.
> >
> > What am I to make of Sheet1:Row25 vs. Row27?
> > This appears to me that for the Inspiron 3542, Dell Wireless for 3.16 has a
> > functional soft block, while there is no change for Dell RBNT.
> >
> > Rows36 and 37... these are tellin gme that the ARBT method is broken on this
> > machine?
> >
> >> --
> >> Pali Rohár
> >> pali.rohar@gmail.com
> >>
> 
> 
> 

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

Re: [PATCH v2 0/3] Dell Airplane Mode Switch driver

[Pali Rohár]

Darren, can you review/comment this v2 series? It is OK for 4.2 now?

On Thursday 07 May 2015 10:24:37 Alex Hung wrote:
> Darren,
> 
> I guess you were looking at "Sheet1" that was comparison between
> dell-rbtn and dell-wireless quite a while ago. The updated results for
> dell-rbtn v2 are in the tab of "Dell-rbtnv2"
> 
> On Thu, May 7, 2015 at 5:57 AM, Darren Hart <dvhart@infradead.org> wrote:
> > On Wed, May 06, 2015 at 01:31:19PM +0200, Pali Rohár wrote:
> >> Looks like everything is OK. Test3 is expected to not work correctly as
> >> driver is not loaded...
> >>
> >> On Wednesday 06 May 2015 17:11:08 Alex Hung wrote:
> >> > The test was updated @
> >> > https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSGh3UmG__UAO2qfZ829CkJLPo06aI/edit?usp=sharing.
> >> > Please check the tab "Dell-rbtnv2"
> >> >
> >> > Notes:
> >> > 1. The systems come and go and I can find some of original ones but I
> >> > tests some others
> >> > 2. Test 3 was done by Test 2 + "rmmod dell-laptop". All were run with
> >> > all wireless devices are ON
> >> >
> >> > Summary:
> >> > From external behaves such as Desktop's viewpoint (Unity was used and
> >> > hope that's not surprising), the wireless devices are ON/OFF
> >> > correctly. Other details are listed in the report.
> >
> > What am I to make of Sheet1:Row25 vs. Row27?
> > This appears to me that for the Inspiron 3542, Dell Wireless for 3.16 has a
> > functional soft block, while there is no change for Dell RBNT.
> >
> > Rows36 and 37... these are tellin gme that the ARBT method is broken on this
> > machine?
> >
> >> --
> >> Pali Rohár
> >> pali.rohar@gmail.com
> >>
> 
> 
> 

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

Re: [PATCH v2 0/3] Dell Airplane Mode Switch driver

[Darren Hart]

On Wed, May 13, 2015 at 01:48:41PM +0200, Pali Rohár wrote:
> Darren, can you review/comment this v2 series? It is OK for 4.2 now?
> 

I thought I was waiting on an Ack from Alex but reviewing the various threads I
think he's OK with this.

Running the patches through checkpatch reports various issues about tabs
(resolved by using proper multi-line comment formatting), line length, and not
wrapping strings. I corrected these locally to move things along, but when
building:

  CC [M]  drivers/platform/x86/dell-rbtn.o
drivers/platform/x86/dell-rbtn.c: In function ‘dell_rbtn_notifier_register’:
drivers/platform/x86/dell-rbtn.c:273:2: warning: ignoring return value of ‘driver_for_each_device’, declared with attribute warn_unused_result [-Wunused-result]
  driver_for_each_device(&rbtn_driver.drv, NULL, &ret, rbtn_inc_count);
  ^
drivers/platform/x86/dell-rbtn.c:284:3: warning: ignoring return value of ‘driver_for_each_device’, declared with attribute warn_unused_result [-Wunused-result]
   driver_for_each_device(&rbtn_driver.drv, NULL, (void *)false,
   ^
drivers/platform/x86/dell-rbtn.c: In function ‘dell_rbtn_notifier_unregister’:
drivers/platform/x86/dell-rbtn.c:300:3: warning: ignoring return value of ‘driver_for_each_device’, declared with attribute warn_unused_result [-Wunused-result]
   driver_for_each_device(&rbtn_driver.drv, NULL, (void *)true,

We can't introduce new warnings to the build.

I've pushed my fixes to the series to my dell-rbtn branch, please start from
there and resolve the above, and resubmit. We can still make 4.2. But please
make use of checkpatch and watch for warnings like the above in your builds
tests so we can avoid unecessary churn.

Thanks,

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH v2 0/3] Dell Airplane Mode Switch driver

[Darren Hart]

On Wed, May 13, 2015 at 01:48:41PM +0200, Pali Rohár wrote:
> Darren, can you review/comment this v2 series? It is OK for 4.2 now?
> 

I thought I was waiting on an Ack from Alex but reviewing the various threads I
think he's OK with this.

Running the patches through checkpatch reports various issues about tabs
(resolved by using proper multi-line comment formatting), line length, and not
wrapping strings. I corrected these locally to move things along, but when
building:

  CC [M]  drivers/platform/x86/dell-rbtn.o
drivers/platform/x86/dell-rbtn.c: In function ‘dell_rbtn_notifier_register’:
drivers/platform/x86/dell-rbtn.c:273:2: warning: ignoring return value of ‘driver_for_each_device’, declared with attribute warn_unused_result [-Wunused-result]
  driver_for_each_device(&rbtn_driver.drv, NULL, &ret, rbtn_inc_count);
  ^
drivers/platform/x86/dell-rbtn.c:284:3: warning: ignoring return value of ‘driver_for_each_device’, declared with attribute warn_unused_result [-Wunused-result]
   driver_for_each_device(&rbtn_driver.drv, NULL, (void *)false,
   ^
drivers/platform/x86/dell-rbtn.c: In function ‘dell_rbtn_notifier_unregister’:
drivers/platform/x86/dell-rbtn.c:300:3: warning: ignoring return value of ‘driver_for_each_device’, declared with attribute warn_unused_result [-Wunused-result]
   driver_for_each_device(&rbtn_driver.drv, NULL, (void *)true,

We can't introduce new warnings to the build.

I've pushed my fixes to the series to my dell-rbtn branch, please start from
there and resolve the above, and resubmit. We can still make 4.2. But please
make use of checkpatch and watch for warnings like the above in your builds
tests so we can avoid unecessary churn.

Thanks,

-- 
Darren Hart
Intel Open Source Technology Center

[PATCH v3 0/3] Dell Airplane Mode Switch driver

[Pali Rohár]

This patch series add new acpi Dell Airplane Mode Switch driver (DELLABCE and
DELRBTN acpi devices). It provides radio HW switch events (together with current
state of radio devices) and export them via rfkill interface. These events are
also used in dell-laptop driver instead i8042 filter hook function (when acpi
device is available).

In v2 was added support for laptops which have toggle button instead HW slider
switch. For that I reused code done by Alex Hung.

v3 is just cleanup.

Pali Rohár (3):
  dell-rbtn: Dell Airplane Mode Switch driver
  dell-rbtn: Export notifier for other kernel modules
  dell-laptop: Use dell-rbtn instead i8042 filter when possible

 MAINTAINERS                        |    5 +
 drivers/platform/x86/Kconfig       |   13 ++
 drivers/platform/x86/Makefile      |    1 +
 drivers/platform/x86/dell-laptop.c |   67 +++++-
 drivers/platform/x86/dell-rbtn.c   |  433 ++++++++++++++++++++++++++++++++++++
 drivers/platform/x86/dell-rbtn.h   |   35 +++
 6 files changed, 549 insertions(+), 5 deletions(-)
 create mode 100644 drivers/platform/x86/dell-rbtn.c
 create mode 100644 drivers/platform/x86/dell-rbtn.h

-- 
1.7.10.4

[PATCH v3 1/3] dell-rbtn: Dell Airplane Mode Switch driver

[Pali Rohár]

This is an ACPI driver for Dell laptops which receive HW switch events.
It exports rfkill device dell-rbtn which provide correct hard rfkill state.

Alex Hung added code for supporting Dell laptops which have toggle button
instead HW slider switch. On these laptops toggle button event is reported
by new input device (instead rfkill) as they do not have hw radio switch.

It looks like those are two different functions (rfkill, input device), but
Dell BIOS exports them via same ACPI device and uses same ACPI functions.
So code is in one kernel driver.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Cc: Alex Hung <alex.hung@canonical.com>

Correct multi-line comment formatting and line length issues.

Signed-off-by: Darren Hart <dvhart@linux.intel.com>

[Fengguang Wu <fengguang.wu@intel.com>: rbtn_ops can be static]
---
Changes since v2:
 - rbtn_ops is static
 - added MAINTAINERS
 - fixed checkpatch.pl warnings
---
 MAINTAINERS                      |    5 +
 drivers/platform/x86/Kconfig     |   13 ++
 drivers/platform/x86/Makefile    |    1 +
 drivers/platform/x86/dell-rbtn.c |  345 ++++++++++++++++++++++++++++++++++++++
 4 files changed, 364 insertions(+)
 create mode 100644 drivers/platform/x86/dell-rbtn.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 2e5bbc0..5808066 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3071,6 +3071,11 @@ L:	platform-driver-x86@vger.kernel.org
 S:	Maintained
 F:	drivers/platform/x86/dell-laptop.c
 
+DELL LAPTOP RBTN DRIVER
+M:	Pali Rohár <pali.rohar@gmail.com>
+S:	Maintained
+F:	drivers/platform/x86/dell-rbtn.*
+
 DELL LAPTOP FREEFALL DRIVER
 M:	Pali Rohár <pali.rohar@gmail.com>
 S:	Maintained
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 399085d..8c03223 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -138,6 +138,19 @@ config DELL_SMO8800
 	  To compile this driver as a module, choose M here: the module will
 	  be called dell-smo8800.
 
+config DELL_RBTN
+	tristate "Dell Airplane Mode Switch driver"
+	depends on ACPI
+	depends on RFKILL
+	---help---
+	  Say Y here if you want to support Dell Airplane Mode Switch ACPI
+	  device on Dell laptops. Sometimes it has names: DELLABCE or DELRBTN.
+	  This driver register rfkill device and receives HW rfkill events
+	  (when wifi/bluetooth was enabled) and set correct hard rfkill state.
+
+	  To compile this driver as a module, choose M here: the module will
+	  be called dell-rbtn.
+
 
 config FUJITSU_LAPTOP
 	tristate "Fujitsu Laptop Extras"
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index f82232b..b3e54ed 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_DELL_LAPTOP)	+= dell-laptop.o
 obj-$(CONFIG_DELL_WMI)		+= dell-wmi.o
 obj-$(CONFIG_DELL_WMI_AIO)	+= dell-wmi-aio.o
 obj-$(CONFIG_DELL_SMO8800)	+= dell-smo8800.o
+obj-$(CONFIG_DELL_RBTN)		+= dell-rbtn.o
 obj-$(CONFIG_ACER_WMI)		+= acer-wmi.o
 obj-$(CONFIG_ACERHDF)		+= acerhdf.o
 obj-$(CONFIG_HP_ACCEL)		+= hp_accel.o
diff --git a/drivers/platform/x86/dell-rbtn.c b/drivers/platform/x86/dell-rbtn.c
new file mode 100644
index 0000000..af89f91
--- /dev/null
+++ b/drivers/platform/x86/dell-rbtn.c
@@ -0,0 +1,345 @@
+/*
+    Dell Airplane Mode Switch driver
+    Copyright (C) 2014-2015  Pali Rohár <pali.rohar@gmail.com>
+
+    This program is free software; you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+*/
+
+#include <linux/module.h>
+#include <linux/acpi.h>
+#include <linux/rfkill.h>
+#include <linux/input.h>
+
+enum rbtn_type {
+	RBTN_UNKNOWN,
+	RBTN_TOGGLE,
+	RBTN_SLIDER,
+};
+
+struct rbtn_data {
+	enum rbtn_type type;
+	struct rfkill *rfkill;
+	struct input_dev *input_dev;
+};
+
+
+/*
+ * acpi functions
+ */
+
+static enum rbtn_type rbtn_check(struct acpi_device *device)
+{
+	unsigned long long output;
+	acpi_status status;
+
+	status = acpi_evaluate_integer(device->handle, "CRBT", NULL, &output);
+	if (ACPI_FAILURE(status))
+		return RBTN_UNKNOWN;
+
+	switch (output) {
+	case 0:
+	case 1:
+		return RBTN_TOGGLE;
+	case 2:
+	case 3:
+		return RBTN_SLIDER;
+	default:
+		return RBTN_UNKNOWN;
+	}
+}
+
+static int rbtn_get(struct acpi_device *device)
+{
+	unsigned long long output;
+	acpi_status status;
+
+	status = acpi_evaluate_integer(device->handle, "GRBT", NULL, &output);
+	if (ACPI_FAILURE(status))
+		return -EINVAL;
+
+	return !output;
+}
+
+static int rbtn_radio_enable(struct acpi_device *device, bool enable)
+{
+	struct acpi_object_list input;
+	union acpi_object param;
+	acpi_status status;
+
+	param.type = ACPI_TYPE_INTEGER;
+	param.integer.value = enable;
+	input.count = 1;
+	input.pointer = &param;
+
+	status = acpi_evaluate_object(device->handle, "ARBT", &input, NULL);
+	if (ACPI_FAILURE(status))
+		return -EINVAL;
+
+	return 0;
+}
+
+
+/*
+ * rfkill device
+ */
+
+static void rbtn_rfkill_query(struct rfkill *rfkill, void *data)
+{
+	struct acpi_device *device = data;
+	int state;
+
+	state = rbtn_get(device);
+	if (state < 0)
+		return;
+
+	rfkill_set_states(rfkill, state, state);
+}
+
+static int rbtn_rfkill_set_block(void *data, bool blocked)
+{
+	/* NOTE: setting soft rfkill state is not supported */
+	return -EINVAL;
+}
+
+static struct rfkill_ops rbtn_ops = {
+	.query = rbtn_rfkill_query,
+	.set_block = rbtn_rfkill_set_block,
+};
+
+static int rbtn_rfkill_init(struct acpi_device *device)
+{
+	struct rbtn_data *rbtn_data = device->driver_data;
+	int ret;
+
+	if (rbtn_data->rfkill)
+		return 0;
+
+	/* NOTE: rbtn controls all radio devices, not only WLAN
+	 *       but rfkill interface does not support "ANY" type
+	 *       so "WLAN" type is used
+	 */
+	rbtn_data->rfkill = rfkill_alloc("dell-rbtn", &device->dev,
+					 RFKILL_TYPE_WLAN, &rbtn_ops, device);
+	if (!rbtn_data->rfkill)
+		return -ENOMEM;
+
+	ret = rfkill_register(rbtn_data->rfkill);
+	if (ret) {
+		rfkill_destroy(rbtn_data->rfkill);
+		rbtn_data->rfkill = NULL;
+		return ret;
+	}
+
+	return 0;
+}
+
+static void rbtn_rfkill_exit(struct acpi_device *device)
+{
+	struct rbtn_data *rbtn_data = device->driver_data;
+
+	if (!rbtn_data->rfkill)
+		return;
+
+	rfkill_unregister(rbtn_data->rfkill);
+	rfkill_destroy(rbtn_data->rfkill);
+	rbtn_data->rfkill = NULL;
+}
+
+static void rbtn_rfkill_event(struct acpi_device *device)
+{
+	struct rbtn_data *rbtn_data = device->driver_data;
+
+	if (rbtn_data->rfkill)
+		rbtn_rfkill_query(rbtn_data->rfkill, device);
+}
+
+
+/*
+ * input device
+ */
+
+static int rbtn_input_init(struct rbtn_data *rbtn_data)
+{
+	int ret;
+
+	rbtn_data->input_dev = input_allocate_device();
+	if (!rbtn_data->input_dev)
+		return -ENOMEM;
+
+	rbtn_data->input_dev->name = "DELL Wireless hotkeys";
+	rbtn_data->input_dev->phys = "dellabce/input0";
+	rbtn_data->input_dev->id.bustype = BUS_HOST;
+	rbtn_data->input_dev->evbit[0] = BIT(EV_KEY);
+	set_bit(KEY_RFKILL, rbtn_data->input_dev->keybit);
+
+	ret = input_register_device(rbtn_data->input_dev);
+	if (ret) {
+		input_free_device(rbtn_data->input_dev);
+		rbtn_data->input_dev = NULL;
+		return ret;
+	}
+
+	return 0;
+}
+
+static void rbtn_input_exit(struct rbtn_data *rbtn_data)
+{
+	input_unregister_device(rbtn_data->input_dev);
+	rbtn_data->input_dev = NULL;
+}
+
+static void rbtn_input_event(struct rbtn_data *rbtn_data)
+{
+	input_report_key(rbtn_data->input_dev, KEY_RFKILL, 1);
+	input_sync(rbtn_data->input_dev);
+	input_report_key(rbtn_data->input_dev, KEY_RFKILL, 0);
+	input_sync(rbtn_data->input_dev);
+}
+
+
+/*
+ * acpi driver
+ */
+
+static int rbtn_add(struct acpi_device *device);
+static int rbtn_remove(struct acpi_device *device);
+static void rbtn_notify(struct acpi_device *device, u32 event);
+
+static const struct acpi_device_id rbtn_ids[] = {
+	{ "DELRBTN", 0 },
+	{ "DELLABCE", 0 },
+	{ "", 0 },
+};
+
+static struct acpi_driver rbtn_driver = {
+	.name = "dell-rbtn",
+	.ids = rbtn_ids,
+	.ops = {
+		.add = rbtn_add,
+		.remove = rbtn_remove,
+		.notify = rbtn_notify,
+	},
+	.owner = THIS_MODULE,
+};
+
+
+/*
+ * acpi driver functions
+ */
+
+static int rbtn_add(struct acpi_device *device)
+{
+	struct rbtn_data *rbtn_data;
+	enum rbtn_type type;
+	int ret = 0;
+
+	type = rbtn_check(device);
+	if (type == RBTN_UNKNOWN) {
+		dev_info(&device->dev, "Unknown device type\n");
+		return -EINVAL;
+	}
+
+	ret = rbtn_radio_enable(device, true);
+	if (ret < 0) {
+		dev_err(&device->dev, "Cannot enable device\n");
+		return ret;
+	}
+
+	rbtn_data = devm_kzalloc(&device->dev, sizeof(*rbtn_data), GFP_KERNEL);
+	if (!rbtn_data)
+		return -ENOMEM;
+
+	rbtn_data->type = type;
+	device->driver_data = rbtn_data;
+
+	switch (rbtn_data->type) {
+	case RBTN_TOGGLE:
+		ret = rbtn_input_init(rbtn_data);
+		break;
+	case RBTN_SLIDER:
+		ret = rbtn_rfkill_init(device);
+		break;
+	default:
+		ret = -EINVAL;
+	}
+
+	return ret;
+
+}
+
+static int rbtn_remove(struct acpi_device *device)
+{
+	struct rbtn_data *rbtn_data = device->driver_data;
+	int ret;
+
+	switch (rbtn_data->type) {
+	case RBTN_TOGGLE:
+		rbtn_input_exit(rbtn_data);
+		break;
+	case RBTN_SLIDER:
+		rbtn_rfkill_exit(device);
+		break;
+	default:
+		break;
+	}
+
+	ret = rbtn_radio_enable(device, false);
+	if (ret < 0)
+		return ret;
+
+	device->driver_data = NULL;
+	return 0;
+}
+
+static void rbtn_notify(struct acpi_device *device, u32 event)
+{
+	struct rbtn_data *rbtn_data = device->driver_data;
+
+	if (event != 0x80) {
+		dev_info(&device->dev, "Received unknown event (0x%x)\n",
+			 event);
+		return;
+	}
+
+	switch (rbtn_data->type) {
+	case RBTN_TOGGLE:
+		rbtn_input_event(rbtn_data);
+		break;
+	case RBTN_SLIDER:
+		rbtn_rfkill_event(device);
+		break;
+	default:
+		break;
+	}
+}
+
+
+/*
+ * module functions
+ */
+
+static int __init rbtn_init(void)
+{
+	return acpi_bus_register_driver(&rbtn_driver);
+}
+
+static void __exit rbtn_exit(void)
+{
+	acpi_bus_unregister_driver(&rbtn_driver);
+}
+
+module_init(rbtn_init);
+module_exit(rbtn_exit);
+
+MODULE_DEVICE_TABLE(acpi, rbtn_ids);
+MODULE_DESCRIPTION("Dell Airplane Mode Switch driver");
+MODULE_AUTHOR("Pali Rohár <pali.rohar@gmail.com>");
+MODULE_LICENSE("GPL");
-- 
1.7.10.4

[PATCH v3 2/3] dell-rbtn: Export notifier for other kernel modules

[Pali Rohár]

This patch exports notifier functions so other modules can receive HW
switch events. By default when some module register notifier, dell-rbtn
driver automatically remove rfkill interfaces from system (it is expected
that other module will use events for other rfkill interface). This
behaviour can be changed with new module parameter "auto_remove_rfkill".

This patch is designed for dell-laptop module for receiving those events.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>

Cleanup MODULE_PARM_DESC formatting and grammar.

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
---
Changes since v2:
 - check return value of driver_for_each_device
 - fixed checkpatch.pl warnings
---
 drivers/platform/x86/dell-rbtn.c |   92 +++++++++++++++++++++++++++++++++++++-
 drivers/platform/x86/dell-rbtn.h |   35 +++++++++++++++
 2 files changed, 125 insertions(+), 2 deletions(-)
 create mode 100644 drivers/platform/x86/dell-rbtn.h

diff --git a/drivers/platform/x86/dell-rbtn.c b/drivers/platform/x86/dell-rbtn.c
index af89f91..266aeb9 100644
--- a/drivers/platform/x86/dell-rbtn.c
+++ b/drivers/platform/x86/dell-rbtn.c
@@ -232,6 +232,82 @@ static struct acpi_driver rbtn_driver = {
 
 
 /*
+ * notifier export functions
+ */
+
+static bool auto_remove_rfkill = true;
+
+static ATOMIC_NOTIFIER_HEAD(rbtn_chain_head);
+
+static int rbtn_inc_count(struct device *dev, void *data)
+{
+	struct acpi_device *device = to_acpi_device(dev);
+	struct rbtn_data *rbtn_data = device->driver_data;
+	int *count = data;
+
+	if (rbtn_data->type == RBTN_SLIDER)
+		(*count)++;
+
+	return 0;
+}
+
+static int rbtn_switch_dev(struct device *dev, void *data)
+{
+	struct acpi_device *device = to_acpi_device(dev);
+	bool enable = data;
+
+	if (enable)
+		rbtn_rfkill_init(device);
+	else
+		rbtn_rfkill_exit(device);
+
+	return 0;
+}
+
+int dell_rbtn_notifier_register(struct notifier_block *nb)
+{
+	bool first;
+	int count;
+	int ret;
+
+	count = 0;
+	ret = driver_for_each_device(&rbtn_driver.drv, NULL, &count,
+				     rbtn_inc_count);
+	if (ret || count == 0)
+		return -ENODEV;
+
+	first = !rbtn_chain_head.head;
+
+	ret = atomic_notifier_chain_register(&rbtn_chain_head, nb);
+	if (ret != 0)
+		return ret;
+
+	if (auto_remove_rfkill && first)
+		ret = driver_for_each_device(&rbtn_driver.drv, NULL,
+					     (void *)false, rbtn_switch_dev);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(dell_rbtn_notifier_register);
+
+int dell_rbtn_notifier_unregister(struct notifier_block *nb)
+{
+	int ret;
+
+	ret = atomic_notifier_chain_unregister(&rbtn_chain_head, nb);
+	if (ret != 0)
+		return ret;
+
+	if (auto_remove_rfkill && !rbtn_chain_head.head)
+		ret = driver_for_each_device(&rbtn_driver.drv, NULL,
+					     (void *)true, rbtn_switch_dev);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(dell_rbtn_notifier_unregister);
+
+
+/*
  * acpi driver functions
  */
 
@@ -265,7 +341,10 @@ static int rbtn_add(struct acpi_device *device)
 		ret = rbtn_input_init(rbtn_data);
 		break;
 	case RBTN_SLIDER:
-		ret = rbtn_rfkill_init(device);
+		if (auto_remove_rfkill && rbtn_chain_head.head)
+			ret = 0;
+		else
+			ret = rbtn_rfkill_init(device);
 		break;
 	default:
 		ret = -EINVAL;
@@ -315,6 +394,7 @@ static void rbtn_notify(struct acpi_device *device, u32 event)
 		break;
 	case RBTN_SLIDER:
 		rbtn_rfkill_event(device);
+		atomic_notifier_call_chain(&rbtn_chain_head, event, device);
 		break;
 	default:
 		break;
@@ -328,7 +408,9 @@ static void rbtn_notify(struct acpi_device *device, u32 event)
 
 static int __init rbtn_init(void)
 {
-	return acpi_bus_register_driver(&rbtn_driver);
+	/* ignore errors so module always loads and exports needed functions */
+	acpi_bus_register_driver(&rbtn_driver);
+	return 0;
 }
 
 static void __exit rbtn_exit(void)
@@ -336,9 +418,15 @@ static void __exit rbtn_exit(void)
 	acpi_bus_unregister_driver(&rbtn_driver);
 }
 
+module_param(auto_remove_rfkill, bool, 0444);
 module_init(rbtn_init);
 module_exit(rbtn_exit);
 
+MODULE_PARM_DESC(auto_remove_rfkill, "Automatically remove rfkill devices when "
+				     "other modules start receiving events "
+				     "from this module and re-add them when "
+				     "the last module stops receiving events "
+				     "(default true)");
 MODULE_DEVICE_TABLE(acpi, rbtn_ids);
 MODULE_DESCRIPTION("Dell Airplane Mode Switch driver");
 MODULE_AUTHOR("Pali Rohár <pali.rohar@gmail.com>");
diff --git a/drivers/platform/x86/dell-rbtn.h b/drivers/platform/x86/dell-rbtn.h
new file mode 100644
index 0000000..d6b44b0
--- /dev/null
+++ b/drivers/platform/x86/dell-rbtn.h
@@ -0,0 +1,35 @@
+/*
+    Dell Airplane Mode Switch driver
+    Copyright (C) 2014-2015  Pali Rohár <pali.rohar@gmail.com>
+
+    This program is free software; you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+*/
+
+#ifndef _DELL_RBTN_H_
+#define _DELL_RBTN_H_
+
+struct notifier_block;
+
+#if defined(CONFIG_DELL_RBTN) || defined(CONFIG_DELL_RBTN_MODULE)
+int dell_rbtn_notifier_register(struct notifier_block *nb);
+int dell_rbtn_notifier_unregister(struct notifier_block *nb);
+#else
+static inline int dell_rbtn_notifier_register(struct notifier_block *nb)
+{
+	return -ENODEV;
+}
+static inline int dell_rbtn_notifier_unregister(struct notifier_block *nb)
+{
+	return -ENODEV;
+}
+#endif
+
+#endif
-- 
1.7.10.4

Re: [PATCH v3 2/3] dell-rbtn: Export notifier for other kernel modules

[Dmitry Torokhov]

On Thu, May 14, 2015 at 3:54 AM, Pali Rohár <pali.rohar@gmail.com> wrote:

> @@ -328,7 +408,9 @@ static void rbtn_notify(struct acpi_device *device, u32 event)
>
>  static int __init rbtn_init(void)
>  {
> -       return acpi_bus_register_driver(&rbtn_driver);
> +       /* ignore errors so module always loads and exports needed functions */
> +       acpi_bus_register_driver(&rbtn_driver);
> +       return 0;

Ahem, and if it fails for some reason and you try to unload the module
what will happen when you call
acpi_bus_unregister_driver(&rbtn_driver) in rbtn_exit()?\

Thanks.

-- 
Dmitry

Re: [PATCH v3 2/3] dell-rbtn: Export notifier for other kernel modules

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 897 bytes --]

On Saturday 23 May 2015 00:45:57 Dmitry Torokhov wrote:
> On Thu, May 14, 2015 at 3:54 AM, Pali Rohár <pali.rohar@gmail.com>
> wrote:
> > @@ -328,7 +408,9 @@ static void rbtn_notify(struct acpi_device
> > *device, u32 event)
> > 
> >  static int __init rbtn_init(void)
> >  {
> > 
> > -       return acpi_bus_register_driver(&rbtn_driver);
> > +       /* ignore errors so module always loads and exports needed
> > functions */ +       acpi_bus_register_driver(&rbtn_driver);
> > +       return 0;
> 
> Ahem, and if it fails for some reason and you try to unload the
> module what will happen when you call
> acpi_bus_unregister_driver(&rbtn_driver) in rbtn_exit()?\
> 
> Thanks.

I'm thinking about using symbol_request() in dell-laptop.c (instead hard 
dependency) and then not ignoring error here... It could fix this 
problem.

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH v3 2/3] dell-rbtn: Export notifier for other kernel modules

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 313 bytes --]

On Sat, 23 May 2015 03:05:50 +0200, Pali Rohár said:

> I'm thinking about using symbol_request() in dell-laptop.c (instead hard=20
> dependency) and then not ignoring error here... It could fix this=20
> problem.

That would also address the problem of a build
that has DELL_LAPTOP=[ym] but DELL_RBTN=n.

[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]

Re: [PATCH v3 2/3] dell-rbtn: Export notifier for other kernel modules

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 601 bytes --]

On Sunday 24 May 2015 07:07:36 Valdis.Kletnieks@vt.edu wrote:
> On Sat, 23 May 2015 03:05:50 +0200, Pali Rohár said:
> > I'm thinking about using symbol_request() in dell-laptop.c (instead
> > hard=20 dependency) and then not ignoring error here... It could
> > fix this=20 problem.
> 
> That would also address the problem of a build
> that has DELL_LAPTOP=[ym] but DELL_RBTN=n.

That is already handled. But DELL_LAPTOP=y and DELL_RBTN=m not. I will 
send PATCH v4 with all fixed after somebody tell me what to do with 
kernel panic at boot...

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[PATCH v3 3/3] dell-laptop: Use dell-rbtn instead i8042 filter when possible

[Pali Rohár]

Until now module dell-laptop registered rfkill device which used i8042
filter function for receiving HW switch rfkill events (handling special
keycode).

But for some dell laptops there is native ACPI driver dell-rbtn which can
receive rfkill events (without i8042 hacks). On some machines it can also
control rfkill devices, but can turn on/off all radio devices.

So this patch will combine best from both sides. It will use native ACPI
driver dell-rbtn for receiving events and dell-laptop SMBIOS interface for
enabling or disabling radio devices. If ACPI driver or device will not be
available fallback to i8042 filter function will be used.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
---
 drivers/platform/x86/dell-laptop.c |   67 +++++++++++++++++++++++++++++++++---
 1 file changed, 62 insertions(+), 5 deletions(-)

diff --git a/drivers/platform/x86/dell-laptop.c b/drivers/platform/x86/dell-laptop.c
index d688d80..c9ea0f8 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -32,6 +32,7 @@
 #include <linux/debugfs.h>
 #include <linux/seq_file.h>
 #include "../../firmware/dcdbas.h"
+#include "dell-rbtn.h"
 
 #define BRIGHTNESS_TOKEN 0x7d
 #define KBD_LED_OFF_TOKEN 0x01E1
@@ -642,6 +643,20 @@ static bool dell_laptop_i8042_filter(unsigned char data, unsigned char str,
 	return false;
 }
 
+static bool dell_laptop_use_rbtn;
+
+static int dell_laptop_rbtn_notifier_call(struct notifier_block *nb,
+					  unsigned long action, void *data)
+{
+	schedule_delayed_work(&dell_rfkill_work,
+			      round_jiffies_relative(HZ / 4));
+	return NOTIFY_OK;
+}
+
+static struct notifier_block dell_laptop_rbtn_notifier = {
+	.notifier_call = dell_laptop_rbtn_notifier_call,
+};
+
 static int __init dell_setup_rfkill(void)
 {
 	int status, ret, whitelisted;
@@ -718,10 +733,46 @@ static int __init dell_setup_rfkill(void)
 			goto err_wwan;
 	}
 
-	ret = i8042_install_filter(dell_laptop_i8042_filter);
-	if (ret) {
-		pr_warn("Unable to install key filter\n");
+	/*
+	 * Dell Airplane Mode Switch driver (dell-rbtn) supports ACPI devices
+	 * which can receive HW button switch events and also can control radio
+	 * devices. Somtimes ACPI device supports only reciving events (without
+	 * enable/disable software control).
+	 *
+	 * Dell SMBIOS on whitelisted models supports controlling radio devices
+	 * but does not support receiving HW button switch events. We can use
+	 * i8042 filter hook function to receive keyboard data and handle
+	 * keycode for HW button.
+	 *
+	 * Dell Airplane Mode Switch driver supports only one rfkill switch
+	 * which enable/disable all radio devices. But Dell SMBIOS supports more
+	 * granularity and can enable/disable also one type of radio device
+	 * (e.g disable only bluetooth device without touching wifi device).
+	 *
+	 * So if it is possible we will use Dell Airplane Mode Switch ACPI
+	 * driver for receiving HW events and Dell SMBIOS for setting rfkill
+	 * states. If ACPI driver or device is not available we will fallback to
+	 * i8042 filter hook function.
+	 *
+	 * To prevent duplicate rfkill devices which control and do same thing,
+	 * dell-rbtn driver will automatically remove its own rfkill devices
+	 * once function dell_rbtn_notifier_register() is called.
+	 */
+
+	ret = dell_rbtn_notifier_register(&dell_laptop_rbtn_notifier);
+	if (ret == 0) {
+		pr_info("Using dell-rbtn acpi driver for receiving events\n");
+		dell_laptop_use_rbtn = true;
+	} else if (ret != -ENODEV) {
+		pr_warn("Unable to register dell rbtn notifier\n");
 		goto err_filter;
+	} else {
+		ret = i8042_install_filter(dell_laptop_i8042_filter);
+		if (ret) {
+			pr_warn("Unable to install key filter\n");
+			goto err_filter;
+		}
+		pr_info("Using i8042 filter function for receiving events\n");
 	}
 
 	return 0;
@@ -1961,7 +2012,10 @@ static int __init dell_init(void)
 	return 0;
 
 fail_backlight:
-	i8042_remove_filter(dell_laptop_i8042_filter);
+	if (dell_laptop_use_rbtn)
+		dell_rbtn_notifier_unregister(&dell_laptop_rbtn_notifier);
+	else
+		i8042_remove_filter(dell_laptop_i8042_filter);
 	cancel_delayed_work_sync(&dell_rfkill_work);
 	dell_cleanup_rfkill();
 fail_rfkill:
@@ -1983,7 +2037,10 @@ static void __exit dell_exit(void)
 	if (quirks && quirks->touchpad_led)
 		touchpad_led_exit();
 	kbd_led_exit();
-	i8042_remove_filter(dell_laptop_i8042_filter);
+	if (dell_laptop_use_rbtn)
+		dell_rbtn_notifier_unregister(&dell_laptop_rbtn_notifier);
+	else
+		i8042_remove_filter(dell_laptop_i8042_filter);
 	cancel_delayed_work_sync(&dell_rfkill_work);
 	backlight_device_unregister(dell_backlight_device);
 	dell_cleanup_rfkill();
-- 
1.7.10.4

Re: [PATCH v3 0/3] Dell Airplane Mode Switch driver

[Darren Hart]

On Thu, May 14, 2015 at 12:54:24PM +0200, Pali Rohár wrote:
> This patch series add new acpi Dell Airplane Mode Switch driver (DELLABCE and
> DELRBTN acpi devices). It provides radio HW switch events (together with current
> state of radio devices) and export them via rfkill interface. These events are
> also used in dell-laptop driver instead i8042 filter hook function (when acpi
> device is available).
> 
> In v2 was added support for laptops which have toggle button instead HW slider
> switch. For that I reused code done by Alex Hung.
> 
> v3 is just cleanup.
> 
> Pali Rohár (3):
>   dell-rbtn: Dell Airplane Mode Switch driver
>   dell-rbtn: Export notifier for other kernel modules
>   dell-laptop: Use dell-rbtn instead i8042 filter when possible

Queued for 4.2, thanks for sticking with it Pali, Gabriele, and Alex.

-- 
Darren Hart
Intel Open Source Technology Center

[PATCH v4 0/3] Dell Airplane Mode Switch driver

[Pali Rohár]

This patch series add new acpi Dell Airplane Mode Switch driver (DELLABCE and
DELRBTN acpi devices). It provides radio HW switch events (together with current
state of radio devices) and export them via rfkill interface. These events are
also used in dell-laptop driver instead i8042 filter hook function (when acpi
device is available).

In v2 was added support for laptops which have toggle button instead HW slider
switch. For that I reused code done by Alex Hung.

v3 is just cleanup.

In v4 was fixed dependency problems.

Pali Rohár (3):
  dell-rbtn: Dell Airplane Mode Switch driver
  dell-rbtn: Export notifier for other kernel modules
  dell-laptop: Use dell-rbtn instead i8042 filter when possible

 MAINTAINERS                        |    5 +
 drivers/platform/x86/Kconfig       |   16 ++
 drivers/platform/x86/Makefile      |    1 +
 drivers/platform/x86/dell-laptop.c |   91 +++++++-
 drivers/platform/x86/dell-rbtn.c   |  423 ++++++++++++++++++++++++++++++++++++
 drivers/platform/x86/dell-rbtn.h   |   24 ++
 6 files changed, 552 insertions(+), 8 deletions(-)
 create mode 100644 drivers/platform/x86/dell-rbtn.c
 create mode 100644 drivers/platform/x86/dell-rbtn.h

-- 
1.7.9.5

[PATCH v4 1/3] dell-rbtn: Dell Airplane Mode Switch driver

[Pali Rohár]

This is an ACPI driver for Dell laptops which receive HW slider radio switch
or hotkey toggle wifi button events. It exports rfkill device dell-rbtn
(which provide correct hard rfkill state) or hotkey input device.

Alex Hung is author of original hotkey input device code.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Cc: Alex Hung <alex.hung@canonical.com>

rbtn_ops can be static

Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>

Correct multi-line comment formatting.

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
---
Changes for v4:
 - depends on INPUT
 - rename rbtn_radio_enable() to rbtn_acquire()
 - never fail in rbtn_remove() return value in acpi is ignored!
 - use module_acpi_driver() instead module_init()/module_exit()
 - change description in commit message in Kconfig
---
 MAINTAINERS                      |    5 +
 drivers/platform/x86/Kconfig     |   16 ++
 drivers/platform/x86/Makefile    |    1 +
 drivers/platform/x86/dell-rbtn.c |  332 ++++++++++++++++++++++++++++++++++++++
 4 files changed, 354 insertions(+)
 create mode 100644 drivers/platform/x86/dell-rbtn.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 2e5bbc0..5808066 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3071,6 +3071,11 @@ L:	platform-driver-x86@vger.kernel.org
 S:	Maintained
 F:	drivers/platform/x86/dell-laptop.c
 
+DELL LAPTOP RBTN DRIVER
+M:	Pali Rohár <pali.rohar@gmail.com>
+S:	Maintained
+F:	drivers/platform/x86/dell-rbtn.*
+
 DELL LAPTOP FREEFALL DRIVER
 M:	Pali Rohár <pali.rohar@gmail.com>
 S:	Maintained
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 399085d..bca0aee 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -138,6 +138,22 @@ config DELL_SMO8800
 	  To compile this driver as a module, choose M here: the module will
 	  be called dell-smo8800.
 
+config DELL_RBTN
+	tristate "Dell Airplane Mode Switch driver"
+	depends on ACPI
+	depends on INPUT
+	depends on RFKILL
+	---help---
+	  Say Y here if you want to support Dell Airplane Mode Switch ACPI
+	  device on Dell laptops. Sometimes it has names: DELLABCE or DELRBTN.
+	  This driver register rfkill device or input hotkey device depending
+	  on hardware type (hw switch slider or keyboard toggle button). For
+	  rfkill devices it receive HW switch events and set correct hard
+	  rfkill state.
+
+	  To compile this driver as a module, choose M here: the module will
+	  be called dell-rbtn.
+
 
 config FUJITSU_LAPTOP
 	tristate "Fujitsu Laptop Extras"
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index f82232b..b3e54ed 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_DELL_LAPTOP)	+= dell-laptop.o
 obj-$(CONFIG_DELL_WMI)		+= dell-wmi.o
 obj-$(CONFIG_DELL_WMI_AIO)	+= dell-wmi-aio.o
 obj-$(CONFIG_DELL_SMO8800)	+= dell-smo8800.o
+obj-$(CONFIG_DELL_RBTN)		+= dell-rbtn.o
 obj-$(CONFIG_ACER_WMI)		+= acer-wmi.o
 obj-$(CONFIG_ACERHDF)		+= acerhdf.o
 obj-$(CONFIG_HP_ACCEL)		+= hp_accel.o
diff --git a/drivers/platform/x86/dell-rbtn.c b/drivers/platform/x86/dell-rbtn.c
new file mode 100644
index 0000000..1c19fff
--- /dev/null
+++ b/drivers/platform/x86/dell-rbtn.c
@@ -0,0 +1,332 @@
+/*
+    Dell Airplane Mode Switch driver
+    Copyright (C) 2014-2015  Pali Rohár <pali.rohar@gmail.com>
+
+    This program is free software; you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+*/
+
+#include <linux/module.h>
+#include <linux/acpi.h>
+#include <linux/rfkill.h>
+#include <linux/input.h>
+
+enum rbtn_type {
+	RBTN_UNKNOWN,
+	RBTN_TOGGLE,
+	RBTN_SLIDER,
+};
+
+struct rbtn_data {
+	enum rbtn_type type;
+	struct rfkill *rfkill;
+	struct input_dev *input_dev;
+};
+
+
+/*
+ * acpi functions
+ */
+
+static enum rbtn_type rbtn_check(struct acpi_device *device)
+{
+	unsigned long long output;
+	acpi_status status;
+
+	status = acpi_evaluate_integer(device->handle, "CRBT", NULL, &output);
+	if (ACPI_FAILURE(status))
+		return RBTN_UNKNOWN;
+
+	switch (output) {
+	case 0:
+	case 1:
+		return RBTN_TOGGLE;
+	case 2:
+	case 3:
+		return RBTN_SLIDER;
+	default:
+		return RBTN_UNKNOWN;
+	}
+}
+
+static int rbtn_get(struct acpi_device *device)
+{
+	unsigned long long output;
+	acpi_status status;
+
+	status = acpi_evaluate_integer(device->handle, "GRBT", NULL, &output);
+	if (ACPI_FAILURE(status))
+		return -EINVAL;
+
+	return !output;
+}
+
+static int rbtn_acquire(struct acpi_device *device, bool enable)
+{
+	struct acpi_object_list input;
+	union acpi_object param;
+	acpi_status status;
+
+	param.type = ACPI_TYPE_INTEGER;
+	param.integer.value = enable;
+	input.count = 1;
+	input.pointer = &param;
+
+	status = acpi_evaluate_object(device->handle, "ARBT", &input, NULL);
+	if (ACPI_FAILURE(status))
+		return -EINVAL;
+
+	return 0;
+}
+
+
+/*
+ * rfkill device
+ */
+
+static void rbtn_rfkill_query(struct rfkill *rfkill, void *data)
+{
+	struct acpi_device *device = data;
+	int state;
+
+	state = rbtn_get(device);
+	if (state < 0)
+		return;
+
+	rfkill_set_states(rfkill, state, state);
+}
+
+static int rbtn_rfkill_set_block(void *data, bool blocked)
+{
+	/* NOTE: setting soft rfkill state is not supported */
+	return -EINVAL;
+}
+
+static struct rfkill_ops rbtn_ops = {
+	.query = rbtn_rfkill_query,
+	.set_block = rbtn_rfkill_set_block,
+};
+
+static int rbtn_rfkill_init(struct acpi_device *device)
+{
+	struct rbtn_data *rbtn_data = device->driver_data;
+	int ret;
+
+	if (rbtn_data->rfkill)
+		return 0;
+
+	/*
+	 * NOTE: rbtn controls all radio devices, not only WLAN
+	 *       but rfkill interface does not support "ANY" type
+	 *       so "WLAN" type is used
+	 */
+	rbtn_data->rfkill = rfkill_alloc("dell-rbtn", &device->dev,
+					 RFKILL_TYPE_WLAN, &rbtn_ops, device);
+	if (!rbtn_data->rfkill)
+		return -ENOMEM;
+
+	ret = rfkill_register(rbtn_data->rfkill);
+	if (ret) {
+		rfkill_destroy(rbtn_data->rfkill);
+		rbtn_data->rfkill = NULL;
+		return ret;
+	}
+
+	return 0;
+}
+
+static void rbtn_rfkill_exit(struct acpi_device *device)
+{
+	struct rbtn_data *rbtn_data = device->driver_data;
+
+	if (!rbtn_data->rfkill)
+		return;
+
+	rfkill_unregister(rbtn_data->rfkill);
+	rfkill_destroy(rbtn_data->rfkill);
+	rbtn_data->rfkill = NULL;
+}
+
+static void rbtn_rfkill_event(struct acpi_device *device)
+{
+	struct rbtn_data *rbtn_data = device->driver_data;
+
+	if (rbtn_data->rfkill)
+		rbtn_rfkill_query(rbtn_data->rfkill, device);
+}
+
+
+/*
+ * input device
+ */
+
+static int rbtn_input_init(struct rbtn_data *rbtn_data)
+{
+	int ret;
+
+	rbtn_data->input_dev = input_allocate_device();
+	if (!rbtn_data->input_dev)
+		return -ENOMEM;
+
+	rbtn_data->input_dev->name = "DELL Wireless hotkeys";
+	rbtn_data->input_dev->phys = "dellabce/input0";
+	rbtn_data->input_dev->id.bustype = BUS_HOST;
+	rbtn_data->input_dev->evbit[0] = BIT(EV_KEY);
+	set_bit(KEY_RFKILL, rbtn_data->input_dev->keybit);
+
+	ret = input_register_device(rbtn_data->input_dev);
+	if (ret) {
+		input_free_device(rbtn_data->input_dev);
+		rbtn_data->input_dev = NULL;
+		return ret;
+	}
+
+	return 0;
+}
+
+static void rbtn_input_exit(struct rbtn_data *rbtn_data)
+{
+	input_unregister_device(rbtn_data->input_dev);
+	rbtn_data->input_dev = NULL;
+}
+
+static void rbtn_input_event(struct rbtn_data *rbtn_data)
+{
+	input_report_key(rbtn_data->input_dev, KEY_RFKILL, 1);
+	input_sync(rbtn_data->input_dev);
+	input_report_key(rbtn_data->input_dev, KEY_RFKILL, 0);
+	input_sync(rbtn_data->input_dev);
+}
+
+
+/*
+ * acpi driver
+ */
+
+static int rbtn_add(struct acpi_device *device);
+static int rbtn_remove(struct acpi_device *device);
+static void rbtn_notify(struct acpi_device *device, u32 event);
+
+static const struct acpi_device_id rbtn_ids[] = {
+	{ "DELRBTN", 0 },
+	{ "DELLABCE", 0 },
+	{ "", 0 },
+};
+
+static struct acpi_driver rbtn_driver = {
+	.name = "dell-rbtn",
+	.ids = rbtn_ids,
+	.ops = {
+		.add = rbtn_add,
+		.remove = rbtn_remove,
+		.notify = rbtn_notify,
+	},
+	.owner = THIS_MODULE,
+};
+
+
+/*
+ * acpi driver functions
+ */
+
+static int rbtn_add(struct acpi_device *device)
+{
+	struct rbtn_data *rbtn_data;
+	enum rbtn_type type;
+	int ret = 0;
+
+	type = rbtn_check(device);
+	if (type == RBTN_UNKNOWN) {
+		dev_info(&device->dev, "Unknown device type\n");
+		return -EINVAL;
+	}
+
+	ret = rbtn_acquire(device, true);
+	if (ret < 0) {
+		dev_err(&device->dev, "Cannot enable device\n");
+		return ret;
+	}
+
+	rbtn_data = devm_kzalloc(&device->dev, sizeof(*rbtn_data), GFP_KERNEL);
+	if (!rbtn_data)
+		return -ENOMEM;
+
+	rbtn_data->type = type;
+	device->driver_data = rbtn_data;
+
+	switch (rbtn_data->type) {
+	case RBTN_TOGGLE:
+		ret = rbtn_input_init(rbtn_data);
+		break;
+	case RBTN_SLIDER:
+		ret = rbtn_rfkill_init(device);
+		break;
+	default:
+		ret = -EINVAL;
+	}
+
+	return ret;
+
+}
+
+static int rbtn_remove(struct acpi_device *device)
+{
+	struct rbtn_data *rbtn_data = device->driver_data;
+
+	switch (rbtn_data->type) {
+	case RBTN_TOGGLE:
+		rbtn_input_exit(rbtn_data);
+		break;
+	case RBTN_SLIDER:
+		rbtn_rfkill_exit(device);
+		break;
+	default:
+		break;
+	}
+
+	rbtn_acquire(device, false);
+	device->driver_data = NULL;
+
+	return 0;
+}
+
+static void rbtn_notify(struct acpi_device *device, u32 event)
+{
+	struct rbtn_data *rbtn_data = device->driver_data;
+
+	if (event != 0x80) {
+		dev_info(&device->dev, "Received unknown event (0x%x)\n",
+			 event);
+		return;
+	}
+
+	switch (rbtn_data->type) {
+	case RBTN_TOGGLE:
+		rbtn_input_event(rbtn_data);
+		break;
+	case RBTN_SLIDER:
+		rbtn_rfkill_event(device);
+		break;
+	default:
+		break;
+	}
+}
+
+
+/*
+ * module functions
+ */
+
+module_acpi_driver(rbtn_driver);
+
+MODULE_DEVICE_TABLE(acpi, rbtn_ids);
+MODULE_DESCRIPTION("Dell Airplane Mode Switch driver");
+MODULE_AUTHOR("Pali Rohár <pali.rohar@gmail.com>");
+MODULE_LICENSE("GPL");
-- 
1.7.9.5

[PATCH v4 2/3] dell-rbtn: Export notifier for other kernel modules

[Pali Rohár]

This patch exports notifier functions so other modules can receive HW
switch events. By default when some module register notifier, dell-rbtn
driver automatically remove rfkill interfaces from system (it is expected
that other module will use events for other rfkill interface). This
behaviour can be changed with new module parameter "auto_remove_rfkill".

This patch is designed for dell-laptop module for receiving those events.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>

Cleanup MODULE_PARM_DESC formatting and grammar.

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
---
Changes for v4:
 - check for RBTN_SLIDER in rbtn_switch_dev()
 - remove #ifdef CONFIG_DELL_RBTN guards in dell-rbtn.h (not needed anymore)
 - do not ignore error code in module_init() (now in module_acpi_driver())
---
 drivers/platform/x86/dell-rbtn.c |   93 +++++++++++++++++++++++++++++++++++++-
 drivers/platform/x86/dell-rbtn.h |   24 ++++++++++
 2 files changed, 116 insertions(+), 1 deletion(-)
 create mode 100644 drivers/platform/x86/dell-rbtn.h

diff --git a/drivers/platform/x86/dell-rbtn.c b/drivers/platform/x86/dell-rbtn.c
index 1c19fff..cd410e3 100644
--- a/drivers/platform/x86/dell-rbtn.c
+++ b/drivers/platform/x86/dell-rbtn.c
@@ -233,6 +233,86 @@ static struct acpi_driver rbtn_driver = {
 
 
 /*
+ * notifier export functions
+ */
+
+static bool auto_remove_rfkill = true;
+
+static ATOMIC_NOTIFIER_HEAD(rbtn_chain_head);
+
+static int rbtn_inc_count(struct device *dev, void *data)
+{
+	struct acpi_device *device = to_acpi_device(dev);
+	struct rbtn_data *rbtn_data = device->driver_data;
+	int *count = data;
+
+	if (rbtn_data->type == RBTN_SLIDER)
+		(*count)++;
+
+	return 0;
+}
+
+static int rbtn_switch_dev(struct device *dev, void *data)
+{
+	struct acpi_device *device = to_acpi_device(dev);
+	struct rbtn_data *rbtn_data = device->driver_data;
+	bool enable = data;
+
+	if (rbtn_data->type != RBTN_SLIDER)
+		return 0;
+
+	if (enable)
+		rbtn_rfkill_init(device);
+	else
+		rbtn_rfkill_exit(device);
+
+	return 0;
+}
+
+int dell_rbtn_notifier_register(struct notifier_block *nb)
+{
+	bool first;
+	int count;
+	int ret;
+
+	count = 0;
+	ret = driver_for_each_device(&rbtn_driver.drv, NULL, &count,
+				     rbtn_inc_count);
+	if (ret || count == 0)
+		return -ENODEV;
+
+	first = !rbtn_chain_head.head;
+
+	ret = atomic_notifier_chain_register(&rbtn_chain_head, nb);
+	if (ret != 0)
+		return ret;
+
+	if (auto_remove_rfkill && first)
+		ret = driver_for_each_device(&rbtn_driver.drv, NULL,
+					     (void *)false, rbtn_switch_dev);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(dell_rbtn_notifier_register);
+
+int dell_rbtn_notifier_unregister(struct notifier_block *nb)
+{
+	int ret;
+
+	ret = atomic_notifier_chain_unregister(&rbtn_chain_head, nb);
+	if (ret != 0)
+		return ret;
+
+	if (auto_remove_rfkill && !rbtn_chain_head.head)
+		ret = driver_for_each_device(&rbtn_driver.drv, NULL,
+					     (void *)true, rbtn_switch_dev);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(dell_rbtn_notifier_unregister);
+
+
+/*
  * acpi driver functions
  */
 
@@ -266,7 +346,10 @@ static int rbtn_add(struct acpi_device *device)
 		ret = rbtn_input_init(rbtn_data);
 		break;
 	case RBTN_SLIDER:
-		ret = rbtn_rfkill_init(device);
+		if (auto_remove_rfkill && rbtn_chain_head.head)
+			ret = 0;
+		else
+			ret = rbtn_rfkill_init(device);
 		break;
 	default:
 		ret = -EINVAL;
@@ -313,6 +396,7 @@ static void rbtn_notify(struct acpi_device *device, u32 event)
 		break;
 	case RBTN_SLIDER:
 		rbtn_rfkill_event(device);
+		atomic_notifier_call_chain(&rbtn_chain_head, event, device);
 		break;
 	default:
 		break;
@@ -326,6 +410,13 @@ static void rbtn_notify(struct acpi_device *device, u32 event)
 
 module_acpi_driver(rbtn_driver);
 
+module_param(auto_remove_rfkill, bool, 0444);
+
+MODULE_PARM_DESC(auto_remove_rfkill, "Automatically remove rfkill devices when "
+				     "other modules start receiving events "
+				     "from this module and re-add them when "
+				     "the last module stops receiving events "
+				     "(default true)");
 MODULE_DEVICE_TABLE(acpi, rbtn_ids);
 MODULE_DESCRIPTION("Dell Airplane Mode Switch driver");
 MODULE_AUTHOR("Pali Rohár <pali.rohar@gmail.com>");
diff --git a/drivers/platform/x86/dell-rbtn.h b/drivers/platform/x86/dell-rbtn.h
new file mode 100644
index 0000000..c59cc6b
--- /dev/null
+++ b/drivers/platform/x86/dell-rbtn.h
@@ -0,0 +1,24 @@
+/*
+    Dell Airplane Mode Switch driver
+    Copyright (C) 2014-2015  Pali Rohár <pali.rohar@gmail.com>
+
+    This program is free software; you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+*/
+
+#ifndef _DELL_RBTN_H_
+#define _DELL_RBTN_H_
+
+struct notifier_block;
+
+int dell_rbtn_notifier_register(struct notifier_block *nb);
+int dell_rbtn_notifier_unregister(struct notifier_block *nb);
+
+#endif
-- 
1.7.9.5

[PATCH v4 3/3] dell-laptop: Use dell-rbtn instead i8042 filter when possible

[Pali Rohár]

Until now module dell-laptop registered rfkill device which used i8042
filter function for receiving HW switch rfkill events (handling special
keycode).

But for some dell laptops there is native ACPI driver dell-rbtn which can
receive rfkill events (without i8042 hooks).

So this patch will combine best from both sides. It will use native ACPI
driver dell-rbtn for receiving events and dell-laptop SMBIOS interface for
enabling or disabling radio devices. If ACPI driver or device will not be
available fallback to i8042 filter function will be used.

Patch also changes module_init() to late_initcall() to ensure that init
function will be called after initializing dell-rbtn.c driver.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
---
Changes for v4:
 - Use symbol_request() instead hard dependency on function symbols
 - Move rfkill/rbtn/i8042 clean code to dell_cleanup_rfkill()
 - Use late_initcall() instead module_init()
 - Fix commit message and comments, spelling error fixed by aspell
---
 drivers/platform/x86/dell-laptop.c |   91 ++++++++++++++++++++++++++++++++----
 1 file changed, 83 insertions(+), 8 deletions(-)

diff --git a/drivers/platform/x86/dell-laptop.c b/drivers/platform/x86/dell-laptop.c
index d688d80..be4e425 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -32,6 +32,7 @@
 #include <linux/debugfs.h>
 #include <linux/seq_file.h>
 #include "../../firmware/dcdbas.h"
+#include "dell-rbtn.h"
 
 #define BRIGHTNESS_TOKEN 0x7d
 #define KBD_LED_OFF_TOKEN 0x01E1
@@ -642,6 +643,20 @@ static bool dell_laptop_i8042_filter(unsigned char data, unsigned char str,
 	return false;
 }
 
+static int (*dell_rbtn_notifier_register_func)(struct notifier_block *);
+static int (*dell_rbtn_notifier_unregister_func)(struct notifier_block *);
+
+static int dell_laptop_rbtn_notifier_call(struct notifier_block *nb,
+					  unsigned long action, void *data)
+{
+	schedule_delayed_work(&dell_rfkill_work, 0);
+	return NOTIFY_OK;
+}
+
+static struct notifier_block dell_laptop_rbtn_notifier = {
+	.notifier_call = dell_laptop_rbtn_notifier_call,
+};
+
 static int __init dell_setup_rfkill(void)
 {
 	int status, ret, whitelisted;
@@ -718,10 +733,59 @@ static int __init dell_setup_rfkill(void)
 			goto err_wwan;
 	}
 
-	ret = i8042_install_filter(dell_laptop_i8042_filter);
-	if (ret) {
-		pr_warn("Unable to install key filter\n");
+	/*
+	 * Dell Airplane Mode Switch driver (dell-rbtn) supports ACPI devices
+	 * which can receive events from HW slider switch.
+	 *
+	 * Dell SMBIOS on whitelisted models supports controlling radio devices
+	 * but does not support receiving HW button switch events. We can use
+	 * i8042 filter hook function to receive keyboard data and handle
+	 * keycode for HW button.
+	 *
+	 * So if it is possible we will use Dell Airplane Mode Switch ACPI
+	 * driver for receiving HW events and Dell SMBIOS for setting rfkill
+	 * states. If ACPI driver or device is not available we will fallback to
+	 * i8042 filter hook function.
+	 *
+	 * To prevent duplicate rfkill devices which control and do same thing,
+	 * dell-rbtn driver will automatically remove its own rfkill devices
+	 * once function dell_rbtn_notifier_register() is called.
+	 */
+
+	dell_rbtn_notifier_register_func = symbol_request(dell_rbtn_notifier_register);
+	if ( dell_rbtn_notifier_register_func ) {
+		dell_rbtn_notifier_unregister_func = symbol_request(dell_rbtn_notifier_unregister);
+		if ( ! dell_rbtn_notifier_unregister_func ) {
+			symbol_put(dell_rbtn_notifier_register);
+			dell_rbtn_notifier_register_func = NULL;
+		}
+	}
+
+	if (dell_rbtn_notifier_register_func) {
+		ret = dell_rbtn_notifier_register_func(&dell_laptop_rbtn_notifier);
+		symbol_put(dell_rbtn_notifier_register);
+		dell_rbtn_notifier_register_func = NULL;
+		if (ret != 0) {
+			symbol_put(dell_rbtn_notifier_unregister);
+			dell_rbtn_notifier_unregister_func = NULL;
+		}
+	} else {
+		pr_info("Symbols from dell-rbtn acpi driver are not available\n");
+		ret = -ENODEV;
+	}
+
+	if (ret == 0) {
+		pr_info("Using dell-rbtn acpi driver for receiving events\n");
+	} else if (ret != -ENODEV) {
+		pr_warn("Unable to register dell rbtn notifier\n");
 		goto err_filter;
+	} else {
+		ret = i8042_install_filter(dell_laptop_i8042_filter);
+		if (ret) {
+			pr_warn("Unable to install key filter\n");
+			goto err_filter;
+		}
+		pr_info("Using i8042 filter function for receiving events\n");
 	}
 
 	return 0;
@@ -744,6 +808,14 @@ err_wifi:
 
 static void dell_cleanup_rfkill(void)
 {
+	if (dell_rbtn_notifier_unregister_func) {
+		dell_rbtn_notifier_unregister_func(&dell_laptop_rbtn_notifier);
+		symbol_put(dell_rbtn_notifier_unregister);
+		dell_rbtn_notifier_unregister_func = NULL;
+	} else {
+		i8042_remove_filter(dell_laptop_i8042_filter);
+	}
+	cancel_delayed_work_sync(&dell_rfkill_work);
 	if (wifi_rfkill) {
 		rfkill_unregister(wifi_rfkill);
 		rfkill_destroy(wifi_rfkill);
@@ -1961,8 +2033,6 @@ static int __init dell_init(void)
 	return 0;
 
 fail_backlight:
-	i8042_remove_filter(dell_laptop_i8042_filter);
-	cancel_delayed_work_sync(&dell_rfkill_work);
 	dell_cleanup_rfkill();
 fail_rfkill:
 	free_page((unsigned long)bufferpage);
@@ -1983,8 +2053,6 @@ static void __exit dell_exit(void)
 	if (quirks && quirks->touchpad_led)
 		touchpad_led_exit();
 	kbd_led_exit();
-	i8042_remove_filter(dell_laptop_i8042_filter);
-	cancel_delayed_work_sync(&dell_rfkill_work);
 	backlight_device_unregister(dell_backlight_device);
 	dell_cleanup_rfkill();
 	if (platform_device) {
@@ -1995,7 +2063,14 @@ static void __exit dell_exit(void)
 	free_page((unsigned long)buffer);
 }
 
-module_init(dell_init);
+/* dell-rbtn.c driver export functions which will not work correctly (and could
+ * cause kernel crash) if they are called before dell-rbtn.c init code. This is
+ * not problem when dell-rbtn.c is compiled as external module. When both files
+ * (dell-rbtn.c and dell-laptop.c) are compiled statically into kernel, then we
+ * need to ensure that dell_init() will be called after initializing dell-rbtn.
+ * This can be achieved by late_initcall() instead module_init().
+ */
+late_initcall(dell_init);
 module_exit(dell_exit);
 
 MODULE_AUTHOR("Matthew Garrett <mjg@redhat.com>");
-- 
1.7.9.5

Re: [PATCH v4 3/3] dell-laptop: Use dell-rbtn instead i8042 filter when possible

[Darren Hart]

On Wed, May 27, 2015 at 11:28:25PM +0200, Pali Rohár wrote:
> Until now module dell-laptop registered rfkill device which used i8042
> filter function for receiving HW switch rfkill events (handling special
> keycode).
> 
> But for some dell laptops there is native ACPI driver dell-rbtn which can
> receive rfkill events (without i8042 hooks).
> 
> So this patch will combine best from both sides. It will use native ACPI
> driver dell-rbtn for receiving events and dell-laptop SMBIOS interface for
> enabling or disabling radio devices. If ACPI driver or device will not be
> available fallback to i8042 filter function will be used.
> 
> Patch also changes module_init() to late_initcall() to ensure that init
> function will be called after initializing dell-rbtn.c driver.
> 
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
> Signed-off-by: Darren Hart <dvhart@linux.intel.com>


Several basic checkpatch.pl errors in this one. Please always run checkpatch.pl
before submitting patches, these sorts of issues should be caught before hitting
the mailing list.

Please provide some details on the scenarios you have tested to verify you have
addressed the build and runtime issues reported.

Thanks,

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH v4 3/3] dell-laptop: Use dell-rbtn instead i8042 filter when possible

[Darren Hart]

On Wed, May 27, 2015 at 07:52:13PM -0700, Darren Hart wrote:
> On Wed, May 27, 2015 at 11:28:25PM +0200, Pali Rohár wrote:
> > Until now module dell-laptop registered rfkill device which used i8042
> > filter function for receiving HW switch rfkill events (handling special
> > keycode).
> > 
> > But for some dell laptops there is native ACPI driver dell-rbtn which can
> > receive rfkill events (without i8042 hooks).
> > 
> > So this patch will combine best from both sides. It will use native ACPI
> > driver dell-rbtn for receiving events and dell-laptop SMBIOS interface for
> > enabling or disabling radio devices. If ACPI driver or device will not be
> > available fallback to i8042 filter function will be used.
> > 
> > Patch also changes module_init() to late_initcall() to ensure that init
> > function will be called after initializing dell-rbtn.c driver.
> > 
> > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
> > Signed-off-by: Darren Hart <dvhart@linux.intel.com>
> 
> 
> Several basic checkpatch.pl errors in this one. Please always run checkpatch.pl
> before submitting patches, these sorts of issues should be caught before hitting
> the mailing list.
> 
> Please provide some details on the scenarios you have tested to verify you have
> addressed the build and runtime issues reported.
> 

Checking in so this doesn't fall through the cracks. Do you have a v5 in the
works for the 4.2 merge window?

Thanks,

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH v4 3/3] dell-laptop: Use dell-rbtn instead i8042 filter when possible

[Pali Rohár]

On Tuesday 02 June 2015 20:55:05 Darren Hart wrote:
> On Wed, May 27, 2015 at 07:52:13PM -0700, Darren Hart wrote:
> > On Wed, May 27, 2015 at 11:28:25PM +0200, Pali Rohár wrote:
> > > Until now module dell-laptop registered rfkill device which used i8042
> > > filter function for receiving HW switch rfkill events (handling special
> > > keycode).
> > > 
> > > But for some dell laptops there is native ACPI driver dell-rbtn which can
> > > receive rfkill events (without i8042 hooks).
> > > 
> > > So this patch will combine best from both sides. It will use native ACPI
> > > driver dell-rbtn for receiving events and dell-laptop SMBIOS interface for
> > > enabling or disabling radio devices. If ACPI driver or device will not be
> > > available fallback to i8042 filter function will be used.
> > > 
> > > Patch also changes module_init() to late_initcall() to ensure that init
> > > function will be called after initializing dell-rbtn.c driver.
> > > 
> > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > > Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
> > > Signed-off-by: Darren Hart <dvhart@linux.intel.com>
> > 
> > 
> > Several basic checkpatch.pl errors in this one. Please always run checkpatch.pl
> > before submitting patches, these sorts of issues should be caught before hitting
> > the mailing list.
> > 
> > Please provide some details on the scenarios you have tested to verify you have
> > addressed the build and runtime issues reported.
> > 
> 
> Checking in so this doesn't fall through the cracks. Do you have a v5 in the
> works for the 4.2 merge window?
> 
> Thanks,
> 

In last days I did not have time to look at it... When do you need to
see v5 if it could go to 4.2?

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

Re: [PATCH v4 3/3] dell-laptop: Use dell-rbtn instead i8042 filter when possible

[Darren Hart]

On Wed, Jun 03, 2015 at 10:15:09AM +0200, Pali Rohár wrote:
> On Tuesday 02 June 2015 20:55:05 Darren Hart wrote:
> > On Wed, May 27, 2015 at 07:52:13PM -0700, Darren Hart wrote:
> > > On Wed, May 27, 2015 at 11:28:25PM +0200, Pali Rohár wrote:
> > > > Until now module dell-laptop registered rfkill device which used i8042
> > > > filter function for receiving HW switch rfkill events (handling special
> > > > keycode).
> > > > 
> > > > But for some dell laptops there is native ACPI driver dell-rbtn which can
> > > > receive rfkill events (without i8042 hooks).
> > > > 
> > > > So this patch will combine best from both sides. It will use native ACPI
> > > > driver dell-rbtn for receiving events and dell-laptop SMBIOS interface for
> > > > enabling or disabling radio devices. If ACPI driver or device will not be
> > > > available fallback to i8042 filter function will be used.
> > > > 
> > > > Patch also changes module_init() to late_initcall() to ensure that init
> > > > function will be called after initializing dell-rbtn.c driver.
> > > > 
> > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > > > Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
> > > > Signed-off-by: Darren Hart <dvhart@linux.intel.com>
> > > 
> > > 
> > > Several basic checkpatch.pl errors in this one. Please always run checkpatch.pl
> > > before submitting patches, these sorts of issues should be caught before hitting
> > > the mailing list.
> > > 
> > > Please provide some details on the scenarios you have tested to verify you have
> > > addressed the build and runtime issues reported.
> > > 
> > 
> > Checking in so this doesn't fall through the cracks. Do you have a v5 in the
> > works for the 4.2 merge window?
> > 
> > Thanks,
> > 
> 
> In last days I did not have time to look at it... When do you need to
> see v5 if it could go to 4.2?

No rush in general, I just wanted to make sure you weren't waiting on me while I
was waiting for you.

We're at the mercy of Linus' decision regarding how many RCs before he releases
4.1. I suspect we have another week, but it could be this weekend.

I like to have new functionality in linux-next for two weeks prior to sending a
pull to Linus. To meet that, you should really have it in this weekend. If Linus
releases 4.1 this weekend, that will just barely make two weeks before the end
of the merge window.

Thanks,

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH v4 3/3] dell-laptop: Use dell-rbtn instead i8042 filter when possible

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 2699 bytes --]

On Thursday 04 June 2015 07:16:55 Darren Hart wrote:
> On Wed, Jun 03, 2015 at 10:15:09AM +0200, Pali Rohár wrote:
> > On Tuesday 02 June 2015 20:55:05 Darren Hart wrote:
> > > On Wed, May 27, 2015 at 07:52:13PM -0700, Darren Hart wrote:
> > > > On Wed, May 27, 2015 at 11:28:25PM +0200, Pali Rohár wrote:
> > > > > Until now module dell-laptop registered rfkill device which
> > > > > used i8042 filter function for receiving HW switch rfkill
> > > > > events (handling special keycode).
> > > > > 
> > > > > But for some dell laptops there is native ACPI driver
> > > > > dell-rbtn which can receive rfkill events (without i8042
> > > > > hooks).
> > > > > 
> > > > > So this patch will combine best from both sides. It will use
> > > > > native ACPI driver dell-rbtn for receiving events and
> > > > > dell-laptop SMBIOS interface for enabling or disabling radio
> > > > > devices. If ACPI driver or device will not be available
> > > > > fallback to i8042 filter function will be used.
> > > > > 
> > > > > Patch also changes module_init() to late_initcall() to ensure
> > > > > that init function will be called after initializing
> > > > > dell-rbtn.c driver.
> > > > > 
> > > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > > > > Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
> > > > > Signed-off-by: Darren Hart <dvhart@linux.intel.com>
> > > > 
> > > > Several basic checkpatch.pl errors in this one. Please always
> > > > run checkpatch.pl before submitting patches, these sorts of
> > > > issues should be caught before hitting the mailing list.
> > > > 
> > > > Please provide some details on the scenarios you have tested to
> > > > verify you have addressed the build and runtime issues
> > > > reported.
> > > 
> > > Checking in so this doesn't fall through the cracks. Do you have
> > > a v5 in the works for the 4.2 merge window?
> > > 
> > > Thanks,
> > 
> > In last days I did not have time to look at it... When do you need
> > to see v5 if it could go to 4.2?
> 
> No rush in general, I just wanted to make sure you weren't waiting on
> me while I was waiting for you.
> 
> We're at the mercy of Linus' decision regarding how many RCs before
> he releases 4.1. I suspect we have another week, but it could be
> this weekend.
> 
> I like to have new functionality in linux-next for two weeks prior to
> sending a pull to Linus. To meet that, you should really have it in
> this weekend. If Linus releases 4.1 this weekend, that will just
> barely make two weeks before the end of the merge window.
> 
> Thanks,

v5 with fixed checkpatch.pl problems was sent.

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[PATCH v5 0/3] Dell Airplane Mode Switch driver

[Pali Rohár]

This patch series add new acpi Dell Airplane Mode Switch driver (DELLABCE and
DELRBTN acpi devices). It provides radio HW switch events (together with current
state of radio devices) and export them via rfkill interface. These events are
also used in dell-laptop driver instead i8042 filter hook function (when acpi
device is available).

In v2 was added support for laptops which have toggle button instead HW slider
switch. For that I reused code done by Alex Hung.

v3 is just cleanup.

In v4 was fixed dependency problems.

In v5 was fixed checkpatch.pl problems.

Pali Rohár (3):
  dell-rbtn: Dell Airplane Mode Switch driver
  dell-rbtn: Export notifier for other kernel modules
  dell-laptop: Use dell-rbtn instead i8042 filter when possible

 MAINTAINERS                        |    5 +
 drivers/platform/x86/Kconfig       |   16 ++
 drivers/platform/x86/Makefile      |    1 +
 drivers/platform/x86/dell-laptop.c |   94 +++++++-
 drivers/platform/x86/dell-rbtn.c   |  423 ++++++++++++++++++++++++++++++++++++
 drivers/platform/x86/dell-rbtn.h   |   24 ++
 6 files changed, 555 insertions(+), 8 deletions(-)
 create mode 100644 drivers/platform/x86/dell-rbtn.c
 create mode 100644 drivers/platform/x86/dell-rbtn.h

-- 
1.7.9.5

[PATCH v5 1/3] dell-rbtn: Dell Airplane Mode Switch driver

[Pali Rohár]

This is an ACPI driver for Dell laptops which receive HW slider radio
switch or hotkey toggle wifi button events. It exports rfkill device
dell-rbtn (which provide correct hard rfkill state) or hotkey input device.

Alex Hung is author of original hotkey input device code.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Cc: Alex Hung <alex.hung@canonical.com>

rbtn_ops can be static

Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>

Correct multi-line comment formatting.

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
---
Changes for v5:
* fixed commit message
---
 MAINTAINERS                      |    5 +
 drivers/platform/x86/Kconfig     |   16 ++
 drivers/platform/x86/Makefile    |    1 +
 drivers/platform/x86/dell-rbtn.c |  332 ++++++++++++++++++++++++++++++++++++++
 4 files changed, 354 insertions(+)
 create mode 100644 drivers/platform/x86/dell-rbtn.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 2e5bbc0..5808066 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3071,6 +3071,11 @@ L:	platform-driver-x86@vger.kernel.org
 S:	Maintained
 F:	drivers/platform/x86/dell-laptop.c
 
+DELL LAPTOP RBTN DRIVER
+M:	Pali Rohár <pali.rohar@gmail.com>
+S:	Maintained
+F:	drivers/platform/x86/dell-rbtn.*
+
 DELL LAPTOP FREEFALL DRIVER
 M:	Pali Rohár <pali.rohar@gmail.com>
 S:	Maintained
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 399085d..bca0aee 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -138,6 +138,22 @@ config DELL_SMO8800
 	  To compile this driver as a module, choose M here: the module will
 	  be called dell-smo8800.
 
+config DELL_RBTN
+	tristate "Dell Airplane Mode Switch driver"
+	depends on ACPI
+	depends on INPUT
+	depends on RFKILL
+	---help---
+	  Say Y here if you want to support Dell Airplane Mode Switch ACPI
+	  device on Dell laptops. Sometimes it has names: DELLABCE or DELRBTN.
+	  This driver register rfkill device or input hotkey device depending
+	  on hardware type (hw switch slider or keyboard toggle button). For
+	  rfkill devices it receive HW switch events and set correct hard
+	  rfkill state.
+
+	  To compile this driver as a module, choose M here: the module will
+	  be called dell-rbtn.
+
 
 config FUJITSU_LAPTOP
 	tristate "Fujitsu Laptop Extras"
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index f82232b..b3e54ed 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_DELL_LAPTOP)	+= dell-laptop.o
 obj-$(CONFIG_DELL_WMI)		+= dell-wmi.o
 obj-$(CONFIG_DELL_WMI_AIO)	+= dell-wmi-aio.o
 obj-$(CONFIG_DELL_SMO8800)	+= dell-smo8800.o
+obj-$(CONFIG_DELL_RBTN)		+= dell-rbtn.o
 obj-$(CONFIG_ACER_WMI)		+= acer-wmi.o
 obj-$(CONFIG_ACERHDF)		+= acerhdf.o
 obj-$(CONFIG_HP_ACCEL)		+= hp_accel.o
diff --git a/drivers/platform/x86/dell-rbtn.c b/drivers/platform/x86/dell-rbtn.c
new file mode 100644
index 0000000..1c19fff
--- /dev/null
+++ b/drivers/platform/x86/dell-rbtn.c
@@ -0,0 +1,332 @@
+/*
+    Dell Airplane Mode Switch driver
+    Copyright (C) 2014-2015  Pali Rohár <pali.rohar@gmail.com>
+
+    This program is free software; you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+*/
+
+#include <linux/module.h>
+#include <linux/acpi.h>
+#include <linux/rfkill.h>
+#include <linux/input.h>
+
+enum rbtn_type {
+	RBTN_UNKNOWN,
+	RBTN_TOGGLE,
+	RBTN_SLIDER,
+};
+
+struct rbtn_data {
+	enum rbtn_type type;
+	struct rfkill *rfkill;
+	struct input_dev *input_dev;
+};
+
+
+/*
+ * acpi functions
+ */
+
+static enum rbtn_type rbtn_check(struct acpi_device *device)
+{
+	unsigned long long output;
+	acpi_status status;
+
+	status = acpi_evaluate_integer(device->handle, "CRBT", NULL, &output);
+	if (ACPI_FAILURE(status))
+		return RBTN_UNKNOWN;
+
+	switch (output) {
+	case 0:
+	case 1:
+		return RBTN_TOGGLE;
+	case 2:
+	case 3:
+		return RBTN_SLIDER;
+	default:
+		return RBTN_UNKNOWN;
+	}
+}
+
+static int rbtn_get(struct acpi_device *device)
+{
+	unsigned long long output;
+	acpi_status status;
+
+	status = acpi_evaluate_integer(device->handle, "GRBT", NULL, &output);
+	if (ACPI_FAILURE(status))
+		return -EINVAL;
+
+	return !output;
+}
+
+static int rbtn_acquire(struct acpi_device *device, bool enable)
+{
+	struct acpi_object_list input;
+	union acpi_object param;
+	acpi_status status;
+
+	param.type = ACPI_TYPE_INTEGER;
+	param.integer.value = enable;
+	input.count = 1;
+	input.pointer = &param;
+
+	status = acpi_evaluate_object(device->handle, "ARBT", &input, NULL);
+	if (ACPI_FAILURE(status))
+		return -EINVAL;
+
+	return 0;
+}
+
+
+/*
+ * rfkill device
+ */
+
+static void rbtn_rfkill_query(struct rfkill *rfkill, void *data)
+{
+	struct acpi_device *device = data;
+	int state;
+
+	state = rbtn_get(device);
+	if (state < 0)
+		return;
+
+	rfkill_set_states(rfkill, state, state);
+}
+
+static int rbtn_rfkill_set_block(void *data, bool blocked)
+{
+	/* NOTE: setting soft rfkill state is not supported */
+	return -EINVAL;
+}
+
+static struct rfkill_ops rbtn_ops = {
+	.query = rbtn_rfkill_query,
+	.set_block = rbtn_rfkill_set_block,
+};
+
+static int rbtn_rfkill_init(struct acpi_device *device)
+{
+	struct rbtn_data *rbtn_data = device->driver_data;
+	int ret;
+
+	if (rbtn_data->rfkill)
+		return 0;
+
+	/*
+	 * NOTE: rbtn controls all radio devices, not only WLAN
+	 *       but rfkill interface does not support "ANY" type
+	 *       so "WLAN" type is used
+	 */
+	rbtn_data->rfkill = rfkill_alloc("dell-rbtn", &device->dev,
+					 RFKILL_TYPE_WLAN, &rbtn_ops, device);
+	if (!rbtn_data->rfkill)
+		return -ENOMEM;
+
+	ret = rfkill_register(rbtn_data->rfkill);
+	if (ret) {
+		rfkill_destroy(rbtn_data->rfkill);
+		rbtn_data->rfkill = NULL;
+		return ret;
+	}
+
+	return 0;
+}
+
+static void rbtn_rfkill_exit(struct acpi_device *device)
+{
+	struct rbtn_data *rbtn_data = device->driver_data;
+
+	if (!rbtn_data->rfkill)
+		return;
+
+	rfkill_unregister(rbtn_data->rfkill);
+	rfkill_destroy(rbtn_data->rfkill);
+	rbtn_data->rfkill = NULL;
+}
+
+static void rbtn_rfkill_event(struct acpi_device *device)
+{
+	struct rbtn_data *rbtn_data = device->driver_data;
+
+	if (rbtn_data->rfkill)
+		rbtn_rfkill_query(rbtn_data->rfkill, device);
+}
+
+
+/*
+ * input device
+ */
+
+static int rbtn_input_init(struct rbtn_data *rbtn_data)
+{
+	int ret;
+
+	rbtn_data->input_dev = input_allocate_device();
+	if (!rbtn_data->input_dev)
+		return -ENOMEM;
+
+	rbtn_data->input_dev->name = "DELL Wireless hotkeys";
+	rbtn_data->input_dev->phys = "dellabce/input0";
+	rbtn_data->input_dev->id.bustype = BUS_HOST;
+	rbtn_data->input_dev->evbit[0] = BIT(EV_KEY);
+	set_bit(KEY_RFKILL, rbtn_data->input_dev->keybit);
+
+	ret = input_register_device(rbtn_data->input_dev);
+	if (ret) {
+		input_free_device(rbtn_data->input_dev);
+		rbtn_data->input_dev = NULL;
+		return ret;
+	}
+
+	return 0;
+}
+
+static void rbtn_input_exit(struct rbtn_data *rbtn_data)
+{
+	input_unregister_device(rbtn_data->input_dev);
+	rbtn_data->input_dev = NULL;
+}
+
+static void rbtn_input_event(struct rbtn_data *rbtn_data)
+{
+	input_report_key(rbtn_data->input_dev, KEY_RFKILL, 1);
+	input_sync(rbtn_data->input_dev);
+	input_report_key(rbtn_data->input_dev, KEY_RFKILL, 0);
+	input_sync(rbtn_data->input_dev);
+}
+
+
+/*
+ * acpi driver
+ */
+
+static int rbtn_add(struct acpi_device *device);
+static int rbtn_remove(struct acpi_device *device);
+static void rbtn_notify(struct acpi_device *device, u32 event);
+
+static const struct acpi_device_id rbtn_ids[] = {
+	{ "DELRBTN", 0 },
+	{ "DELLABCE", 0 },
+	{ "", 0 },
+};
+
+static struct acpi_driver rbtn_driver = {
+	.name = "dell-rbtn",
+	.ids = rbtn_ids,
+	.ops = {
+		.add = rbtn_add,
+		.remove = rbtn_remove,
+		.notify = rbtn_notify,
+	},
+	.owner = THIS_MODULE,
+};
+
+
+/*
+ * acpi driver functions
+ */
+
+static int rbtn_add(struct acpi_device *device)
+{
+	struct rbtn_data *rbtn_data;
+	enum rbtn_type type;
+	int ret = 0;
+
+	type = rbtn_check(device);
+	if (type == RBTN_UNKNOWN) {
+		dev_info(&device->dev, "Unknown device type\n");
+		return -EINVAL;
+	}
+
+	ret = rbtn_acquire(device, true);
+	if (ret < 0) {
+		dev_err(&device->dev, "Cannot enable device\n");
+		return ret;
+	}
+
+	rbtn_data = devm_kzalloc(&device->dev, sizeof(*rbtn_data), GFP_KERNEL);
+	if (!rbtn_data)
+		return -ENOMEM;
+
+	rbtn_data->type = type;
+	device->driver_data = rbtn_data;
+
+	switch (rbtn_data->type) {
+	case RBTN_TOGGLE:
+		ret = rbtn_input_init(rbtn_data);
+		break;
+	case RBTN_SLIDER:
+		ret = rbtn_rfkill_init(device);
+		break;
+	default:
+		ret = -EINVAL;
+	}
+
+	return ret;
+
+}
+
+static int rbtn_remove(struct acpi_device *device)
+{
+	struct rbtn_data *rbtn_data = device->driver_data;
+
+	switch (rbtn_data->type) {
+	case RBTN_TOGGLE:
+		rbtn_input_exit(rbtn_data);
+		break;
+	case RBTN_SLIDER:
+		rbtn_rfkill_exit(device);
+		break;
+	default:
+		break;
+	}
+
+	rbtn_acquire(device, false);
+	device->driver_data = NULL;
+
+	return 0;
+}
+
+static void rbtn_notify(struct acpi_device *device, u32 event)
+{
+	struct rbtn_data *rbtn_data = device->driver_data;
+
+	if (event != 0x80) {
+		dev_info(&device->dev, "Received unknown event (0x%x)\n",
+			 event);
+		return;
+	}
+
+	switch (rbtn_data->type) {
+	case RBTN_TOGGLE:
+		rbtn_input_event(rbtn_data);
+		break;
+	case RBTN_SLIDER:
+		rbtn_rfkill_event(device);
+		break;
+	default:
+		break;
+	}
+}
+
+
+/*
+ * module functions
+ */
+
+module_acpi_driver(rbtn_driver);
+
+MODULE_DEVICE_TABLE(acpi, rbtn_ids);
+MODULE_DESCRIPTION("Dell Airplane Mode Switch driver");
+MODULE_AUTHOR("Pali Rohár <pali.rohar@gmail.com>");
+MODULE_LICENSE("GPL");
-- 
1.7.9.5

[PATCH v5 2/3] dell-rbtn: Export notifier for other kernel modules

[Pali Rohár]

This patch exports notifier functions so other modules can receive HW
switch events. By default when some module register notifier, dell-rbtn
driver automatically remove rfkill interfaces from system (it is expected
that other module will use events for other rfkill interface). This
behaviour can be changed with new module parameter "auto_remove_rfkill".

This patch is designed for dell-laptop module for receiving those events.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>

Cleanup MODULE_PARM_DESC formatting and grammar.

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
---
 drivers/platform/x86/dell-rbtn.c |   93 +++++++++++++++++++++++++++++++++++++-
 drivers/platform/x86/dell-rbtn.h |   24 ++++++++++
 2 files changed, 116 insertions(+), 1 deletion(-)
 create mode 100644 drivers/platform/x86/dell-rbtn.h

diff --git a/drivers/platform/x86/dell-rbtn.c b/drivers/platform/x86/dell-rbtn.c
index 1c19fff..cd410e3 100644
--- a/drivers/platform/x86/dell-rbtn.c
+++ b/drivers/platform/x86/dell-rbtn.c
@@ -233,6 +233,86 @@ static struct acpi_driver rbtn_driver = {
 
 
 /*
+ * notifier export functions
+ */
+
+static bool auto_remove_rfkill = true;
+
+static ATOMIC_NOTIFIER_HEAD(rbtn_chain_head);
+
+static int rbtn_inc_count(struct device *dev, void *data)
+{
+	struct acpi_device *device = to_acpi_device(dev);
+	struct rbtn_data *rbtn_data = device->driver_data;
+	int *count = data;
+
+	if (rbtn_data->type == RBTN_SLIDER)
+		(*count)++;
+
+	return 0;
+}
+
+static int rbtn_switch_dev(struct device *dev, void *data)
+{
+	struct acpi_device *device = to_acpi_device(dev);
+	struct rbtn_data *rbtn_data = device->driver_data;
+	bool enable = data;
+
+	if (rbtn_data->type != RBTN_SLIDER)
+		return 0;
+
+	if (enable)
+		rbtn_rfkill_init(device);
+	else
+		rbtn_rfkill_exit(device);
+
+	return 0;
+}
+
+int dell_rbtn_notifier_register(struct notifier_block *nb)
+{
+	bool first;
+	int count;
+	int ret;
+
+	count = 0;
+	ret = driver_for_each_device(&rbtn_driver.drv, NULL, &count,
+				     rbtn_inc_count);
+	if (ret || count == 0)
+		return -ENODEV;
+
+	first = !rbtn_chain_head.head;
+
+	ret = atomic_notifier_chain_register(&rbtn_chain_head, nb);
+	if (ret != 0)
+		return ret;
+
+	if (auto_remove_rfkill && first)
+		ret = driver_for_each_device(&rbtn_driver.drv, NULL,
+					     (void *)false, rbtn_switch_dev);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(dell_rbtn_notifier_register);
+
+int dell_rbtn_notifier_unregister(struct notifier_block *nb)
+{
+	int ret;
+
+	ret = atomic_notifier_chain_unregister(&rbtn_chain_head, nb);
+	if (ret != 0)
+		return ret;
+
+	if (auto_remove_rfkill && !rbtn_chain_head.head)
+		ret = driver_for_each_device(&rbtn_driver.drv, NULL,
+					     (void *)true, rbtn_switch_dev);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(dell_rbtn_notifier_unregister);
+
+
+/*
  * acpi driver functions
  */
 
@@ -266,7 +346,10 @@ static int rbtn_add(struct acpi_device *device)
 		ret = rbtn_input_init(rbtn_data);
 		break;
 	case RBTN_SLIDER:
-		ret = rbtn_rfkill_init(device);
+		if (auto_remove_rfkill && rbtn_chain_head.head)
+			ret = 0;
+		else
+			ret = rbtn_rfkill_init(device);
 		break;
 	default:
 		ret = -EINVAL;
@@ -313,6 +396,7 @@ static void rbtn_notify(struct acpi_device *device, u32 event)
 		break;
 	case RBTN_SLIDER:
 		rbtn_rfkill_event(device);
+		atomic_notifier_call_chain(&rbtn_chain_head, event, device);
 		break;
 	default:
 		break;
@@ -326,6 +410,13 @@ static void rbtn_notify(struct acpi_device *device, u32 event)
 
 module_acpi_driver(rbtn_driver);
 
+module_param(auto_remove_rfkill, bool, 0444);
+
+MODULE_PARM_DESC(auto_remove_rfkill, "Automatically remove rfkill devices when "
+				     "other modules start receiving events "
+				     "from this module and re-add them when "
+				     "the last module stops receiving events "
+				     "(default true)");
 MODULE_DEVICE_TABLE(acpi, rbtn_ids);
 MODULE_DESCRIPTION("Dell Airplane Mode Switch driver");
 MODULE_AUTHOR("Pali Rohár <pali.rohar@gmail.com>");
diff --git a/drivers/platform/x86/dell-rbtn.h b/drivers/platform/x86/dell-rbtn.h
new file mode 100644
index 0000000..c59cc6b
--- /dev/null
+++ b/drivers/platform/x86/dell-rbtn.h
@@ -0,0 +1,24 @@
+/*
+    Dell Airplane Mode Switch driver
+    Copyright (C) 2014-2015  Pali Rohár <pali.rohar@gmail.com>
+
+    This program is free software; you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+*/
+
+#ifndef _DELL_RBTN_H_
+#define _DELL_RBTN_H_
+
+struct notifier_block;
+
+int dell_rbtn_notifier_register(struct notifier_block *nb);
+int dell_rbtn_notifier_unregister(struct notifier_block *nb);
+
+#endif
-- 
1.7.9.5

[PATCH v5 3/3] dell-laptop: Use dell-rbtn instead i8042 filter when possible

[Pali Rohár]

Until now module dell-laptop registered rfkill device which used i8042
filter function for receiving HW switch rfkill events (handling special
keycode).

But for some dell laptops there is native ACPI driver dell-rbtn which can
receive rfkill events (without i8042 hooks).

So this patch will combine best from both sides. It will use native ACPI
driver dell-rbtn for receiving events and dell-laptop SMBIOS interface for
enabling or disabling radio devices. If ACPI driver or device will not be
available fallback to i8042 filter function will be used.

Patch also changes module_init() to late_initcall() to ensure that init
function will be called after initializing dell-rbtn.c driver.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
---
Changes vor v5:
* fixed long lines
---
 drivers/platform/x86/dell-laptop.c |   94 +++++++++++++++++++++++++++++++++---
 1 file changed, 86 insertions(+), 8 deletions(-)

diff --git a/drivers/platform/x86/dell-laptop.c b/drivers/platform/x86/dell-laptop.c
index d688d80..83e3d7f 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -32,6 +32,7 @@
 #include <linux/debugfs.h>
 #include <linux/seq_file.h>
 #include "../../firmware/dcdbas.h"
+#include "dell-rbtn.h"
 
 #define BRIGHTNESS_TOKEN 0x7d
 #define KBD_LED_OFF_TOKEN 0x01E1
@@ -642,6 +643,20 @@ static bool dell_laptop_i8042_filter(unsigned char data, unsigned char str,
 	return false;
 }
 
+static int (*dell_rbtn_notifier_register_func)(struct notifier_block *);
+static int (*dell_rbtn_notifier_unregister_func)(struct notifier_block *);
+
+static int dell_laptop_rbtn_notifier_call(struct notifier_block *nb,
+					  unsigned long action, void *data)
+{
+	schedule_delayed_work(&dell_rfkill_work, 0);
+	return NOTIFY_OK;
+}
+
+static struct notifier_block dell_laptop_rbtn_notifier = {
+	.notifier_call = dell_laptop_rbtn_notifier_call,
+};
+
 static int __init dell_setup_rfkill(void)
 {
 	int status, ret, whitelisted;
@@ -718,10 +733,62 @@ static int __init dell_setup_rfkill(void)
 			goto err_wwan;
 	}
 
-	ret = i8042_install_filter(dell_laptop_i8042_filter);
-	if (ret) {
-		pr_warn("Unable to install key filter\n");
+	/*
+	 * Dell Airplane Mode Switch driver (dell-rbtn) supports ACPI devices
+	 * which can receive events from HW slider switch.
+	 *
+	 * Dell SMBIOS on whitelisted models supports controlling radio devices
+	 * but does not support receiving HW button switch events. We can use
+	 * i8042 filter hook function to receive keyboard data and handle
+	 * keycode for HW button.
+	 *
+	 * So if it is possible we will use Dell Airplane Mode Switch ACPI
+	 * driver for receiving HW events and Dell SMBIOS for setting rfkill
+	 * states. If ACPI driver or device is not available we will fallback to
+	 * i8042 filter hook function.
+	 *
+	 * To prevent duplicate rfkill devices which control and do same thing,
+	 * dell-rbtn driver will automatically remove its own rfkill devices
+	 * once function dell_rbtn_notifier_register() is called.
+	 */
+
+	dell_rbtn_notifier_register_func =
+		symbol_request(dell_rbtn_notifier_register);
+	if (dell_rbtn_notifier_register_func) {
+		dell_rbtn_notifier_unregister_func =
+			symbol_request(dell_rbtn_notifier_unregister);
+		if (!dell_rbtn_notifier_unregister_func) {
+			symbol_put(dell_rbtn_notifier_register);
+			dell_rbtn_notifier_register_func = NULL;
+		}
+	}
+
+	if (dell_rbtn_notifier_register_func) {
+		ret = dell_rbtn_notifier_register_func(
+			&dell_laptop_rbtn_notifier);
+		symbol_put(dell_rbtn_notifier_register);
+		dell_rbtn_notifier_register_func = NULL;
+		if (ret != 0) {
+			symbol_put(dell_rbtn_notifier_unregister);
+			dell_rbtn_notifier_unregister_func = NULL;
+		}
+	} else {
+		pr_info("Symbols from dell-rbtn acpi driver are not available\n");
+		ret = -ENODEV;
+	}
+
+	if (ret == 0) {
+		pr_info("Using dell-rbtn acpi driver for receiving events\n");
+	} else if (ret != -ENODEV) {
+		pr_warn("Unable to register dell rbtn notifier\n");
 		goto err_filter;
+	} else {
+		ret = i8042_install_filter(dell_laptop_i8042_filter);
+		if (ret) {
+			pr_warn("Unable to install key filter\n");
+			goto err_filter;
+		}
+		pr_info("Using i8042 filter function for receiving events\n");
 	}
 
 	return 0;
@@ -744,6 +811,14 @@ err_wifi:
 
 static void dell_cleanup_rfkill(void)
 {
+	if (dell_rbtn_notifier_unregister_func) {
+		dell_rbtn_notifier_unregister_func(&dell_laptop_rbtn_notifier);
+		symbol_put(dell_rbtn_notifier_unregister);
+		dell_rbtn_notifier_unregister_func = NULL;
+	} else {
+		i8042_remove_filter(dell_laptop_i8042_filter);
+	}
+	cancel_delayed_work_sync(&dell_rfkill_work);
 	if (wifi_rfkill) {
 		rfkill_unregister(wifi_rfkill);
 		rfkill_destroy(wifi_rfkill);
@@ -1961,8 +2036,6 @@ static int __init dell_init(void)
 	return 0;
 
 fail_backlight:
-	i8042_remove_filter(dell_laptop_i8042_filter);
-	cancel_delayed_work_sync(&dell_rfkill_work);
 	dell_cleanup_rfkill();
 fail_rfkill:
 	free_page((unsigned long)bufferpage);
@@ -1983,8 +2056,6 @@ static void __exit dell_exit(void)
 	if (quirks && quirks->touchpad_led)
 		touchpad_led_exit();
 	kbd_led_exit();
-	i8042_remove_filter(dell_laptop_i8042_filter);
-	cancel_delayed_work_sync(&dell_rfkill_work);
 	backlight_device_unregister(dell_backlight_device);
 	dell_cleanup_rfkill();
 	if (platform_device) {
@@ -1995,7 +2066,14 @@ static void __exit dell_exit(void)
 	free_page((unsigned long)buffer);
 }
 
-module_init(dell_init);
+/* dell-rbtn.c driver export functions which will not work correctly (and could
+ * cause kernel crash) if they are called before dell-rbtn.c init code. This is
+ * not problem when dell-rbtn.c is compiled as external module. When both files
+ * (dell-rbtn.c and dell-laptop.c) are compiled statically into kernel, then we
+ * need to ensure that dell_init() will be called after initializing dell-rbtn.
+ * This can be achieved by late_initcall() instead module_init().
+ */
+late_initcall(dell_init);
 module_exit(dell_exit);
 
 MODULE_AUTHOR("Matthew Garrett <mjg@redhat.com>");
-- 
1.7.9.5

Re: [PATCH v5 0/3] Dell Airplane Mode Switch driver

[Darren Hart]

On Sat, Jun 06, 2015 at 10:23:27AM +0200, Pali Rohár wrote:
> This patch series add new acpi Dell Airplane Mode Switch driver (DELLABCE and
> DELRBTN acpi devices). It provides radio HW switch events (together with current
> state of radio devices) and export them via rfkill interface. These events are
> also used in dell-laptop driver instead i8042 filter hook function (when acpi
> device is available).
> 
> In v2 was added support for laptops which have toggle button instead HW slider
> switch. For that I reused code done by Alex Hung.
> 
> v3 is just cleanup.
> 
> In v4 was fixed dependency problems.

Please be more specific in the future. You want people that haven't looked at
this for a couple of weeks to be able to quickly identify what changed and
confirm they agree. You want people to review your code, you want to reduce the
barrier to do so. Easy to do while it's fresh in your mind.

Thanks for the update, I have these qeueud to testing.

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH v5 0/3] Dell Airplane Mode Switch driver

[Pali Rohár]

On Sunday 07 June 2015 21:12:38 Darren Hart wrote:
> On Sat, Jun 06, 2015 at 10:23:27AM +0200, Pali Rohár wrote:
> > This patch series add new acpi Dell Airplane Mode Switch driver (DELLABCE and
> > DELRBTN acpi devices). It provides radio HW switch events (together with current
> > state of radio devices) and export them via rfkill interface. These events are
> > also used in dell-laptop driver instead i8042 filter hook function (when acpi
> > device is available).
> > 
> > In v2 was added support for laptops which have toggle button instead HW slider
> > switch. For that I reused code done by Alex Hung.
> > 
> > v3 is just cleanup.
> > 
> > In v4 was fixed dependency problems.
> 
> Please be more specific in the future. You want people that haven't looked at
> this for a couple of weeks to be able to quickly identify what changed and
> confirm they agree. You want people to review your code, you want to reduce the
> barrier to do so. Easy to do while it's fresh in your mind.
> 
> Thanks for the update, I have these qeueud to testing.
> 

I wrote more details into individual patches above diffstat lines. But
if you want detailed description also to cover letter email, I can do
that in the future...

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

Re: [PATCH v5 0/3] Dell Airplane Mode Switch driver

[Darren Hart]

On Mon, Jun 08, 2015 at 09:30:36AM +0200, Pali Rohár wrote:
> On Sunday 07 June 2015 21:12:38 Darren Hart wrote:
> > On Sat, Jun 06, 2015 at 10:23:27AM +0200, Pali Rohár wrote:
> > > This patch series add new acpi Dell Airplane Mode Switch driver (DELLABCE and
> > > DELRBTN acpi devices). It provides radio HW switch events (together with current
> > > state of radio devices) and export them via rfkill interface. These events are
> > > also used in dell-laptop driver instead i8042 filter hook function (when acpi
> > > device is available).
> > > 
> > > In v2 was added support for laptops which have toggle button instead HW slider
> > > switch. For that I reused code done by Alex Hung.
> > > 
> > > v3 is just cleanup.
> > > 
> > > In v4 was fixed dependency problems.
> > 
> > Please be more specific in the future. You want people that haven't looked at
> > this for a couple of weeks to be able to quickly identify what changed and
> > confirm they agree. You want people to review your code, you want to reduce the
> > barrier to do so. Easy to do while it's fresh in your mind.
> > 
> > Thanks for the update, I have these qeueud to testing.
> > 
> 
> I wrote more details into individual patches above diffstat lines. But
> if you want detailed description also to cover letter email, I can do
> that in the future...

The individual patches is better. It's typical to leave the entire changelog
after the ---, and not just the current version. I found what I was actually
looking for was in the v4 changelog.

It's not a huge deal, but if the goal is to get people (and not just me) to
review the code, we want to make it as easy for them as possible to get the
necessary context to start reviewing. No doubt certain maintainer may feel
differently.

-- 
Darren Hart
Intel Open Source Technology Center