All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 00/33] acpi4asus updates for 2.6.33
@ 2009-12-03  7:44 Corentin Chary
  2009-12-03  7:44 ` [PATCH 01/33] eeepc-laptop: disp attribute should be write-only Corentin Chary
  2009-12-09 21:04 ` [PATCH 00/33] acpi4asus updates for 2.6.33 Len Brown
  0 siblings, 2 replies; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:44 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Corentin Chary

Hi Len,
Here patchs from acpi4asus for 2.6.33.
You'll find a major rewrite of eeepc-laptop by Alan Jenkins which really
cleans the code. I'm working one something similar for asus-laptop, this should
be ready for 2.6.34.
There is also some fix and updates for asus-laptop and asus-acpi.
asus-laptop now support Lenovo SL laptop (yep this is strange, but this is the
same acpi interface).

There is two smalls style issues in Alan's patchs, but I made a patch to fix that
in the serie, it was easier than reworking the whole serie, but I'll try to
avoid that next time.

The last two patchs may be controversial.

The first one add the KEY_WIRELESS_CYCLE. This keycode could be used when
the key is not only for wlan, but could also be used for bluetooth and wimax.

The last schedule some asus-laptop features for removale, because they are
not defined in a standard way in the acpi interface.
Thanks,

Alan Jenkins (25):
  eeepc-laptop: disp attribute should be write-only
  asus-laptop: Remove redundant NULL checks
  asus-acpi: Remove redundant NULL checks
  asus-laptop: Remove uneccesary acpi_disabled check
  asus-acpi: Remove uneccesary acpi_disabled checks
  asus-acpi: set acpi_driver.owner
  asus-laptop: set acpi_driver.owner
  eeepc-laptop: Remove redundant NULL checks
  eeepc-laptop: Remove uneccesary acpi_disabled check
  eeepc-laptop: set acpi_driver.owner
  eeepc-laptop: fix value of pwm1_enable to match documentation
  eeepc-laptop: fix led initialization order
  eeepc-laptop: fix potential leak (led_init() failure)
  eeepc-laptop: fix set_acpi() to return non-zero on failure
  eeepc-laptop: remove redundant NULL checks
  eeepc-laptop: no need to check argument of set_brightness()
  eeepc-laptop: simplify acpi initialization
  eeepc-laptop: simplify how the hwmon device reads values from the EC
  eeepc-laptop: refactor notifications
  eeepc-laptop: move platform driver registration out of
    eeepc_hotk_add()
  eeepc-laptop: move platform device initialisation to a separate
    function
  eeepc-laptop: code movement
  eeepc-laptop: revise names
  eeepc-laptop: callbacks should use "driver data" parameter or field
  eeepc-laptop: re-add check for eeepc->backlight == NULL

Corentin Chary (7):
  eeepc-laptop: add touchpad led
  asus-laptop: use KEY_F13 to map "Disable Touchpad" event
  asus-laptop: Add wlan switch found on V6V
  eeepc-laptop: map keys found on newer eeepc
  eeepc-laptop: fix coding style
  input: add KEY_WIRELESS_CYCLE
  asus-laptop: schedule display_get and lcd_switch for removal

Ike Panhc (1):
  asus-laptop: add Lenovo SL hotkey support

 Documentation/feature-removal-schedule.txt |   20 +
 drivers/platform/x86/Kconfig               |    2 +
 drivers/platform/x86/asus-laptop.c         |   21 +-
 drivers/platform/x86/asus_acpi.c           |   19 +-
 drivers/platform/x86/eeepc-laptop.c        | 1415 +++++++++++++++------------
 include/linux/input.h                      |    1 +
 6 files changed, 825 insertions(+), 653 deletions(-)


^ permalink raw reply	[flat|nested] 55+ messages in thread

* [PATCH 01/33] eeepc-laptop: disp attribute should be write-only
  2009-12-03  7:44 [PATCH 00/33] acpi4asus updates for 2.6.33 Corentin Chary
@ 2009-12-03  7:44 ` Corentin Chary
  2009-12-03  7:44   ` [PATCH 02/33] asus-laptop: Remove redundant NULL checks Corentin Chary
  2009-12-09 21:04 ` [PATCH 00/33] acpi4asus updates for 2.6.33 Len Brown
  1 sibling, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:44 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Alan Jenkins, Corentin Chary

From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>

Currently, reading from the disp attribute fails with "No such device",
which is misleading. According to CMSG table on acpi4asus project site,
no models have a getter method corresponding to SDSP. Change the file
permission to disallow reads.

If some joker changes the permission to permit reads, then return -EIO
to be consistent with sysfs' behaviour when no show() method is
provided.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
---
 drivers/platform/x86/eeepc-laptop.c |   14 +++++++-------
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index 4226e53..2c65a37 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -380,7 +380,7 @@ static ssize_t store_sys_acpi(int cm, const char *buf, size_t count)
 	if (rv > 0)
 		value = set_acpi(cm, value);
 	if (value < 0)
-		return value;
+		return -EIO;
 	return rv;
 }
 
@@ -389,11 +389,11 @@ static ssize_t show_sys_acpi(int cm, char *buf)
 	int value = get_acpi(cm);
 
 	if (value < 0)
-		return value;
+		return -EIO;
 	return sprintf(buf, "%d\n", value);
 }
 
-#define EEEPC_CREATE_DEVICE_ATTR(_name, _cm)				\
+#define EEEPC_CREATE_DEVICE_ATTR(_name, _mode, _cm)			\
 	static ssize_t show_##_name(struct device *dev,			\
 				    struct device_attribute *attr,	\
 				    char *buf)				\
@@ -409,14 +409,14 @@ static ssize_t show_sys_acpi(int cm, char *buf)
 	static struct device_attribute dev_attr_##_name = {		\
 		.attr = {						\
 			.name = __stringify(_name),			\
-			.mode = 0644 },					\
+			.mode = _mode },				\
 		.show   = show_##_name,					\
 		.store  = store_##_name,				\
 	}
 
-EEEPC_CREATE_DEVICE_ATTR(camera, CM_ASL_CAMERA);
-EEEPC_CREATE_DEVICE_ATTR(cardr, CM_ASL_CARDREADER);
-EEEPC_CREATE_DEVICE_ATTR(disp, CM_ASL_DISPLAYSWITCH);
+EEEPC_CREATE_DEVICE_ATTR(camera, 0644, CM_ASL_CAMERA);
+EEEPC_CREATE_DEVICE_ATTR(cardr, 0644, CM_ASL_CARDREADER);
+EEEPC_CREATE_DEVICE_ATTR(disp, 0200, CM_ASL_DISPLAYSWITCH);
 
 struct eeepc_cpufv {
 	int num;
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 02/33] asus-laptop: Remove redundant NULL checks
  2009-12-03  7:44 ` [PATCH 01/33] eeepc-laptop: disp attribute should be write-only Corentin Chary
@ 2009-12-03  7:44   ` Corentin Chary
  2009-12-03  7:44     ` [PATCH 03/33] asus-acpi: " Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:44 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Alan Jenkins

From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>

The acpi device callbacks add, start, remove, suspend and resume can
never be called with a NULL acpi_device. Each callsite in acpi/scan.c
has to dereference the device in order to get the ops structure, e.g.

    struct acpi_device *acpi_dev = to_acpi_device(dev);
    struct acpi_driver *acpi_drv = acpi_dev->driver;

    if (acpi_drv && acpi_drv->ops.suspend)
        return acpi_drv->ops.suspend(acpi_dev, state);

Remove all checks for acpi_dev == NULL within these callbacks.

Also remove the checks for acpi_driver_data(acpi_dev) == NULL. None of
these checks could fail unless the driver does something strange
(which none of them do), the acpi core did something terribly wrong,
or we have a memory corruption issue. If this does happen then it's
best to dereference the pointer and crash noisily.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
 drivers/platform/x86/asus-laptop.c |    6 ------
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/drivers/platform/x86/asus-laptop.c b/drivers/platform/x86/asus-laptop.c
index b39d2bb..8af43e9 100644
--- a/drivers/platform/x86/asus-laptop.c
+++ b/drivers/platform/x86/asus-laptop.c
@@ -1240,9 +1240,6 @@ static int asus_hotk_add(struct acpi_device *device)
 {
 	int result;
 
-	if (!device)
-		return -EINVAL;
-
 	pr_notice("Asus Laptop Support version %s\n",
 	       ASUS_LAPTOP_VERSION);
 
@@ -1306,9 +1303,6 @@ end:
 
 static int asus_hotk_remove(struct acpi_device *device, int type)
 {
-	if (!device || !acpi_driver_data(device))
-		return -EINVAL;
-
 	kfree(hotk->name);
 	kfree(hotk);
 
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 03/33] asus-acpi: Remove redundant NULL checks
  2009-12-03  7:44   ` [PATCH 02/33] asus-laptop: Remove redundant NULL checks Corentin Chary
@ 2009-12-03  7:44     ` Corentin Chary
  2009-12-03  7:44       ` [PATCH 04/33] asus-laptop: Remove uneccesary acpi_disabled check Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:44 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Alan Jenkins

From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>

The acpi device callbacks add, start, remove, suspend and resume can
never be called with a NULL acpi_device. Each callsite in acpi/scan.c
has to dereference the device in order to get the ops structure, e.g.

    struct acpi_device *acpi_dev = to_acpi_device(dev);
    struct acpi_driver *acpi_drv = acpi_dev->driver;

    if (acpi_drv && acpi_drv->ops.suspend)
        return acpi_drv->ops.suspend(acpi_dev, state);

Remove all checks for acpi_dev == NULL within these callbacks.

Also remove the checks for acpi_driver_data(acpi_dev) == NULL. None of
these checks could fail unless the driver does something strange
(which none of them do), the acpi core did something terribly wrong,
or we have a memory corruption issue. If this does happen then it's
best to dereference the pointer and crash noisily.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
 drivers/platform/x86/asus_acpi.c |    6 ------
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/drivers/platform/x86/asus_acpi.c b/drivers/platform/x86/asus_acpi.c
index ddf5240..25a7d57 100644
--- a/drivers/platform/x86/asus_acpi.c
+++ b/drivers/platform/x86/asus_acpi.c
@@ -1334,9 +1334,6 @@ static int asus_hotk_add(struct acpi_device *device)
 	acpi_status status = AE_OK;
 	int result;
 
-	if (!device)
-		return -EINVAL;
-
 	printk(KERN_NOTICE "Asus Laptop ACPI Extras version %s\n",
 	       ASUS_ACPI_VERSION);
 
@@ -1392,9 +1389,6 @@ end:
 
 static int asus_hotk_remove(struct acpi_device *device, int type)
 {
-	if (!device || !acpi_driver_data(device))
-		return -EINVAL;
-
 	asus_hotk_remove_fs(device);
 
 	kfree(hotk);
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 04/33] asus-laptop: Remove uneccesary acpi_disabled check
  2009-12-03  7:44     ` [PATCH 03/33] asus-acpi: " Corentin Chary
@ 2009-12-03  7:44       ` Corentin Chary
  2009-12-03  7:44         ` [PATCH 05/33] asus-acpi: Remove uneccesary acpi_disabled checks Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:44 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Alan Jenkins

From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>

acpi_bus_register_driver() already checks acpi_disabled, so acpi bus
drivers don't need to.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
 drivers/platform/x86/asus-laptop.c |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/drivers/platform/x86/asus-laptop.c b/drivers/platform/x86/asus-laptop.c
index 8af43e9..4234edb 100644
--- a/drivers/platform/x86/asus-laptop.c
+++ b/drivers/platform/x86/asus-laptop.c
@@ -1438,9 +1438,6 @@ static int __init asus_laptop_init(void)
 {
 	int result;
 
-	if (acpi_disabled)
-		return -ENODEV;
-
 	result = acpi_bus_register_driver(&asus_hotk_driver);
 	if (result < 0)
 		return result;
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 05/33] asus-acpi: Remove uneccesary acpi_disabled checks
  2009-12-03  7:44       ` [PATCH 04/33] asus-laptop: Remove uneccesary acpi_disabled check Corentin Chary
@ 2009-12-03  7:44         ` Corentin Chary
  2009-12-03  7:44           ` [PATCH 06/33] asus-acpi: set acpi_driver.owner Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:44 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Alan Jenkins

From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>

acpi_bus_register_driver() already checks acpi_disabled, so acpi bus
drivers don't need to.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
 drivers/platform/x86/asus_acpi.c |   12 ++++--------
 1 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/platform/x86/asus_acpi.c b/drivers/platform/x86/asus_acpi.c
index 25a7d57..783243f 100644
--- a/drivers/platform/x86/asus_acpi.c
+++ b/drivers/platform/x86/asus_acpi.c
@@ -1416,21 +1416,17 @@ static int __init asus_acpi_init(void)
 {
 	int result;
 
-	if (acpi_disabled)
-		return -ENODEV;
+	result = acpi_bus_register_driver(&asus_hotk_driver);
+	if (result < 0)
+		return result;
 
 	asus_proc_dir = proc_mkdir(PROC_ASUS, acpi_root_dir);
 	if (!asus_proc_dir) {
 		printk(KERN_ERR "Asus ACPI: Unable to create /proc entry\n");
+		acpi_bus_unregister_driver(&asus_hotk_driver);
 		return -ENODEV;
 	}
 
-	result = acpi_bus_register_driver(&asus_hotk_driver);
-	if (result < 0) {
-		remove_proc_entry(PROC_ASUS, acpi_root_dir);
-		return result;
-	}
-
 	/*
 	 * This is a bit of a kludge.  We only want this module loaded
 	 * for ASUS systems, but there's currently no way to probe the
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 06/33] asus-acpi: set acpi_driver.owner
  2009-12-03  7:44         ` [PATCH 05/33] asus-acpi: Remove uneccesary acpi_disabled checks Corentin Chary
@ 2009-12-03  7:44           ` Corentin Chary
  2009-12-03  7:44             ` [PATCH 07/33] asus-laptop: " Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:44 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Alan Jenkins

From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>

The owner field provides the link between drivers and modules in sysfs,
but no ACPI driver was setting it.

After setting the owner field, we can see which module provides which
driver and vice versa by looking at /sys/bus/acpi/driver/*/module and
/sys/module/*/drivers/acpi:*.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
 drivers/platform/x86/asus_acpi.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/platform/x86/asus_acpi.c b/drivers/platform/x86/asus_acpi.c
index 783243f..0c9c531 100644
--- a/drivers/platform/x86/asus_acpi.c
+++ b/drivers/platform/x86/asus_acpi.c
@@ -466,6 +466,7 @@ MODULE_DEVICE_TABLE(acpi, asus_device_ids);
 static struct acpi_driver asus_hotk_driver = {
 	.name = "asus_acpi",
 	.class = ACPI_HOTK_CLASS,
+	.owner = THIS_MODULE,
 	.ids = asus_device_ids,
 	.flags = ACPI_DRIVER_ALL_NOTIFY_EVENTS,
 	.ops = {
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 07/33] asus-laptop: set acpi_driver.owner
  2009-12-03  7:44           ` [PATCH 06/33] asus-acpi: set acpi_driver.owner Corentin Chary
@ 2009-12-03  7:44             ` Corentin Chary
  2009-12-03  7:44               ` [PATCH 08/33] eeepc-laptop: add touchpad led Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:44 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Alan Jenkins

From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>

The owner field provides the link between drivers and modules in sysfs,
but no ACPI driver was setting it.

After setting the owner field, we can see which module provides which
driver and vice versa by looking at /sys/bus/acpi/driver/*/module and
/sys/module/*/drivers/acpi:*.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
 drivers/platform/x86/asus-laptop.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/platform/x86/asus-laptop.c b/drivers/platform/x86/asus-laptop.c
index 4234edb..6c05172 100644
--- a/drivers/platform/x86/asus-laptop.c
+++ b/drivers/platform/x86/asus-laptop.c
@@ -232,6 +232,7 @@ static void asus_hotk_notify(struct acpi_device *device, u32 event);
 static struct acpi_driver asus_hotk_driver = {
 	.name = ASUS_HOTK_NAME,
 	.class = ASUS_HOTK_CLASS,
+	.owner = THIS_MODULE,
 	.ids = asus_device_ids,
 	.flags = ACPI_DRIVER_ALL_NOTIFY_EVENTS,
 	.ops = {
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 08/33] eeepc-laptop: add touchpad led
  2009-12-03  7:44             ` [PATCH 07/33] asus-laptop: " Corentin Chary
@ 2009-12-03  7:44               ` Corentin Chary
  2009-12-03  7:44                 ` [PATCH 09/33] eeepc-laptop: Remove redundant NULL checks Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:44 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Corentin Chary

This led can be found on Eeepc 1005 series.

Signed-off-by: Corentin Chary <corentincj@iksaif.net>
---
 drivers/platform/x86/Kconfig        |    2 +
 drivers/platform/x86/eeepc-laptop.c |   67 +++++++++++++++++++++++++++++++++++
 2 files changed, 69 insertions(+), 0 deletions(-)

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 55ca39d..e5e4312 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -334,6 +334,8 @@ config EEEPC_LAPTOP
 	depends on HOTPLUG_PCI
 	select BACKLIGHT_CLASS_DEVICE
 	select HWMON
+	select LEDS_CLASS
+	select NEW_LEDS
 	---help---
 	  This driver supports the Fn-Fx keys on Eee PC laptops.
 
diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index 2c65a37..9130434 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -34,6 +34,7 @@
 #include <linux/rfkill.h>
 #include <linux/pci.h>
 #include <linux/pci_hotplug.h>
+#include <linux/leds.h>
 
 #define EEEPC_LAPTOP_VERSION	"0.1"
 
@@ -507,6 +508,39 @@ static struct attribute_group platform_attribute_group = {
 };
 
 /*
+ * LEDs
+ */
+/*
+ * These functions actually update the LED's, and are called from a
+ * workqueue. By doing this as separate work rather than when the LED
+ * subsystem asks, we avoid messing with the Asus ACPI stuff during a
+ * potentially bad time, such as a timer interrupt.
+ */
+static int tpd_led_wk;
+
+static void tpd_led_update(struct work_struct *ignored)
+{
+	int value = tpd_led_wk;
+	set_acpi(CM_ASL_TPD, value);
+}
+
+static struct workqueue_struct *led_workqueue;
+static DECLARE_WORK(tpd_led_work, tpd_led_update);
+
+static void tpd_led_set(struct led_classdev *led_cdev,
+			enum led_brightness value)
+{
+	tpd_led_wk = (value > 0) ? 1 : 0;
+	queue_work(led_workqueue, &tpd_led_work);
+}
+
+static struct led_classdev tpd_led = {
+	.name           = "eeepc::touchpad",
+	.brightness_set = tpd_led_set,
+	.max_brightness = 1
+};
+
+/*
  * Hotkey functions
  */
 static struct key_entry *eepc_get_entry_by_scancode(int code)
@@ -1034,6 +1068,14 @@ static void eeepc_hwmon_exit(void)
 	eeepc_hwmon_device = NULL;
 }
 
+static void eeepc_led_exit(void)
+{
+	if (led_workqueue)
+		destroy_workqueue(led_workqueue);
+	if (tpd_led.dev)
+		led_classdev_unregister(&tpd_led);
+}
+
 static int eeepc_new_rfkill(struct rfkill **rfkill,
 			    const char *name, struct device *dev,
 			    enum rfkill_type type, int cm)
@@ -1190,6 +1232,24 @@ static int eeepc_input_init(struct device *dev)
 	return 0;
 }
 
+static int eeepc_led_init(struct device *dev)
+{
+	int rv;
+
+	if (get_acpi(CM_ASL_TPD) == -ENODEV)
+		return 0;
+
+	rv = led_classdev_register(dev, &tpd_led);
+	if (rv)
+		return rv;
+
+	led_workqueue = create_singlethread_workqueue("led_workqueue");
+	if (!led_workqueue)
+		return -ENOMEM;
+
+	return 0;
+}
+
 static int __devinit eeepc_hotk_add(struct acpi_device *device)
 {
 	struct device *dev;
@@ -1248,6 +1308,10 @@ static int __devinit eeepc_hotk_add(struct acpi_device *device)
 	if (result)
 		goto fail_hwmon;
 
+	result = eeepc_led_init(dev);
+	if (result)
+		goto fail_led;
+
 	result = eeepc_rfkill_init(dev);
 	if (result)
 		goto fail_rfkill;
@@ -1255,6 +1319,8 @@ static int __devinit eeepc_hotk_add(struct acpi_device *device)
 	return 0;
 
 fail_rfkill:
+	eeepc_led_exit();
+fail_led:
 	eeepc_hwmon_exit();
 fail_hwmon:
 	eeepc_input_exit();
@@ -1284,6 +1350,7 @@ static int eeepc_hotk_remove(struct acpi_device *device, int type)
 	eeepc_rfkill_exit();
 	eeepc_input_exit();
 	eeepc_hwmon_exit();
+	eeepc_led_exit();
 	sysfs_remove_group(&platform_device->dev.kobj,
 			   &platform_attribute_group);
 	platform_device_unregister(platform_device);
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 09/33] eeepc-laptop: Remove redundant NULL checks
  2009-12-03  7:44               ` [PATCH 08/33] eeepc-laptop: add touchpad led Corentin Chary
@ 2009-12-03  7:44                 ` Corentin Chary
  2009-12-03  7:44                   ` [PATCH 10/33] eeepc-laptop: Remove uneccesary acpi_disabled check Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:44 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Alan Jenkins

From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>

The acpi device callbacks add, start, remove, suspend and resume can
never be called with a NULL acpi_device. Each callsite in acpi/scan.c
has to dereference the device in order to get the ops structure, e.g.

    struct acpi_device *acpi_dev = to_acpi_device(dev);
    struct acpi_driver *acpi_drv = acpi_dev->driver;

    if (acpi_drv && acpi_drv->ops.suspend)
        return acpi_drv->ops.suspend(acpi_dev, state);

Remove all checks for acpi_dev == NULL within these callbacks.

Also remove the checks for acpi_driver_data(acpi_dev) == NULL. None of
these checks could fail unless the driver does something strange
(which none of them do), the acpi core did something terribly wrong,
or we have a memory corruption issue. If this does happen then it's
best to dereference the pointer and crash noisily.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
 drivers/platform/x86/eeepc-laptop.c |    5 -----
 1 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index 9130434..7dde47a 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -1255,8 +1255,6 @@ static int __devinit eeepc_hotk_add(struct acpi_device *device)
 	struct device *dev;
 	int result;
 
-	if (!device)
-		return -EINVAL;
 	pr_notice(EEEPC_HOTK_NAME "\n");
 	ehotk = kzalloc(sizeof(struct eeepc_hotk), GFP_KERNEL);
 	if (!ehotk)
@@ -1343,9 +1341,6 @@ fail_platform_driver:
 
 static int eeepc_hotk_remove(struct acpi_device *device, int type)
 {
-	if (!device || !acpi_driver_data(device))
-		return -EINVAL;
-
 	eeepc_backlight_exit();
 	eeepc_rfkill_exit();
 	eeepc_input_exit();
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 10/33] eeepc-laptop: Remove uneccesary acpi_disabled check
  2009-12-03  7:44                 ` [PATCH 09/33] eeepc-laptop: Remove redundant NULL checks Corentin Chary
@ 2009-12-03  7:44                   ` Corentin Chary
  2009-12-03  7:44                     ` [PATCH 11/33] eeepc-laptop: set acpi_driver.owner Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:44 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Alan Jenkins

From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>

acpi_bus_register_driver() already checks acpi_disabled, so acpi bus
drivers don't need to.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
 drivers/platform/x86/eeepc-laptop.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index 7dde47a..f5efe8d 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -1359,8 +1359,6 @@ static int __init eeepc_laptop_init(void)
 {
 	int result;
 
-	if (acpi_disabled)
-		return -ENODEV;
 	result = acpi_bus_register_driver(&eeepc_hotk_driver);
 	if (result < 0)
 		return result;
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 11/33] eeepc-laptop: set acpi_driver.owner
  2009-12-03  7:44                   ` [PATCH 10/33] eeepc-laptop: Remove uneccesary acpi_disabled check Corentin Chary
@ 2009-12-03  7:44                     ` Corentin Chary
  2009-12-03  7:44                       ` [PATCH 12/33] eeepc-laptop: fix value of pwm1_enable to match documentation Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:44 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Alan Jenkins

From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>

The owner field provides the link between drivers and modules in sysfs,
but no ACPI driver was setting it.

After setting the owner field, we can see which module provides which
driver and vice versa by looking at /sys/bus/acpi/driver/*/module and
/sys/module/*/drivers/acpi:*.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
 drivers/platform/x86/eeepc-laptop.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index f5efe8d..1c04c87 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -214,6 +214,7 @@ MODULE_DEVICE_TABLE(acpi, eeepc_device_ids);
 static struct acpi_driver eeepc_hotk_driver = {
 	.name = EEEPC_HOTK_NAME,
 	.class = EEEPC_HOTK_CLASS,
+	.owner = THIS_MODULE,
 	.ids = eeepc_device_ids,
 	.flags = ACPI_DRIVER_ALL_NOTIFY_EVENTS,
 	.ops = {
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 12/33] eeepc-laptop: fix value of pwm1_enable to match documentation
  2009-12-03  7:44                     ` [PATCH 11/33] eeepc-laptop: set acpi_driver.owner Corentin Chary
@ 2009-12-03  7:44                       ` Corentin Chary
  2009-12-03  7:44                         ` [PATCH 13/33] eeepc-laptop: fix led initialization order Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:44 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Alan Jenkins

From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>

Documentation/hwmon/sysfs-interface tells us that automatic fan speed
control should be represented by a value of 2 or above for pwm1_enable.
Fix eeepc_get_fan_ctrl() to return 2 for automatic fan control.

Setting "1" for manual control is already consistent with the
documentation, so this remains unchanged.

Let's preserve the ABI for this specific driver, so that writing "0"
will still invoke automatic control.

(The documentation says setting "0" should leave the fan at full speed
all the time.  This mode is not directly supported by our hardware. Full
speed is rather noisy on my 701 and the automatic control has never used
it.  If you really want this e.g. to prolong the life of an EeePC used
as a server, you can always use manual mode.  hwmon has always been
fairly machine-specific, and you're in a tiny minority (or elite :-).
I'm sure you're smart enough to notice that the fan doesn't turn on to
full speed when you try this mode, either by ear or checking
fan_input1.

We could even claim to be honouring the spirit of the documentation.
"0" really means "safe mode".  EeePCs default to automatic mode, ie that
is what Asus will actually test.  Since we do not provide any way to
tamper with the temperature threshold, automatic mode _is_ the safe
option).

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
 drivers/platform/x86/eeepc-laptop.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index 1c04c87..6c982d6 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -935,7 +935,10 @@ static int eeepc_get_fan_ctrl(void)
 	int value = 0;
 
 	read_acpi_int(NULL, EEEPC_EC_FAN_CTRL, &value);
-	return ((value & 0x02 ? 1 : 0));
+	if (value & 0x02)
+		return 1; /* manual */
+	else
+		return 2; /* automatic */
 }
 
 static void eeepc_set_fan_ctrl(int manual)
@@ -943,7 +946,7 @@ static void eeepc_set_fan_ctrl(int manual)
 	int value = 0;
 
 	read_acpi_int(NULL, EEEPC_EC_FAN_CTRL, &value);
-	if (manual)
+	if (manual == 1)
 		value |= 0x02;
 	else
 		value &= ~0x02;
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 13/33] eeepc-laptop: fix led initialization order
  2009-12-03  7:44                       ` [PATCH 12/33] eeepc-laptop: fix value of pwm1_enable to match documentation Corentin Chary
@ 2009-12-03  7:44                         ` Corentin Chary
  2009-12-03  7:44                           ` [PATCH 14/33] eeepc-laptop: fix potential leak (led_init() failure) Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:44 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Alan Jenkins

From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>

Create the workqueue thread used by tpd_led_set() *before* we register
the led device.  (And vice versa for unregistration).

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
 drivers/platform/x86/eeepc-laptop.c |   12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index 6c982d6..ac45faf 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -1074,10 +1074,10 @@ static void eeepc_hwmon_exit(void)
 
 static void eeepc_led_exit(void)
 {
-	if (led_workqueue)
-		destroy_workqueue(led_workqueue);
 	if (tpd_led.dev)
 		led_classdev_unregister(&tpd_led);
+	if (led_workqueue)
+		destroy_workqueue(led_workqueue);
 }
 
 static int eeepc_new_rfkill(struct rfkill **rfkill,
@@ -1243,14 +1243,14 @@ static int eeepc_led_init(struct device *dev)
 	if (get_acpi(CM_ASL_TPD) == -ENODEV)
 		return 0;
 
-	rv = led_classdev_register(dev, &tpd_led);
-	if (rv)
-		return rv;
-
 	led_workqueue = create_singlethread_workqueue("led_workqueue");
 	if (!led_workqueue)
 		return -ENOMEM;
 
+	rv = led_classdev_register(dev, &tpd_led);
+	if (rv)
+		return rv;
+
 	return 0;
 }
 
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 14/33] eeepc-laptop: fix potential leak (led_init() failure)
  2009-12-03  7:44                         ` [PATCH 13/33] eeepc-laptop: fix led initialization order Corentin Chary
@ 2009-12-03  7:44                           ` Corentin Chary
  2009-12-03  7:44                             ` [PATCH 15/33] eeepc-laptop: fix set_acpi() to return non-zero on failure Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:44 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Alan Jenkins

From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>

If we bail out because we can't create the led class device, we need to
ensure the led workqueue is cleaned up.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
 drivers/platform/x86/eeepc-laptop.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index ac45faf..8b686b5 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -1248,8 +1248,10 @@ static int eeepc_led_init(struct device *dev)
 		return -ENOMEM;
 
 	rv = led_classdev_register(dev, &tpd_led);
-	if (rv)
+	if (rv) {
+		destroy_workqueue(led_workqueue);
 		return rv;
+	}
 
 	return 0;
 }
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 15/33] eeepc-laptop: fix set_acpi() to return non-zero on failure
  2009-12-03  7:44                           ` [PATCH 14/33] eeepc-laptop: fix potential leak (led_init() failure) Corentin Chary
@ 2009-12-03  7:44                             ` Corentin Chary
  2009-12-03  7:45                               ` [PATCH 16/33] eeepc-laptop: remove redundant NULL checks Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:44 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Alan Jenkins

From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>

If the control method does not exist, return -ENODEV for consistency
with get_acpi()

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
 drivers/platform/x86/eeepc-laptop.c |   34 +++++++++++++++++++---------------
 1 files changed, 19 insertions(+), 15 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index 8b686b5..abd7389 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -289,26 +289,30 @@ static int read_acpi_int(acpi_handle handle, const char *method, int *val)
 
 static int set_acpi(int cm, int value)
 {
-	if (ehotk->cm_supported & (0x1 << cm)) {
-		const char *method = cm_setv[cm];
-		if (method == NULL)
-			return -ENODEV;
-		if (write_acpi_int(ehotk->handle, method, value, NULL))
-			pr_warning("Error writing %s\n", method);
-	}
+	const char *method = cm_setv[cm];
+
+	if (method == NULL)
+		return -ENODEV;
+	if ((ehotk->cm_supported & (0x1 << cm)) == 0)
+		return -ENODEV;
+
+	if (write_acpi_int(ehotk->handle, method, value, NULL))
+		pr_warning("Error writing %s\n", method);
 	return 0;
 }
 
 static int get_acpi(int cm)
 {
-	int value = -ENODEV;
-	if ((ehotk->cm_supported & (0x1 << cm))) {
-		const char *method = cm_getv[cm];
-		if (method == NULL)
-			return -ENODEV;
-		if (read_acpi_int(ehotk->handle, method, &value))
-			pr_warning("Error reading %s\n", method);
-	}
+	const char *method = cm_getv[cm];
+	int value;
+
+	if (method == NULL)
+		return -ENODEV;
+	if ((ehotk->cm_supported & (0x1 << cm)) == 0)
+		return -ENODEV;
+
+	if (read_acpi_int(ehotk->handle, method, &value))
+		pr_warning("Error reading %s\n", method);
 	return value;
 }
 
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 16/33] eeepc-laptop: remove redundant NULL checks
  2009-12-03  7:44                             ` [PATCH 15/33] eeepc-laptop: fix set_acpi() to return non-zero on failure Corentin Chary
@ 2009-12-03  7:45                               ` Corentin Chary
  2009-12-03  7:45                                 ` [PATCH 17/33] eeepc-laptop: no need to check argument of set_brightness() Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:45 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Alan Jenkins

From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>

eeepc_hotk_notify() cannot be called with ehotk == NULL or bd == NULL.
We check both variables for allocation failure and would bail out before
the notifier is registered.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
 drivers/platform/x86/eeepc-laptop.c |   42 +++++++++++++++-------------------
 1 files changed, 19 insertions(+), 23 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index abd7389..f6b7796 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -662,12 +662,11 @@ static int notify_brn(void)
 {
 	/* returns the *previous* brightness, or -1 */
 	struct backlight_device *bd = eeepc_backlight_device;
-	if (bd) {
-		int old = bd->props.brightness;
-		backlight_force_update(bd, BACKLIGHT_UPDATE_HOTKEY);
-		return old;
-	}
-	return -1;
+	int old = bd->props.brightness;
+
+	backlight_force_update(bd, BACKLIGHT_UPDATE_HOTKEY);
+
+	return old;
 }
 
 static int eeepc_get_adapter_status(struct hotplug_slot *hotplug_slot,
@@ -741,8 +740,6 @@ static void eeepc_hotk_notify(struct acpi_device *device, u32 event)
 	u16 count;
 	int brn = -ENODEV;
 
-	if (!ehotk)
-		return;
 	if (event > ACPI_MAX_SYS_NOTIFY)
 		return;
 	if (event >= NOTIFY_BRN_MIN && event <= NOTIFY_BRN_MAX)
@@ -753,21 +750,20 @@ static void eeepc_hotk_notify(struct acpi_device *device, u32 event)
 					dev_name(&ehotk->device->dev), event,
 					count);
 	if (ehotk->inputdev) {
-		if (brn != -ENODEV) {
-			/* brightness-change events need special
-			 * handling for conversion to key events
-			 */
-			if (brn < 0)
-				brn = event;
-			else
-				brn += NOTIFY_BRN_MIN;
-			if (event < brn)
-				event = NOTIFY_BRN_MIN; /* brightness down */
-			else if (event > brn)
-				event = NOTIFY_BRN_MIN + 2; /* ... up */
-			else
-				event = NOTIFY_BRN_MIN + 1; /* ... unchanged */
-		}
+		/* brightness-change events need special
+		 * handling for conversion to key events
+		 */
+		if (brn < 0)
+			brn = event;
+		else
+			brn += NOTIFY_BRN_MIN;
+		if (event < brn)
+			event = NOTIFY_BRN_MIN; /* brightness down */
+		else if (event > brn)
+			event = NOTIFY_BRN_MIN + 2; /* ... up */
+		else
+			event = NOTIFY_BRN_MIN + 1; /* ... unchanged */
+
 		key = eepc_get_entry_by_scancode(event);
 		if (key) {
 			switch (key->type) {
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 17/33] eeepc-laptop: no need to check argument of set_brightness()
  2009-12-03  7:45                               ` [PATCH 16/33] eeepc-laptop: remove redundant NULL checks Corentin Chary
@ 2009-12-03  7:45                                 ` Corentin Chary
  2009-12-03  7:45                                   ` [PATCH 18/33] eeepc-laptop: simplify acpi initialization Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:45 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Alan Jenkins

From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>

We already tell the backlight class our maximum brightness value; it
will validate the user requested values for us.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
 drivers/platform/x86/eeepc-laptop.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index f6b7796..9f33e51 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -326,7 +326,6 @@ static int read_brightness(struct backlight_device *bd)
 
 static int set_brightness(struct backlight_device *bd, int value)
 {
-	value = max(0, min(15, value));
 	return set_acpi(CM_ASL_PANELBRIGHT, value);
 }
 
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 18/33] eeepc-laptop: simplify acpi initialization
  2009-12-03  7:45                                 ` [PATCH 17/33] eeepc-laptop: no need to check argument of set_brightness() Corentin Chary
@ 2009-12-03  7:45                                   ` Corentin Chary
  2009-12-03  7:45                                     ` [PATCH 19/33] eeepc-laptop: simplify how the hwmon device reads values from the EC Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:45 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Alan Jenkins

From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>

We don't need to store init_flags after using them.  And we don't use
the result of INIT, so we don't need to allocate a buffer for it.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
 drivers/platform/x86/eeepc-laptop.c |   55 ++++++++++++++++------------------
 1 files changed, 26 insertions(+), 29 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index 9f33e51..50ceaaf 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -136,7 +136,6 @@ struct eeepc_hotk {
 	acpi_handle handle;		/* the handle of the hotk device */
 	u32 cm_supported;		/* the control methods supported
 					   by this BIOS */
-	uint init_flag;			/* Init flags */
 	u16 event_count[128];		/* count for each event */
 	struct input_dev *inputdev;
 	u16 *keycode_map;
@@ -256,8 +255,7 @@ MODULE_LICENSE("GPL");
 /*
  * ACPI Helpers
  */
-static int write_acpi_int(acpi_handle handle, const char *method, int val,
-			  struct acpi_buffer *output)
+static int write_acpi_int(acpi_handle handle, const char *method, int val)
 {
 	struct acpi_object_list params;
 	union acpi_object in_obj;
@@ -268,7 +266,7 @@ static int write_acpi_int(acpi_handle handle, const char *method, int val,
 	in_obj.type = ACPI_TYPE_INTEGER;
 	in_obj.integer.value = val;
 
-	status = acpi_evaluate_object(handle, (char *)method, &params, output);
+	status = acpi_evaluate_object(handle, (char *)method, &params, NULL);
 	return (status == AE_OK ? 0 : -1);
 }
 
@@ -296,7 +294,7 @@ static int set_acpi(int cm, int value)
 	if ((ehotk->cm_supported & (0x1 << cm)) == 0)
 		return -ENODEV;
 
-	if (write_acpi_int(ehotk->handle, method, value, NULL))
+	if (write_acpi_int(ehotk->handle, method, value))
 		pr_warning("Error writing %s\n", method);
 	return 0;
 }
@@ -624,36 +622,36 @@ static void cmsg_quirks(void)
 	cmsg_quirk(CM_ASL_TPD, "TPD");
 }
 
-static int eeepc_hotk_check(void)
+static int eeepc_hotk_init(void)
 {
-	struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+	unsigned int init_flags;
 	int result;
 
 	result = acpi_bus_get_status(ehotk->device);
 	if (result)
 		return result;
-	if (ehotk->device->status.present) {
-		if (write_acpi_int(ehotk->handle, "INIT", ehotk->init_flag,
-				    &buffer)) {
-			pr_err("Hotkey initialization failed\n");
-			return -ENODEV;
-		} else {
-			pr_notice("Hotkey init flags 0x%x\n", ehotk->init_flag);
-		}
-		/* get control methods supported */
-		if (read_acpi_int(ehotk->handle, "CMSG"
-				   , &ehotk->cm_supported)) {
-			pr_err("Get control methods supported failed\n");
-			return -ENODEV;
-		} else {
-			cmsg_quirks();
-			pr_info("Get control methods supported: 0x%x\n",
-				ehotk->cm_supported);
-		}
-	} else {
+	if (!ehotk->device->status.present) {
 		pr_err("Hotkey device not present, aborting\n");
-		return -EINVAL;
+		return -ENODEV;
 	}
+
+	init_flags = DISABLE_ASL_WLAN | DISABLE_ASL_DISPLAYSWITCH;
+	pr_notice("Hotkey init flags 0x%x\n", init_flags);
+
+	if (write_acpi_int(ehotk->handle, "INIT", init_flags)) {
+		pr_err("Hotkey initialization failed\n");
+		return -ENODEV;
+	}
+
+	/* get control methods supported */
+	if (read_acpi_int(ehotk->handle, "CMSG",
+				&ehotk->cm_supported)) {
+		pr_err("Get control methods supported failed\n");
+		return -ENODEV;
+	}
+	cmsg_quirks();
+	pr_info("Get control methods supported: 0x%x\n", ehotk->cm_supported);
+
 	return 0;
 }
 
@@ -1264,14 +1262,13 @@ static int __devinit eeepc_hotk_add(struct acpi_device *device)
 	ehotk = kzalloc(sizeof(struct eeepc_hotk), GFP_KERNEL);
 	if (!ehotk)
 		return -ENOMEM;
-	ehotk->init_flag = DISABLE_ASL_WLAN | DISABLE_ASL_DISPLAYSWITCH;
 	ehotk->handle = device->handle;
 	strcpy(acpi_device_name(device), EEEPC_HOTK_DEVICE_NAME);
 	strcpy(acpi_device_class(device), EEEPC_HOTK_CLASS);
 	device->driver_data = ehotk;
 	ehotk->device = device;
 
-	result = eeepc_hotk_check();
+	result = eeepc_hotk_init();
 	if (result)
 		goto fail_platform_driver;
 	eeepc_enable_camera();
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 19/33] eeepc-laptop: simplify how the hwmon device reads values from the EC
  2009-12-03  7:45                                   ` [PATCH 18/33] eeepc-laptop: simplify acpi initialization Corentin Chary
@ 2009-12-03  7:45                                     ` Corentin Chary
  2009-12-03  7:45                                       ` [PATCH 20/33] eeepc-laptop: refactor notifications Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:45 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Alan Jenkins

From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>

The hwmon device uses ec_write() to write values to the EC.  So for
consistency it should use ec_read() to read values.  The extra layers
of indirection used did not add any value.

This may mean we no longer take the ACPI global lock for such reads
(if the EC operation region requires the lock and the EC does not).
But there is no point locking each one-byte read individually, when
write operations do not use the lock at all.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
 drivers/platform/x86/eeepc-laptop.c |   43 +++++++++++++++++------------------
 1 files changed, 21 insertions(+), 22 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index 50ceaaf..04a59d3 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -118,14 +118,14 @@ static const char *cm_setv[] = {
 	NULL, NULL, "PBPS", "TPDS"
 };
 
-#define EEEPC_EC	"\\_SB.PCI0.SBRG.EC0."
+#define EEEPC_EC_SC00      0x61
+#define EEEPC_EC_FAN_PWM   (EEEPC_EC_SC00 + 2) /* Fan PWM duty cycle (%) */
+#define EEEPC_EC_FAN_HRPM  (EEEPC_EC_SC00 + 5) /* High byte, fan speed (RPM) */
+#define EEEPC_EC_FAN_LRPM  (EEEPC_EC_SC00 + 6) /* Low byte, fan speed (RPM) */
+
+#define EEEPC_EC_SFB0      0xD0
+#define EEEPC_EC_FAN_CTRL  (EEEPC_EC_SFB0 + 3) /* Byte containing SF25  */
 
-#define EEEPC_EC_FAN_PWM	EEEPC_EC "SC02" /* Fan PWM duty cycle (%) */
-#define EEEPC_EC_SC02		0x63
-#define EEEPC_EC_FAN_HRPM	EEEPC_EC "SC05" /* High byte, fan speed (RPM) */
-#define EEEPC_EC_FAN_LRPM	EEEPC_EC "SC06" /* Low byte, fan speed (RPM) */
-#define EEEPC_EC_FAN_CTRL	EEEPC_EC "SFB3" /* Byte containing SF25  */
-#define EEEPC_EC_SFB3		0xD3
 
 /*
  * This is the main structure, we can use it to store useful information
@@ -903,35 +903,34 @@ static int eeepc_hotk_restore(struct device *device)
  */
 static int eeepc_get_fan_pwm(void)
 {
-	int value = 0;
+	u8 value = 0;
 
-	read_acpi_int(NULL, EEEPC_EC_FAN_PWM, &value);
-	value = value * 255 / 100;
-	return (value);
+	ec_read(EEEPC_EC_FAN_PWM, &value);
+	return value * 255 / 100;
 }
 
 static void eeepc_set_fan_pwm(int value)
 {
 	value = SENSORS_LIMIT(value, 0, 255);
 	value = value * 100 / 255;
-	ec_write(EEEPC_EC_SC02, value);
+	ec_write(EEEPC_EC_FAN_PWM, value);
 }
 
 static int eeepc_get_fan_rpm(void)
 {
-	int high = 0;
-	int low = 0;
+	u8 high = 0;
+	u8 low = 0;
 
-	read_acpi_int(NULL, EEEPC_EC_FAN_HRPM, &high);
-	read_acpi_int(NULL, EEEPC_EC_FAN_LRPM, &low);
-	return (high << 8 | low);
+	ec_read(EEEPC_EC_FAN_HRPM, &high);
+	ec_read(EEEPC_EC_FAN_LRPM, &low);
+	return high << 8 | low;
 }
 
 static int eeepc_get_fan_ctrl(void)
 {
-	int value = 0;
+	u8 value = 0;
 
-	read_acpi_int(NULL, EEEPC_EC_FAN_CTRL, &value);
+	ec_read(EEEPC_EC_FAN_CTRL, &value);
 	if (value & 0x02)
 		return 1; /* manual */
 	else
@@ -940,14 +939,14 @@ static int eeepc_get_fan_ctrl(void)
 
 static void eeepc_set_fan_ctrl(int manual)
 {
-	int value = 0;
+	u8 value = 0;
 
-	read_acpi_int(NULL, EEEPC_EC_FAN_CTRL, &value);
+	ec_read(EEEPC_EC_FAN_CTRL, &value);
 	if (manual == 1)
 		value |= 0x02;
 	else
 		value &= ~0x02;
-	ec_write(EEEPC_EC_SFB3, value);
+	ec_write(EEEPC_EC_FAN_CTRL, value);
 }
 
 static ssize_t store_sys_hwmon(void (*set)(int), const char *buf, size_t count)
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 20/33] eeepc-laptop: refactor notifications
  2009-12-03  7:45                                     ` [PATCH 19/33] eeepc-laptop: simplify how the hwmon device reads values from the EC Corentin Chary
@ 2009-12-03  7:45                                       ` Corentin Chary
  2009-12-03  7:45                                         ` [PATCH 21/33] eeepc-laptop: move platform driver registration out of eeepc_hotk_add() Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:45 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Alan Jenkins

From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>

Separate out input_notify(), in a similar way to how notify_brn()
is already separated.  This will allow all the functions which refer to
the input device to be grouped together.

This includes a small behaviour change - we now synthesize brightness
up/down key events even if the brightness is already at the
maximum/minimum value.  This is consistent with the new uevent
interface.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
 drivers/platform/x86/eeepc-laptop.c |   71 +++++++++++++++++++----------------
 1 files changed, 39 insertions(+), 32 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index 04a59d3..b4eacb6 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -655,9 +655,8 @@ static int eeepc_hotk_init(void)
 	return 0;
 }
 
-static int notify_brn(void)
+static int eeepc_backlight_notify(void)
 {
-	/* returns the *previous* brightness, or -1 */
 	struct backlight_device *bd = eeepc_backlight_device;
 	int old = bd->props.brightness;
 
@@ -731,50 +730,58 @@ static void eeepc_rfkill_notify(acpi_handle handle, u32 event, void *data)
 	eeepc_rfkill_hotplug();
 }
 
-static void eeepc_hotk_notify(struct acpi_device *device, u32 event)
+static void eeepc_input_notify(int event)
 {
 	static struct key_entry *key;
+
+	key = eepc_get_entry_by_scancode(event);
+	if (key) {
+		switch (key->type) {
+		case KE_KEY:
+			input_report_key(ehotk->inputdev, key->keycode,
+						1);
+			input_sync(ehotk->inputdev);
+			input_report_key(ehotk->inputdev, key->keycode,
+						0);
+			input_sync(ehotk->inputdev);
+			break;
+		}
+	}
+}
+
+static void eeepc_hotk_notify(struct acpi_device *device, u32 event)
+{
 	u16 count;
-	int brn = -ENODEV;
 
 	if (event > ACPI_MAX_SYS_NOTIFY)
 		return;
-	if (event >= NOTIFY_BRN_MIN && event <= NOTIFY_BRN_MAX)
-		brn = notify_brn();
 	count = ehotk->event_count[event % 128]++;
 	acpi_bus_generate_proc_event(ehotk->device, event, count);
 	acpi_bus_generate_netlink_event(ehotk->device->pnp.device_class,
 					dev_name(&ehotk->device->dev), event,
 					count);
-	if (ehotk->inputdev) {
-		/* brightness-change events need special
-		 * handling for conversion to key events
-		 */
-		if (brn < 0)
-			brn = event;
-		else
-			brn += NOTIFY_BRN_MIN;
-		if (event < brn)
+
+	if (event >= NOTIFY_BRN_MIN && event <= NOTIFY_BRN_MAX) {
+		int old_brightness, new_brightness;
+
+		/* Update backlight device. */
+		old_brightness = eeepc_backlight_notify();
+
+		/* Convert brightness event to keypress (obsolescent hack). */
+		new_brightness = event - NOTIFY_BRN_MIN;
+
+		if (new_brightness < old_brightness) {
 			event = NOTIFY_BRN_MIN; /* brightness down */
-		else if (event > brn)
-			event = NOTIFY_BRN_MIN + 2; /* ... up */
-		else
-			event = NOTIFY_BRN_MIN + 1; /* ... unchanged */
-
-		key = eepc_get_entry_by_scancode(event);
-		if (key) {
-			switch (key->type) {
-			case KE_KEY:
-				input_report_key(ehotk->inputdev, key->keycode,
-						 1);
-				input_sync(ehotk->inputdev);
-				input_report_key(ehotk->inputdev, key->keycode,
-						 0);
-				input_sync(ehotk->inputdev);
-				break;
-			}
+		} else if (new_brightness > old_brightness) {
+			event = NOTIFY_BRN_MAX; /* brightness up */
+		} else {
+			/*
+			 * no change in brightness - already at min/max,
+			 * event will be desired value (or else ignored).
+			 */
 		}
 	}
+	eeepc_input_notify(event);
 }
 
 static int eeepc_register_rfkill_notifier(char *node)
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 21/33] eeepc-laptop: move platform driver registration out of eeepc_hotk_add()
  2009-12-03  7:45                                       ` [PATCH 20/33] eeepc-laptop: refactor notifications Corentin Chary
@ 2009-12-03  7:45                                         ` Corentin Chary
  2009-12-03  7:45                                           ` [PATCH 22/33] eeepc-laptop: move platform device initialisation to a separate function Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:45 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Alan Jenkins

From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>

Strictly speaking we should register the platform driver exactly once,
whether there are zero, one, or multiple matching acpi devices.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
 drivers/platform/x86/eeepc-laptop.c |   25 +++++++++++++++----------
 1 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index b4eacb6..3f9b286 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -1276,13 +1276,10 @@ static int __devinit eeepc_hotk_add(struct acpi_device *device)
 
 	result = eeepc_hotk_init();
 	if (result)
-		goto fail_platform_driver;
+		goto fail_platform_device1;
 	eeepc_enable_camera();
 
 	/* Register platform stuff */
-	result = platform_driver_register(&platform_driver);
-	if (result)
-		goto fail_platform_driver;
 	platform_device = platform_device_alloc(EEEPC_HOTK_FILE, -1);
 	if (!platform_device) {
 		result = -ENOMEM;
@@ -1340,8 +1337,6 @@ fail_sysfs:
 fail_platform_device2:
 	platform_device_put(platform_device);
 fail_platform_device1:
-	platform_driver_unregister(&platform_driver);
-fail_platform_driver:
 	kfree(ehotk);
 
 	return result;
@@ -1357,7 +1352,6 @@ static int eeepc_hotk_remove(struct acpi_device *device, int type)
 	sysfs_remove_group(&platform_device->dev.kobj,
 			   &platform_attribute_group);
 	platform_device_unregister(platform_device);
-	platform_driver_unregister(&platform_driver);
 
 	kfree(ehotk);
 	return 0;
@@ -1367,19 +1361,30 @@ static int __init eeepc_laptop_init(void)
 {
 	int result;
 
-	result = acpi_bus_register_driver(&eeepc_hotk_driver);
+	result = platform_driver_register(&platform_driver);
 	if (result < 0)
 		return result;
+
+	result = acpi_bus_register_driver(&eeepc_hotk_driver);
+	if (result < 0)
+		goto fail_acpi_driver;
 	if (!ehotk) {
-		acpi_bus_unregister_driver(&eeepc_hotk_driver);
-		return -ENODEV;
+		result = -ENODEV;
+		goto fail_no_device;
 	}
 	return 0;
+
+fail_no_device:
+	acpi_bus_unregister_driver(&eeepc_hotk_driver);
+fail_acpi_driver:
+	platform_driver_unregister(&platform_driver);
+	return result;
 }
 
 static void __exit eeepc_laptop_exit(void)
 {
 	acpi_bus_unregister_driver(&eeepc_hotk_driver);
+	platform_driver_unregister(&platform_driver);
 }
 
 module_init(eeepc_laptop_init);
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 22/33] eeepc-laptop: move platform device initialisation to a separate function
  2009-12-03  7:45                                         ` [PATCH 21/33] eeepc-laptop: move platform driver registration out of eeepc_hotk_add() Corentin Chary
@ 2009-12-03  7:45                                           ` Corentin Chary
  2009-12-03  7:45                                             ` [PATCH 23/33] eeepc-laptop: code movement Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:45 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Alan Jenkins

From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>

This moves the sysfs_create_group() call just after the declaration of
the platform device attributes.  It should make it easier to examine
the implementation of the platform device attributes in isolation
from the rest of the code.  (The next commit will apply this pattern
to all of the sub-devices as well).

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk
---
 drivers/platform/x86/eeepc-laptop.c |   64 +++++++++++++++++++++-------------
 1 files changed, 39 insertions(+), 25 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index 3f9b286..f4f6796 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -509,6 +509,38 @@ static struct attribute_group platform_attribute_group = {
 	.attrs = platform_attributes
 };
 
+static int eeepc_platform_init(void)
+{
+	int result;
+
+	platform_device = platform_device_alloc(EEEPC_HOTK_FILE, -1);
+	if (!platform_device)
+		return -ENOMEM;
+
+	result = platform_device_add(platform_device);
+	if (result)
+		goto fail_platform_device;
+
+	result = sysfs_create_group(&platform_device->dev.kobj,
+				    &platform_attribute_group);
+	if (result)
+		goto fail_sysfs;
+	return 0;
+
+fail_sysfs:
+	platform_device_del(platform_device);
+fail_platform_device:
+	platform_device_put(platform_device);
+	return result;
+}
+
+static void eeepc_platform_exit(void)
+{
+	sysfs_remove_group(&platform_device->dev.kobj,
+			   &platform_attribute_group);
+	platform_device_unregister(platform_device);
+}
+
 /*
  * LEDs
  */
@@ -1276,22 +1308,12 @@ static int __devinit eeepc_hotk_add(struct acpi_device *device)
 
 	result = eeepc_hotk_init();
 	if (result)
-		goto fail_platform_device1;
+		goto fail_platform;
 	eeepc_enable_camera();
 
-	/* Register platform stuff */
-	platform_device = platform_device_alloc(EEEPC_HOTK_FILE, -1);
-	if (!platform_device) {
-		result = -ENOMEM;
-		goto fail_platform_device1;
-	}
-	result = platform_device_add(platform_device);
+	result = eeepc_platform_init();
 	if (result)
-		goto fail_platform_device2;
-	result = sysfs_create_group(&platform_device->dev.kobj,
-				    &platform_attribute_group);
-	if (result)
-		goto fail_sysfs;
+		goto fail_platform;
 
 	dev = &platform_device->dev;
 
@@ -1300,8 +1322,7 @@ static int __devinit eeepc_hotk_add(struct acpi_device *device)
 		if (result)
 			goto fail_backlight;
 	} else
-		pr_info("Backlight controlled by ACPI video "
-			"driver\n");
+		pr_info("Backlight controlled by ACPI video driver\n");
 
 	result = eeepc_input_init(dev);
 	if (result)
@@ -1330,13 +1351,8 @@ fail_hwmon:
 fail_input:
 	eeepc_backlight_exit();
 fail_backlight:
-	sysfs_remove_group(&platform_device->dev.kobj,
-			   &platform_attribute_group);
-fail_sysfs:
-	platform_device_del(platform_device);
-fail_platform_device2:
-	platform_device_put(platform_device);
-fail_platform_device1:
+	eeepc_platform_exit();
+fail_platform:
 	kfree(ehotk);
 
 	return result;
@@ -1349,9 +1365,7 @@ static int eeepc_hotk_remove(struct acpi_device *device, int type)
 	eeepc_input_exit();
 	eeepc_hwmon_exit();
 	eeepc_led_exit();
-	sysfs_remove_group(&platform_device->dev.kobj,
-			   &platform_attribute_group);
-	platform_device_unregister(platform_device);
+	eeepc_platform_exit();
 
 	kfree(ehotk);
 	return 0;
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 23/33] eeepc-laptop: code movement
  2009-12-03  7:45                                           ` [PATCH 22/33] eeepc-laptop: move platform device initialisation to a separate function Corentin Chary
@ 2009-12-03  7:45                                             ` Corentin Chary
  2009-12-03  7:45                                               ` [PATCH 24/33] eeepc-laptop: revise names Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:45 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Alan Jenkins

From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>

Move e.g. backlight_init() and backlight_exit() together along with the
other backlight functions, instead of grouping init() and exit()
functions.  Move e.g. backlight_ops to follow the functions it refers
to, and remove the forward declarations.  The code itself should remain
unchanged.

The eeepc-laptop driver implements a number of interfaces like the
backlight class driver.  This change makes it easier to examine the
implementation of one interface at at a time, without having to search
through the file to find init() and exit() functions etc.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
 drivers/platform/x86/eeepc-laptop.c |  934 +++++++++++++++++------------------
 1 files changed, 462 insertions(+), 472 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index f4f6796..f457587 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -44,6 +44,9 @@
 #define EEEPC_HOTK_DEVICE_NAME	"Hotkey"
 #define EEEPC_HOTK_HID		"ASUS010"
 
+MODULE_AUTHOR("Corentin Chary, Eric Cooper");
+MODULE_DESCRIPTION(EEEPC_HOTK_NAME);
+MODULE_LICENSE("GPL");
 
 /*
  * Definitions for Asus EeePC
@@ -118,57 +121,6 @@ static const char *cm_setv[] = {
 	NULL, NULL, "PBPS", "TPDS"
 };
 
-#define EEEPC_EC_SC00      0x61
-#define EEEPC_EC_FAN_PWM   (EEEPC_EC_SC00 + 2) /* Fan PWM duty cycle (%) */
-#define EEEPC_EC_FAN_HRPM  (EEEPC_EC_SC00 + 5) /* High byte, fan speed (RPM) */
-#define EEEPC_EC_FAN_LRPM  (EEEPC_EC_SC00 + 6) /* Low byte, fan speed (RPM) */
-
-#define EEEPC_EC_SFB0      0xD0
-#define EEEPC_EC_FAN_CTRL  (EEEPC_EC_SFB0 + 3) /* Byte containing SF25  */
-
-
-/*
- * This is the main structure, we can use it to store useful information
- * about the hotk device
- */
-struct eeepc_hotk {
-	struct acpi_device *device;	/* the device we are in */
-	acpi_handle handle;		/* the handle of the hotk device */
-	u32 cm_supported;		/* the control methods supported
-					   by this BIOS */
-	u16 event_count[128];		/* count for each event */
-	struct input_dev *inputdev;
-	u16 *keycode_map;
-	struct rfkill *wlan_rfkill;
-	struct rfkill *bluetooth_rfkill;
-	struct rfkill *wwan3g_rfkill;
-	struct rfkill *wimax_rfkill;
-	struct hotplug_slot *hotplug_slot;
-	struct mutex hotplug_lock;
-};
-
-/* The actual device the driver binds to */
-static struct eeepc_hotk *ehotk;
-
-/* Platform device/driver */
-static int eeepc_hotk_thaw(struct device *device);
-static int eeepc_hotk_restore(struct device *device);
-
-static struct dev_pm_ops eeepc_pm_ops = {
-	.thaw = eeepc_hotk_thaw,
-	.restore = eeepc_hotk_restore,
-};
-
-static struct platform_driver platform_driver = {
-	.driver = {
-		.name = EEEPC_HOTK_FILE,
-		.owner = THIS_MODULE,
-		.pm = &eeepc_pm_ops,
-	}
-};
-
-static struct platform_device *platform_device;
-
 struct key_entry {
 	char type;
 	u8 code;
@@ -189,48 +141,40 @@ static struct key_entry eeepc_keymap[] = {
 	{KE_KEY, 0x1b, KEY_ZOOM },
 	{KE_KEY, 0x1c, KEY_PROG2 },
 	{KE_KEY, 0x1d, KEY_PROG3 },
-	{KE_KEY, NOTIFY_BRN_MIN,     KEY_BRIGHTNESSDOWN },
-	{KE_KEY, NOTIFY_BRN_MIN + 2, KEY_BRIGHTNESSUP },
+	{KE_KEY, NOTIFY_BRN_MIN, KEY_BRIGHTNESSDOWN },
+	{KE_KEY, NOTIFY_BRN_MAX, KEY_BRIGHTNESSUP },
 	{KE_KEY, 0x30, KEY_SWITCHVIDEOMODE },
 	{KE_KEY, 0x31, KEY_SWITCHVIDEOMODE },
 	{KE_KEY, 0x32, KEY_SWITCHVIDEOMODE },
 	{KE_END, 0},
 };
 
+
 /*
- * The hotkey driver declaration
+ * This is the main structure, we can use it to store useful information
+ * about the hotk device
  */
-static int eeepc_hotk_add(struct acpi_device *device);
-static int eeepc_hotk_remove(struct acpi_device *device, int type);
-static void eeepc_hotk_notify(struct acpi_device *device, u32 event);
-
-static const struct acpi_device_id eeepc_device_ids[] = {
-	{EEEPC_HOTK_HID, 0},
-	{"", 0},
-};
-MODULE_DEVICE_TABLE(acpi, eeepc_device_ids);
-
-static struct acpi_driver eeepc_hotk_driver = {
-	.name = EEEPC_HOTK_NAME,
-	.class = EEEPC_HOTK_CLASS,
-	.owner = THIS_MODULE,
-	.ids = eeepc_device_ids,
-	.flags = ACPI_DRIVER_ALL_NOTIFY_EVENTS,
-	.ops = {
-		.add = eeepc_hotk_add,
-		.remove = eeepc_hotk_remove,
-		.notify = eeepc_hotk_notify,
-	},
+struct eeepc_hotk {
+	struct acpi_device *device;	/* the device we are in */
+	acpi_handle handle;		/* the handle of the hotk device */
+	u32 cm_supported;		/* the control methods supported
+					   by this BIOS */
+	u16 event_count[128];		/* count for each event */
+	struct input_dev *inputdev;
+	u16 *keycode_map;
+	struct rfkill *wlan_rfkill;
+	struct rfkill *bluetooth_rfkill;
+	struct rfkill *wwan3g_rfkill;
+	struct rfkill *wimax_rfkill;
+	struct hotplug_slot *hotplug_slot;
+	struct mutex hotplug_lock;
 };
 
-/* PCI hotplug ops */
-static int eeepc_get_adapter_status(struct hotplug_slot *slot, u8 *value);
+/* The actual device the driver binds to */
+static struct eeepc_hotk *ehotk;
 
-static struct hotplug_slot_ops eeepc_hotplug_slot_ops = {
-	.owner = THIS_MODULE,
-	.get_adapter_status = eeepc_get_adapter_status,
-	.get_power_status = eeepc_get_adapter_status,
-};
+/* The platform device */
+static struct platform_device *platform_device;
 
 /* The backlight device /sys/class/backlight */
 static struct backlight_device *eeepc_backlight_device;
@@ -238,19 +182,6 @@ static struct backlight_device *eeepc_backlight_device;
 /* The hwmon device */
 static struct device *eeepc_hwmon_device;
 
-/*
- * The backlight class declaration
- */
-static int read_brightness(struct backlight_device *bd);
-static int update_bl_status(struct backlight_device *bd);
-static struct backlight_ops eeepcbl_ops = {
-	.get_brightness = read_brightness,
-	.update_status = update_bl_status,
-};
-
-MODULE_AUTHOR("Corentin Chary, Eric Cooper");
-MODULE_DESCRIPTION(EEEPC_HOTK_NAME);
-MODULE_LICENSE("GPL");
 
 /*
  * ACPI Helpers
@@ -315,55 +246,6 @@ static int get_acpi(int cm)
 }
 
 /*
- * Backlight
- */
-static int read_brightness(struct backlight_device *bd)
-{
-	return get_acpi(CM_ASL_PANELBRIGHT);
-}
-
-static int set_brightness(struct backlight_device *bd, int value)
-{
-	return set_acpi(CM_ASL_PANELBRIGHT, value);
-}
-
-static int update_bl_status(struct backlight_device *bd)
-{
-	return set_brightness(bd, bd->props.brightness);
-}
-
-/*
- * Rfkill helpers
- */
-
-static bool eeepc_wlan_rfkill_blocked(void)
-{
-	if (get_acpi(CM_ASL_WLAN) == 1)
-		return false;
-	return true;
-}
-
-static int eeepc_rfkill_set(void *data, bool blocked)
-{
-	unsigned long asl = (unsigned long)data;
-	return set_acpi(asl, !blocked);
-}
-
-static const struct rfkill_ops eeepc_rfkill_ops = {
-	.set_block = eeepc_rfkill_set,
-};
-
-static void __devinit eeepc_enable_camera(void)
-{
-	/*
-	 * If the following call to set_acpi() fails, it's because there's no
-	 * camera so we can ignore the error.
-	 */
-	if (get_acpi(CM_ASL_CAMERA) == 0)
-		set_acpi(CM_ASL_CAMERA, 1);
-}
-
-/*
  * Sys helpers
  */
 static int parse_arg(const char *buf, unsigned long count, int *val)
@@ -574,140 +456,43 @@ static struct led_classdev tpd_led = {
 	.max_brightness = 1
 };
 
-/*
- * Hotkey functions
- */
-static struct key_entry *eepc_get_entry_by_scancode(int code)
-{
-	struct key_entry *key;
-
-	for (key = eeepc_keymap; key->type != KE_END; key++)
-		if (code == key->code)
-			return key;
-
-	return NULL;
-}
-
-static struct key_entry *eepc_get_entry_by_keycode(int code)
-{
-	struct key_entry *key;
-
-	for (key = eeepc_keymap; key->type != KE_END; key++)
-		if (code == key->keycode && key->type == KE_KEY)
-			return key;
-
-	return NULL;
-}
-
-static int eeepc_getkeycode(struct input_dev *dev, int scancode, int *keycode)
-{
-	struct key_entry *key = eepc_get_entry_by_scancode(scancode);
-
-	if (key && key->type == KE_KEY) {
-		*keycode = key->keycode;
-		return 0;
-	}
-
-	return -EINVAL;
-}
-
-static int eeepc_setkeycode(struct input_dev *dev, int scancode, int keycode)
+static int eeepc_led_init(struct device *dev)
 {
-	struct key_entry *key;
-	int old_keycode;
-
-	if (keycode < 0 || keycode > KEY_MAX)
-		return -EINVAL;
+	int rv;
 
-	key = eepc_get_entry_by_scancode(scancode);
-	if (key && key->type == KE_KEY) {
-		old_keycode = key->keycode;
-		key->keycode = keycode;
-		set_bit(keycode, dev->keybit);
-		if (!eepc_get_entry_by_keycode(old_keycode))
-			clear_bit(old_keycode, dev->keybit);
+	if (get_acpi(CM_ASL_TPD) == -ENODEV)
 		return 0;
-	}
-
-	return -EINVAL;
-}
-
-static void cmsg_quirk(int cm, const char *name)
-{
-	int dummy;
-
-	/* Some BIOSes do not report cm although it is avaliable.
-	   Check if cm_getv[cm] works and, if yes, assume cm should be set. */
-	if (!(ehotk->cm_supported & (1 << cm))
-	    && !read_acpi_int(ehotk->handle, cm_getv[cm], &dummy)) {
-		pr_info("%s (%x) not reported by BIOS,"
-			" enabling anyway\n", name, 1 << cm);
-		ehotk->cm_supported |= 1 << cm;
-	}
-}
 
-static void cmsg_quirks(void)
-{
-	cmsg_quirk(CM_ASL_LID, "LID");
-	cmsg_quirk(CM_ASL_TYPE, "TYPE");
-	cmsg_quirk(CM_ASL_PANELPOWER, "PANELPOWER");
-	cmsg_quirk(CM_ASL_TPD, "TPD");
-}
-
-static int eeepc_hotk_init(void)
-{
-	unsigned int init_flags;
-	int result;
-
-	result = acpi_bus_get_status(ehotk->device);
-	if (result)
-		return result;
-	if (!ehotk->device->status.present) {
-		pr_err("Hotkey device not present, aborting\n");
-		return -ENODEV;
-	}
-
-	init_flags = DISABLE_ASL_WLAN | DISABLE_ASL_DISPLAYSWITCH;
-	pr_notice("Hotkey init flags 0x%x\n", init_flags);
-
-	if (write_acpi_int(ehotk->handle, "INIT", init_flags)) {
-		pr_err("Hotkey initialization failed\n");
-		return -ENODEV;
-	}
+	led_workqueue = create_singlethread_workqueue("led_workqueue");
+	if (!led_workqueue)
+		return -ENOMEM;
 
-	/* get control methods supported */
-	if (read_acpi_int(ehotk->handle, "CMSG",
-				&ehotk->cm_supported)) {
-		pr_err("Get control methods supported failed\n");
-		return -ENODEV;
+	rv = led_classdev_register(dev, &tpd_led);
+	if (rv) {
+		destroy_workqueue(led_workqueue);
+		return rv;
 	}
-	cmsg_quirks();
-	pr_info("Get control methods supported: 0x%x\n", ehotk->cm_supported);
 
 	return 0;
 }
 
-static int eeepc_backlight_notify(void)
+static void eeepc_led_exit(void)
 {
-	struct backlight_device *bd = eeepc_backlight_device;
-	int old = bd->props.brightness;
-
-	backlight_force_update(bd, BACKLIGHT_UPDATE_HOTKEY);
-
-	return old;
+	if (tpd_led.dev)
+		led_classdev_unregister(&tpd_led);
+	if (led_workqueue)
+		destroy_workqueue(led_workqueue);
 }
 
-static int eeepc_get_adapter_status(struct hotplug_slot *hotplug_slot,
-				    u8 *value)
-{
-	int val = get_acpi(CM_ASL_WLAN);
-
-	if (val == 1 || val == 0)
-		*value = val;
-	else
-		return -EINVAL;
 
-	return 0;
+/*
+ * PCI hotplug (for wlan rfkill)
+ */
+static bool eeepc_wlan_rfkill_blocked(void)
+{
+	if (get_acpi(CM_ASL_WLAN) == 1)
+		return false;
+	return true;
 }
 
 static void eeepc_rfkill_hotplug(void)
@@ -762,60 +547,6 @@ static void eeepc_rfkill_notify(acpi_handle handle, u32 event, void *data)
 	eeepc_rfkill_hotplug();
 }
 
-static void eeepc_input_notify(int event)
-{
-	static struct key_entry *key;
-
-	key = eepc_get_entry_by_scancode(event);
-	if (key) {
-		switch (key->type) {
-		case KE_KEY:
-			input_report_key(ehotk->inputdev, key->keycode,
-						1);
-			input_sync(ehotk->inputdev);
-			input_report_key(ehotk->inputdev, key->keycode,
-						0);
-			input_sync(ehotk->inputdev);
-			break;
-		}
-	}
-}
-
-static void eeepc_hotk_notify(struct acpi_device *device, u32 event)
-{
-	u16 count;
-
-	if (event > ACPI_MAX_SYS_NOTIFY)
-		return;
-	count = ehotk->event_count[event % 128]++;
-	acpi_bus_generate_proc_event(ehotk->device, event, count);
-	acpi_bus_generate_netlink_event(ehotk->device->pnp.device_class,
-					dev_name(&ehotk->device->dev), event,
-					count);
-
-	if (event >= NOTIFY_BRN_MIN && event <= NOTIFY_BRN_MAX) {
-		int old_brightness, new_brightness;
-
-		/* Update backlight device. */
-		old_brightness = eeepc_backlight_notify();
-
-		/* Convert brightness event to keypress (obsolescent hack). */
-		new_brightness = event - NOTIFY_BRN_MIN;
-
-		if (new_brightness < old_brightness) {
-			event = NOTIFY_BRN_MIN; /* brightness down */
-		} else if (new_brightness > old_brightness) {
-			event = NOTIFY_BRN_MAX; /* brightness up */
-		} else {
-			/*
-			 * no change in brightness - already at min/max,
-			 * event will be desired value (or else ignored).
-			 */
-		}
-	}
-	eeepc_input_notify(event);
-}
-
 static int eeepc_register_rfkill_notifier(char *node)
 {
 	acpi_status status = AE_OK;
@@ -853,12 +584,31 @@ static void eeepc_unregister_rfkill_notifier(char *node)
 	}
 }
 
+static int eeepc_get_adapter_status(struct hotplug_slot *hotplug_slot,
+				    u8 *value)
+{
+	int val = get_acpi(CM_ASL_WLAN);
+
+	if (val == 1 || val == 0)
+		*value = val;
+	else
+		return -EINVAL;
+
+	return 0;
+}
+
 static void eeepc_cleanup_pci_hotplug(struct hotplug_slot *hotplug_slot)
 {
 	kfree(hotplug_slot->info);
 	kfree(hotplug_slot);
 }
 
+static struct hotplug_slot_ops eeepc_hotplug_slot_ops = {
+	.owner = THIS_MODULE,
+	.get_adapter_status = eeepc_get_adapter_status,
+	.get_power_status = eeepc_get_adapter_status,
+};
+
 static int eeepc_setup_pci_hotplug(void)
 {
 	int ret = -ENOMEM;
@@ -901,6 +651,140 @@ error_slot:
 	return ret;
 }
 
+/*
+ * Rfkill devices
+ */
+static int eeepc_rfkill_set(void *data, bool blocked)
+{
+	unsigned long asl = (unsigned long)data;
+	return set_acpi(asl, !blocked);
+}
+
+static const struct rfkill_ops eeepc_rfkill_ops = {
+	.set_block = eeepc_rfkill_set,
+};
+
+static int eeepc_new_rfkill(struct rfkill **rfkill,
+			    const char *name, struct device *dev,
+			    enum rfkill_type type, int cm)
+{
+	int result;
+
+	result = get_acpi(cm);
+	if (result < 0)
+		return result;
+
+	*rfkill = rfkill_alloc(name, dev, type,
+			       &eeepc_rfkill_ops, (void *)(unsigned long)cm);
+
+	if (!*rfkill)
+		return -EINVAL;
+
+	rfkill_init_sw_state(*rfkill, get_acpi(cm) != 1);
+	result = rfkill_register(*rfkill);
+	if (result) {
+		rfkill_destroy(*rfkill);
+		*rfkill = NULL;
+		return result;
+	}
+	return 0;
+}
+
+static void eeepc_rfkill_exit(void)
+{
+	eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P5");
+	eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P6");
+	eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P7");
+	if (ehotk->wlan_rfkill) {
+		rfkill_unregister(ehotk->wlan_rfkill);
+		rfkill_destroy(ehotk->wlan_rfkill);
+		ehotk->wlan_rfkill = NULL;
+	}
+	/*
+	 * Refresh pci hotplug in case the rfkill state was changed after
+	 * eeepc_unregister_rfkill_notifier()
+	 */
+	eeepc_rfkill_hotplug();
+	if (ehotk->hotplug_slot)
+		pci_hp_deregister(ehotk->hotplug_slot);
+
+	if (ehotk->bluetooth_rfkill) {
+		rfkill_unregister(ehotk->bluetooth_rfkill);
+		rfkill_destroy(ehotk->bluetooth_rfkill);
+		ehotk->bluetooth_rfkill = NULL;
+	}
+	if (ehotk->wwan3g_rfkill) {
+		rfkill_unregister(ehotk->wwan3g_rfkill);
+		rfkill_destroy(ehotk->wwan3g_rfkill);
+		ehotk->wwan3g_rfkill = NULL;
+	}
+	if (ehotk->wimax_rfkill) {
+		rfkill_unregister(ehotk->wimax_rfkill);
+		rfkill_destroy(ehotk->wimax_rfkill);
+		ehotk->wimax_rfkill = NULL;
+	}
+}
+
+static int eeepc_rfkill_init(struct device *dev)
+{
+	int result = 0;
+
+	mutex_init(&ehotk->hotplug_lock);
+
+	result = eeepc_new_rfkill(&ehotk->wlan_rfkill,
+				  "eeepc-wlan", dev,
+				  RFKILL_TYPE_WLAN, CM_ASL_WLAN);
+
+	if (result && result != -ENODEV)
+		goto exit;
+
+	result = eeepc_new_rfkill(&ehotk->bluetooth_rfkill,
+				  "eeepc-bluetooth", dev,
+				  RFKILL_TYPE_BLUETOOTH, CM_ASL_BLUETOOTH);
+
+	if (result && result != -ENODEV)
+		goto exit;
+
+	result = eeepc_new_rfkill(&ehotk->wwan3g_rfkill,
+				  "eeepc-wwan3g", dev,
+				  RFKILL_TYPE_WWAN, CM_ASL_3G);
+
+	if (result && result != -ENODEV)
+		goto exit;
+
+	result = eeepc_new_rfkill(&ehotk->wimax_rfkill,
+				  "eeepc-wimax", dev,
+				  RFKILL_TYPE_WIMAX, CM_ASL_WIMAX);
+
+	if (result && result != -ENODEV)
+		goto exit;
+
+	result = eeepc_setup_pci_hotplug();
+	/*
+	 * If we get -EBUSY then something else is handling the PCI hotplug -
+	 * don't fail in this case
+	 */
+	if (result == -EBUSY)
+		result = 0;
+
+	eeepc_register_rfkill_notifier("\\_SB.PCI0.P0P5");
+	eeepc_register_rfkill_notifier("\\_SB.PCI0.P0P6");
+	eeepc_register_rfkill_notifier("\\_SB.PCI0.P0P7");
+	/*
+	 * Refresh pci hotplug in case the rfkill state was changed during
+	 * setup.
+	 */
+	eeepc_rfkill_hotplug();
+
+exit:
+	if (result && result != -ENODEV)
+		eeepc_rfkill_exit();
+	return result;
+}
+
+/*
+ * Platform driver - hibernate/resume callbacks
+ */
 static int eeepc_hotk_thaw(struct device *device)
 {
 	if (ehotk->wlan_rfkill) {
@@ -937,9 +821,31 @@ static int eeepc_hotk_restore(struct device *device)
 	return 0;
 }
 
+static struct dev_pm_ops eeepc_pm_ops = {
+	.thaw = eeepc_hotk_thaw,
+	.restore = eeepc_hotk_restore,
+};
+
+static struct platform_driver platform_driver = {
+	.driver = {
+		.name = EEEPC_HOTK_FILE,
+		.owner = THIS_MODULE,
+		.pm = &eeepc_pm_ops,
+	}
+};
+
 /*
- * Hwmon
+ * Hwmon device
  */
+
+#define EEEPC_EC_SC00      0x61
+#define EEEPC_EC_FAN_PWM   (EEEPC_EC_SC00 + 2) /* Fan PWM duty cycle (%) */
+#define EEEPC_EC_FAN_HRPM  (EEEPC_EC_SC00 + 5) /* High byte, fan speed (RPM) */
+#define EEEPC_EC_FAN_LRPM  (EEEPC_EC_SC00 + 6) /* Low byte, fan speed (RPM) */
+
+#define EEEPC_EC_SFB0      0xD0
+#define EEEPC_EC_FAN_CTRL  (EEEPC_EC_SFB0 + 3) /* Byte containing SF25  */
+
 static int eeepc_get_fan_pwm(void)
 {
 	u8 value = 0;
@@ -1043,57 +949,6 @@ static struct attribute_group hwmon_attribute_group = {
 	.attrs = hwmon_attributes
 };
 
-/*
- * exit/init
- */
-static void eeepc_backlight_exit(void)
-{
-	if (eeepc_backlight_device)
-		backlight_device_unregister(eeepc_backlight_device);
-	eeepc_backlight_device = NULL;
-}
-
-static void eeepc_rfkill_exit(void)
-{
-	eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P5");
-	eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P6");
-	eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P7");
-	if (ehotk->wlan_rfkill) {
-		rfkill_unregister(ehotk->wlan_rfkill);
-		rfkill_destroy(ehotk->wlan_rfkill);
-		ehotk->wlan_rfkill = NULL;
-	}
-	/*
-	 * Refresh pci hotplug in case the rfkill state was changed after
-	 * eeepc_unregister_rfkill_notifier()
-	 */
-	eeepc_rfkill_hotplug();
-	if (ehotk->hotplug_slot)
-		pci_hp_deregister(ehotk->hotplug_slot);
-
-	if (ehotk->bluetooth_rfkill) {
-		rfkill_unregister(ehotk->bluetooth_rfkill);
-		rfkill_destroy(ehotk->bluetooth_rfkill);
-		ehotk->bluetooth_rfkill = NULL;
-	}
-	if (ehotk->wwan3g_rfkill) {
-		rfkill_unregister(ehotk->wwan3g_rfkill);
-		rfkill_destroy(ehotk->wwan3g_rfkill);
-		ehotk->wwan3g_rfkill = NULL;
-	}
-	if (ehotk->wimax_rfkill) {
-		rfkill_unregister(ehotk->wimax_rfkill);
-		rfkill_destroy(ehotk->wimax_rfkill);
-		ehotk->wimax_rfkill = NULL;
-	}
-}
-
-static void eeepc_input_exit(void)
-{
-	if (ehotk->inputdev)
-		input_unregister_device(ehotk->inputdev);
-}
-
 static void eeepc_hwmon_exit(void)
 {
 	struct device *hwmon;
@@ -1107,96 +962,56 @@ static void eeepc_hwmon_exit(void)
 	eeepc_hwmon_device = NULL;
 }
 
-static void eeepc_led_exit(void)
-{
-	if (tpd_led.dev)
-		led_classdev_unregister(&tpd_led);
-	if (led_workqueue)
-		destroy_workqueue(led_workqueue);
-}
-
-static int eeepc_new_rfkill(struct rfkill **rfkill,
-			    const char *name, struct device *dev,
-			    enum rfkill_type type, int cm)
+static int eeepc_hwmon_init(struct device *dev)
 {
+	struct device *hwmon;
 	int result;
 
-	result = get_acpi(cm);
-	if (result < 0)
-		return result;
-
-	*rfkill = rfkill_alloc(name, dev, type,
-			       &eeepc_rfkill_ops, (void *)(unsigned long)cm);
-
-	if (!*rfkill)
-		return -EINVAL;
-
-	rfkill_init_sw_state(*rfkill, get_acpi(cm) != 1);
-	result = rfkill_register(*rfkill);
-	if (result) {
-		rfkill_destroy(*rfkill);
-		*rfkill = NULL;
-		return result;
+	hwmon = hwmon_device_register(dev);
+	if (IS_ERR(hwmon)) {
+		pr_err("Could not register eeepc hwmon device\n");
+		eeepc_hwmon_device = NULL;
+		return PTR_ERR(hwmon);
 	}
-	return 0;
+	eeepc_hwmon_device = hwmon;
+	result = sysfs_create_group(&hwmon->kobj,
+				    &hwmon_attribute_group);
+	if (result)
+		eeepc_hwmon_exit();
+	return result;
 }
 
-
-static int eeepc_rfkill_init(struct device *dev)
+/*
+ * Backlight device
+ */
+static int read_brightness(struct backlight_device *bd)
 {
-	int result = 0;
-
-	mutex_init(&ehotk->hotplug_lock);
-
-	result = eeepc_new_rfkill(&ehotk->wlan_rfkill,
-				  "eeepc-wlan", dev,
-				  RFKILL_TYPE_WLAN, CM_ASL_WLAN);
-
-	if (result && result != -ENODEV)
-		goto exit;
-
-	result = eeepc_new_rfkill(&ehotk->bluetooth_rfkill,
-				  "eeepc-bluetooth", dev,
-				  RFKILL_TYPE_BLUETOOTH, CM_ASL_BLUETOOTH);
-
-	if (result && result != -ENODEV)
-		goto exit;
-
-	result = eeepc_new_rfkill(&ehotk->wwan3g_rfkill,
-				  "eeepc-wwan3g", dev,
-				  RFKILL_TYPE_WWAN, CM_ASL_3G);
+	return get_acpi(CM_ASL_PANELBRIGHT);
+}
 
-	if (result && result != -ENODEV)
-		goto exit;
+static int set_brightness(struct backlight_device *bd, int value)
+{
+	return set_acpi(CM_ASL_PANELBRIGHT, value);
+}
 
-	result = eeepc_new_rfkill(&ehotk->wimax_rfkill,
-				  "eeepc-wimax", dev,
-				  RFKILL_TYPE_WIMAX, CM_ASL_WIMAX);
+static int update_bl_status(struct backlight_device *bd)
+{
+	return set_brightness(bd, bd->props.brightness);
+}
 
-	if (result && result != -ENODEV)
-		goto exit;
+static struct backlight_ops eeepcbl_ops = {
+	.get_brightness = read_brightness,
+	.update_status = update_bl_status,
+};
 
-	result = eeepc_setup_pci_hotplug();
-	/*
-	 * If we get -EBUSY then something else is handling the PCI hotplug -
-	 * don't fail in this case
-	 */
-	if (result == -EBUSY)
-		result = 0;
+static int eeepc_backlight_notify(void)
+{
+	struct backlight_device *bd = eeepc_backlight_device;
+	int old = bd->props.brightness;
 
-	eeepc_register_rfkill_notifier("\\_SB.PCI0.P0P5");
-	eeepc_register_rfkill_notifier("\\_SB.PCI0.P0P6");
-	eeepc_register_rfkill_notifier("\\_SB.PCI0.P0P7");
-	/*
-	 * Refresh pci hotplug in case the rfkill state was changed during
-	 * setup.
-	 */
-	eeepc_rfkill_hotplug();
+	backlight_force_update(bd, BACKLIGHT_UPDATE_HOTKEY);
 
-exit:
-	if (result && result != -ENODEV)
-		eeepc_rfkill_exit();
-	return result;
+	return old;
 }
 
 static int eeepc_backlight_init(struct device *dev)
@@ -1218,23 +1033,89 @@ static int eeepc_backlight_init(struct device *dev)
 	return 0;
 }
 
-static int eeepc_hwmon_init(struct device *dev)
+static void eeepc_backlight_exit(void)
 {
-	struct device *hwmon;
-	int result;
+	if (eeepc_backlight_device)
+		backlight_device_unregister(eeepc_backlight_device);
+	eeepc_backlight_device = NULL;
+}
 
-	hwmon = hwmon_device_register(dev);
-	if (IS_ERR(hwmon)) {
-		pr_err("Could not register eeepc hwmon device\n");
-		eeepc_hwmon_device = NULL;
-		return PTR_ERR(hwmon);
+
+/*
+ * Input device (i.e. hotkeys)
+ */
+static struct key_entry *eeepc_get_entry_by_scancode(int code)
+{
+	struct key_entry *key;
+
+	for (key = eeepc_keymap; key->type != KE_END; key++)
+		if (code == key->code)
+			return key;
+
+	return NULL;
+}
+
+static void eeepc_input_notify(int event)
+{
+	static struct key_entry *key;
+
+	key = eeepc_get_entry_by_scancode(event);
+	if (key) {
+		switch (key->type) {
+		case KE_KEY:
+			input_report_key(ehotk->inputdev, key->keycode,
+						1);
+			input_sync(ehotk->inputdev);
+			input_report_key(ehotk->inputdev, key->keycode,
+						0);
+			input_sync(ehotk->inputdev);
+			break;
+		}
 	}
-	eeepc_hwmon_device = hwmon;
-	result = sysfs_create_group(&hwmon->kobj,
-				    &hwmon_attribute_group);
-	if (result)
-		eeepc_hwmon_exit();
-	return result;
+}
+
+static struct key_entry *eepc_get_entry_by_keycode(int code)
+{
+	struct key_entry *key;
+
+	for (key = eeepc_keymap; key->type != KE_END; key++)
+		if (code == key->keycode && key->type == KE_KEY)
+			return key;
+
+	return NULL;
+}
+
+static int eeepc_getkeycode(struct input_dev *dev, int scancode, int *keycode)
+{
+	struct key_entry *key = eeepc_get_entry_by_scancode(scancode);
+
+	if (key && key->type == KE_KEY) {
+		*keycode = key->keycode;
+		return 0;
+	}
+
+	return -EINVAL;
+}
+
+static int eeepc_setkeycode(struct input_dev *dev, int scancode, int keycode)
+{
+	struct key_entry *key;
+	int old_keycode;
+
+	if (keycode < 0 || keycode > KEY_MAX)
+		return -EINVAL;
+
+	key = eeepc_get_entry_by_scancode(scancode);
+	if (key && key->type == KE_KEY) {
+		old_keycode = key->keycode;
+		key->keycode = keycode;
+		set_bit(keycode, dev->keybit);
+		if (!eepc_get_entry_by_keycode(old_keycode))
+			clear_bit(old_keycode, dev->keybit);
+		return 0;
+	}
+
+	return -EINVAL;
 }
 
 static int eeepc_input_init(struct device *dev)
@@ -1271,26 +1152,114 @@ static int eeepc_input_init(struct device *dev)
 	return 0;
 }
 
-static int eeepc_led_init(struct device *dev)
+static void eeepc_input_exit(void)
 {
-	int rv;
+	if (ehotk->inputdev)
+		input_unregister_device(ehotk->inputdev);
+}
 
-	if (get_acpi(CM_ASL_TPD) == -ENODEV)
-		return 0;
+/*
+ * ACPI driver
+ */
+static void eeepc_hotk_notify(struct acpi_device *device, u32 event)
+{
+	u16 count;
 
-	led_workqueue = create_singlethread_workqueue("led_workqueue");
-	if (!led_workqueue)
-		return -ENOMEM;
+	if (event > ACPI_MAX_SYS_NOTIFY)
+		return;
+	count = ehotk->event_count[event % 128]++;
+	acpi_bus_generate_proc_event(ehotk->device, event, count);
+	acpi_bus_generate_netlink_event(ehotk->device->pnp.device_class,
+					dev_name(&ehotk->device->dev), event,
+					count);
 
-	rv = led_classdev_register(dev, &tpd_led);
-	if (rv) {
-		destroy_workqueue(led_workqueue);
-		return rv;
+	if (event >= NOTIFY_BRN_MIN && event <= NOTIFY_BRN_MAX) {
+		int old_brightness, new_brightness;
+
+		/* Update backlight device. */
+		old_brightness = eeepc_backlight_notify();
+
+		/* Convert brightness event to keypress (obsolescent hack). */
+		new_brightness = event - NOTIFY_BRN_MIN;
+
+		if (new_brightness < old_brightness) {
+			event = NOTIFY_BRN_MIN; /* brightness down */
+		} else if (new_brightness > old_brightness) {
+			event = NOTIFY_BRN_MAX; /* brightness up */
+		} else {
+			/*
+			 * no change in brightness - already at min/max,
+			 * event will be desired value (or else ignored).
+			 */
+		}
 	}
+	eeepc_input_notify(event);
+}
+
+static void cmsg_quirk(int cm, const char *name)
+{
+	int dummy;
+
+	/* Some BIOSes do not report cm although it is avaliable.
+	   Check if cm_getv[cm] works and, if yes, assume cm should be set. */
+	if (!(ehotk->cm_supported & (1 << cm))
+	    && !read_acpi_int(ehotk->handle, cm_getv[cm], &dummy)) {
+		pr_info("%s (%x) not reported by BIOS,"
+			" enabling anyway\n", name, 1 << cm);
+		ehotk->cm_supported |= 1 << cm;
+	}
+}
+
+static void cmsg_quirks(void)
+{
+	cmsg_quirk(CM_ASL_LID, "LID");
+	cmsg_quirk(CM_ASL_TYPE, "TYPE");
+	cmsg_quirk(CM_ASL_PANELPOWER, "PANELPOWER");
+	cmsg_quirk(CM_ASL_TPD, "TPD");
+}
+
+static int eeepc_hotk_init(void)
+{
+	unsigned int init_flags;
+	int result;
+
+	result = acpi_bus_get_status(ehotk->device);
+	if (result)
+		return result;
+	if (!ehotk->device->status.present) {
+		pr_err("Hotkey device not present, aborting\n");
+		return -ENODEV;
+	}
+
+	init_flags = DISABLE_ASL_WLAN | DISABLE_ASL_DISPLAYSWITCH;
+	pr_notice("Hotkey init flags 0x%x\n", init_flags);
+
+	if (write_acpi_int(ehotk->handle, "INIT", init_flags)) {
+		pr_err("Hotkey initialization failed\n");
+		return -ENODEV;
+	}
+
+	/* get control methods supported */
+	if (read_acpi_int(ehotk->handle, "CMSG", &ehotk->cm_supported)) {
+		pr_err("Get control methods supported failed\n");
+		return -ENODEV;
+	}
+	cmsg_quirks();
+	pr_info("Get control methods supported: 0x%x\n", ehotk->cm_supported);
 
 	return 0;
 }
 
+static void __devinit eeepc_enable_camera(void)
+{
+	/*
+	 * If the following call to set_acpi() fails, it's because there's no
+	 * camera so we can ignore the error.
+	 */
+	if (get_acpi(CM_ASL_CAMERA) == 0)
+		set_acpi(CM_ASL_CAMERA, 1);
+}
+
 static int __devinit eeepc_hotk_add(struct acpi_device *device)
 {
 	struct device *dev;
@@ -1371,6 +1340,27 @@ static int eeepc_hotk_remove(struct acpi_device *device, int type)
 	return 0;
 }
 
+
+static const struct acpi_device_id eeepc_device_ids[] = {
+	{EEEPC_HOTK_HID, 0},
+	{"", 0},
+};
+MODULE_DEVICE_TABLE(acpi, eeepc_device_ids);
+
+static struct acpi_driver eeepc_hotk_driver = {
+	.name = EEEPC_HOTK_NAME,
+	.class = EEEPC_HOTK_CLASS,
+	.owner = THIS_MODULE,
+	.ids = eeepc_device_ids,
+	.flags = ACPI_DRIVER_ALL_NOTIFY_EVENTS,
+	.ops = {
+		.add = eeepc_hotk_add,
+		.remove = eeepc_hotk_remove,
+		.notify = eeepc_hotk_notify,
+	},
+};
+
+
 static int __init eeepc_laptop_init(void)
 {
 	int result;
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 24/33] eeepc-laptop: revise names
  2009-12-03  7:45                                             ` [PATCH 23/33] eeepc-laptop: code movement Corentin Chary
@ 2009-12-03  7:45                                               ` Corentin Chary
  2009-12-03  7:45                                                 ` [PATCH 25/33] eeepc-laptop: callbacks should use "driver data" parameter or field Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:45 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Alan Jenkins

From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>

eeepc-laptop now does a lot more than just hotkeys.  Replace the "hotk"
names used throughout the driver with some slightly more appropriate
names.  The actual strings used in kernel messages and sysfs are left
unchanged.

e.g.
	EEEPC_HOTK_FILE  -> EEEPC_LAPTOP_FILE
	EEEPC_HOTK_HID   -> EEEPC_ACPI_HID

	eeepc_hotk_notify -> eeepc_acpi_notify
	struct eeepc_hotk -> struct eeepc_laptop
	ehotk             -> eeepc

I'm about to refactor the entire driver to remove the global "ehotk"
variable, and I don't wish to add "struct eeepc_hotk *ehotk" to
functions which have nothing to do with hotkeys.

Also
 - fix the name of "eepc_get_entry_by_keycode()"
 - remove the unused definition of NOTIFY_WLAN_ON.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
 drivers/platform/x86/eeepc-laptop.c |  253 +++++++++++++++++------------------
 1 files changed, 125 insertions(+), 128 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index f457587..b9b5aeb 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -1,5 +1,5 @@
 /*
- *  eepc-laptop.c - Asus Eee PC extras
+ *  eeepc-laptop.c - Asus Eee PC extras
  *
  *  Based on asus_acpi.c as patched for the Eee PC by Asus:
  *  ftp://ftp.asus.com/pub/ASUS/EeePC/701/ASUS_ACPI_071126.rar
@@ -37,21 +37,20 @@
 #include <linux/leds.h>
 
 #define EEEPC_LAPTOP_VERSION	"0.1"
+#define EEEPC_LAPTOP_NAME	"Eee PC Hotkey Driver"
+#define EEEPC_LAPTOP_FILE	"eeepc"
 
-#define EEEPC_HOTK_NAME		"Eee PC Hotkey Driver"
-#define EEEPC_HOTK_FILE		"eeepc"
-#define EEEPC_HOTK_CLASS	"hotkey"
-#define EEEPC_HOTK_DEVICE_NAME	"Hotkey"
-#define EEEPC_HOTK_HID		"ASUS010"
+#define EEEPC_ACPI_CLASS	"hotkey"
+#define EEEPC_ACPI_DEVICE_NAME	"Hotkey"
+#define EEEPC_ACPI_HID		"ASUS010"
 
 MODULE_AUTHOR("Corentin Chary, Eric Cooper");
-MODULE_DESCRIPTION(EEEPC_HOTK_NAME);
+MODULE_DESCRIPTION(EEEPC_LAPTOP_NAME);
 MODULE_LICENSE("GPL");
 
 /*
  * Definitions for Asus EeePC
  */
-#define	NOTIFY_WLAN_ON	0x10
 #define NOTIFY_BRN_MIN	0x20
 #define NOTIFY_BRN_MAX	0x2f
 
@@ -152,9 +151,8 @@ static struct key_entry eeepc_keymap[] = {
 
 /*
  * This is the main structure, we can use it to store useful information
- * about the hotk device
  */
-struct eeepc_hotk {
+struct eeepc_laptop {
 	struct acpi_device *device;	/* the device we are in */
 	acpi_handle handle;		/* the handle of the hotk device */
 	u32 cm_supported;		/* the control methods supported
@@ -171,7 +169,7 @@ struct eeepc_hotk {
 };
 
 /* The actual device the driver binds to */
-static struct eeepc_hotk *ehotk;
+static struct eeepc_laptop *eeepc;
 
 /* The platform device */
 static struct platform_device *platform_device;
@@ -222,10 +220,10 @@ static int set_acpi(int cm, int value)
 
 	if (method == NULL)
 		return -ENODEV;
-	if ((ehotk->cm_supported & (0x1 << cm)) == 0)
+	if ((eeepc->cm_supported & (0x1 << cm)) == 0)
 		return -ENODEV;
 
-	if (write_acpi_int(ehotk->handle, method, value))
+	if (write_acpi_int(eeepc->handle, method, value))
 		pr_warning("Error writing %s\n", method);
 	return 0;
 }
@@ -237,10 +235,10 @@ static int get_acpi(int cm)
 
 	if (method == NULL)
 		return -ENODEV;
-	if ((ehotk->cm_supported & (0x1 << cm)) == 0)
+	if ((eeepc->cm_supported & (0x1 << cm)) == 0)
 		return -ENODEV;
 
-	if (read_acpi_int(ehotk->handle, method, &value))
+	if (read_acpi_int(eeepc->handle, method, &value))
 		pr_warning("Error reading %s\n", method);
 	return value;
 }
@@ -395,7 +393,7 @@ static int eeepc_platform_init(void)
 {
 	int result;
 
-	platform_device = platform_device_alloc(EEEPC_HOTK_FILE, -1);
+	platform_device = platform_device_alloc(EEEPC_LAPTOP_FILE, -1);
 	if (!platform_device)
 		return -ENOMEM;
 
@@ -501,12 +499,12 @@ static void eeepc_rfkill_hotplug(void)
 	struct pci_bus *bus;
 	bool blocked = eeepc_wlan_rfkill_blocked();
 
-	if (ehotk->wlan_rfkill)
-		rfkill_set_sw_state(ehotk->wlan_rfkill, blocked);
+	if (eeepc->wlan_rfkill)
+		rfkill_set_sw_state(eeepc->wlan_rfkill, blocked);
 
-	mutex_lock(&ehotk->hotplug_lock);
+	mutex_lock(&eeepc->hotplug_lock);
 
-	if (ehotk->hotplug_slot) {
+	if (eeepc->hotplug_slot) {
 		bus = pci_find_bus(0, 1);
 		if (!bus) {
 			pr_warning("Unable to find PCI bus 1?\n");
@@ -536,7 +534,7 @@ static void eeepc_rfkill_hotplug(void)
 	}
 
 out_unlock:
-	mutex_unlock(&ehotk->hotplug_lock);
+	mutex_unlock(&eeepc->hotplug_lock);
 }
 
 static void eeepc_rfkill_notify(acpi_handle handle, u32 event, void *data)
@@ -619,22 +617,22 @@ static int eeepc_setup_pci_hotplug(void)
 		return -ENODEV;
 	}
 
-	ehotk->hotplug_slot = kzalloc(sizeof(struct hotplug_slot), GFP_KERNEL);
-	if (!ehotk->hotplug_slot)
+	eeepc->hotplug_slot = kzalloc(sizeof(struct hotplug_slot), GFP_KERNEL);
+	if (!eeepc->hotplug_slot)
 		goto error_slot;
 
-	ehotk->hotplug_slot->info = kzalloc(sizeof(struct hotplug_slot_info),
+	eeepc->hotplug_slot->info = kzalloc(sizeof(struct hotplug_slot_info),
 					    GFP_KERNEL);
-	if (!ehotk->hotplug_slot->info)
+	if (!eeepc->hotplug_slot->info)
 		goto error_info;
 
-	ehotk->hotplug_slot->private = ehotk;
-	ehotk->hotplug_slot->release = &eeepc_cleanup_pci_hotplug;
-	ehotk->hotplug_slot->ops = &eeepc_hotplug_slot_ops;
-	eeepc_get_adapter_status(ehotk->hotplug_slot,
-				 &ehotk->hotplug_slot->info->adapter_status);
+	eeepc->hotplug_slot->private = eeepc;
+	eeepc->hotplug_slot->release = &eeepc_cleanup_pci_hotplug;
+	eeepc->hotplug_slot->ops = &eeepc_hotplug_slot_ops;
+	eeepc_get_adapter_status(eeepc->hotplug_slot,
+				 &eeepc->hotplug_slot->info->adapter_status);
 
-	ret = pci_hp_register(ehotk->hotplug_slot, bus, 0, "eeepc-wifi");
+	ret = pci_hp_register(eeepc->hotplug_slot, bus, 0, "eeepc-wifi");
 	if (ret) {
 		pr_err("Unable to register hotplug slot - %d\n", ret);
 		goto error_register;
@@ -643,10 +641,10 @@ static int eeepc_setup_pci_hotplug(void)
 	return 0;
 
 error_register:
-	kfree(ehotk->hotplug_slot->info);
+	kfree(eeepc->hotplug_slot->info);
 error_info:
-	kfree(ehotk->hotplug_slot);
-	ehotk->hotplug_slot = NULL;
+	kfree(eeepc->hotplug_slot);
+	eeepc->hotplug_slot = NULL;
 error_slot:
 	return ret;
 }
@@ -695,33 +693,33 @@ static void eeepc_rfkill_exit(void)
 	eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P5");
 	eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P6");
 	eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P7");
-	if (ehotk->wlan_rfkill) {
-		rfkill_unregister(ehotk->wlan_rfkill);
-		rfkill_destroy(ehotk->wlan_rfkill);
-		ehotk->wlan_rfkill = NULL;
+	if (eeepc->wlan_rfkill) {
+		rfkill_unregister(eeepc->wlan_rfkill);
+		rfkill_destroy(eeepc->wlan_rfkill);
+		eeepc->wlan_rfkill = NULL;
 	}
 	/*
 	 * Refresh pci hotplug in case the rfkill state was changed after
 	 * eeepc_unregister_rfkill_notifier()
 	 */
 	eeepc_rfkill_hotplug();
-	if (ehotk->hotplug_slot)
-		pci_hp_deregister(ehotk->hotplug_slot);
+	if (eeepc->hotplug_slot)
+		pci_hp_deregister(eeepc->hotplug_slot);
 
-	if (ehotk->bluetooth_rfkill) {
-		rfkill_unregister(ehotk->bluetooth_rfkill);
-		rfkill_destroy(ehotk->bluetooth_rfkill);
-		ehotk->bluetooth_rfkill = NULL;
+	if (eeepc->bluetooth_rfkill) {
+		rfkill_unregister(eeepc->bluetooth_rfkill);
+		rfkill_destroy(eeepc->bluetooth_rfkill);
+		eeepc->bluetooth_rfkill = NULL;
 	}
-	if (ehotk->wwan3g_rfkill) {
-		rfkill_unregister(ehotk->wwan3g_rfkill);
-		rfkill_destroy(ehotk->wwan3g_rfkill);
-		ehotk->wwan3g_rfkill = NULL;
+	if (eeepc->wwan3g_rfkill) {
+		rfkill_unregister(eeepc->wwan3g_rfkill);
+		rfkill_destroy(eeepc->wwan3g_rfkill);
+		eeepc->wwan3g_rfkill = NULL;
 	}
-	if (ehotk->wimax_rfkill) {
-		rfkill_unregister(ehotk->wimax_rfkill);
-		rfkill_destroy(ehotk->wimax_rfkill);
-		ehotk->wimax_rfkill = NULL;
+	if (eeepc->wimax_rfkill) {
+		rfkill_unregister(eeepc->wimax_rfkill);
+		rfkill_destroy(eeepc->wimax_rfkill);
+		eeepc->wimax_rfkill = NULL;
 	}
 }
 
@@ -729,30 +727,30 @@ static int eeepc_rfkill_init(struct device *dev)
 {
 	int result = 0;
 
-	mutex_init(&ehotk->hotplug_lock);
+	mutex_init(&eeepc->hotplug_lock);
 
-	result = eeepc_new_rfkill(&ehotk->wlan_rfkill,
+	result = eeepc_new_rfkill(&eeepc->wlan_rfkill,
 				  "eeepc-wlan", dev,
 				  RFKILL_TYPE_WLAN, CM_ASL_WLAN);
 
 	if (result && result != -ENODEV)
 		goto exit;
 
-	result = eeepc_new_rfkill(&ehotk->bluetooth_rfkill,
+	result = eeepc_new_rfkill(&eeepc->bluetooth_rfkill,
 				  "eeepc-bluetooth", dev,
 				  RFKILL_TYPE_BLUETOOTH, CM_ASL_BLUETOOTH);
 
 	if (result && result != -ENODEV)
 		goto exit;
 
-	result = eeepc_new_rfkill(&ehotk->wwan3g_rfkill,
+	result = eeepc_new_rfkill(&eeepc->wwan3g_rfkill,
 				  "eeepc-wwan3g", dev,
 				  RFKILL_TYPE_WWAN, CM_ASL_3G);
 
 	if (result && result != -ENODEV)
 		goto exit;
 
-	result = eeepc_new_rfkill(&ehotk->wimax_rfkill,
+	result = eeepc_new_rfkill(&eeepc->wimax_rfkill,
 				  "eeepc-wimax", dev,
 				  RFKILL_TYPE_WIMAX, CM_ASL_WIMAX);
 
@@ -785,9 +783,9 @@ exit:
 /*
  * Platform driver - hibernate/resume callbacks
  */
-static int eeepc_hotk_thaw(struct device *device)
+static int eeepc_thaw(struct device *device)
 {
-	if (ehotk->wlan_rfkill) {
+	if (eeepc->wlan_rfkill) {
 		bool wlan;
 
 		/*
@@ -802,33 +800,33 @@ static int eeepc_hotk_thaw(struct device *device)
 	return 0;
 }
 
-static int eeepc_hotk_restore(struct device *device)
+static int eeepc_restore(struct device *device)
 {
 	/* Refresh both wlan rfkill state and pci hotplug */
-	if (ehotk->wlan_rfkill)
+	if (eeepc->wlan_rfkill)
 		eeepc_rfkill_hotplug();
 
-	if (ehotk->bluetooth_rfkill)
-		rfkill_set_sw_state(ehotk->bluetooth_rfkill,
+	if (eeepc->bluetooth_rfkill)
+		rfkill_set_sw_state(eeepc->bluetooth_rfkill,
 				    get_acpi(CM_ASL_BLUETOOTH) != 1);
-	if (ehotk->wwan3g_rfkill)
-		rfkill_set_sw_state(ehotk->wwan3g_rfkill,
+	if (eeepc->wwan3g_rfkill)
+		rfkill_set_sw_state(eeepc->wwan3g_rfkill,
 				    get_acpi(CM_ASL_3G) != 1);
-	if (ehotk->wimax_rfkill)
-		rfkill_set_sw_state(ehotk->wimax_rfkill,
+	if (eeepc->wimax_rfkill)
+		rfkill_set_sw_state(eeepc->wimax_rfkill,
 				    get_acpi(CM_ASL_WIMAX) != 1);
 
 	return 0;
 }
 
 static struct dev_pm_ops eeepc_pm_ops = {
-	.thaw = eeepc_hotk_thaw,
-	.restore = eeepc_hotk_restore,
+	.thaw = eeepc_thaw,
+	.restore = eeepc_restore,
 };
 
 static struct platform_driver platform_driver = {
 	.driver = {
-		.name = EEEPC_HOTK_FILE,
+		.name = EEEPC_LAPTOP_FILE,
 		.owner = THIS_MODULE,
 		.pm = &eeepc_pm_ops,
 	}
@@ -1018,7 +1016,7 @@ static int eeepc_backlight_init(struct device *dev)
 {
 	struct backlight_device *bd;
 
-	bd = backlight_device_register(EEEPC_HOTK_FILE, dev,
+	bd = backlight_device_register(EEEPC_LAPTOP_FILE, dev,
 				       NULL, &eeepcbl_ops);
 	if (IS_ERR(bd)) {
 		pr_err("Could not register eeepc backlight device\n");
@@ -1063,12 +1061,12 @@ static void eeepc_input_notify(int event)
 	if (key) {
 		switch (key->type) {
 		case KE_KEY:
-			input_report_key(ehotk->inputdev, key->keycode,
+			input_report_key(eeepc->inputdev, key->keycode,
 						1);
-			input_sync(ehotk->inputdev);
-			input_report_key(ehotk->inputdev, key->keycode,
+			input_sync(eeepc->inputdev);
+			input_report_key(eeepc->inputdev, key->keycode,
 						0);
-			input_sync(ehotk->inputdev);
+			input_sync(eeepc->inputdev);
 			break;
 		}
 	}
@@ -1123,30 +1121,30 @@ static int eeepc_input_init(struct device *dev)
 	const struct key_entry *key;
 	int result;
 
-	ehotk->inputdev = input_allocate_device();
-	if (!ehotk->inputdev) {
+	eeepc->inputdev = input_allocate_device();
+	if (!eeepc->inputdev) {
 		pr_info("Unable to allocate input device\n");
 		return -ENOMEM;
 	}
-	ehotk->inputdev->name = "Asus EeePC extra buttons";
-	ehotk->inputdev->dev.parent = dev;
-	ehotk->inputdev->phys = EEEPC_HOTK_FILE "/input0";
-	ehotk->inputdev->id.bustype = BUS_HOST;
-	ehotk->inputdev->getkeycode = eeepc_getkeycode;
-	ehotk->inputdev->setkeycode = eeepc_setkeycode;
+	eeepc->inputdev->name = "Asus EeePC extra buttons";
+	eeepc->inputdev->dev.parent = dev;
+	eeepc->inputdev->phys = EEEPC_LAPTOP_FILE "/input0";
+	eeepc->inputdev->id.bustype = BUS_HOST;
+	eeepc->inputdev->getkeycode = eeepc_getkeycode;
+	eeepc->inputdev->setkeycode = eeepc_setkeycode;
 
 	for (key = eeepc_keymap; key->type != KE_END; key++) {
 		switch (key->type) {
 		case KE_KEY:
-			set_bit(EV_KEY, ehotk->inputdev->evbit);
-			set_bit(key->keycode, ehotk->inputdev->keybit);
+			set_bit(EV_KEY, eeepc->inputdev->evbit);
+			set_bit(key->keycode, eeepc->inputdev->keybit);
 			break;
 		}
 	}
-	result = input_register_device(ehotk->inputdev);
+	result = input_register_device(eeepc->inputdev);
 	if (result) {
 		pr_info("Unable to register input device\n");
-		input_free_device(ehotk->inputdev);
+		input_free_device(eeepc->inputdev);
 		return result;
 	}
 	return 0;
@@ -1154,23 +1152,23 @@ static int eeepc_input_init(struct device *dev)
 
 static void eeepc_input_exit(void)
 {
-	if (ehotk->inputdev)
-		input_unregister_device(ehotk->inputdev);
+	if (eeepc->inputdev)
+		input_unregister_device(eeepc->inputdev);
 }
 
 /*
  * ACPI driver
  */
-static void eeepc_hotk_notify(struct acpi_device *device, u32 event)
+static void eeepc_acpi_notify(struct acpi_device *device, u32 event)
 {
 	u16 count;
 
 	if (event > ACPI_MAX_SYS_NOTIFY)
 		return;
-	count = ehotk->event_count[event % 128]++;
-	acpi_bus_generate_proc_event(ehotk->device, event, count);
-	acpi_bus_generate_netlink_event(ehotk->device->pnp.device_class,
-					dev_name(&ehotk->device->dev), event,
+	count = eeepc->event_count[event % 128]++;
+	acpi_bus_generate_proc_event(eeepc->device, event, count);
+	acpi_bus_generate_netlink_event(eeepc->device->pnp.device_class,
+					dev_name(&eeepc->device->dev), event,
 					count);
 
 	if (event >= NOTIFY_BRN_MIN && event <= NOTIFY_BRN_MAX) {
@@ -1202,11 +1200,11 @@ static void cmsg_quirk(int cm, const char *name)
 
 	/* Some BIOSes do not report cm although it is avaliable.
 	   Check if cm_getv[cm] works and, if yes, assume cm should be set. */
-	if (!(ehotk->cm_supported & (1 << cm))
-	    && !read_acpi_int(ehotk->handle, cm_getv[cm], &dummy)) {
+	if (!(eeepc->cm_supported & (1 << cm))
+	    && !read_acpi_int(eeepc->handle, cm_getv[cm], &dummy)) {
 		pr_info("%s (%x) not reported by BIOS,"
 			" enabling anyway\n", name, 1 << cm);
-		ehotk->cm_supported |= 1 << cm;
+		eeepc->cm_supported |= 1 << cm;
 	}
 }
 
@@ -1218,15 +1216,15 @@ static void cmsg_quirks(void)
 	cmsg_quirk(CM_ASL_TPD, "TPD");
 }
 
-static int eeepc_hotk_init(void)
+static int eeepc_acpi_init(void)
 {
 	unsigned int init_flags;
 	int result;
 
-	result = acpi_bus_get_status(ehotk->device);
+	result = acpi_bus_get_status(eeepc->device);
 	if (result)
 		return result;
-	if (!ehotk->device->status.present) {
+	if (!eeepc->device->status.present) {
 		pr_err("Hotkey device not present, aborting\n");
 		return -ENODEV;
 	}
@@ -1234,18 +1232,18 @@ static int eeepc_hotk_init(void)
 	init_flags = DISABLE_ASL_WLAN | DISABLE_ASL_DISPLAYSWITCH;
 	pr_notice("Hotkey init flags 0x%x\n", init_flags);
 
-	if (write_acpi_int(ehotk->handle, "INIT", init_flags)) {
+	if (write_acpi_int(eeepc->handle, "INIT", init_flags)) {
 		pr_err("Hotkey initialization failed\n");
 		return -ENODEV;
 	}
 
 	/* get control methods supported */
-	if (read_acpi_int(ehotk->handle, "CMSG", &ehotk->cm_supported)) {
+	if (read_acpi_int(eeepc->handle, "CMSG", &eeepc->cm_supported)) {
 		pr_err("Get control methods supported failed\n");
 		return -ENODEV;
 	}
 	cmsg_quirks();
-	pr_info("Get control methods supported: 0x%x\n", ehotk->cm_supported);
+	pr_info("Get control methods supported: 0x%x\n", eeepc->cm_supported);
 
 	return 0;
 }
@@ -1260,22 +1258,22 @@ static void __devinit eeepc_enable_camera(void)
 		set_acpi(CM_ASL_CAMERA, 1);
 }
 
-static int __devinit eeepc_hotk_add(struct acpi_device *device)
+static int __devinit eeepc_acpi_add(struct acpi_device *device)
 {
 	struct device *dev;
 	int result;
 
-	pr_notice(EEEPC_HOTK_NAME "\n");
-	ehotk = kzalloc(sizeof(struct eeepc_hotk), GFP_KERNEL);
-	if (!ehotk)
+	pr_notice(EEEPC_LAPTOP_NAME "\n");
+	eeepc = kzalloc(sizeof(struct eeepc_laptop), GFP_KERNEL);
+	if (!eeepc)
 		return -ENOMEM;
-	ehotk->handle = device->handle;
-	strcpy(acpi_device_name(device), EEEPC_HOTK_DEVICE_NAME);
-	strcpy(acpi_device_class(device), EEEPC_HOTK_CLASS);
-	device->driver_data = ehotk;
-	ehotk->device = device;
+	eeepc->handle = device->handle;
+	strcpy(acpi_device_name(device), EEEPC_ACPI_DEVICE_NAME);
+	strcpy(acpi_device_class(device), EEEPC_ACPI_CLASS);
+	device->driver_data = eeepc;
+	eeepc->device = device;
 
-	result = eeepc_hotk_init();
+	result = eeepc_acpi_init();
 	if (result)
 		goto fail_platform;
 	eeepc_enable_camera();
@@ -1283,7 +1281,6 @@ static int __devinit eeepc_hotk_add(struct acpi_device *device)
 	result = eeepc_platform_init();
 	if (result)
 		goto fail_platform;
-
 	dev = &platform_device->dev;
 
 	if (!acpi_video_backlight_support()) {
@@ -1322,12 +1319,12 @@ fail_input:
 fail_backlight:
 	eeepc_platform_exit();
 fail_platform:
-	kfree(ehotk);
+	kfree(eeepc);
 
 	return result;
 }
 
-static int eeepc_hotk_remove(struct acpi_device *device, int type)
+static int eeepc_acpi_remove(struct acpi_device *device, int type)
 {
 	eeepc_backlight_exit();
 	eeepc_rfkill_exit();
@@ -1336,27 +1333,27 @@ static int eeepc_hotk_remove(struct acpi_device *device, int type)
 	eeepc_led_exit();
 	eeepc_platform_exit();
 
-	kfree(ehotk);
+	kfree(eeepc);
 	return 0;
 }
 
 
 static const struct acpi_device_id eeepc_device_ids[] = {
-	{EEEPC_HOTK_HID, 0},
+	{EEEPC_ACPI_HID, 0},
 	{"", 0},
 };
 MODULE_DEVICE_TABLE(acpi, eeepc_device_ids);
 
-static struct acpi_driver eeepc_hotk_driver = {
-	.name = EEEPC_HOTK_NAME,
-	.class = EEEPC_HOTK_CLASS,
+static struct acpi_driver eeepc_acpi_driver = {
+	.name = EEEPC_LAPTOP_NAME,
+	.class = EEEPC_ACPI_CLASS,
 	.owner = THIS_MODULE,
 	.ids = eeepc_device_ids,
 	.flags = ACPI_DRIVER_ALL_NOTIFY_EVENTS,
 	.ops = {
-		.add = eeepc_hotk_add,
-		.remove = eeepc_hotk_remove,
-		.notify = eeepc_hotk_notify,
+		.add = eeepc_acpi_add,
+		.remove = eeepc_acpi_remove,
+		.notify = eeepc_acpi_notify,
 	},
 };
 
@@ -1369,17 +1366,17 @@ static int __init eeepc_laptop_init(void)
 	if (result < 0)
 		return result;
 
-	result = acpi_bus_register_driver(&eeepc_hotk_driver);
+	result = acpi_bus_register_driver(&eeepc_acpi_driver);
 	if (result < 0)
 		goto fail_acpi_driver;
-	if (!ehotk) {
+	if (!eeepc) {
 		result = -ENODEV;
 		goto fail_no_device;
 	}
 	return 0;
 
 fail_no_device:
-	acpi_bus_unregister_driver(&eeepc_hotk_driver);
+	acpi_bus_unregister_driver(&eeepc_acpi_driver);
 fail_acpi_driver:
 	platform_driver_unregister(&platform_driver);
 	return result;
@@ -1387,7 +1384,7 @@ fail_acpi_driver:
 
 static void __exit eeepc_laptop_exit(void)
 {
-	acpi_bus_unregister_driver(&eeepc_hotk_driver);
+	acpi_bus_unregister_driver(&eeepc_acpi_driver);
 	platform_driver_unregister(&platform_driver);
 }
 
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 25/33] eeepc-laptop: callbacks should use "driver data" parameter or field
  2009-12-03  7:45                                               ` [PATCH 24/33] eeepc-laptop: revise names Corentin Chary
@ 2009-12-03  7:45                                                 ` Corentin Chary
  2009-12-03  7:45                                                   ` [PATCH 26/33] asus-laptop: use KEY_F13 to map "Disable Touchpad" event Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:45 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Alan Jenkins, Bjorn Helgaas

From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>

Callback methods should not refer to a variable like "eeepc" (formally
"ehotk").  Instead, they should extract the data they need either from
a "driver data" parameter, or the "driver data" field of the object
which they operate on.  The "eeepc" variable can then be removed.

In practice, drivers under "drivers/platform" can get away without using
driver data, because it doesn't make sense to have more than one
instance of them.  However this makes it harder to review them for
correctness.  This is especially true for core ACPI developers who have
not previously been exposed to this anti-pattern :-).

This will serve as an example of best practice for new driver writers
(whether they find it themselves, or have it pointed out during review
:-).

The hwmon sub-device is a special case.  It uses ec_{read,write} which
are defined to communicate with the (first) EC, so it does not require
any driver data.  It should still only be instantiated in the context of
an ASUS010 device because we don't have a safe way to probe for it.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
CC: Bjorn Helgaas <bjorn.helgaas@hp.com>
---
 drivers/platform/x86/eeepc-laptop.c |  466 ++++++++++++++++++++---------------
 1 files changed, 268 insertions(+), 198 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index b9b5aeb..935ec44 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -128,7 +128,7 @@ struct key_entry {
 
 enum { KE_KEY, KE_END };
 
-static struct key_entry eeepc_keymap[] = {
+static const struct key_entry eeepc_keymap[] = {
 	/* Sleep already handled via generic ACPI code */
 	{KE_KEY, 0x10, KEY_WLAN },
 	{KE_KEY, 0x11, KEY_WLAN },
@@ -153,33 +153,31 @@ static struct key_entry eeepc_keymap[] = {
  * This is the main structure, we can use it to store useful information
  */
 struct eeepc_laptop {
-	struct acpi_device *device;	/* the device we are in */
-	acpi_handle handle;		/* the handle of the hotk device */
+	acpi_handle handle;		/* the handle of the acpi device */
 	u32 cm_supported;		/* the control methods supported
 					   by this BIOS */
 	u16 event_count[128];		/* count for each event */
+
+	struct platform_device *platform_device;
+	struct device *hwmon_device;
+	struct backlight_device *backlight_device;
+
 	struct input_dev *inputdev;
-	u16 *keycode_map;
+	struct key_entry *keymap;
+
 	struct rfkill *wlan_rfkill;
 	struct rfkill *bluetooth_rfkill;
 	struct rfkill *wwan3g_rfkill;
 	struct rfkill *wimax_rfkill;
+
 	struct hotplug_slot *hotplug_slot;
 	struct mutex hotplug_lock;
-};
-
-/* The actual device the driver binds to */
-static struct eeepc_laptop *eeepc;
-
-/* The platform device */
-static struct platform_device *platform_device;
-
-/* The backlight device /sys/class/backlight */
-static struct backlight_device *eeepc_backlight_device;
-
-/* The hwmon device */
-static struct device *eeepc_hwmon_device;
 
+	struct led_classdev tpd_led;
+	int tpd_led_wk;
+	struct workqueue_struct *led_workqueue;
+	struct work_struct tpd_led_work;
+};
 
 /*
  * ACPI Helpers
@@ -214,7 +212,7 @@ static int read_acpi_int(acpi_handle handle, const char *method, int *val)
 	}
 }
 
-static int set_acpi(int cm, int value)
+static int set_acpi(struct eeepc_laptop *eeepc, int cm, int value)
 {
 	const char *method = cm_setv[cm];
 
@@ -228,7 +226,7 @@ static int set_acpi(int cm, int value)
 	return 0;
 }
 
-static int get_acpi(int cm)
+static int get_acpi(struct eeepc_laptop *eeepc, int cm)
 {
 	const char *method = cm_getv[cm];
 	int value;
@@ -243,6 +241,26 @@ static int get_acpi(int cm)
 	return value;
 }
 
+static int acpi_setter_handle(struct eeepc_laptop *eeepc, int cm, acpi_handle *handle)
+{
+	const char *method = cm_setv[cm];
+	acpi_status status;
+
+	if (method == NULL)
+		return -ENODEV;
+	if ((eeepc->cm_supported & (0x1 << cm)) == 0)
+		return -ENODEV;
+
+	status = acpi_get_handle(eeepc->handle, (char *)method,
+			         handle);
+	if (status != AE_OK) {
+		pr_warning("Error finding %s\n", method);
+		return -ENODEV;
+	}
+	return 0;
+}
+
+
 /*
  * Sys helpers
  */
@@ -255,21 +273,24 @@ static int parse_arg(const char *buf, unsigned long count, int *val)
 	return count;
 }
 
-static ssize_t store_sys_acpi(int cm, const char *buf, size_t count)
+static ssize_t store_sys_acpi(struct device *dev, int cm,
+			      const char *buf, size_t count)
 {
+	struct eeepc_laptop *eeepc = dev_get_drvdata(dev);
 	int rv, value;
 
 	rv = parse_arg(buf, count, &value);
 	if (rv > 0)
-		value = set_acpi(cm, value);
+		value = set_acpi(eeepc, cm, value);
 	if (value < 0)
 		return -EIO;
 	return rv;
 }
 
-static ssize_t show_sys_acpi(int cm, char *buf)
+static ssize_t show_sys_acpi(struct device *dev, int cm, char *buf)
 {
-	int value = get_acpi(cm);
+	struct eeepc_laptop *eeepc = dev_get_drvdata(dev);
+	int value = get_acpi(eeepc, cm);
 
 	if (value < 0)
 		return -EIO;
@@ -281,13 +302,13 @@ static ssize_t show_sys_acpi(int cm, char *buf)
 				    struct device_attribute *attr,	\
 				    char *buf)				\
 	{								\
-		return show_sys_acpi(_cm, buf);				\
+		return show_sys_acpi(dev, _cm, buf);			\
 	}								\
 	static ssize_t store_##_name(struct device *dev,		\
 				     struct device_attribute *attr,	\
 				     const char *buf, size_t count)	\
 	{								\
-		return store_sys_acpi(_cm, buf, count);			\
+		return store_sys_acpi(dev, _cm, buf, count);		\
 	}								\
 	static struct device_attribute dev_attr_##_name = {		\
 		.attr = {						\
@@ -306,9 +327,9 @@ struct eeepc_cpufv {
 	int cur;
 };
 
-static int get_cpufv(struct eeepc_cpufv *c)
+static int get_cpufv(struct eeepc_laptop *eeepc, struct eeepc_cpufv *c)
 {
-	c->cur = get_acpi(CM_ASL_CPUFV);
+	c->cur = get_acpi(eeepc, CM_ASL_CPUFV);
 	c->num = (c->cur >> 8) & 0xff;
 	c->cur &= 0xff;
 	if (c->cur < 0 || c->num <= 0 || c->num > 12)
@@ -320,11 +341,12 @@ static ssize_t show_available_cpufv(struct device *dev,
 				    struct device_attribute *attr,
 				    char *buf)
 {
+	struct eeepc_laptop *eeepc = dev_get_drvdata(dev);
 	struct eeepc_cpufv c;
 	int i;
 	ssize_t len = 0;
 
-	if (get_cpufv(&c))
+	if (get_cpufv(eeepc, &c))
 		return -ENODEV;
 	for (i = 0; i < c.num; i++)
 		len += sprintf(buf + len, "%d ", i);
@@ -336,9 +358,10 @@ static ssize_t show_cpufv(struct device *dev,
 			  struct device_attribute *attr,
 			  char *buf)
 {
+	struct eeepc_laptop *eeepc = dev_get_drvdata(dev);
 	struct eeepc_cpufv c;
 
-	if (get_cpufv(&c))
+	if (get_cpufv(eeepc, &c))
 		return -ENODEV;
 	return sprintf(buf, "%#x\n", (c.num << 8) | c.cur);
 }
@@ -347,17 +370,18 @@ static ssize_t store_cpufv(struct device *dev,
 			   struct device_attribute *attr,
 			   const char *buf, size_t count)
 {
+	struct eeepc_laptop *eeepc = dev_get_drvdata(dev);
 	struct eeepc_cpufv c;
 	int rv, value;
 
-	if (get_cpufv(&c))
+	if (get_cpufv(eeepc, &c))
 		return -ENODEV;
 	rv = parse_arg(buf, count, &value);
 	if (rv < 0)
 		return rv;
 	if (!rv || value < 0 || value >= c.num)
 		return -EINVAL;
-	set_acpi(CM_ASL_CPUFV, value);
+	set_acpi(eeepc, CM_ASL_CPUFV, value);
 	return rv;
 }
 
@@ -389,36 +413,37 @@ static struct attribute_group platform_attribute_group = {
 	.attrs = platform_attributes
 };
 
-static int eeepc_platform_init(void)
+static int eeepc_platform_init(struct eeepc_laptop *eeepc)
 {
 	int result;
 
-	platform_device = platform_device_alloc(EEEPC_LAPTOP_FILE, -1);
-	if (!platform_device)
+	eeepc->platform_device = platform_device_alloc(EEEPC_LAPTOP_FILE, -1);
+	if (!eeepc->platform_device)
 		return -ENOMEM;
+	platform_set_drvdata(eeepc->platform_device, eeepc);
 
-	result = platform_device_add(platform_device);
+	result = platform_device_add(eeepc->platform_device);
 	if (result)
 		goto fail_platform_device;
 
-	result = sysfs_create_group(&platform_device->dev.kobj,
+	result = sysfs_create_group(&eeepc->platform_device->dev.kobj,
 				    &platform_attribute_group);
 	if (result)
 		goto fail_sysfs;
 	return 0;
 
 fail_sysfs:
-	platform_device_del(platform_device);
+	platform_device_del(eeepc->platform_device);
 fail_platform_device:
-	platform_device_put(platform_device);
+	platform_device_put(eeepc->platform_device);
 	return result;
 }
 
-static void eeepc_platform_exit(void)
+static void eeepc_platform_exit(struct eeepc_laptop *eeepc)
 {
-	sysfs_remove_group(&platform_device->dev.kobj,
+	sysfs_remove_group(&eeepc->platform_device->dev.kobj,
 			   &platform_attribute_group);
-	platform_device_unregister(platform_device);
+	platform_device_unregister(eeepc->platform_device);
 }
 
 /*
@@ -430,74 +455,76 @@ static void eeepc_platform_exit(void)
  * subsystem asks, we avoid messing with the Asus ACPI stuff during a
  * potentially bad time, such as a timer interrupt.
  */
-static int tpd_led_wk;
+static void tpd_led_update(struct work_struct *work)
+ {
+	struct eeepc_laptop *eeepc;
 
-static void tpd_led_update(struct work_struct *ignored)
-{
-	int value = tpd_led_wk;
-	set_acpi(CM_ASL_TPD, value);
-}
+	eeepc = container_of(work, struct eeepc_laptop, tpd_led_work);
 
-static struct workqueue_struct *led_workqueue;
-static DECLARE_WORK(tpd_led_work, tpd_led_update);
+	set_acpi(eeepc, CM_ASL_TPD, eeepc->tpd_led_wk);
+}
 
 static void tpd_led_set(struct led_classdev *led_cdev,
 			enum led_brightness value)
 {
-	tpd_led_wk = (value > 0) ? 1 : 0;
-	queue_work(led_workqueue, &tpd_led_work);
-}
+	struct eeepc_laptop *eeepc;
 
-static struct led_classdev tpd_led = {
-	.name           = "eeepc::touchpad",
-	.brightness_set = tpd_led_set,
-	.max_brightness = 1
-};
+	eeepc = container_of(led_cdev, struct eeepc_laptop, tpd_led);
 
-static int eeepc_led_init(struct device *dev)
+	eeepc->tpd_led_wk = (value > 0) ? 1 : 0;
+	queue_work(eeepc->led_workqueue, &eeepc->tpd_led_work);
+}
+
+static int eeepc_led_init(struct eeepc_laptop *eeepc)
 {
 	int rv;
 
-	if (get_acpi(CM_ASL_TPD) == -ENODEV)
+	if (get_acpi(eeepc, CM_ASL_TPD) == -ENODEV)
 		return 0;
 
-	led_workqueue = create_singlethread_workqueue("led_workqueue");
-	if (!led_workqueue)
+	eeepc->led_workqueue = create_singlethread_workqueue("led_workqueue");
+	if (!eeepc->led_workqueue)
 		return -ENOMEM;
+	INIT_WORK(&eeepc->tpd_led_work, tpd_led_update);
+
+	eeepc->tpd_led.name = "eeepc::touchpad";
+	eeepc->tpd_led.brightness_set = tpd_led_set;
+	eeepc->tpd_led.max_brightness = 1;
 
-	rv = led_classdev_register(dev, &tpd_led);
+	rv = led_classdev_register(&eeepc->platform_device->dev,
+				   &eeepc->tpd_led);
 	if (rv) {
-		destroy_workqueue(led_workqueue);
+		destroy_workqueue(eeepc->led_workqueue);
 		return rv;
 	}
 
 	return 0;
 }
 
-static void eeepc_led_exit(void)
+static void eeepc_led_exit(struct eeepc_laptop *eeepc)
 {
-	if (tpd_led.dev)
-		led_classdev_unregister(&tpd_led);
-	if (led_workqueue)
-		destroy_workqueue(led_workqueue);
+	if (eeepc->tpd_led.dev)
+		led_classdev_unregister(&eeepc->tpd_led);
+	if (eeepc->led_workqueue)
+		destroy_workqueue(eeepc->led_workqueue);
 }
 
 
 /*
  * PCI hotplug (for wlan rfkill)
  */
-static bool eeepc_wlan_rfkill_blocked(void)
+static bool eeepc_wlan_rfkill_blocked(struct eeepc_laptop *eeepc)
 {
-	if (get_acpi(CM_ASL_WLAN) == 1)
+	if (get_acpi(eeepc, CM_ASL_WLAN) == 1)
 		return false;
 	return true;
 }
 
-static void eeepc_rfkill_hotplug(void)
+static void eeepc_rfkill_hotplug(struct eeepc_laptop *eeepc)
 {
 	struct pci_dev *dev;
 	struct pci_bus *bus;
-	bool blocked = eeepc_wlan_rfkill_blocked();
+	bool blocked = eeepc_wlan_rfkill_blocked(eeepc);
 
 	if (eeepc->wlan_rfkill)
 		rfkill_set_sw_state(eeepc->wlan_rfkill, blocked);
@@ -539,15 +566,18 @@ out_unlock:
 
 static void eeepc_rfkill_notify(acpi_handle handle, u32 event, void *data)
 {
+	struct eeepc_laptop *eeepc = data;
+
 	if (event != ACPI_NOTIFY_BUS_CHECK)
 		return;
 
-	eeepc_rfkill_hotplug();
+	eeepc_rfkill_hotplug(eeepc);
 }
 
-static int eeepc_register_rfkill_notifier(char *node)
+static int eeepc_register_rfkill_notifier(struct eeepc_laptop *eeepc,
+					  char *node)
 {
-	acpi_status status = AE_OK;
+	acpi_status status;
 	acpi_handle handle;
 
 	status = acpi_get_handle(NULL, node, &handle);
@@ -556,7 +586,7 @@ static int eeepc_register_rfkill_notifier(char *node)
 		status = acpi_install_notify_handler(handle,
 						     ACPI_SYSTEM_NOTIFY,
 						     eeepc_rfkill_notify,
-						     NULL);
+						     eeepc);
 		if (ACPI_FAILURE(status))
 			pr_warning("Failed to register notify on %s\n", node);
 	} else
@@ -565,7 +595,8 @@ static int eeepc_register_rfkill_notifier(char *node)
 	return 0;
 }
 
-static void eeepc_unregister_rfkill_notifier(char *node)
+static void eeepc_unregister_rfkill_notifier(struct eeepc_laptop *eeepc,
+					     char *node)
 {
 	acpi_status status = AE_OK;
 	acpi_handle handle;
@@ -585,7 +616,8 @@ static void eeepc_unregister_rfkill_notifier(char *node)
 static int eeepc_get_adapter_status(struct hotplug_slot *hotplug_slot,
 				    u8 *value)
 {
-	int val = get_acpi(CM_ASL_WLAN);
+	struct eeepc_laptop *eeepc = hotplug_slot->private;
+	int val = get_acpi(eeepc, CM_ASL_WLAN);
 
 	if (val == 1 || val == 0)
 		*value = val;
@@ -607,7 +639,7 @@ static struct hotplug_slot_ops eeepc_hotplug_slot_ops = {
 	.get_power_status = eeepc_get_adapter_status,
 };
 
-static int eeepc_setup_pci_hotplug(void)
+static int eeepc_setup_pci_hotplug(struct eeepc_laptop *eeepc)
 {
 	int ret = -ENOMEM;
 	struct pci_bus *bus = pci_find_bus(0, 1);
@@ -654,31 +686,34 @@ error_slot:
  */
 static int eeepc_rfkill_set(void *data, bool blocked)
 {
-	unsigned long asl = (unsigned long)data;
-	return set_acpi(asl, !blocked);
+	acpi_handle handle = data;
+
+	return write_acpi_int(handle, NULL, !blocked);
 }
 
 static const struct rfkill_ops eeepc_rfkill_ops = {
 	.set_block = eeepc_rfkill_set,
 };
 
-static int eeepc_new_rfkill(struct rfkill **rfkill,
-			    const char *name, struct device *dev,
+static int eeepc_new_rfkill(struct eeepc_laptop *eeepc,
+			    struct rfkill **rfkill,
+			    const char *name,
 			    enum rfkill_type type, int cm)
 {
+	acpi_handle handle;
 	int result;
 
-	result = get_acpi(cm);
+	result = acpi_setter_handle(eeepc, cm, &handle);
 	if (result < 0)
 		return result;
 
-	*rfkill = rfkill_alloc(name, dev, type,
-			       &eeepc_rfkill_ops, (void *)(unsigned long)cm);
+	*rfkill = rfkill_alloc(name, &eeepc->platform_device->dev, type,
+			       &eeepc_rfkill_ops, handle);
 
 	if (!*rfkill)
 		return -EINVAL;
 
-	rfkill_init_sw_state(*rfkill, get_acpi(cm) != 1);
+	rfkill_init_sw_state(*rfkill, get_acpi(eeepc, cm) != 1);
 	result = rfkill_register(*rfkill);
 	if (result) {
 		rfkill_destroy(*rfkill);
@@ -688,11 +723,11 @@ static int eeepc_new_rfkill(struct rfkill **rfkill,
 	return 0;
 }
 
-static void eeepc_rfkill_exit(void)
+static void eeepc_rfkill_exit(struct eeepc_laptop *eeepc)
 {
-	eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P5");
-	eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P6");
-	eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P7");
+	eeepc_unregister_rfkill_notifier(eeepc, "\\_SB.PCI0.P0P5");
+	eeepc_unregister_rfkill_notifier(eeepc, "\\_SB.PCI0.P0P6");
+	eeepc_unregister_rfkill_notifier(eeepc, "\\_SB.PCI0.P0P7");
 	if (eeepc->wlan_rfkill) {
 		rfkill_unregister(eeepc->wlan_rfkill);
 		rfkill_destroy(eeepc->wlan_rfkill);
@@ -702,7 +737,7 @@ static void eeepc_rfkill_exit(void)
 	 * Refresh pci hotplug in case the rfkill state was changed after
 	 * eeepc_unregister_rfkill_notifier()
 	 */
-	eeepc_rfkill_hotplug();
+	eeepc_rfkill_hotplug(eeepc);
 	if (eeepc->hotplug_slot)
 		pci_hp_deregister(eeepc->hotplug_slot);
 
@@ -723,41 +758,41 @@ static void eeepc_rfkill_exit(void)
 	}
 }
 
-static int eeepc_rfkill_init(struct device *dev)
+static int eeepc_rfkill_init(struct eeepc_laptop *eeepc)
 {
 	int result = 0;
 
 	mutex_init(&eeepc->hotplug_lock);
 
-	result = eeepc_new_rfkill(&eeepc->wlan_rfkill,
-				  "eeepc-wlan", dev,
-				  RFKILL_TYPE_WLAN, CM_ASL_WLAN);
+	result = eeepc_new_rfkill(eeepc, &eeepc->wlan_rfkill,
+				  "eeepc-wlan", RFKILL_TYPE_WLAN,
+				  CM_ASL_WLAN);
 
 	if (result && result != -ENODEV)
 		goto exit;
 
-	result = eeepc_new_rfkill(&eeepc->bluetooth_rfkill,
-				  "eeepc-bluetooth", dev,
-				  RFKILL_TYPE_BLUETOOTH, CM_ASL_BLUETOOTH);
+	result = eeepc_new_rfkill(eeepc, &eeepc->bluetooth_rfkill,
+				  "eeepc-bluetooth", RFKILL_TYPE_BLUETOOTH,
+				  CM_ASL_BLUETOOTH);
 
 	if (result && result != -ENODEV)
 		goto exit;
 
-	result = eeepc_new_rfkill(&eeepc->wwan3g_rfkill,
-				  "eeepc-wwan3g", dev,
-				  RFKILL_TYPE_WWAN, CM_ASL_3G);
+	result = eeepc_new_rfkill(eeepc, &eeepc->wwan3g_rfkill,
+				  "eeepc-wwan3g", RFKILL_TYPE_WWAN,
+				  CM_ASL_3G);
 
 	if (result && result != -ENODEV)
 		goto exit;
 
-	result = eeepc_new_rfkill(&eeepc->wimax_rfkill,
-				  "eeepc-wimax", dev,
-				  RFKILL_TYPE_WIMAX, CM_ASL_WIMAX);
+	result = eeepc_new_rfkill(eeepc, &eeepc->wimax_rfkill,
+				  "eeepc-wimax", RFKILL_TYPE_WIMAX,
+				  CM_ASL_WIMAX);
 
 	if (result && result != -ENODEV)
 		goto exit;
 
-	result = eeepc_setup_pci_hotplug();
+	result = eeepc_setup_pci_hotplug(eeepc);
 	/*
 	 * If we get -EBUSY then something else is handling the PCI hotplug -
 	 * don't fail in this case
@@ -765,26 +800,28 @@ static int eeepc_rfkill_init(struct device *dev)
 	if (result == -EBUSY)
 		result = 0;
 
-	eeepc_register_rfkill_notifier("\\_SB.PCI0.P0P5");
-	eeepc_register_rfkill_notifier("\\_SB.PCI0.P0P6");
-	eeepc_register_rfkill_notifier("\\_SB.PCI0.P0P7");
+	eeepc_register_rfkill_notifier(eeepc, "\\_SB.PCI0.P0P5");
+	eeepc_register_rfkill_notifier(eeepc, "\\_SB.PCI0.P0P6");
+	eeepc_register_rfkill_notifier(eeepc, "\\_SB.PCI0.P0P7");
 	/*
 	 * Refresh pci hotplug in case the rfkill state was changed during
 	 * setup.
 	 */
-	eeepc_rfkill_hotplug();
+	eeepc_rfkill_hotplug(eeepc);
 
 exit:
 	if (result && result != -ENODEV)
-		eeepc_rfkill_exit();
+		eeepc_rfkill_exit(eeepc);
 	return result;
 }
 
 /*
  * Platform driver - hibernate/resume callbacks
  */
-static int eeepc_thaw(struct device *device)
+static int eeepc_hotk_thaw(struct device *device)
 {
+	struct eeepc_laptop *eeepc = dev_get_drvdata(device);
+
 	if (eeepc->wlan_rfkill) {
 		bool wlan;
 
@@ -793,35 +830,37 @@ static int eeepc_thaw(struct device *device)
 		 * during suspend.  Normally it restores it on resume, but
 		 * we should kick it ourselves in case hibernation is aborted.
 		 */
-		wlan = get_acpi(CM_ASL_WLAN);
-		set_acpi(CM_ASL_WLAN, wlan);
+		wlan = get_acpi(eeepc, CM_ASL_WLAN);
+		set_acpi(eeepc, CM_ASL_WLAN, wlan);
 	}
 
 	return 0;
 }
 
-static int eeepc_restore(struct device *device)
+static int eeepc_hotk_restore(struct device *device)
 {
+	struct eeepc_laptop *eeepc = dev_get_drvdata(device);
+
 	/* Refresh both wlan rfkill state and pci hotplug */
 	if (eeepc->wlan_rfkill)
-		eeepc_rfkill_hotplug();
+		eeepc_rfkill_hotplug(eeepc);
 
 	if (eeepc->bluetooth_rfkill)
 		rfkill_set_sw_state(eeepc->bluetooth_rfkill,
-				    get_acpi(CM_ASL_BLUETOOTH) != 1);
+				    get_acpi(eeepc, CM_ASL_BLUETOOTH) != 1);
 	if (eeepc->wwan3g_rfkill)
 		rfkill_set_sw_state(eeepc->wwan3g_rfkill,
-				    get_acpi(CM_ASL_3G) != 1);
+				    get_acpi(eeepc, CM_ASL_3G) != 1);
 	if (eeepc->wimax_rfkill)
 		rfkill_set_sw_state(eeepc->wimax_rfkill,
-				    get_acpi(CM_ASL_WIMAX) != 1);
+				    get_acpi(eeepc, CM_ASL_WIMAX) != 1);
 
 	return 0;
 }
 
 static struct dev_pm_ops eeepc_pm_ops = {
-	.thaw = eeepc_thaw,
-	.restore = eeepc_restore,
+	.thaw = eeepc_hotk_thaw,
+	.restore = eeepc_hotk_restore,
 };
 
 static struct platform_driver platform_driver = {
@@ -947,35 +986,35 @@ static struct attribute_group hwmon_attribute_group = {
 	.attrs = hwmon_attributes
 };
 
-static void eeepc_hwmon_exit(void)
+static void eeepc_hwmon_exit(struct eeepc_laptop *eeepc)
 {
 	struct device *hwmon;
 
-	hwmon = eeepc_hwmon_device;
+	hwmon = eeepc->hwmon_device;
 	if (!hwmon)
-		return ;
+		return;
 	sysfs_remove_group(&hwmon->kobj,
 			   &hwmon_attribute_group);
 	hwmon_device_unregister(hwmon);
-	eeepc_hwmon_device = NULL;
+	eeepc->hwmon_device = NULL;
 }
 
-static int eeepc_hwmon_init(struct device *dev)
+static int eeepc_hwmon_init(struct eeepc_laptop *eeepc)
 {
 	struct device *hwmon;
 	int result;
 
-	hwmon = hwmon_device_register(dev);
+	hwmon = hwmon_device_register(&eeepc->platform_device->dev);
 	if (IS_ERR(hwmon)) {
 		pr_err("Could not register eeepc hwmon device\n");
-		eeepc_hwmon_device = NULL;
+		eeepc->hwmon_device = NULL;
 		return PTR_ERR(hwmon);
 	}
-	eeepc_hwmon_device = hwmon;
+	eeepc->hwmon_device = hwmon;
 	result = sysfs_create_group(&hwmon->kobj,
 				    &hwmon_attribute_group);
 	if (result)
-		eeepc_hwmon_exit();
+		eeepc_hwmon_exit(eeepc);
 	return result;
 }
 
@@ -984,12 +1023,16 @@ static int eeepc_hwmon_init(struct device *dev)
  */
 static int read_brightness(struct backlight_device *bd)
 {
-	return get_acpi(CM_ASL_PANELBRIGHT);
+	struct eeepc_laptop *eeepc = bl_get_data(bd);
+
+	return get_acpi(eeepc, CM_ASL_PANELBRIGHT);
 }
 
 static int set_brightness(struct backlight_device *bd, int value)
 {
-	return set_acpi(CM_ASL_PANELBRIGHT, value);
+	struct eeepc_laptop *eeepc = bl_get_data(bd);
+
+	return set_acpi(eeepc, CM_ASL_PANELBRIGHT, value);
 }
 
 static int update_bl_status(struct backlight_device *bd)
@@ -1002,9 +1045,9 @@ static struct backlight_ops eeepcbl_ops = {
 	.update_status = update_bl_status,
 };
 
-static int eeepc_backlight_notify(void)
+static int eeepc_backlight_notify(struct eeepc_laptop *eeepc)
 {
-	struct backlight_device *bd = eeepc_backlight_device;
+	struct backlight_device *bd = eeepc->backlight_device;
 	int old = bd->props.brightness;
 
 	backlight_force_update(bd, BACKLIGHT_UPDATE_HOTKEY);
@@ -1012,52 +1055,55 @@ static int eeepc_backlight_notify(void)
 	return old;
 }
 
-static int eeepc_backlight_init(struct device *dev)
+static int eeepc_backlight_init(struct eeepc_laptop *eeepc)
 {
 	struct backlight_device *bd;
 
-	bd = backlight_device_register(EEEPC_LAPTOP_FILE, dev,
-				       NULL, &eeepcbl_ops);
+	bd = backlight_device_register(EEEPC_LAPTOP_FILE,
+				       &eeepc->platform_device->dev,
+				       eeepc, &eeepcbl_ops);
 	if (IS_ERR(bd)) {
 		pr_err("Could not register eeepc backlight device\n");
-		eeepc_backlight_device = NULL;
+		eeepc->backlight_device = NULL;
 		return PTR_ERR(bd);
 	}
-	eeepc_backlight_device = bd;
+	eeepc->backlight_device = bd;
 	bd->props.max_brightness = 15;
-	bd->props.brightness = read_brightness(NULL);
+	bd->props.brightness = read_brightness(bd);
 	bd->props.power = FB_BLANK_UNBLANK;
 	backlight_update_status(bd);
 	return 0;
 }
 
-static void eeepc_backlight_exit(void)
+static void eeepc_backlight_exit(struct eeepc_laptop *eeepc)
 {
-	if (eeepc_backlight_device)
-		backlight_device_unregister(eeepc_backlight_device);
-	eeepc_backlight_device = NULL;
+	if (eeepc->backlight_device)
+		backlight_device_unregister(eeepc->backlight_device);
+	eeepc->backlight_device = NULL;
 }
 
 
 /*
  * Input device (i.e. hotkeys)
  */
-static struct key_entry *eeepc_get_entry_by_scancode(int code)
+static struct key_entry *eeepc_get_entry_by_scancode(
+	struct eeepc_laptop *eeepc,
+	int code)
 {
 	struct key_entry *key;
 
-	for (key = eeepc_keymap; key->type != KE_END; key++)
+	for (key = eeepc->keymap; key->type != KE_END; key++)
 		if (code == key->code)
 			return key;
 
 	return NULL;
 }
 
-static void eeepc_input_notify(int event)
+static void eeepc_input_notify(struct eeepc_laptop *eeepc, int event)
 {
 	static struct key_entry *key;
 
-	key = eeepc_get_entry_by_scancode(event);
+	key = eeepc_get_entry_by_scancode(eeepc, event);
 	if (key) {
 		switch (key->type) {
 		case KE_KEY:
@@ -1072,11 +1118,12 @@ static void eeepc_input_notify(int event)
 	}
 }
 
-static struct key_entry *eepc_get_entry_by_keycode(int code)
+static struct key_entry *eeepc_get_entry_by_keycode(
+	struct eeepc_laptop *eeepc, int code)
 {
 	struct key_entry *key;
 
-	for (key = eeepc_keymap; key->type != KE_END; key++)
+	for (key = eeepc->keymap; key->type != KE_END; key++)
 		if (code == key->keycode && key->type == KE_KEY)
 			return key;
 
@@ -1085,7 +1132,8 @@ static struct key_entry *eepc_get_entry_by_keycode(int code)
 
 static int eeepc_getkeycode(struct input_dev *dev, int scancode, int *keycode)
 {
-	struct key_entry *key = eeepc_get_entry_by_scancode(scancode);
+	struct eeepc_laptop *eeepc = input_get_drvdata(dev);
+	struct key_entry *key = eeepc_get_entry_by_scancode(eeepc, scancode);
 
 	if (key && key->type == KE_KEY) {
 		*keycode = key->keycode;
@@ -1097,18 +1145,19 @@ static int eeepc_getkeycode(struct input_dev *dev, int scancode, int *keycode)
 
 static int eeepc_setkeycode(struct input_dev *dev, int scancode, int keycode)
 {
+	struct eeepc_laptop *eeepc = input_get_drvdata(dev);
 	struct key_entry *key;
 	int old_keycode;
 
 	if (keycode < 0 || keycode > KEY_MAX)
 		return -EINVAL;
 
-	key = eeepc_get_entry_by_scancode(scancode);
+	key = eeepc_get_entry_by_scancode(eeepc, scancode);
 	if (key && key->type == KE_KEY) {
 		old_keycode = key->keycode;
 		key->keycode = keycode;
 		set_bit(keycode, dev->keybit);
-		if (!eepc_get_entry_by_keycode(old_keycode))
+		if (!eeepc_get_entry_by_keycode(eeepc, old_keycode))
 			clear_bit(old_keycode, dev->keybit);
 		return 0;
 	}
@@ -1116,7 +1165,7 @@ static int eeepc_setkeycode(struct input_dev *dev, int scancode, int keycode)
 	return -EINVAL;
 }
 
-static int eeepc_input_init(struct device *dev)
+static int eeepc_input_init(struct eeepc_laptop *eeepc)
 {
 	const struct key_entry *key;
 	int result;
@@ -1127,12 +1176,15 @@ static int eeepc_input_init(struct device *dev)
 		return -ENOMEM;
 	}
 	eeepc->inputdev->name = "Asus EeePC extra buttons";
-	eeepc->inputdev->dev.parent = dev;
+	eeepc->inputdev->dev.parent = &eeepc->platform_device->dev;
 	eeepc->inputdev->phys = EEEPC_LAPTOP_FILE "/input0";
 	eeepc->inputdev->id.bustype = BUS_HOST;
 	eeepc->inputdev->getkeycode = eeepc_getkeycode;
 	eeepc->inputdev->setkeycode = eeepc_setkeycode;
+	input_set_drvdata(eeepc->inputdev, eeepc);
 
+	eeepc->keymap = kmemdup(eeepc_keymap, sizeof(eeepc_keymap),
+				GFP_KERNEL);
 	for (key = eeepc_keymap; key->type != KE_END; key++) {
 		switch (key->type) {
 		case KE_KEY:
@@ -1150,10 +1202,12 @@ static int eeepc_input_init(struct device *dev)
 	return 0;
 }
 
-static void eeepc_input_exit(void)
+static void eeepc_input_exit(struct eeepc_laptop *eeepc)
 {
-	if (eeepc->inputdev)
+	if (eeepc->inputdev) {
 		input_unregister_device(eeepc->inputdev);
+		kfree(eeepc->keymap);
+	}
 }
 
 /*
@@ -1161,21 +1215,22 @@ static void eeepc_input_exit(void)
  */
 static void eeepc_acpi_notify(struct acpi_device *device, u32 event)
 {
+	struct eeepc_laptop *eeepc = acpi_driver_data(device);
 	u16 count;
 
 	if (event > ACPI_MAX_SYS_NOTIFY)
 		return;
 	count = eeepc->event_count[event % 128]++;
-	acpi_bus_generate_proc_event(eeepc->device, event, count);
-	acpi_bus_generate_netlink_event(eeepc->device->pnp.device_class,
-					dev_name(&eeepc->device->dev), event,
+	acpi_bus_generate_proc_event(device, event, count);
+	acpi_bus_generate_netlink_event(device->pnp.device_class,
+					dev_name(&device->dev), event,
 					count);
 
 	if (event >= NOTIFY_BRN_MIN && event <= NOTIFY_BRN_MAX) {
 		int old_brightness, new_brightness;
 
 		/* Update backlight device. */
-		old_brightness = eeepc_backlight_notify();
+		old_brightness = eeepc_backlight_notify(eeepc);
 
 		/* Convert brightness event to keypress (obsolescent hack). */
 		new_brightness = event - NOTIFY_BRN_MIN;
@@ -1191,10 +1246,10 @@ static void eeepc_acpi_notify(struct acpi_device *device, u32 event)
 			 */
 		}
 	}
-	eeepc_input_notify(event);
+	eeepc_input_notify(eeepc, event);
 }
 
-static void cmsg_quirk(int cm, const char *name)
+static void cmsg_quirk(struct eeepc_laptop *eeepc, int cm, const char *name)
 {
 	int dummy;
 
@@ -1208,23 +1263,23 @@ static void cmsg_quirk(int cm, const char *name)
 	}
 }
 
-static void cmsg_quirks(void)
+static void cmsg_quirks(struct eeepc_laptop *eeepc)
 {
-	cmsg_quirk(CM_ASL_LID, "LID");
-	cmsg_quirk(CM_ASL_TYPE, "TYPE");
-	cmsg_quirk(CM_ASL_PANELPOWER, "PANELPOWER");
-	cmsg_quirk(CM_ASL_TPD, "TPD");
+	cmsg_quirk(eeepc, CM_ASL_LID, "LID");
+	cmsg_quirk(eeepc, CM_ASL_TYPE, "TYPE");
+	cmsg_quirk(eeepc, CM_ASL_PANELPOWER, "PANELPOWER");
+	cmsg_quirk(eeepc, CM_ASL_TPD, "TPD");
 }
 
-static int eeepc_acpi_init(void)
+static int eeepc_acpi_init(struct eeepc_laptop *eeepc, struct acpi_device *device)
 {
 	unsigned int init_flags;
 	int result;
 
-	result = acpi_bus_get_status(eeepc->device);
+	result = acpi_bus_get_status(device);
 	if (result)
 		return result;
-	if (!eeepc->device->status.present) {
+	if (!device->status.present) {
 		pr_err("Hotkey device not present, aborting\n");
 		return -ENODEV;
 	}
@@ -1242,25 +1297,27 @@ static int eeepc_acpi_init(void)
 		pr_err("Get control methods supported failed\n");
 		return -ENODEV;
 	}
-	cmsg_quirks();
+	cmsg_quirks(eeepc);
 	pr_info("Get control methods supported: 0x%x\n", eeepc->cm_supported);
 
 	return 0;
 }
 
-static void __devinit eeepc_enable_camera(void)
+static void __devinit eeepc_enable_camera(struct eeepc_laptop *eeepc)
 {
 	/*
 	 * If the following call to set_acpi() fails, it's because there's no
 	 * camera so we can ignore the error.
 	 */
-	if (get_acpi(CM_ASL_CAMERA) == 0)
-		set_acpi(CM_ASL_CAMERA, 1);
+	if (get_acpi(eeepc, CM_ASL_CAMERA) == 0)
+		set_acpi(eeepc, CM_ASL_CAMERA, 1);
 }
 
+static bool eeepc_device_present;
+
 static int __devinit eeepc_acpi_add(struct acpi_device *device)
 {
-	struct device *dev;
+	struct eeepc_laptop *eeepc;
 	int result;
 
 	pr_notice(EEEPC_LAPTOP_NAME "\n");
@@ -1271,53 +1328,64 @@ static int __devinit eeepc_acpi_add(struct acpi_device *device)
 	strcpy(acpi_device_name(device), EEEPC_ACPI_DEVICE_NAME);
 	strcpy(acpi_device_class(device), EEEPC_ACPI_CLASS);
 	device->driver_data = eeepc;
-	eeepc->device = device;
 
-	result = eeepc_acpi_init();
+	result = eeepc_acpi_init(eeepc, device);
 	if (result)
 		goto fail_platform;
-	eeepc_enable_camera();
+	eeepc_enable_camera(eeepc);
 
-	result = eeepc_platform_init();
+	/*
+	 * Register the platform device first.  It is used as a parent for the
+	 * sub-devices below.
+	 *
+	 * Note that if there are multiple instances of this ACPI device it
+	 * will bail out, because the platform device is registered with a
+	 * fixed name.  Of course it doesn't make sense to have more than one,
+	 * and machine-specific scripts find the fixed name convenient.  But
+	 * It's also good for us to exclude multiple instances because both
+	 * our hwmon and our wlan rfkill subdevice use global ACPI objects
+	 * (the EC and the wlan PCI slot respectively).
+	 */
+	result = eeepc_platform_init(eeepc);
 	if (result)
 		goto fail_platform;
-	dev = &platform_device->dev;
 
 	if (!acpi_video_backlight_support()) {
-		result = eeepc_backlight_init(dev);
+		result = eeepc_backlight_init(eeepc);
 		if (result)
 			goto fail_backlight;
 	} else
 		pr_info("Backlight controlled by ACPI video driver\n");
 
-	result = eeepc_input_init(dev);
+	result = eeepc_input_init(eeepc);
 	if (result)
 		goto fail_input;
 
-	result = eeepc_hwmon_init(dev);
+	result = eeepc_hwmon_init(eeepc);
 	if (result)
 		goto fail_hwmon;
 
-	result = eeepc_led_init(dev);
+	result = eeepc_led_init(eeepc);
 	if (result)
 		goto fail_led;
 
-	result = eeepc_rfkill_init(dev);
+	result = eeepc_rfkill_init(eeepc);
 	if (result)
 		goto fail_rfkill;
 
+	eeepc_device_present = true;
 	return 0;
 
 fail_rfkill:
-	eeepc_led_exit();
+	eeepc_led_exit(eeepc);
 fail_led:
-	eeepc_hwmon_exit();
+	eeepc_hwmon_exit(eeepc);
 fail_hwmon:
-	eeepc_input_exit();
+	eeepc_input_exit(eeepc);
 fail_input:
-	eeepc_backlight_exit();
+	eeepc_backlight_exit(eeepc);
 fail_backlight:
-	eeepc_platform_exit();
+	eeepc_platform_exit(eeepc);
 fail_platform:
 	kfree(eeepc);
 
@@ -1326,12 +1394,14 @@ fail_platform:
 
 static int eeepc_acpi_remove(struct acpi_device *device, int type)
 {
-	eeepc_backlight_exit();
-	eeepc_rfkill_exit();
-	eeepc_input_exit();
-	eeepc_hwmon_exit();
-	eeepc_led_exit();
-	eeepc_platform_exit();
+	struct eeepc_laptop *eeepc = acpi_driver_data(device);
+
+	eeepc_backlight_exit(eeepc);
+	eeepc_rfkill_exit(eeepc);
+	eeepc_input_exit(eeepc);
+	eeepc_hwmon_exit(eeepc);
+	eeepc_led_exit(eeepc);
+	eeepc_platform_exit(eeepc);
 
 	kfree(eeepc);
 	return 0;
@@ -1369,7 +1439,7 @@ static int __init eeepc_laptop_init(void)
 	result = acpi_bus_register_driver(&eeepc_acpi_driver);
 	if (result < 0)
 		goto fail_acpi_driver;
-	if (!eeepc) {
+	if (!eeepc_device_present) {
 		result = -ENODEV;
 		goto fail_no_device;
 	}
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 26/33] asus-laptop: use KEY_F13 to map "Disable Touchpad" event
  2009-12-03  7:45                                                 ` [PATCH 25/33] eeepc-laptop: callbacks should use "driver data" parameter or field Corentin Chary
@ 2009-12-03  7:45                                                   ` Corentin Chary
  2009-12-03  7:45                                                     ` [PATCH 27/33] asus-laptop: add Lenovo SL hotkey support Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:45 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Corentin Chary

The same key is used in toshiba-laptop, and there is no
reserved key for that.

Signed-off-by: Corentin Chary <corentincj@iksaif.net>
---
 drivers/platform/x86/asus-laptop.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/platform/x86/asus-laptop.c b/drivers/platform/x86/asus-laptop.c
index 6c05172..e931e80 100644
--- a/drivers/platform/x86/asus-laptop.c
+++ b/drivers/platform/x86/asus-laptop.c
@@ -313,7 +313,7 @@ static struct key_entry asus_keymap[] = {
 	{KE_KEY, 0x5F, KEY_WLAN},
 	{KE_KEY, 0x60, KEY_SWITCHVIDEOMODE},
 	{KE_KEY, 0x61, KEY_SWITCHVIDEOMODE},
-	{KE_KEY, 0x6B, BTN_TOUCH}, /* Lock Mouse */
+	{KE_KEY, 0x6B, KEY_F13}, /* Lock Touchpad */
 	{KE_KEY, 0x82, KEY_CAMERA},
 	{KE_KEY, 0x8A, KEY_PROG1},
 	{KE_KEY, 0x95, KEY_MEDIA},
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 27/33] asus-laptop: add Lenovo SL hotkey support
  2009-12-03  7:45                                                   ` [PATCH 26/33] asus-laptop: use KEY_F13 to map "Disable Touchpad" event Corentin Chary
@ 2009-12-03  7:45                                                     ` Corentin Chary
  2009-12-03  7:45                                                       ` [PATCH 28/33] asus-laptop: Add wlan switch found on V6V Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:45 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Ike Panhc

From: Ike Panhc <ike.pan@canonical.com>

Lenovo SL series laptop has a very similar DSDT with Asus laptops. We can
easily have the extra ACPI function support with little modification in
asus-laptop.c

Here is the hotkey enablement for Lenovo SL series laptop.

This patch will enable the following hotkey:
 - Volumn Up
 - Volumn Down
 - Mute
 - Screen Lock (Fn+F2)
 - Battery Status (Fn+F3)
 - WLAN switch (Fn+F5)
 - Video output switch (Fn+F7)
 - Touchpad switch (Fn+F8)
 - Screen Magnifier (Fn+Space)

The following function of Lenovo SL laptop is still need to be enabled:
 - Hotkey: KEY_SUSPEND (Fn+F4), KEY_SLEEP (Fn+F12), Dock Eject (Fn+F9)
 - Rfkill for bluetooth and wlan
 - LenovoCare LED
 - Hwmon for fan speed
 - Fingerprint scanner
 - Active Protection System

Signed-off-by: Ike Panhc <ike.pan@canonical.com>
---
 drivers/platform/x86/asus-laptop.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/platform/x86/asus-laptop.c b/drivers/platform/x86/asus-laptop.c
index e931e80..83948df 100644
--- a/drivers/platform/x86/asus-laptop.c
+++ b/drivers/platform/x86/asus-laptop.c
@@ -221,6 +221,7 @@ static struct asus_hotk *hotk;
  */
 static const struct acpi_device_id asus_device_ids[] = {
 	{"ATK0100", 0},
+	{"ATK0101", 0},
 	{"", 0},
 };
 MODULE_DEVICE_TABLE(acpi, asus_device_ids);
@@ -294,6 +295,11 @@ struct key_entry {
 enum { KE_KEY, KE_END };
 
 static struct key_entry asus_keymap[] = {
+	{KE_KEY, 0x02, KEY_SCREENLOCK},
+	{KE_KEY, 0x05, KEY_WLAN},
+	{KE_KEY, 0x08, KEY_F13},
+	{KE_KEY, 0x17, KEY_ZOOM},
+	{KE_KEY, 0x1f, KEY_BATTERY},
 	{KE_KEY, 0x30, KEY_VOLUMEUP},
 	{KE_KEY, 0x31, KEY_VOLUMEDOWN},
 	{KE_KEY, 0x32, KEY_MUTE},
@@ -313,6 +319,8 @@ static struct key_entry asus_keymap[] = {
 	{KE_KEY, 0x5F, KEY_WLAN},
 	{KE_KEY, 0x60, KEY_SWITCHVIDEOMODE},
 	{KE_KEY, 0x61, KEY_SWITCHVIDEOMODE},
+	{KE_KEY, 0x62, KEY_SWITCHVIDEOMODE},
+	{KE_KEY, 0x63, KEY_SWITCHVIDEOMODE},
 	{KE_KEY, 0x6B, KEY_F13}, /* Lock Touchpad */
 	{KE_KEY, 0x82, KEY_CAMERA},
 	{KE_KEY, 0x8A, KEY_PROG1},
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 28/33] asus-laptop: Add wlan switch found on V6V
  2009-12-03  7:45                                                     ` [PATCH 27/33] asus-laptop: add Lenovo SL hotkey support Corentin Chary
@ 2009-12-03  7:45                                                       ` Corentin Chary
  2009-12-03  7:45                                                         ` [PATCH 29/33] eeepc-laptop: map keys found on newer eeepc Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:45 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Corentin Chary

Signed-off-by: Corentin Chary <corentincj@iksaif.net>
---
 drivers/platform/x86/asus-laptop.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/platform/x86/asus-laptop.c b/drivers/platform/x86/asus-laptop.c
index 83948df..3348cc6 100644
--- a/drivers/platform/x86/asus-laptop.c
+++ b/drivers/platform/x86/asus-laptop.c
@@ -323,6 +323,7 @@ static struct key_entry asus_keymap[] = {
 	{KE_KEY, 0x63, KEY_SWITCHVIDEOMODE},
 	{KE_KEY, 0x6B, KEY_F13}, /* Lock Touchpad */
 	{KE_KEY, 0x82, KEY_CAMERA},
+	{KE_KEY, 0x88, KEY_WLAN },
 	{KE_KEY, 0x8A, KEY_PROG1},
 	{KE_KEY, 0x95, KEY_MEDIA},
 	{KE_KEY, 0x99, KEY_PHONE},
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 29/33] eeepc-laptop: map keys found on newer eeepc
  2009-12-03  7:45                                                       ` [PATCH 28/33] asus-laptop: Add wlan switch found on V6V Corentin Chary
@ 2009-12-03  7:45                                                         ` Corentin Chary
  2009-12-03  7:45                                                           ` [PATCH 30/33] eeepc-laptop: fix coding style Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:45 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Corentin Chary

Signed-off-by: Corentin Chary <corentincj@iksaif.net>
---
 drivers/platform/x86/eeepc-laptop.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index 935ec44..920d9d9 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -136,6 +136,7 @@ static const struct key_entry eeepc_keymap[] = {
 	{KE_KEY, 0x13, KEY_MUTE },
 	{KE_KEY, 0x14, KEY_VOLUMEDOWN },
 	{KE_KEY, 0x15, KEY_VOLUMEUP },
+	{KE_KEY, 0x16, KEY_DISPLAY_OFF },
 	{KE_KEY, 0x1a, KEY_COFFEE },
 	{KE_KEY, 0x1b, KEY_ZOOM },
 	{KE_KEY, 0x1c, KEY_PROG2 },
@@ -145,6 +146,8 @@ static const struct key_entry eeepc_keymap[] = {
 	{KE_KEY, 0x30, KEY_SWITCHVIDEOMODE },
 	{KE_KEY, 0x31, KEY_SWITCHVIDEOMODE },
 	{KE_KEY, 0x32, KEY_SWITCHVIDEOMODE },
+	{KE_KEY, 0x37, KEY_F13 }, /* Disable Touchpad */
+	{KE_KEY, 0x38, KEY_F14 },
 	{KE_END, 0},
 };
 
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 30/33] eeepc-laptop: fix coding style
  2009-12-03  7:45                                                         ` [PATCH 29/33] eeepc-laptop: map keys found on newer eeepc Corentin Chary
@ 2009-12-03  7:45                                                           ` Corentin Chary
  2009-12-03  7:45                                                             ` [PATCH 31/33] eeepc-laptop: re-add check for eeepc->backlight == NULL Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:45 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Corentin Chary

fix styles problems introduced by commit
e86bda235a08b6a8e64c1e8bb9d175f6961554e3

Signed-off-by: Corentin Chary <corentincj@iksaif.net>
---
 drivers/platform/x86/eeepc-laptop.c |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index 920d9d9..5f0eb76 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -244,7 +244,8 @@ static int get_acpi(struct eeepc_laptop *eeepc, int cm)
 	return value;
 }
 
-static int acpi_setter_handle(struct eeepc_laptop *eeepc, int cm, acpi_handle *handle)
+static int acpi_setter_handle(struct eeepc_laptop *eeepc, int cm,
+			      acpi_handle *handle)
 {
 	const char *method = cm_setv[cm];
 	acpi_status status;
@@ -255,7 +256,7 @@ static int acpi_setter_handle(struct eeepc_laptop *eeepc, int cm, acpi_handle *h
 		return -ENODEV;
 
 	status = acpi_get_handle(eeepc->handle, (char *)method,
-			         handle);
+				 handle);
 	if (status != AE_OK) {
 		pr_warning("Error finding %s\n", method);
 		return -ENODEV;
@@ -1274,7 +1275,8 @@ static void cmsg_quirks(struct eeepc_laptop *eeepc)
 	cmsg_quirk(eeepc, CM_ASL_TPD, "TPD");
 }
 
-static int eeepc_acpi_init(struct eeepc_laptop *eeepc, struct acpi_device *device)
+static int eeepc_acpi_init(struct eeepc_laptop *eeepc,
+			   struct acpi_device *device)
 {
 	unsigned int init_flags;
 	int result;
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 31/33] eeepc-laptop: re-add check for eeepc->backlight == NULL
  2009-12-03  7:45                                                           ` [PATCH 30/33] eeepc-laptop: fix coding style Corentin Chary
@ 2009-12-03  7:45                                                             ` Corentin Chary
  2009-12-03  7:45                                                               ` [PATCH 32/33] input: add KEY_WIRELESS_CYCLE Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:45 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Alan Jenkins

From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>

As Corentin points out, we do not create a backlight device if the ACPI
video driver is able to provide equivalent functionality. So we do need
to check before we try to update the backlight device.

We now ignore brightness events completely if we have not created a
backlight device.  This is slightly more cautious than the original
check.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
 drivers/platform/x86/eeepc-laptop.c |   42 ++++++++++++++++++++--------------
 1 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index 5f0eb76..d07a4c0 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -1230,27 +1230,35 @@ static void eeepc_acpi_notify(struct acpi_device *device, u32 event)
 					dev_name(&device->dev), event,
 					count);
 
+	/* Brightness events are special */
 	if (event >= NOTIFY_BRN_MIN && event <= NOTIFY_BRN_MAX) {
-		int old_brightness, new_brightness;
 
-		/* Update backlight device. */
-		old_brightness = eeepc_backlight_notify(eeepc);
-
-		/* Convert brightness event to keypress (obsolescent hack). */
-		new_brightness = event - NOTIFY_BRN_MIN;
-
-		if (new_brightness < old_brightness) {
-			event = NOTIFY_BRN_MIN; /* brightness down */
-		} else if (new_brightness > old_brightness) {
-			event = NOTIFY_BRN_MAX; /* brightness up */
-		} else {
-			/*
-			 * no change in brightness - already at min/max,
-			 * event will be desired value (or else ignored).
-			 */
+		/* Ignore them completely if the acpi video driver is used */
+		if (eeepc->backlight_device != NULL) {
+			int old_brightness, new_brightness;
+
+			/* Update the backlight device. */
+			old_brightness = eeepc_backlight_notify(eeepc);
+
+			/* Convert event to keypress (obsolescent hack) */
+			new_brightness = event - NOTIFY_BRN_MIN;
+
+			if (new_brightness < old_brightness) {
+				event = NOTIFY_BRN_MIN; /* brightness down */
+			} else if (new_brightness > old_brightness) {
+				event = NOTIFY_BRN_MAX; /* brightness up */
+			} else {
+				/*
+				* no change in brightness - already at min/max,
+				* event will be desired value (or else ignored)
+				*/
+			}
+			eeepc_input_notify(eeepc, event);
 		}
+	} else {
+		/* Everything else is a bona-fide keypress event */
+		eeepc_input_notify(eeepc, event);
 	}
-	eeepc_input_notify(eeepc, event);
 }
 
 static void cmsg_quirk(struct eeepc_laptop *eeepc, int cm, const char *name)
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 32/33] input: add KEY_WIRELESS_CYCLE
  2009-12-03  7:45                                                             ` [PATCH 31/33] eeepc-laptop: re-add check for eeepc->backlight == NULL Corentin Chary
@ 2009-12-03  7:45                                                               ` Corentin Chary
  2009-12-03  7:45                                                                 ` [PATCH 33/33] asus-laptop: schedule display_get and lcd_switch for removal Corentin Chary
  2009-12-03  7:54                                                                 ` [PATCH 32/33] input: add KEY_WIRELESS_CYCLE Dmitry Torokhov
  0 siblings, 2 replies; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:45 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Corentin Chary, linux-input

This keycode could be used in a lot of platform specific drivers.
For example, on Asus laptops, Fn+F2 allow to cycle trought wireless
drivers (bt/wl: off/off, on/off, off/on, on/on).

Currently, these key are mapped to KEY_WLAN, and KEY_BLUETOOTH/KEY_WIMAX
are rarely used.

Cc: linux-input@vger.kernel.org
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
---
 include/linux/input.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/linux/input.h b/include/linux/input.h
index c2b1a7d..c961908 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -376,6 +376,7 @@ struct input_absinfo {
 #define KEY_DISPLAY_OFF		245	/* display device to off state */
 
 #define KEY_WIMAX		246
+#define KEY_WIRELESS_CYCLE	247
 
 /* Range 248 - 255 is reserved for special needs of AT keyboard driver */
 
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* [PATCH 33/33] asus-laptop: schedule display_get and lcd_switch for removal
  2009-12-03  7:45                                                               ` [PATCH 32/33] input: add KEY_WIRELESS_CYCLE Corentin Chary
@ 2009-12-03  7:45                                                                 ` Corentin Chary
  2009-12-03  7:54                                                                 ` [PATCH 32/33] input: add KEY_WIRELESS_CYCLE Dmitry Torokhov
  1 sibling, 0 replies; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  7:45 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Corentin Chary

Signed-off-by: Corentin Chary <corentincj@iksaif.net>
---
 Documentation/feature-removal-schedule.txt |   20 ++++++++++++++++++++
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index bc693ff..d1c9e17 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -489,3 +489,23 @@ Why:	With the recent innovations in CPU hardware acceleration technologies
 Who:	Alok N Kataria <akataria@vmware.com>
 
 ----------------------------
+
+What:	Support for lcd_switch and display_get in asus-laptop driver
+When:	March 2010
+Why:	These two features use non-standard interfaces. There are the
+	only features that really need multiple path to guess what's
+	the right method name on a specific laptop.
+
+	Removing them will allow to remove a lot of code an significantly
+	clean the drivers.
+
+	This will affect the backlight code which won't be able to know
+	if the backlight is on or off. The platform display file will also be
+	write only (like the one in eeepc-laptop).
+
+	This should'nt affect a lot of user because they usually know
+	when their display is on or off.
+
+Who:	Corentin Chary <corentin.chary@gmail.com>
+
+----------------------------
-- 
1.6.5.3


^ permalink raw reply related	[flat|nested] 55+ messages in thread

* Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE
  2009-12-03  7:45                                                               ` [PATCH 32/33] input: add KEY_WIRELESS_CYCLE Corentin Chary
  2009-12-03  7:45                                                                 ` [PATCH 33/33] asus-laptop: schedule display_get and lcd_switch for removal Corentin Chary
@ 2009-12-03  7:54                                                                 ` Dmitry Torokhov
  2009-12-03  8:12                                                                   ` Corentin Chary
  2009-12-03 10:54                                                                   ` Henrique de Moraes Holschuh
  1 sibling, 2 replies; 55+ messages in thread
From: Dmitry Torokhov @ 2009-12-03  7:54 UTC (permalink / raw)
  To: Corentin Chary; +Cc: Len Brown, linux-acpi, linux-input

On Thu, Dec 03, 2009 at 08:45:16AM +0100, Corentin Chary wrote:
> This keycode could be used in a lot of platform specific drivers.
> For example, on Asus laptops, Fn+F2 allow to cycle trought wireless
> drivers (bt/wl: off/off, on/off, off/on, on/on).
> 
> Currently, these key are mapped to KEY_WLAN, and KEY_BLUETOOTH/KEY_WIMAX
> are rarely used.
> 

Is there any application support for such cycling? IOW does anyone cares
to do such cycling?

-- 
Dmitry

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE
  2009-12-03  7:54                                                                 ` [PATCH 32/33] input: add KEY_WIRELESS_CYCLE Dmitry Torokhov
@ 2009-12-03  8:12                                                                   ` Corentin Chary
  2009-12-03  8:21                                                                     ` Dmitry Torokhov
  2009-12-06  6:58                                                                     ` Andrey Rahmatullin
  2009-12-03 10:54                                                                   ` Henrique de Moraes Holschuh
  1 sibling, 2 replies; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  8:12 UTC (permalink / raw)
  To: Dmitry Torokhov; +Cc: Len Brown, linux-acpi, linux-input

On Thu, Dec 3, 2009 at 8:54 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Thu, Dec 03, 2009 at 08:45:16AM +0100, Corentin Chary wrote:
>> This keycode could be used in a lot of platform specific drivers.
>> For example, on Asus laptops, Fn+F2 allow to cycle trought wireless
>> drivers (bt/wl: off/off, on/off, off/on, on/on).
>>
>> Currently, these key are mapped to KEY_WLAN, and KEY_BLUETOOTH/KEY_WIMAX
>> are rarely used.
>>
>
> Is there any application support for such cycling? IOW does anyone cares
> to do such cycling?

On Asus laptops (both asus and eeepc) the Fn+F2 key cycle
(bluetooth/wlan: on/on, on/off, off/on, off/off) on windows.
On Linux, it only produces a KEY_WLAN keycode.

-- 
Corentin Chary
http://xf.iksaif.net

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE
  2009-12-03  8:12                                                                   ` Corentin Chary
@ 2009-12-03  8:21                                                                     ` Dmitry Torokhov
  2009-12-03  8:51                                                                       ` Corentin Chary
  2009-12-06  6:58                                                                     ` Andrey Rahmatullin
  1 sibling, 1 reply; 55+ messages in thread
From: Dmitry Torokhov @ 2009-12-03  8:21 UTC (permalink / raw)
  To: Corentin Chary; +Cc: Len Brown, linux-acpi, linux-input

On Thu, Dec 03, 2009 at 09:12:52AM +0100, Corentin Chary wrote:
> On Thu, Dec 3, 2009 at 8:54 AM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > On Thu, Dec 03, 2009 at 08:45:16AM +0100, Corentin Chary wrote:
> >> This keycode could be used in a lot of platform specific drivers.
> >> For example, on Asus laptops, Fn+F2 allow to cycle trought wireless
> >> drivers (bt/wl: off/off, on/off, off/on, on/on).
> >>
> >> Currently, these key are mapped to KEY_WLAN, and KEY_BLUETOOTH/KEY_WIMAX
> >> are rarely used.
> >>
> >
> > Is there any application support for such cycling? IOW does anyone cares
> > to do such cycling?
> 
> On Asus laptops (both asus and eeepc) the Fn+F2 key cycle
> (bluetooth/wlan: on/on, on/off, off/on, off/off) on windows.
> On Linux, it only produces a KEY_WLAN keycode.
> 

I understand this. I guess the question is whether people working on
system infrastructure (dbus, Networkmanager, etc) care about having such
functionality on Linux? The reason I am asking is that we added all
KEY_WIMAX and so on defines but I am not usre if anyone wants them.

-- 
Dmitry

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE
  2009-12-03  8:21                                                                     ` Dmitry Torokhov
@ 2009-12-03  8:51                                                                       ` Corentin Chary
  2009-12-03  8:57                                                                         ` Dmitry Torokhov
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  8:51 UTC (permalink / raw)
  To: Dmitry Torokhov; +Cc: Len Brown, linux-acpi, linux-input

On Thu, Dec 3, 2009 at 9:21 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Thu, Dec 03, 2009 at 09:12:52AM +0100, Corentin Chary wrote:
>> On Thu, Dec 3, 2009 at 8:54 AM, Dmitry Torokhov
>> <dmitry.torokhov@gmail.com> wrote:
>> > On Thu, Dec 03, 2009 at 08:45:16AM +0100, Corentin Chary wrote:
>> >> This keycode could be used in a lot of platform specific drivers.
>> >> For example, on Asus laptops, Fn+F2 allow to cycle trought wireless
>> >> drivers (bt/wl: off/off, on/off, off/on, on/on).
>> >>
>> >> Currently, these key are mapped to KEY_WLAN, and KEY_BLUETOOTH/KEY_WIMAX
>> >> are rarely used.
>> >>
>> >
>> > Is there any application support for such cycling? IOW does anyone cares
>> > to do such cycling?
>>
>> On Asus laptops (both asus and eeepc) the Fn+F2 key cycle
>> (bluetooth/wlan: on/on, on/off, off/on, off/off) on windows.
>> On Linux, it only produces a KEY_WLAN keycode.
>>
>
> I understand this. I guess the question is whether people working on
> system infrastructure (dbus, Networkmanager, etc) care about having such
> functionality on Linux? The reason I am asking is that we added all
> KEY_WIMAX and so on defines but I am not usre if anyone wants them.

KEY_WIMAX may not be used a lot because there is not a lot of device
with such a key,
I think this is not the case for KEY_WIRELESS_CYCLE.

The bad thing is that we will need to patch X11 (and Qt, for
kde/solid) to make it works.

Maybe we should Cc dbus/network manager/solid/linux-wireless ?

-- 
Corentin Chary
http://xf.iksaif.net

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE
  2009-12-03  8:51                                                                       ` Corentin Chary
@ 2009-12-03  8:57                                                                         ` Dmitry Torokhov
  2009-12-03  9:22                                                                           ` Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Dmitry Torokhov @ 2009-12-03  8:57 UTC (permalink / raw)
  To: Corentin Chary; +Cc: Len Brown, linux-acpi, linux-input

On Thu, Dec 03, 2009 at 09:51:59AM +0100, Corentin Chary wrote:
> On Thu, Dec 3, 2009 at 9:21 AM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > On Thu, Dec 03, 2009 at 09:12:52AM +0100, Corentin Chary wrote:
> >> On Thu, Dec 3, 2009 at 8:54 AM, Dmitry Torokhov
> >> <dmitry.torokhov@gmail.com> wrote:
> >> > On Thu, Dec 03, 2009 at 08:45:16AM +0100, Corentin Chary wrote:
> >> >> This keycode could be used in a lot of platform specific drivers.
> >> >> For example, on Asus laptops, Fn+F2 allow to cycle trought wireless
> >> >> drivers (bt/wl: off/off, on/off, off/on, on/on).
> >> >>
> >> >> Currently, these key are mapped to KEY_WLAN, and KEY_BLUETOOTH/KEY_WIMAX
> >> >> are rarely used.
> >> >>
> >> >
> >> > Is there any application support for such cycling? IOW does anyone cares
> >> > to do such cycling?
> >>
> >> On Asus laptops (both asus and eeepc) the Fn+F2 key cycle
> >> (bluetooth/wlan: on/on, on/off, off/on, off/off) on windows.
> >> On Linux, it only produces a KEY_WLAN keycode.
> >>
> >
> > I understand this. I guess the question is whether people working on
> > system infrastructure (dbus, Networkmanager, etc) care about having such
> > functionality on Linux? The reason I am asking is that we added all
> > KEY_WIMAX and so on defines but I am not usre if anyone wants them.
> 
> KEY_WIMAX may not be used a lot because there is not a lot of device
> with such a key,
> I think this is not the case for KEY_WIRELESS_CYCLE.
> 
> The bad thing is that we will need to patch X11 (and Qt, for
> kde/solid) to make it works.
> 
> Maybe we should Cc dbus/network manager/solid/linux-wireless ?
> 

That would be a good idea.

-- 
Dmitry

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE
  2009-12-03  8:57                                                                         ` Dmitry Torokhov
@ 2009-12-03  9:22                                                                           ` Corentin Chary
  2009-12-03  9:43                                                                             ` Johannes Berg
  2009-12-03 15:01                                                                             ` Matthew Garrett
  0 siblings, 2 replies; 55+ messages in thread
From: Corentin Chary @ 2009-12-03  9:22 UTC (permalink / raw)
  To: Dmitry Torokhov
  Cc: Len Brown, linux-acpi, linux-input, networkmanager-list,
	linux-wireless, kde-hardware-devel, dbus, hal

On Thu, Dec 3, 2009 at 9:57 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Thu, Dec 03, 2009 at 09:51:59AM +0100, Corentin Chary wrote:
>> On Thu, Dec 3, 2009 at 9:21 AM, Dmitry Torokhov
>> <dmitry.torokhov@gmail.com> wrote:
>> > On Thu, Dec 03, 2009 at 09:12:52AM +0100, Corentin Chary wrote:
>> >> On Thu, Dec 3, 2009 at 8:54 AM, Dmitry Torokhov
>> >> <dmitry.torokhov@gmail.com> wrote:
>> >> > On Thu, Dec 03, 2009 at 08:45:16AM +0100, Corentin Chary wrote:
>> >> >> This keycode could be used in a lot of platform specific drivers.
>> >> >> For example, on Asus laptops, Fn+F2 allow to cycle trought wireless
>> >> >> drivers (bt/wl: off/off, on/off, off/on, on/on).
>> >> >>
>> >> >> Currently, these key are mapped to KEY_WLAN, and KEY_BLUETOOTH/KEY_WIMAX
>> >> >> are rarely used.
>> >> >>
>> >> >
>> >> > Is there any application support for such cycling? IOW does anyone cares
>> >> > to do such cycling?
>> >>
>> >> On Asus laptops (both asus and eeepc) the Fn+F2 key cycle
>> >> (bluetooth/wlan: on/on, on/off, off/on, off/off) on windows.
>> >> On Linux, it only produces a KEY_WLAN keycode.
>> >>
>> >
>> > I understand this. I guess the question is whether people working on
>> > system infrastructure (dbus, Networkmanager, etc) care about having such
>> > functionality on Linux? The reason I am asking is that we added all
>> > KEY_WIMAX and so on defines but I am not usre if anyone wants them.
>>
>> KEY_WIMAX may not be used a lot because there is not a lot of device
>> with such a key,
>> I think this is not the case for KEY_WIRELESS_CYCLE.
>>
>> The bad thing is that we will need to patch X11 (and Qt, for
>> kde/solid) to make it works.
>>
>> Maybe we should Cc dbus/network manager/solid/linux-wireless ?
>>
>
> That would be a good idea.

Here it is.

Dear system infrastructure people,
Do you think a KEY_WIRELESS_CYCLE key would have any application ?

-- 
Corentin Chary
http://xf.iksaif.net

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE
  2009-12-03  9:22                                                                           ` Corentin Chary
@ 2009-12-03  9:43                                                                             ` Johannes Berg
  2009-12-03 11:23                                                                                 ` Will Stephenson
  2009-12-03 15:01                                                                             ` Matthew Garrett
  1 sibling, 1 reply; 55+ messages in thread
From: Johannes Berg @ 2009-12-03  9:43 UTC (permalink / raw)
  To: Corentin Chary
  Cc: Dmitry Torokhov, Len Brown, linux-acpi, linux-input,
	networkmanager-list, linux-wireless, kde-hardware-devel, dbus,
	hal

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

On Thu, 2009-12-03 at 10:22 +0100, Corentin Chary wrote:

> >> > I understand this. I guess the question is whether people working on
> >> > system infrastructure (dbus, Networkmanager, etc) care about having such
> >> > functionality on Linux? The reason I am asking is that we added all
> >> > KEY_WIMAX and so on defines but I am not usre if anyone wants them.
> >>
> >> KEY_WIMAX may not be used a lot because there is not a lot of device
> >> with such a key,
> >> I think this is not the case for KEY_WIRELESS_CYCLE.
> >>
> >> The bad thing is that we will need to patch X11 (and Qt, for
> >> kde/solid) to make it works.
> >>
> >> Maybe we should Cc dbus/network manager/solid/linux-wireless ?
> >>
> >
> > That would be a good idea.
> 
> Here it is.
> 
> Dear system infrastructure people,
> Do you think a KEY_WIRELESS_CYCLE key would have any application ?

Not really.

The naming of the key ultimately will not matter one bit, because it'll
be misnamed on most platforms anyway, unless we want to do DMI matching
or something to name the key. And even then, if there's a wifi key but
no bluetooth key, users may prefer to have the wifi key act as a cycle
key instead.

Therefore, this ought to all be policy in the rfkill daemon.
rfkill-input will be going away as soon as somebody writes a simple
daemon that allows doing such things, I really don't see us adding
support for a cycle key to the kernel code, and for the userspace code
it doesn't matter since users will configure it independent of the key
code anyway.

johannes

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE
  2009-12-03  7:54                                                                 ` [PATCH 32/33] input: add KEY_WIRELESS_CYCLE Dmitry Torokhov
  2009-12-03  8:12                                                                   ` Corentin Chary
@ 2009-12-03 10:54                                                                   ` Henrique de Moraes Holschuh
  1 sibling, 0 replies; 55+ messages in thread
From: Henrique de Moraes Holschuh @ 2009-12-03 10:54 UTC (permalink / raw)
  To: Dmitry Torokhov; +Cc: Corentin Chary, Len Brown, linux-acpi, linux-input

On Wed, 02 Dec 2009, Dmitry Torokhov wrote:
> On Thu, Dec 03, 2009 at 08:45:16AM +0100, Corentin Chary wrote:
> > This keycode could be used in a lot of platform specific drivers.
> > For example, on Asus laptops, Fn+F2 allow to cycle trought wireless
> > drivers (bt/wl: off/off, on/off, off/on, on/on).
> > 
> > Currently, these key are mapped to KEY_WLAN, and KEY_BLUETOOTH/KEY_WIMAX
> > are rarely used.
> 
> Is there any application support for such cycling? IOW does anyone cares
> to do such cycling?

Well, the default ThinkPad behaviour would be to cycle as well, and I'd use
this new keycode if it becomes available.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [Kde-hardware-devel] [PATCH 32/33] input: add KEY_WIRELESS_CYCLE
@ 2009-12-03 11:23                                                                                 ` Will Stephenson
  0 siblings, 0 replies; 55+ messages in thread
From: Will Stephenson @ 2009-12-03 11:23 UTC (permalink / raw)
  To: kde-hardware-devel
  Cc: Johannes Berg, Corentin Chary, dbus, Dmitry Torokhov,
	linux-wireless, hal, linux-acpi, linux-input,
	networkmanager-list, Len Brown

On Thursday 03 December 2009 10:43:32 Johannes Berg wrote:
> On Thu, 2009-12-03 at 10:22 +0100, Corentin Chary wrote:
> > Dear system infrastructure people,
> > Do you think a KEY_WIRELESS_CYCLE key would have any application ?
> 
> Not really.
> 
> The naming of the key ultimately will not matter one bit, because it'll
> be misnamed on most platforms anyway, unless we want to do DMI matching
> or something to name the key. And even then, if there's a wifi key but
> no bluetooth key, users may prefer to have the wifi key act as a cycle
> key instead.
> 
> Therefore, this ought to all be policy in the rfkill daemon.
> rfkill-input will be going away as soon as somebody writes a simple
> daemon that allows doing such things, I really don't see us adding
> support for a cycle key to the kernel code, and for the userspace code
> it doesn't matter since users will configure it independent of the key
> code anyway.

This sounds reasonable to me, as the wireless guy in the KDE camp.  I don't 
want to have to handle these keypresses in a user session anyway - I prefer 
that NetworkManager picks up on them and notifies the client of the state 
change.

Will

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [Kde-hardware-devel] [PATCH 32/33] input: add KEY_WIRELESS_CYCLE
@ 2009-12-03 11:23                                                                                 ` Will Stephenson
  0 siblings, 0 replies; 55+ messages in thread
From: Will Stephenson @ 2009-12-03 11:23 UTC (permalink / raw)
  To: kde-hardware-devel-RoXCvvDuEio
  Cc: Johannes Berg, Corentin Chary,
	dbus-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Dmitry Torokhov,
	linux-wireless-u79uwXL29TY76Z2rM5mHXA,
	hal-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-acpi-u79uwXL29TY76Z2rM5mHXA,
	linux-input-u79uwXL29TY76Z2rM5mHXA,
	networkmanager-list-rDKQcyrBJuzYtjvyW6yDsg, Len Brown

On Thursday 03 December 2009 10:43:32 Johannes Berg wrote:
> On Thu, 2009-12-03 at 10:22 +0100, Corentin Chary wrote:
> > Dear system infrastructure people,
> > Do you think a KEY_WIRELESS_CYCLE key would have any application ?
> 
> Not really.
> 
> The naming of the key ultimately will not matter one bit, because it'll
> be misnamed on most platforms anyway, unless we want to do DMI matching
> or something to name the key. And even then, if there's a wifi key but
> no bluetooth key, users may prefer to have the wifi key act as a cycle
> key instead.
> 
> Therefore, this ought to all be policy in the rfkill daemon.
> rfkill-input will be going away as soon as somebody writes a simple
> daemon that allows doing such things, I really don't see us adding
> support for a cycle key to the kernel code, and for the userspace code
> it doesn't matter since users will configure it independent of the key
> code anyway.

This sounds reasonable to me, as the wireless guy in the KDE camp.  I don't 
want to have to handle these keypresses in a user session anyway - I prefer 
that NetworkManager picks up on them and notifies the client of the state 
change.

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE
  2009-12-03  9:22                                                                           ` Corentin Chary
  2009-12-03  9:43                                                                             ` Johannes Berg
@ 2009-12-03 15:01                                                                             ` Matthew Garrett
  1 sibling, 0 replies; 55+ messages in thread
From: Matthew Garrett @ 2009-12-03 15:01 UTC (permalink / raw)
  To: Corentin Chary
  Cc: Dmitry Torokhov, kde-hardware-devel, dbus, linux-wireless, hal,
	linux-acpi, linux-input, networkmanager-list, Len Brown

On Thu, Dec 03, 2009 at 10:22:16AM +0100, Corentin Chary wrote:

> Dear system infrastructure people,
> Do you think a KEY_WIRELESS_CYCLE key would have any application ?

Not really. I've got a KEY_RFKILL patch queued, with the intended 
semantics being for rfkill-input to just toggle all devices. If a 
userspace rfkill daemon is running, it could use that to implement the 
cycle policy you want. I don't think we need both.

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE
  2009-12-03  8:12                                                                   ` Corentin Chary
  2009-12-03  8:21                                                                     ` Dmitry Torokhov
@ 2009-12-06  6:58                                                                     ` Andrey Rahmatullin
  2009-12-06  7:17                                                                       ` Dmitry Torokhov
  1 sibling, 1 reply; 55+ messages in thread
From: Andrey Rahmatullin @ 2009-12-06  6:58 UTC (permalink / raw)
  To: Corentin Chary; +Cc: Dmitry Torokhov, Len Brown, linux-acpi, linux-input

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

On Thu, Dec 03, 2009 at 09:12:52AM +0100, Corentin Chary wrote:
> >> This keycode could be used in a lot of platform specific drivers.
> >> For example, on Asus laptops, Fn+F2 allow to cycle trought wireless
> >> drivers (bt/wl: off/off, on/off, off/on, on/on).
> >>
> >> Currently, these key are mapped to KEY_WLAN, and KEY_BLUETOOTH/KEY_WIMAX
> >> are rarely used.
> > Is there any application support for such cycling? IOW does anyone cares
> > to do such cycling?
> On Asus laptops (both asus and eeepc) the Fn+F2 key cycle
> (bluetooth/wlan: on/on, on/off, off/on, off/off) on windows.
> On Linux, it only produces a KEY_WLAN keycode.
Default eee901's Xandros cycles and even shows an OSD with BT and WLAN
state images.

-- 
WBR, wRAR (ALT Linux Team)

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE
  2009-12-06  6:58                                                                     ` Andrey Rahmatullin
@ 2009-12-06  7:17                                                                       ` Dmitry Torokhov
  2009-12-06  8:21                                                                         ` Corentin Chary
  0 siblings, 1 reply; 55+ messages in thread
From: Dmitry Torokhov @ 2009-12-06  7:17 UTC (permalink / raw)
  To: Andrey Rahmatullin; +Cc: Corentin Chary, Len Brown, linux-acpi, linux-input

On Sun, Dec 06, 2009 at 11:58:29AM +0500, Andrey Rahmatullin wrote:
> On Thu, Dec 03, 2009 at 09:12:52AM +0100, Corentin Chary wrote:
> > >> This keycode could be used in a lot of platform specific drivers.
> > >> For example, on Asus laptops, Fn+F2 allow to cycle trought wireless
> > >> drivers (bt/wl: off/off, on/off, off/on, on/on).
> > >>
> > >> Currently, these key are mapped to KEY_WLAN, and KEY_BLUETOOTH/KEY_WIMAX
> > >> are rarely used.
> > > Is there any application support for such cycling? IOW does anyone cares
> > > to do such cycling?
> > On Asus laptops (both asus and eeepc) the Fn+F2 key cycle
> > (bluetooth/wlan: on/on, on/off, off/on, off/off) on windows.
> > On Linux, it only produces a KEY_WLAN keycode.
> Default eee901's Xandros cycles and even shows an OSD with BT and WLAN
> state images.
> 

You are describing the visible result. Whether it is done as a custom
policy to KEY_WLAN presses or utilizes a separate key definition - is
not known.

Anyway, we got the response form wireless developers and infrastructure
people and thyy do not care about having a new defintion so I guess that
settles it.

-- 
Dmitry

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE
  2009-12-06  7:17                                                                       ` Dmitry Torokhov
@ 2009-12-06  8:21                                                                         ` Corentin Chary
  2009-12-06 14:54                                                                           ` Matthew Garrett
  0 siblings, 1 reply; 55+ messages in thread
From: Corentin Chary @ 2009-12-06  8:21 UTC (permalink / raw)
  To: Dmitry Torokhov; +Cc: Andrey Rahmatullin, Len Brown, linux-acpi, linux-input

On Sun, Dec 6, 2009 at 8:17 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Sun, Dec 06, 2009 at 11:58:29AM +0500, Andrey Rahmatullin wrote:
>> On Thu, Dec 03, 2009 at 09:12:52AM +0100, Corentin Chary wrote:
>> > >> This keycode could be used in a lot of platform specific drivers.
>> > >> For example, on Asus laptops, Fn+F2 allow to cycle trought wireless
>> > >> drivers (bt/wl: off/off, on/off, off/on, on/on).
>> > >>
>> > >> Currently, these key are mapped to KEY_WLAN, and KEY_BLUETOOTH/KEY_WIMAX
>> > >> are rarely used.
>> > > Is there any application support for such cycling? IOW does anyone cares
>> > > to do such cycling?
>> > On Asus laptops (both asus and eeepc) the Fn+F2 key cycle
>> > (bluetooth/wlan: on/on, on/off, off/on, off/off) on windows.
>> > On Linux, it only produces a KEY_WLAN keycode.
>> Default eee901's Xandros cycles and even shows an OSD with BT and WLAN
>> state images.
>>
>
> You are describing the visible result. Whether it is done as a custom
> policy to KEY_WLAN presses or utilizes a separate key definition - is
> not known.
Old xandros builds use the acpi event.
New builds have switched to eeepc-laptop (based on my 2.6.30
backport), so they may use an input event (KEY_WLAN).

> Anyway, we got the response form wireless developers and infrastructure
> people and thyy do not care about having a new defintion so I guess that
> settles it.
Yep

-- 
Corentin Chary
http://xf.iksaif.net

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE
  2009-12-06  8:21                                                                         ` Corentin Chary
@ 2009-12-06 14:54                                                                           ` Matthew Garrett
  2009-12-07 11:47                                                                             ` Henrique de Moraes Holschuh
  0 siblings, 1 reply; 55+ messages in thread
From: Matthew Garrett @ 2009-12-06 14:54 UTC (permalink / raw)
  To: Corentin Chary
  Cc: Dmitry Torokhov, Andrey Rahmatullin, Len Brown, linux-acpi, linux-input

On Sun, Dec 06, 2009 at 09:21:12AM +0100, Corentin Chary wrote:

> Old xandros builds use the acpi event.
> New builds have switched to eeepc-laptop (based on my 2.6.30
> backport), so they may use an input event (KEY_WLAN).

Yeah. We should probably change that to KEY_RFKILL once that lands.

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE
  2009-12-06 14:54                                                                           ` Matthew Garrett
@ 2009-12-07 11:47                                                                             ` Henrique de Moraes Holschuh
  2009-12-07 12:55                                                                               ` Matthew Garrett
  0 siblings, 1 reply; 55+ messages in thread
From: Henrique de Moraes Holschuh @ 2009-12-07 11:47 UTC (permalink / raw)
  To: Matthew Garrett
  Cc: Corentin Chary, Dmitry Torokhov, Andrey Rahmatullin, Len Brown,
	linux-acpi, linux-input

On Sun, 06 Dec 2009, Matthew Garrett wrote:
> On Sun, Dec 06, 2009 at 09:21:12AM +0100, Corentin Chary wrote:
> > Old xandros builds use the acpi event.
> > New builds have switched to eeepc-laptop (based on my 2.6.30
> > backport), so they may use an input event (KEY_WLAN).
> 
> Yeah. We should probably change that to KEY_RFKILL once that lands.

Depends on what is being done in userspace to the other KEY_(radio type).

What I do know, is that I will miss a keycode that rfkills just my WLAN... I
use that for power management, it is nice to have a key that is for WLAN
only, and another that is for bluetooth-only...

It is a pity KEY_RFKILL is arriving too late to avoid the loss of KEY_WLAN
(or is it?)

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE
  2009-12-07 11:47                                                                             ` Henrique de Moraes Holschuh
@ 2009-12-07 12:55                                                                               ` Matthew Garrett
  2009-12-07 13:23                                                                                 ` Henrique de Moraes Holschuh
  0 siblings, 1 reply; 55+ messages in thread
From: Matthew Garrett @ 2009-12-07 12:55 UTC (permalink / raw)
  To: Henrique de Moraes Holschuh
  Cc: Corentin Chary, Dmitry Torokhov, Andrey Rahmatullin, Len Brown,
	linux-acpi, linux-input

On Mon, Dec 07, 2009 at 09:47:49AM -0200, Henrique de Moraes Holschuh wrote:

> What I do know, is that I will miss a keycode that rfkills just my WLAN... I
> use that for power management, it is nice to have a key that is for WLAN
> only, and another that is for bluetooth-only...

KEY_WLAN will still be there, and you can still remap. But the default 
behaviour should be for thinkpad-acpi (for instance) to generate 
KEY_RFKILL, since Fn+F5 isn't supposed to be wlan only.

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE
  2009-12-07 12:55                                                                               ` Matthew Garrett
@ 2009-12-07 13:23                                                                                 ` Henrique de Moraes Holschuh
  2009-12-07 14:20                                                                                   ` Matthew Garrett
  0 siblings, 1 reply; 55+ messages in thread
From: Henrique de Moraes Holschuh @ 2009-12-07 13:23 UTC (permalink / raw)
  To: Matthew Garrett
  Cc: Corentin Chary, Dmitry Torokhov, Andrey Rahmatullin, Len Brown,
	linux-acpi, linux-input

On Mon, 07 Dec 2009, Matthew Garrett wrote:
> On Mon, Dec 07, 2009 at 09:47:49AM -0200, Henrique de Moraes Holschuh wrote:
> > What I do know, is that I will miss a keycode that rfkills just my WLAN... I
> > use that for power management, it is nice to have a key that is for WLAN
> > only, and another that is for bluetooth-only...
> 
> KEY_WLAN will still be there, and you can still remap. But the default 
> behaviour should be for thinkpad-acpi (for instance) to generate 
> KEY_RFKILL, since Fn+F5 isn't supposed to be wlan only.

That's not what I got from this thread.  What I got was that KEY_WLAN would
be overloaded with KEY_RFKILL semanthics, regardless of anything we did in
the kernel side.

I hope I got it wrong.

I am strongly with you here: add a *new* KEY_RFKILL, fix the kernel drivers
and any eventual userspace to use the new KEY_RFKILL, and have KEY_WLAN do
what it is supposed to do.

And, if what we call KEY_WLAN is actually supposed to be KEY_RFKILL, swap
their definitions when adding KEY_RFKILL, so that USB HID devices will
generate KEY_RFKILL instead of KEY_WLAN.

It will be more work, but the end result would be superior, IMO.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE
  2009-12-07 13:23                                                                                 ` Henrique de Moraes Holschuh
@ 2009-12-07 14:20                                                                                   ` Matthew Garrett
  2009-12-07 17:02                                                                                     ` Henrique de Moraes Holschuh
  0 siblings, 1 reply; 55+ messages in thread
From: Matthew Garrett @ 2009-12-07 14:20 UTC (permalink / raw)
  To: Henrique de Moraes Holschuh
  Cc: Corentin Chary, Dmitry Torokhov, Andrey Rahmatullin, Len Brown,
	linux-acpi, linux-input

On Mon, Dec 07, 2009 at 11:23:34AM -0200, Henrique de Moraes Holschuh wrote:
> On Mon, 07 Dec 2009, Matthew Garrett wrote:
> > On Mon, Dec 07, 2009 at 09:47:49AM -0200, Henrique de Moraes Holschuh wrote:
> > > What I do know, is that I will miss a keycode that rfkills just my WLAN... I
> > > use that for power management, it is nice to have a key that is for WLAN
> > > only, and another that is for bluetooth-only...
> > 
> > KEY_WLAN will still be there, and you can still remap. But the default 
> > behaviour should be for thinkpad-acpi (for instance) to generate 
> > KEY_RFKILL, since Fn+F5 isn't supposed to be wlan only.
> 
> That's not what I got from this thread.  What I got was that KEY_WLAN would
> be overloaded with KEY_RFKILL semanthics, regardless of anything we did in
> the kernel side.

No.

> I am strongly with you here: add a *new* KEY_RFKILL, fix the kernel drivers
> and any eventual userspace to use the new KEY_RFKILL, and have KEY_WLAN do
> what it is supposed to do.

Right. That's what the patch I sent does.

> And, if what we call KEY_WLAN is actually supposed to be KEY_RFKILL, swap
> their definitions when adding KEY_RFKILL, so that USB HID devices will
> generate KEY_RFKILL instead of KEY_WLAN.

I don't think this is in HID?

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE
  2009-12-07 14:20                                                                                   ` Matthew Garrett
@ 2009-12-07 17:02                                                                                     ` Henrique de Moraes Holschuh
  0 siblings, 0 replies; 55+ messages in thread
From: Henrique de Moraes Holschuh @ 2009-12-07 17:02 UTC (permalink / raw)
  To: Matthew Garrett
  Cc: Corentin Chary, Dmitry Torokhov, Andrey Rahmatullin, Len Brown,
	linux-acpi, linux-input

On Mon, 07 Dec 2009, Matthew Garrett wrote:
> > That's not what I got from this thread.  What I got was that KEY_WLAN would
> > be overloaded with KEY_RFKILL semanthics, regardless of anything we did in
> > the kernel side.
> 
> No.

Good.

> > And, if what we call KEY_WLAN is actually supposed to be KEY_RFKILL, swap
> > their definitions when adding KEY_RFKILL, so that USB HID devices will
> > generate KEY_RFKILL instead of KEY_WLAN.
> 
> I don't think this is in HID?

I don't think it is.  I wrote that along the lines of "even if that were to
happen, there is a way to fix things properly".

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: [PATCH 00/33] acpi4asus updates for 2.6.33
  2009-12-03  7:44 [PATCH 00/33] acpi4asus updates for 2.6.33 Corentin Chary
  2009-12-03  7:44 ` [PATCH 01/33] eeepc-laptop: disp attribute should be write-only Corentin Chary
@ 2009-12-09 21:04 ` Len Brown
  1 sibling, 0 replies; 55+ messages in thread
From: Len Brown @ 2009-12-09 21:04 UTC (permalink / raw)
  To: Corentin Chary; +Cc: linux-acpi

all but #32 applied to acpi-test

thanks,
Len Brown, Intel Open Source Technology Center

On Thu, 3 Dec 2009, Corentin Chary wrote:

> Hi Len,
> Here patchs from acpi4asus for 2.6.33.
> You'll find a major rewrite of eeepc-laptop by Alan Jenkins which really
> cleans the code. I'm working one something similar for asus-laptop, this should
> be ready for 2.6.34.
> There is also some fix and updates for asus-laptop and asus-acpi.
> asus-laptop now support Lenovo SL laptop (yep this is strange, but this is the
> same acpi interface).
> 
> There is two smalls style issues in Alan's patchs, but I made a patch to fix that
> in the serie, it was easier than reworking the whole serie, but I'll try to
> avoid that next time.
> 
> The last two patchs may be controversial.
> 
> The first one add the KEY_WIRELESS_CYCLE. This keycode could be used when
> the key is not only for wlan, but could also be used for bluetooth and wimax.
> 
> The last schedule some asus-laptop features for removale, because they are
> not defined in a standard way in the acpi interface.
> Thanks,
> 
> Alan Jenkins (25):
>   eeepc-laptop: disp attribute should be write-only
>   asus-laptop: Remove redundant NULL checks
>   asus-acpi: Remove redundant NULL checks
>   asus-laptop: Remove uneccesary acpi_disabled check
>   asus-acpi: Remove uneccesary acpi_disabled checks
>   asus-acpi: set acpi_driver.owner
>   asus-laptop: set acpi_driver.owner
>   eeepc-laptop: Remove redundant NULL checks
>   eeepc-laptop: Remove uneccesary acpi_disabled check
>   eeepc-laptop: set acpi_driver.owner
>   eeepc-laptop: fix value of pwm1_enable to match documentation
>   eeepc-laptop: fix led initialization order
>   eeepc-laptop: fix potential leak (led_init() failure)
>   eeepc-laptop: fix set_acpi() to return non-zero on failure
>   eeepc-laptop: remove redundant NULL checks
>   eeepc-laptop: no need to check argument of set_brightness()
>   eeepc-laptop: simplify acpi initialization
>   eeepc-laptop: simplify how the hwmon device reads values from the EC
>   eeepc-laptop: refactor notifications
>   eeepc-laptop: move platform driver registration out of
>     eeepc_hotk_add()
>   eeepc-laptop: move platform device initialisation to a separate
>     function
>   eeepc-laptop: code movement
>   eeepc-laptop: revise names
>   eeepc-laptop: callbacks should use "driver data" parameter or field
>   eeepc-laptop: re-add check for eeepc->backlight == NULL
> 
> Corentin Chary (7):
>   eeepc-laptop: add touchpad led
>   asus-laptop: use KEY_F13 to map "Disable Touchpad" event
>   asus-laptop: Add wlan switch found on V6V
>   eeepc-laptop: map keys found on newer eeepc
>   eeepc-laptop: fix coding style
>   input: add KEY_WIRELESS_CYCLE
>   asus-laptop: schedule display_get and lcd_switch for removal
> 
> Ike Panhc (1):
>   asus-laptop: add Lenovo SL hotkey support
> 
>  Documentation/feature-removal-schedule.txt |   20 +
>  drivers/platform/x86/Kconfig               |    2 +
>  drivers/platform/x86/asus-laptop.c         |   21 +-
>  drivers/platform/x86/asus_acpi.c           |   19 +-
>  drivers/platform/x86/eeepc-laptop.c        | 1415 +++++++++++++++------------
>  include/linux/input.h                      |    1 +
>  6 files changed, 825 insertions(+), 653 deletions(-)
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

^ permalink raw reply	[flat|nested] 55+ messages in thread

end of thread, other threads:[~2009-12-09 21:04 UTC | newest]

Thread overview: 55+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-12-03  7:44 [PATCH 00/33] acpi4asus updates for 2.6.33 Corentin Chary
2009-12-03  7:44 ` [PATCH 01/33] eeepc-laptop: disp attribute should be write-only Corentin Chary
2009-12-03  7:44   ` [PATCH 02/33] asus-laptop: Remove redundant NULL checks Corentin Chary
2009-12-03  7:44     ` [PATCH 03/33] asus-acpi: " Corentin Chary
2009-12-03  7:44       ` [PATCH 04/33] asus-laptop: Remove uneccesary acpi_disabled check Corentin Chary
2009-12-03  7:44         ` [PATCH 05/33] asus-acpi: Remove uneccesary acpi_disabled checks Corentin Chary
2009-12-03  7:44           ` [PATCH 06/33] asus-acpi: set acpi_driver.owner Corentin Chary
2009-12-03  7:44             ` [PATCH 07/33] asus-laptop: " Corentin Chary
2009-12-03  7:44               ` [PATCH 08/33] eeepc-laptop: add touchpad led Corentin Chary
2009-12-03  7:44                 ` [PATCH 09/33] eeepc-laptop: Remove redundant NULL checks Corentin Chary
2009-12-03  7:44                   ` [PATCH 10/33] eeepc-laptop: Remove uneccesary acpi_disabled check Corentin Chary
2009-12-03  7:44                     ` [PATCH 11/33] eeepc-laptop: set acpi_driver.owner Corentin Chary
2009-12-03  7:44                       ` [PATCH 12/33] eeepc-laptop: fix value of pwm1_enable to match documentation Corentin Chary
2009-12-03  7:44                         ` [PATCH 13/33] eeepc-laptop: fix led initialization order Corentin Chary
2009-12-03  7:44                           ` [PATCH 14/33] eeepc-laptop: fix potential leak (led_init() failure) Corentin Chary
2009-12-03  7:44                             ` [PATCH 15/33] eeepc-laptop: fix set_acpi() to return non-zero on failure Corentin Chary
2009-12-03  7:45                               ` [PATCH 16/33] eeepc-laptop: remove redundant NULL checks Corentin Chary
2009-12-03  7:45                                 ` [PATCH 17/33] eeepc-laptop: no need to check argument of set_brightness() Corentin Chary
2009-12-03  7:45                                   ` [PATCH 18/33] eeepc-laptop: simplify acpi initialization Corentin Chary
2009-12-03  7:45                                     ` [PATCH 19/33] eeepc-laptop: simplify how the hwmon device reads values from the EC Corentin Chary
2009-12-03  7:45                                       ` [PATCH 20/33] eeepc-laptop: refactor notifications Corentin Chary
2009-12-03  7:45                                         ` [PATCH 21/33] eeepc-laptop: move platform driver registration out of eeepc_hotk_add() Corentin Chary
2009-12-03  7:45                                           ` [PATCH 22/33] eeepc-laptop: move platform device initialisation to a separate function Corentin Chary
2009-12-03  7:45                                             ` [PATCH 23/33] eeepc-laptop: code movement Corentin Chary
2009-12-03  7:45                                               ` [PATCH 24/33] eeepc-laptop: revise names Corentin Chary
2009-12-03  7:45                                                 ` [PATCH 25/33] eeepc-laptop: callbacks should use "driver data" parameter or field Corentin Chary
2009-12-03  7:45                                                   ` [PATCH 26/33] asus-laptop: use KEY_F13 to map "Disable Touchpad" event Corentin Chary
2009-12-03  7:45                                                     ` [PATCH 27/33] asus-laptop: add Lenovo SL hotkey support Corentin Chary
2009-12-03  7:45                                                       ` [PATCH 28/33] asus-laptop: Add wlan switch found on V6V Corentin Chary
2009-12-03  7:45                                                         ` [PATCH 29/33] eeepc-laptop: map keys found on newer eeepc Corentin Chary
2009-12-03  7:45                                                           ` [PATCH 30/33] eeepc-laptop: fix coding style Corentin Chary
2009-12-03  7:45                                                             ` [PATCH 31/33] eeepc-laptop: re-add check for eeepc->backlight == NULL Corentin Chary
2009-12-03  7:45                                                               ` [PATCH 32/33] input: add KEY_WIRELESS_CYCLE Corentin Chary
2009-12-03  7:45                                                                 ` [PATCH 33/33] asus-laptop: schedule display_get and lcd_switch for removal Corentin Chary
2009-12-03  7:54                                                                 ` [PATCH 32/33] input: add KEY_WIRELESS_CYCLE Dmitry Torokhov
2009-12-03  8:12                                                                   ` Corentin Chary
2009-12-03  8:21                                                                     ` Dmitry Torokhov
2009-12-03  8:51                                                                       ` Corentin Chary
2009-12-03  8:57                                                                         ` Dmitry Torokhov
2009-12-03  9:22                                                                           ` Corentin Chary
2009-12-03  9:43                                                                             ` Johannes Berg
2009-12-03 11:23                                                                               ` [Kde-hardware-devel] " Will Stephenson
2009-12-03 11:23                                                                                 ` Will Stephenson
2009-12-03 15:01                                                                             ` Matthew Garrett
2009-12-06  6:58                                                                     ` Andrey Rahmatullin
2009-12-06  7:17                                                                       ` Dmitry Torokhov
2009-12-06  8:21                                                                         ` Corentin Chary
2009-12-06 14:54                                                                           ` Matthew Garrett
2009-12-07 11:47                                                                             ` Henrique de Moraes Holschuh
2009-12-07 12:55                                                                               ` Matthew Garrett
2009-12-07 13:23                                                                                 ` Henrique de Moraes Holschuh
2009-12-07 14:20                                                                                   ` Matthew Garrett
2009-12-07 17:02                                                                                     ` Henrique de Moraes Holschuh
2009-12-03 10:54                                                                   ` Henrique de Moraes Holschuh
2009-12-09 21:04 ` [PATCH 00/33] acpi4asus updates for 2.6.33 Len Brown

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.