[PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Ike Panhc]

These patches are made against 2.6.36-rc1 and also available at
  git://kernel.ubuntu.com/ikepanhc/ideapad-laptop.git for-upstream

Once the rfkill of a laptop is set to block, it is no way to unblock with Linux
without driver. Thanks for David Woodhouse wrote the first driver solving this.

But the \_SB_.GECN and \_SB_.DECN are only available on Lenovo ideapad S10-3.
Using EC command to control rf/camera power is better because I believe every
ideapads which has VPC2004 device in its DSDT has this common method.

This driver is tested and work fine on Lenovo ideapad B550 and ideapad S10-3.

Ike Panhc (8):
  ideapad: add ACPI helpers
  ideapad: check VPC bit before sync rfkill hw status
  ideapad: make sure we bind on the correct device
  ideapad: use return value of _CFG to tell if device exist or not
  ideapad: use EC command to control camera
  ideapad: rewrite the hw rfkill notify
  ideapad: rewrite the sw rfkill set
  ideapad: Change the driver name to ideapad_laptop

 drivers/platform/x86/Kconfig          |    4 +-
 drivers/platform/x86/Makefile         |    2 +-
 drivers/platform/x86/ideapad_acpi.c   |  306 --------------------------
 drivers/platform/x86/ideapad_laptop.c |  381 +++++++++++++++++++++++++++++++++
 4 files changed, 384 insertions(+), 309 deletions(-)
 delete mode 100644 drivers/platform/x86/ideapad_acpi.c
 create mode 100644 drivers/platform/x86/ideapad_laptop.c

[PATCH 1/8] ideapad: add ACPI helpers

[Ike Panhc]

There are two methods under VPC2004 which is used to access VDAT/VCMD of EC
register. Add helpers for read and write these two registers.

And add read_method_int for reading the return value from ACPI methods which
requires no parameter.

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

diff --git a/drivers/platform/x86/ideapad_acpi.c b/drivers/platform/x86/ideapad_acpi.c
index 7984963..af630e2 100644
--- a/drivers/platform/x86/ideapad_acpi.c
+++ b/drivers/platform/x86/ideapad_acpi.c
@@ -49,6 +49,117 @@ static struct {
 	{ "ideapad_killsw",	RFKILL_TYPE_WLAN }
 };
 
+/*
+ * ACPI Helpers
+ */
+#define IDEAPAD_EC_TIMEOUT (25) /* in ms */
+
+static int read_method_int(acpi_handle handle, const char *method, int *val)
+{
+	acpi_status status;
+	unsigned long long result;
+
+	status = acpi_evaluate_integer(handle, (char *)method, NULL, &result);
+	if (ACPI_FAILURE(status)) {
+		*val = -1;
+		return -1;
+	} else {
+		*val = result;
+		return 0;
+	}
+}
+
+static int method_vpcr(acpi_handle handle, int cmd, int *ret)
+{
+	acpi_status status;
+	unsigned long long result;
+	struct acpi_object_list params;
+	union acpi_object in_obj;
+
+	params.count = 1;
+	params.pointer = &in_obj;
+	in_obj.type = ACPI_TYPE_INTEGER;
+	in_obj.integer.value = cmd;
+
+	status = acpi_evaluate_integer(handle, "VPCR", &params, &result);
+
+	if (ACPI_FAILURE(status)) {
+		*ret = -1;
+		return -1;
+	} else {
+		*ret = result;
+		return 0;
+	}
+}
+
+static int method_vpcw(acpi_handle handle, int cmd, int data)
+{
+	struct acpi_object_list params;
+	union acpi_object in_obj[2];
+	acpi_status status;
+
+	params.count = 2;
+	params.pointer = in_obj;
+	in_obj[0].type = ACPI_TYPE_INTEGER;
+	in_obj[0].integer.value = cmd;
+	in_obj[1].type = ACPI_TYPE_INTEGER;
+	in_obj[1].integer.value = data;
+
+	status = acpi_evaluate_object(handle, "VPCW", &params, NULL);
+	if (status != AE_OK)
+		return -1;
+	return 0;
+}
+
+static int read_ec_data(acpi_handle handle, int cmd, unsigned long *data)
+{
+	int val;
+	unsigned long int start_jiffies, now_jiffies;
+
+	if (method_vpcw(handle, 1, cmd))
+		return -1;
+
+	for (start_jiffies = jiffies;; ) {
+		if (method_vpcr(handle, 1, &val))
+			return -1;
+		if (val == 0) {
+			if (method_vpcr(handle, 0, &val))
+				return -1;
+			*data = val;
+			return 0;
+		}
+		now_jiffies = jiffies;
+		if ((now_jiffies-start_jiffies) > (HZ)/IDEAPAD_EC_TIMEOUT+1) {
+			pr_err("timeout in read_ec_cmd\n");
+			return -1;
+		}
+	}
+}
+
+static int write_ec_cmd(acpi_handle handle, int cmd, unsigned long data)
+{
+	int val;
+	unsigned long int start_jiffies, now_jiffies;
+
+	if (method_vpcw(handle, 0, data))
+		return -1;
+	if (method_vpcw(handle, 1, cmd))
+		return -1;
+
+	for (start_jiffies = jiffies;; ) {
+		if (method_vpcr(handle, 1, &val))
+			return -1;
+		if (val == 0)
+			return 0;
+		now_jiffies = jiffies;
+		if ((now_jiffies-start_jiffies) > (HZ)/IDEAPAD_EC_TIMEOUT+1) {
+			pr_err("timeout in write_ec_cmd\n");
+			return -1;
+		}
+	}
+}
+/* the above is ACPI helpers */
+
 static int ideapad_dev_exists(int device)
 {
 	acpi_status status;
-- 
1.7.0.4

[PATCH 2/8] ideapad: check VPC bit before sync rfkill hw status

[Ike Panhc]

Check VPC bit to make sure the HW rfkill is touched.

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

diff --git a/drivers/platform/x86/ideapad_acpi.c b/drivers/platform/x86/ideapad_acpi.c
index af630e2..6176597 100644
--- a/drivers/platform/x86/ideapad_acpi.c
+++ b/drivers/platform/x86/ideapad_acpi.c
@@ -381,7 +381,21 @@ static int ideapad_acpi_remove(struct acpi_device *adevice, int type)
 
 static void ideapad_acpi_notify(struct acpi_device *adevice, u32 event)
 {
-	ideapad_sync_rfk_state(adevice);
+	acpi_handle handle = adevice->handle;
+	unsigned long vpc1, vpc2, vpc_bit;
+
+	if (read_ec_data(handle, 0x10, &vpc1))
+		return;
+	if (read_ec_data(handle, 0x1A, &vpc2))
+		return;
+
+	vpc1 = (vpc2 << 8) | vpc1;
+	for (vpc_bit = 0; vpc_bit < 16; vpc_bit++) {
+		if (test_bit(vpc_bit, &vpc1)) {
+			if (vpc_bit == 9)
+				ideapad_sync_rfk_state(adevice);
+		}
+	}
 }
 
 static struct acpi_driver ideapad_acpi_driver = {
-- 
1.7.0.4

[PATCH 3/8] ideapad: make sure we bind on the correct device

[Ike Panhc]

By reading from method _STA and _CFG to make sure we bind on the correct
VPC2004 device.

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

diff --git a/drivers/platform/x86/ideapad_acpi.c b/drivers/platform/x86/ideapad_acpi.c
index 6176597..c1eec70 100644
--- a/drivers/platform/x86/ideapad_acpi.c
+++ b/drivers/platform/x86/ideapad_acpi.c
@@ -328,10 +328,18 @@ MODULE_DEVICE_TABLE(acpi, ideapad_device_ids);
 
 static int ideapad_acpi_add(struct acpi_device *adevice)
 {
-	int i;
+	int i, cfg;
 	int devs_present[5];
 	struct ideapad_private *priv;
 
+	if (read_method_int(adevice->handle, "_STA", &i))
+		return -ENODEV;
+	if (i != 0x0F)
+		return -ENODEV;
+
+	if (read_method_int(adevice->handle, "_CFG", &cfg))
+		return -ENODEV;
+
 	for (i = IDEAPAD_DEV_CAMERA; i < IDEAPAD_DEV_KILLSW; i++) {
 		devs_present[i] = ideapad_dev_exists(i);
 		if (devs_present[i] < 0)
-- 
1.7.0.4

[PATCH 4/8] ideapad: use return value of _CFG to tell if device exist or not

[Ike Panhc]

There are several bits of the return value of _CFG shows if RF/Camera devices
exist or not.

Signed-off-by: Ike Panhc <ike.pan@canonical.com>
---
 drivers/platform/x86/ideapad_acpi.c |   44 ++++++++---------------------------
 1 files changed, 10 insertions(+), 34 deletions(-)

diff --git a/drivers/platform/x86/ideapad_acpi.c b/drivers/platform/x86/ideapad_acpi.c
index c1eec70..673b44d 100644
--- a/drivers/platform/x86/ideapad_acpi.c
+++ b/drivers/platform/x86/ideapad_acpi.c
@@ -40,13 +40,14 @@ struct ideapad_private {
 
 static struct {
 	char *name;
+	int cfgbit;
 	int type;
 } ideapad_rfk_data[] = {
-	/* camera has no rfkill */
-	{ "ideapad_wlan",	RFKILL_TYPE_WLAN },
-	{ "ideapad_bluetooth",	RFKILL_TYPE_BLUETOOTH },
-	{ "ideapad_3g",		RFKILL_TYPE_WWAN },
-	{ "ideapad_killsw",	RFKILL_TYPE_WLAN }
+	{ "ideapad_camera",	19, NUM_RFKILL_TYPES },
+	{ "ideapad_wlan",	18, RFKILL_TYPE_WLAN },
+	{ "ideapad_bluetooth",	16, RFKILL_TYPE_BLUETOOTH },
+	{ "ideapad_3g",		17, RFKILL_TYPE_WWAN },
+	{ "ideapad_killsw",	0, RFKILL_TYPE_WLAN }
 };
 
 /*
@@ -160,32 +161,6 @@ static int write_ec_cmd(acpi_handle handle, int cmd, unsigned long data)
 }
 /* the above is ACPI helpers */
 
-static int ideapad_dev_exists(int device)
-{
-	acpi_status status;
-	union acpi_object in_param;
-	struct acpi_object_list input = { 1, &in_param };
-	struct acpi_buffer output;
-	union acpi_object out_obj;
-
-	output.length = sizeof(out_obj);
-	output.pointer = &out_obj;
-
-	in_param.type = ACPI_TYPE_INTEGER;
-	in_param.integer.value = device + 1;
-
-	status = acpi_evaluate_object(NULL, "\\_SB_.DECN", &input, &output);
-	if (ACPI_FAILURE(status)) {
-		printk(KERN_WARNING "IdeaPAD \\_SB_.DECN method failed %d. Is this an IdeaPAD?\n", status);
-		return -ENODEV;
-	}
-	if (out_obj.type != ACPI_TYPE_INTEGER) {
-		printk(KERN_WARNING "IdeaPAD \\_SB_.DECN method returned unexpected type\n");
-		return -ENODEV;
-	}
-	return out_obj.integer.value;
-}
-
 static int ideapad_dev_get_state(int device)
 {
 	acpi_status status;
@@ -341,9 +316,10 @@ static int ideapad_acpi_add(struct acpi_device *adevice)
 		return -ENODEV;
 
 	for (i = IDEAPAD_DEV_CAMERA; i < IDEAPAD_DEV_KILLSW; i++) {
-		devs_present[i] = ideapad_dev_exists(i);
-		if (devs_present[i] < 0)
-			return devs_present[i];
+		if (test_bit(ideapad_rfk_data[i].cfgbit, (unsigned long *)&cfg))
+			devs_present[i] = 1;
+		else
+			devs_present[i] = 0;
 	}
 
 	/* The hardware switch is always present */
-- 
1.7.0.4

[PATCH 5/8] ideapad: use EC command to control camera

[Ike Panhc]

Signed-off-by: Ike Panhc <ike.pan@canonical.com>
---
 drivers/platform/x86/ideapad_acpi.c |   16 +++++++++++-----
 1 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/platform/x86/ideapad_acpi.c b/drivers/platform/x86/ideapad_acpi.c
index 673b44d..a1fdb45 100644
--- a/drivers/platform/x86/ideapad_acpi.c
+++ b/drivers/platform/x86/ideapad_acpi.c
@@ -35,6 +35,7 @@
 #define IDEAPAD_DEV_KILLSW	4
 
 struct ideapad_private {
+	acpi_handle handle;
 	struct rfkill *rfk[5];
 };
 
@@ -209,24 +210,28 @@ static ssize_t show_ideapad_cam(struct device *dev,
 				struct device_attribute *attr,
 				char *buf)
 {
-	int state = ideapad_dev_get_state(IDEAPAD_DEV_CAMERA);
-	if (state < 0)
-		return state;
+	struct ideapad_private *priv = dev_get_drvdata(dev);
+	acpi_handle handle = priv->handle;
+	unsigned long result;
 
-	return sprintf(buf, "%d\n", state);
+	if (read_ec_data(handle, 0x1D, &result))
+		return sprintf(buf, "-1\n");
+	return sprintf(buf, "%lu\n", result);
 }
 
 static ssize_t store_ideapad_cam(struct device *dev,
 				 struct device_attribute *attr,
 				 const char *buf, size_t count)
 {
+	struct ideapad_private *priv = dev_get_drvdata(dev);
+	acpi_handle handle = priv->handle;
 	int ret, state;
 
 	if (!count)
 		return 0;
 	if (sscanf(buf, "%i", &state) != 1)
 		return -EINVAL;
-	ret = ideapad_dev_set_state(IDEAPAD_DEV_CAMERA, !!state);
+	ret = write_ec_cmd(handle, 0x1E, state);
 	if (ret < 0)
 		return ret;
 	return count;
@@ -337,6 +342,7 @@ static int ideapad_acpi_add(struct acpi_device *adevice)
 		}
 	}
 
+	priv->handle = adevice->handle;
 	dev_set_drvdata(&adevice->dev, priv);
 	for (i = IDEAPAD_DEV_WLAN; i <= IDEAPAD_DEV_KILLSW; i++) {
 		if (!devs_present[i])
-- 
1.7.0.4

[PATCH 6/8] ideapad: rewrite the hw rfkill notify

[Ike Panhc]

1. Read hw rfkill status by ec command
2. Not to touch sw status of each rfkill when hw rfkill notify
3. Enable RF when module initial

Signed-off-by: Ike Panhc <ike.pan@canonical.com>
---
 drivers/platform/x86/ideapad_acpi.c |   45 +++++++----------------------------
 1 files changed, 9 insertions(+), 36 deletions(-)

diff --git a/drivers/platform/x86/ideapad_acpi.c b/drivers/platform/x86/ideapad_acpi.c
index a1fdb45..9d0e23f 100644
--- a/drivers/platform/x86/ideapad_acpi.c
+++ b/drivers/platform/x86/ideapad_acpi.c
@@ -162,32 +162,6 @@ static int write_ec_cmd(acpi_handle handle, int cmd, unsigned long data)
 }
 /* the above is ACPI helpers */
 
-static int ideapad_dev_get_state(int device)
-{
-	acpi_status status;
-	union acpi_object in_param;
-	struct acpi_object_list input = { 1, &in_param };
-	struct acpi_buffer output;
-	union acpi_object out_obj;
-
-	output.length = sizeof(out_obj);
-	output.pointer = &out_obj;
-
-	in_param.type = ACPI_TYPE_INTEGER;
-	in_param.integer.value = device + 1;
-
-	status = acpi_evaluate_object(NULL, "\\_SB_.GECN", &input, &output);
-	if (ACPI_FAILURE(status)) {
-		printk(KERN_WARNING "IdeaPAD \\_SB_.GECN method failed %d\n", status);
-		return -ENODEV;
-	}
-	if (out_obj.type != ACPI_TYPE_INTEGER) {
-		printk(KERN_WARNING "IdeaPAD \\_SB_.GECN method returned unexpected type\n");
-		return -ENODEV;
-	}
-	return out_obj.integer.value;
-}
-
 static int ideapad_dev_set_state(int device, int state)
 {
 	acpi_status status;
@@ -255,19 +229,17 @@ static struct rfkill_ops ideapad_rfk_ops = {
 static void ideapad_sync_rfk_state(struct acpi_device *adevice)
 {
 	struct ideapad_private *priv = dev_get_drvdata(&adevice->dev);
-	int hw_blocked = !ideapad_dev_get_state(IDEAPAD_DEV_KILLSW);
+	acpi_handle handle = priv->handle;
+	unsigned long hw_blocked;
 	int i;
 
-	rfkill_set_hw_state(priv->rfk[IDEAPAD_DEV_KILLSW], hw_blocked);
-	for (i = IDEAPAD_DEV_WLAN; i < IDEAPAD_DEV_KILLSW; i++)
-		if (priv->rfk[i])
-			rfkill_set_hw_state(priv->rfk[i], hw_blocked);
-	if (hw_blocked)
+	if (read_ec_data(handle, 0x23, &hw_blocked))
 		return;
+	hw_blocked = !hw_blocked;
 
-	for (i = IDEAPAD_DEV_WLAN; i < IDEAPAD_DEV_KILLSW; i++)
+	for (i = IDEAPAD_DEV_WLAN; i <= IDEAPAD_DEV_KILLSW; i++)
 		if (priv->rfk[i])
-			rfkill_set_sw_state(priv->rfk[i], !ideapad_dev_get_state(i));
+			rfkill_set_hw_state(priv->rfk[i], hw_blocked);
 }
 
 static int ideapad_register_rfkill(struct acpi_device *adevice, int dev)
@@ -275,12 +247,13 @@ static int ideapad_register_rfkill(struct acpi_device *adevice, int dev)
 	struct ideapad_private *priv = dev_get_drvdata(&adevice->dev);
 	int ret;
 
-	priv->rfk[dev] = rfkill_alloc(ideapad_rfk_data[dev-1].name, &adevice->dev,
-				      ideapad_rfk_data[dev-1].type, &ideapad_rfk_ops,
+	priv->rfk[dev] = rfkill_alloc(ideapad_rfk_data[dev].name, &adevice->dev,
+				      ideapad_rfk_data[dev].type, &ideapad_rfk_ops,
 				      (void *)(long)dev);
 	if (!priv->rfk[dev])
 		return -ENOMEM;
 
+	rfkill_init_sw_state(priv->rfk[dev], 0);
 	ret = rfkill_register(priv->rfk[dev]);
 	if (ret) {
 		rfkill_destroy(priv->rfk[dev]);
-- 
1.7.0.4

[PATCH 7/8] ideapad: rewrite the sw rfkill set

[Ike Panhc]

Control power of rf modules by ec commands

Signed-off-by: Ike Panhc <ike.pan@canonical.com>
---
 drivers/platform/x86/ideapad_acpi.c |   37 +++++++++++-----------------------
 1 files changed, 12 insertions(+), 25 deletions(-)

diff --git a/drivers/platform/x86/ideapad_acpi.c b/drivers/platform/x86/ideapad_acpi.c
index 9d0e23f..7c414e5 100644
--- a/drivers/platform/x86/ideapad_acpi.c
+++ b/drivers/platform/x86/ideapad_acpi.c
@@ -37,18 +37,19 @@
 struct ideapad_private {
 	acpi_handle handle;
 	struct rfkill *rfk[5];
-};
+} *ideapad_priv;
 
 static struct {
 	char *name;
 	int cfgbit;
+	int opcode;
 	int type;
 } ideapad_rfk_data[] = {
-	{ "ideapad_camera",	19, NUM_RFKILL_TYPES },
-	{ "ideapad_wlan",	18, RFKILL_TYPE_WLAN },
-	{ "ideapad_bluetooth",	16, RFKILL_TYPE_BLUETOOTH },
-	{ "ideapad_3g",		17, RFKILL_TYPE_WWAN },
-	{ "ideapad_killsw",	0, RFKILL_TYPE_WLAN }
+	{ "ideapad_camera",	19, 0x1E, NUM_RFKILL_TYPES },
+	{ "ideapad_wlan",	18, 0x15, RFKILL_TYPE_WLAN },
+	{ "ideapad_bluetooth",	16, 0x17, RFKILL_TYPE_BLUETOOTH },
+	{ "ideapad_3g",		17, 0x20, RFKILL_TYPE_WWAN },
+	{ "ideapad_killsw",	0,  0,    RFKILL_TYPE_WLAN }
 };
 
 /*
@@ -162,24 +163,6 @@ static int write_ec_cmd(acpi_handle handle, int cmd, unsigned long data)
 }
 /* the above is ACPI helpers */
 
-static int ideapad_dev_set_state(int device, int state)
-{
-	acpi_status status;
-	union acpi_object in_params[2];
-	struct acpi_object_list input = { 2, in_params };
-
-	in_params[0].type = ACPI_TYPE_INTEGER;
-	in_params[0].integer.value = device + 1;
-	in_params[1].type = ACPI_TYPE_INTEGER;
-	in_params[1].integer.value = state;
-
-	status = acpi_evaluate_object(NULL, "\\_SB_.SECN", &input, NULL);
-	if (ACPI_FAILURE(status)) {
-		printk(KERN_WARNING "IdeaPAD \\_SB_.SECN method failed %d\n", status);
-		return -ENODEV;
-	}
-	return 0;
-}
 static ssize_t show_ideapad_cam(struct device *dev,
 				struct device_attribute *attr,
 				char *buf)
@@ -219,7 +202,10 @@ static int ideapad_rfk_set(void *data, bool blocked)
 
 	if (device == IDEAPAD_DEV_KILLSW)
 		return -EINVAL;
-	return ideapad_dev_set_state(device, !blocked);
+
+	return write_ec_cmd(ideapad_priv->handle,
+			    ideapad_rfk_data[device].opcode,
+			    !blocked);
 }
 
 static struct rfkill_ops ideapad_rfk_ops = {
@@ -317,6 +303,7 @@ static int ideapad_acpi_add(struct acpi_device *adevice)
 
 	priv->handle = adevice->handle;
 	dev_set_drvdata(&adevice->dev, priv);
+	ideapad_priv = priv;
 	for (i = IDEAPAD_DEV_WLAN; i <= IDEAPAD_DEV_KILLSW; i++) {
 		if (!devs_present[i])
 			continue;
-- 
1.7.0.4

[PATCH 8/8] ideapad: Change the driver name to ideapad_laptop

[Ike Panhc]

Since the platform drivers doing more for laptops than just using specific
ACPI device. It will be good to change the name from *_acpi to *_laptop.

Reference: http://lkml.org/lkml/2010/8/14/154

Signed-off-by: Ike Panhc <ike.pan@canonical.com>
---
 drivers/platform/x86/Kconfig          |    4 +-
 drivers/platform/x86/Makefile         |    2 +-
 drivers/platform/x86/ideapad_acpi.c   |  381 ---------------------------------
 drivers/platform/x86/ideapad_laptop.c |  381 +++++++++++++++++++++++++++++++++
 4 files changed, 384 insertions(+), 384 deletions(-)
 delete mode 100644 drivers/platform/x86/ideapad_acpi.c
 create mode 100644 drivers/platform/x86/ideapad_laptop.c

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 044f430..635d198 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -219,8 +219,8 @@ config SONYPI_COMPAT
 	  ---help---
 	  Build the sonypi driver compatibility code into the sony-laptop driver.
 
-config IDEAPAD_ACPI
-	tristate "Lenovo IdeaPad ACPI Laptop Extras"
+config IDEAPAD_LAPTOP
+	tristate "Lenovo IdeaPad Laptop Extras"
 	depends on ACPI
 	depends on RFKILL
 	help
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 85fb2b8..9846fa2 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -15,7 +15,7 @@ obj-$(CONFIG_ACERHDF)		+= acerhdf.o
 obj-$(CONFIG_HP_WMI)		+= hp-wmi.o
 obj-$(CONFIG_TC1100_WMI)	+= tc1100-wmi.o
 obj-$(CONFIG_SONY_LAPTOP)	+= sony-laptop.o
-obj-$(CONFIG_IDEAPAD_ACPI)	+= ideapad_acpi.o
+obj-$(CONFIG_IDEAPAD_LAPTOP)	+= ideapad_laptop.o
 obj-$(CONFIG_THINKPAD_ACPI)	+= thinkpad_acpi.o
 obj-$(CONFIG_FUJITSU_LAPTOP)	+= fujitsu-laptop.o
 obj-$(CONFIG_PANASONIC_LAPTOP)	+= panasonic-laptop.o
diff --git a/drivers/platform/x86/ideapad_acpi.c b/drivers/platform/x86/ideapad_acpi.c
deleted file mode 100644
index 7c414e5..0000000
--- a/drivers/platform/x86/ideapad_acpi.c
+++ /dev/null
@@ -1,381 +0,0 @@
-/*
- *  ideapad_acpi.c - Lenovo IdeaPad ACPI Extras
- *
- *  Copyright © 2010 Intel Corporation
- *  Copyright © 2010 David Woodhouse <dwmw2@infradead.org>
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation; either version 2 of the License, or
- *  (at your option) any later version.
- *
- *  This program is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
- *  02110-1301, USA.
- */
-
-#include <linux/kernel.h>
-#include <linux/module.h>
-#include <linux/init.h>
-#include <linux/types.h>
-#include <acpi/acpi_bus.h>
-#include <acpi/acpi_drivers.h>
-#include <linux/rfkill.h>
-
-#define IDEAPAD_DEV_CAMERA	0
-#define IDEAPAD_DEV_WLAN	1
-#define IDEAPAD_DEV_BLUETOOTH	2
-#define IDEAPAD_DEV_3G		3
-#define IDEAPAD_DEV_KILLSW	4
-
-struct ideapad_private {
-	acpi_handle handle;
-	struct rfkill *rfk[5];
-} *ideapad_priv;
-
-static struct {
-	char *name;
-	int cfgbit;
-	int opcode;
-	int type;
-} ideapad_rfk_data[] = {
-	{ "ideapad_camera",	19, 0x1E, NUM_RFKILL_TYPES },
-	{ "ideapad_wlan",	18, 0x15, RFKILL_TYPE_WLAN },
-	{ "ideapad_bluetooth",	16, 0x17, RFKILL_TYPE_BLUETOOTH },
-	{ "ideapad_3g",		17, 0x20, RFKILL_TYPE_WWAN },
-	{ "ideapad_killsw",	0,  0,    RFKILL_TYPE_WLAN }
-};
-
-/*
- * ACPI Helpers
- */
-#define IDEAPAD_EC_TIMEOUT (25) /* in ms */
-
-static int read_method_int(acpi_handle handle, const char *method, int *val)
-{
-	acpi_status status;
-	unsigned long long result;
-
-	status = acpi_evaluate_integer(handle, (char *)method, NULL, &result);
-	if (ACPI_FAILURE(status)) {
-		*val = -1;
-		return -1;
-	} else {
-		*val = result;
-		return 0;
-	}
-}
-
-static int method_vpcr(acpi_handle handle, int cmd, int *ret)
-{
-	acpi_status status;
-	unsigned long long result;
-	struct acpi_object_list params;
-	union acpi_object in_obj;
-
-	params.count = 1;
-	params.pointer = &in_obj;
-	in_obj.type = ACPI_TYPE_INTEGER;
-	in_obj.integer.value = cmd;
-
-	status = acpi_evaluate_integer(handle, "VPCR", &params, &result);
-
-	if (ACPI_FAILURE(status)) {
-		*ret = -1;
-		return -1;
-	} else {
-		*ret = result;
-		return 0;
-	}
-}
-
-static int method_vpcw(acpi_handle handle, int cmd, int data)
-{
-	struct acpi_object_list params;
-	union acpi_object in_obj[2];
-	acpi_status status;
-
-	params.count = 2;
-	params.pointer = in_obj;
-	in_obj[0].type = ACPI_TYPE_INTEGER;
-	in_obj[0].integer.value = cmd;
-	in_obj[1].type = ACPI_TYPE_INTEGER;
-	in_obj[1].integer.value = data;
-
-	status = acpi_evaluate_object(handle, "VPCW", &params, NULL);
-	if (status != AE_OK)
-		return -1;
-	return 0;
-}
-
-static int read_ec_data(acpi_handle handle, int cmd, unsigned long *data)
-{
-	int val;
-	unsigned long int start_jiffies, now_jiffies;
-
-	if (method_vpcw(handle, 1, cmd))
-		return -1;
-
-	for (start_jiffies = jiffies;; ) {
-		if (method_vpcr(handle, 1, &val))
-			return -1;
-		if (val == 0) {
-			if (method_vpcr(handle, 0, &val))
-				return -1;
-			*data = val;
-			return 0;
-		}
-		now_jiffies = jiffies;
-		if ((now_jiffies-start_jiffies) > (HZ)/IDEAPAD_EC_TIMEOUT+1) {
-			pr_err("timeout in read_ec_cmd\n");
-			return -1;
-		}
-	}
-}
-
-static int write_ec_cmd(acpi_handle handle, int cmd, unsigned long data)
-{
-	int val;
-	unsigned long int start_jiffies, now_jiffies;
-
-	if (method_vpcw(handle, 0, data))
-		return -1;
-	if (method_vpcw(handle, 1, cmd))
-		return -1;
-
-	for (start_jiffies = jiffies;; ) {
-		if (method_vpcr(handle, 1, &val))
-			return -1;
-		if (val == 0)
-			return 0;
-		now_jiffies = jiffies;
-		if ((now_jiffies-start_jiffies) > (HZ)/IDEAPAD_EC_TIMEOUT+1) {
-			pr_err("timeout in write_ec_cmd\n");
-			return -1;
-		}
-	}
-}
-/* the above is ACPI helpers */
-
-static ssize_t show_ideapad_cam(struct device *dev,
-				struct device_attribute *attr,
-				char *buf)
-{
-	struct ideapad_private *priv = dev_get_drvdata(dev);
-	acpi_handle handle = priv->handle;
-	unsigned long result;
-
-	if (read_ec_data(handle, 0x1D, &result))
-		return sprintf(buf, "-1\n");
-	return sprintf(buf, "%lu\n", result);
-}
-
-static ssize_t store_ideapad_cam(struct device *dev,
-				 struct device_attribute *attr,
-				 const char *buf, size_t count)
-{
-	struct ideapad_private *priv = dev_get_drvdata(dev);
-	acpi_handle handle = priv->handle;
-	int ret, state;
-
-	if (!count)
-		return 0;
-	if (sscanf(buf, "%i", &state) != 1)
-		return -EINVAL;
-	ret = write_ec_cmd(handle, 0x1E, state);
-	if (ret < 0)
-		return ret;
-	return count;
-}
-
-static DEVICE_ATTR(camera_power, 0644, show_ideapad_cam, store_ideapad_cam);
-
-static int ideapad_rfk_set(void *data, bool blocked)
-{
-	int device = (unsigned long)data;
-
-	if (device == IDEAPAD_DEV_KILLSW)
-		return -EINVAL;
-
-	return write_ec_cmd(ideapad_priv->handle,
-			    ideapad_rfk_data[device].opcode,
-			    !blocked);
-}
-
-static struct rfkill_ops ideapad_rfk_ops = {
-	.set_block = ideapad_rfk_set,
-};
-
-static void ideapad_sync_rfk_state(struct acpi_device *adevice)
-{
-	struct ideapad_private *priv = dev_get_drvdata(&adevice->dev);
-	acpi_handle handle = priv->handle;
-	unsigned long hw_blocked;
-	int i;
-
-	if (read_ec_data(handle, 0x23, &hw_blocked))
-		return;
-	hw_blocked = !hw_blocked;
-
-	for (i = IDEAPAD_DEV_WLAN; i <= IDEAPAD_DEV_KILLSW; i++)
-		if (priv->rfk[i])
-			rfkill_set_hw_state(priv->rfk[i], hw_blocked);
-}
-
-static int ideapad_register_rfkill(struct acpi_device *adevice, int dev)
-{
-	struct ideapad_private *priv = dev_get_drvdata(&adevice->dev);
-	int ret;
-
-	priv->rfk[dev] = rfkill_alloc(ideapad_rfk_data[dev].name, &adevice->dev,
-				      ideapad_rfk_data[dev].type, &ideapad_rfk_ops,
-				      (void *)(long)dev);
-	if (!priv->rfk[dev])
-		return -ENOMEM;
-
-	rfkill_init_sw_state(priv->rfk[dev], 0);
-	ret = rfkill_register(priv->rfk[dev]);
-	if (ret) {
-		rfkill_destroy(priv->rfk[dev]);
-		return ret;
-	}
-	return 0;
-}
-
-static void ideapad_unregister_rfkill(struct acpi_device *adevice, int dev)
-{
-	struct ideapad_private *priv = dev_get_drvdata(&adevice->dev);
-
-	if (!priv->rfk[dev])
-		return;
-
-	rfkill_unregister(priv->rfk[dev]);
-	rfkill_destroy(priv->rfk[dev]);
-}
-
-static const struct acpi_device_id ideapad_device_ids[] = {
-	{ "VPC2004", 0},
-	{ "", 0},
-};
-MODULE_DEVICE_TABLE(acpi, ideapad_device_ids);
-
-static int ideapad_acpi_add(struct acpi_device *adevice)
-{
-	int i, cfg;
-	int devs_present[5];
-	struct ideapad_private *priv;
-
-	if (read_method_int(adevice->handle, "_STA", &i))
-		return -ENODEV;
-	if (i != 0x0F)
-		return -ENODEV;
-
-	if (read_method_int(adevice->handle, "_CFG", &cfg))
-		return -ENODEV;
-
-	for (i = IDEAPAD_DEV_CAMERA; i < IDEAPAD_DEV_KILLSW; i++) {
-		if (test_bit(ideapad_rfk_data[i].cfgbit, (unsigned long *)&cfg))
-			devs_present[i] = 1;
-		else
-			devs_present[i] = 0;
-	}
-
-	/* The hardware switch is always present */
-	devs_present[IDEAPAD_DEV_KILLSW] = 1;
-
-	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
-	if (!priv)
-		return -ENOMEM;
-
-	if (devs_present[IDEAPAD_DEV_CAMERA]) {
-		int ret = device_create_file(&adevice->dev, &dev_attr_camera_power);
-		if (ret) {
-			kfree(priv);
-			return ret;
-		}
-	}
-
-	priv->handle = adevice->handle;
-	dev_set_drvdata(&adevice->dev, priv);
-	ideapad_priv = priv;
-	for (i = IDEAPAD_DEV_WLAN; i <= IDEAPAD_DEV_KILLSW; i++) {
-		if (!devs_present[i])
-			continue;
-
-		ideapad_register_rfkill(adevice, i);
-	}
-	ideapad_sync_rfk_state(adevice);
-	return 0;
-}
-
-static int ideapad_acpi_remove(struct acpi_device *adevice, int type)
-{
-	struct ideapad_private *priv = dev_get_drvdata(&adevice->dev);
-	int i;
-
-	device_remove_file(&adevice->dev, &dev_attr_camera_power);
-
-	for (i = IDEAPAD_DEV_WLAN; i <= IDEAPAD_DEV_KILLSW; i++)
-		ideapad_unregister_rfkill(adevice, i);
-
-	dev_set_drvdata(&adevice->dev, NULL);
-	kfree(priv);
-	return 0;
-}
-
-static void ideapad_acpi_notify(struct acpi_device *adevice, u32 event)
-{
-	acpi_handle handle = adevice->handle;
-	unsigned long vpc1, vpc2, vpc_bit;
-
-	if (read_ec_data(handle, 0x10, &vpc1))
-		return;
-	if (read_ec_data(handle, 0x1A, &vpc2))
-		return;
-
-	vpc1 = (vpc2 << 8) | vpc1;
-	for (vpc_bit = 0; vpc_bit < 16; vpc_bit++) {
-		if (test_bit(vpc_bit, &vpc1)) {
-			if (vpc_bit == 9)
-				ideapad_sync_rfk_state(adevice);
-		}
-	}
-}
-
-static struct acpi_driver ideapad_acpi_driver = {
-	.name = "ideapad_acpi",
-	.class = "IdeaPad",
-	.ids = ideapad_device_ids,
-	.ops.add = ideapad_acpi_add,
-	.ops.remove = ideapad_acpi_remove,
-	.ops.notify = ideapad_acpi_notify,
-	.owner = THIS_MODULE,
-};
-
-
-static int __init ideapad_acpi_module_init(void)
-{
-	acpi_bus_register_driver(&ideapad_acpi_driver);
-
-	return 0;
-}
-
-
-static void __exit ideapad_acpi_module_exit(void)
-{
-	acpi_bus_unregister_driver(&ideapad_acpi_driver);
-
-}
-
-MODULE_AUTHOR("David Woodhouse <dwmw2@infradead.org>");
-MODULE_DESCRIPTION("IdeaPad ACPI Extras");
-MODULE_LICENSE("GPL");
-
-module_init(ideapad_acpi_module_init);
-module_exit(ideapad_acpi_module_exit);
diff --git a/drivers/platform/x86/ideapad_laptop.c b/drivers/platform/x86/ideapad_laptop.c
new file mode 100644
index 0000000..7c414e5
--- /dev/null
+++ b/drivers/platform/x86/ideapad_laptop.c
@@ -0,0 +1,381 @@
+/*
+ *  ideapad_acpi.c - Lenovo IdeaPad ACPI Extras
+ *
+ *  Copyright © 2010 Intel Corporation
+ *  Copyright © 2010 David Woodhouse <dwmw2@infradead.org>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ *  02110-1301, USA.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/types.h>
+#include <acpi/acpi_bus.h>
+#include <acpi/acpi_drivers.h>
+#include <linux/rfkill.h>
+
+#define IDEAPAD_DEV_CAMERA	0
+#define IDEAPAD_DEV_WLAN	1
+#define IDEAPAD_DEV_BLUETOOTH	2
+#define IDEAPAD_DEV_3G		3
+#define IDEAPAD_DEV_KILLSW	4
+
+struct ideapad_private {
+	acpi_handle handle;
+	struct rfkill *rfk[5];
+} *ideapad_priv;
+
+static struct {
+	char *name;
+	int cfgbit;
+	int opcode;
+	int type;
+} ideapad_rfk_data[] = {
+	{ "ideapad_camera",	19, 0x1E, NUM_RFKILL_TYPES },
+	{ "ideapad_wlan",	18, 0x15, RFKILL_TYPE_WLAN },
+	{ "ideapad_bluetooth",	16, 0x17, RFKILL_TYPE_BLUETOOTH },
+	{ "ideapad_3g",		17, 0x20, RFKILL_TYPE_WWAN },
+	{ "ideapad_killsw",	0,  0,    RFKILL_TYPE_WLAN }
+};
+
+/*
+ * ACPI Helpers
+ */
+#define IDEAPAD_EC_TIMEOUT (25) /* in ms */
+
+static int read_method_int(acpi_handle handle, const char *method, int *val)
+{
+	acpi_status status;
+	unsigned long long result;
+
+	status = acpi_evaluate_integer(handle, (char *)method, NULL, &result);
+	if (ACPI_FAILURE(status)) {
+		*val = -1;
+		return -1;
+	} else {
+		*val = result;
+		return 0;
+	}
+}
+
+static int method_vpcr(acpi_handle handle, int cmd, int *ret)
+{
+	acpi_status status;
+	unsigned long long result;
+	struct acpi_object_list params;
+	union acpi_object in_obj;
+
+	params.count = 1;
+	params.pointer = &in_obj;
+	in_obj.type = ACPI_TYPE_INTEGER;
+	in_obj.integer.value = cmd;
+
+	status = acpi_evaluate_integer(handle, "VPCR", &params, &result);
+
+	if (ACPI_FAILURE(status)) {
+		*ret = -1;
+		return -1;
+	} else {
+		*ret = result;
+		return 0;
+	}
+}
+
+static int method_vpcw(acpi_handle handle, int cmd, int data)
+{
+	struct acpi_object_list params;
+	union acpi_object in_obj[2];
+	acpi_status status;
+
+	params.count = 2;
+	params.pointer = in_obj;
+	in_obj[0].type = ACPI_TYPE_INTEGER;
+	in_obj[0].integer.value = cmd;
+	in_obj[1].type = ACPI_TYPE_INTEGER;
+	in_obj[1].integer.value = data;
+
+	status = acpi_evaluate_object(handle, "VPCW", &params, NULL);
+	if (status != AE_OK)
+		return -1;
+	return 0;
+}
+
+static int read_ec_data(acpi_handle handle, int cmd, unsigned long *data)
+{
+	int val;
+	unsigned long int start_jiffies, now_jiffies;
+
+	if (method_vpcw(handle, 1, cmd))
+		return -1;
+
+	for (start_jiffies = jiffies;; ) {
+		if (method_vpcr(handle, 1, &val))
+			return -1;
+		if (val == 0) {
+			if (method_vpcr(handle, 0, &val))
+				return -1;
+			*data = val;
+			return 0;
+		}
+		now_jiffies = jiffies;
+		if ((now_jiffies-start_jiffies) > (HZ)/IDEAPAD_EC_TIMEOUT+1) {
+			pr_err("timeout in read_ec_cmd\n");
+			return -1;
+		}
+	}
+}
+
+static int write_ec_cmd(acpi_handle handle, int cmd, unsigned long data)
+{
+	int val;
+	unsigned long int start_jiffies, now_jiffies;
+
+	if (method_vpcw(handle, 0, data))
+		return -1;
+	if (method_vpcw(handle, 1, cmd))
+		return -1;
+
+	for (start_jiffies = jiffies;; ) {
+		if (method_vpcr(handle, 1, &val))
+			return -1;
+		if (val == 0)
+			return 0;
+		now_jiffies = jiffies;
+		if ((now_jiffies-start_jiffies) > (HZ)/IDEAPAD_EC_TIMEOUT+1) {
+			pr_err("timeout in write_ec_cmd\n");
+			return -1;
+		}
+	}
+}
+/* the above is ACPI helpers */
+
+static ssize_t show_ideapad_cam(struct device *dev,
+				struct device_attribute *attr,
+				char *buf)
+{
+	struct ideapad_private *priv = dev_get_drvdata(dev);
+	acpi_handle handle = priv->handle;
+	unsigned long result;
+
+	if (read_ec_data(handle, 0x1D, &result))
+		return sprintf(buf, "-1\n");
+	return sprintf(buf, "%lu\n", result);
+}
+
+static ssize_t store_ideapad_cam(struct device *dev,
+				 struct device_attribute *attr,
+				 const char *buf, size_t count)
+{
+	struct ideapad_private *priv = dev_get_drvdata(dev);
+	acpi_handle handle = priv->handle;
+	int ret, state;
+
+	if (!count)
+		return 0;
+	if (sscanf(buf, "%i", &state) != 1)
+		return -EINVAL;
+	ret = write_ec_cmd(handle, 0x1E, state);
+	if (ret < 0)
+		return ret;
+	return count;
+}
+
+static DEVICE_ATTR(camera_power, 0644, show_ideapad_cam, store_ideapad_cam);
+
+static int ideapad_rfk_set(void *data, bool blocked)
+{
+	int device = (unsigned long)data;
+
+	if (device == IDEAPAD_DEV_KILLSW)
+		return -EINVAL;
+
+	return write_ec_cmd(ideapad_priv->handle,
+			    ideapad_rfk_data[device].opcode,
+			    !blocked);
+}
+
+static struct rfkill_ops ideapad_rfk_ops = {
+	.set_block = ideapad_rfk_set,
+};
+
+static void ideapad_sync_rfk_state(struct acpi_device *adevice)
+{
+	struct ideapad_private *priv = dev_get_drvdata(&adevice->dev);
+	acpi_handle handle = priv->handle;
+	unsigned long hw_blocked;
+	int i;
+
+	if (read_ec_data(handle, 0x23, &hw_blocked))
+		return;
+	hw_blocked = !hw_blocked;
+
+	for (i = IDEAPAD_DEV_WLAN; i <= IDEAPAD_DEV_KILLSW; i++)
+		if (priv->rfk[i])
+			rfkill_set_hw_state(priv->rfk[i], hw_blocked);
+}
+
+static int ideapad_register_rfkill(struct acpi_device *adevice, int dev)
+{
+	struct ideapad_private *priv = dev_get_drvdata(&adevice->dev);
+	int ret;
+
+	priv->rfk[dev] = rfkill_alloc(ideapad_rfk_data[dev].name, &adevice->dev,
+				      ideapad_rfk_data[dev].type, &ideapad_rfk_ops,
+				      (void *)(long)dev);
+	if (!priv->rfk[dev])
+		return -ENOMEM;
+
+	rfkill_init_sw_state(priv->rfk[dev], 0);
+	ret = rfkill_register(priv->rfk[dev]);
+	if (ret) {
+		rfkill_destroy(priv->rfk[dev]);
+		return ret;
+	}
+	return 0;
+}
+
+static void ideapad_unregister_rfkill(struct acpi_device *adevice, int dev)
+{
+	struct ideapad_private *priv = dev_get_drvdata(&adevice->dev);
+
+	if (!priv->rfk[dev])
+		return;
+
+	rfkill_unregister(priv->rfk[dev]);
+	rfkill_destroy(priv->rfk[dev]);
+}
+
+static const struct acpi_device_id ideapad_device_ids[] = {
+	{ "VPC2004", 0},
+	{ "", 0},
+};
+MODULE_DEVICE_TABLE(acpi, ideapad_device_ids);
+
+static int ideapad_acpi_add(struct acpi_device *adevice)
+{
+	int i, cfg;
+	int devs_present[5];
+	struct ideapad_private *priv;
+
+	if (read_method_int(adevice->handle, "_STA", &i))
+		return -ENODEV;
+	if (i != 0x0F)
+		return -ENODEV;
+
+	if (read_method_int(adevice->handle, "_CFG", &cfg))
+		return -ENODEV;
+
+	for (i = IDEAPAD_DEV_CAMERA; i < IDEAPAD_DEV_KILLSW; i++) {
+		if (test_bit(ideapad_rfk_data[i].cfgbit, (unsigned long *)&cfg))
+			devs_present[i] = 1;
+		else
+			devs_present[i] = 0;
+	}
+
+	/* The hardware switch is always present */
+	devs_present[IDEAPAD_DEV_KILLSW] = 1;
+
+	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	if (devs_present[IDEAPAD_DEV_CAMERA]) {
+		int ret = device_create_file(&adevice->dev, &dev_attr_camera_power);
+		if (ret) {
+			kfree(priv);
+			return ret;
+		}
+	}
+
+	priv->handle = adevice->handle;
+	dev_set_drvdata(&adevice->dev, priv);
+	ideapad_priv = priv;
+	for (i = IDEAPAD_DEV_WLAN; i <= IDEAPAD_DEV_KILLSW; i++) {
+		if (!devs_present[i])
+			continue;
+
+		ideapad_register_rfkill(adevice, i);
+	}
+	ideapad_sync_rfk_state(adevice);
+	return 0;
+}
+
+static int ideapad_acpi_remove(struct acpi_device *adevice, int type)
+{
+	struct ideapad_private *priv = dev_get_drvdata(&adevice->dev);
+	int i;
+
+	device_remove_file(&adevice->dev, &dev_attr_camera_power);
+
+	for (i = IDEAPAD_DEV_WLAN; i <= IDEAPAD_DEV_KILLSW; i++)
+		ideapad_unregister_rfkill(adevice, i);
+
+	dev_set_drvdata(&adevice->dev, NULL);
+	kfree(priv);
+	return 0;
+}
+
+static void ideapad_acpi_notify(struct acpi_device *adevice, u32 event)
+{
+	acpi_handle handle = adevice->handle;
+	unsigned long vpc1, vpc2, vpc_bit;
+
+	if (read_ec_data(handle, 0x10, &vpc1))
+		return;
+	if (read_ec_data(handle, 0x1A, &vpc2))
+		return;
+
+	vpc1 = (vpc2 << 8) | vpc1;
+	for (vpc_bit = 0; vpc_bit < 16; vpc_bit++) {
+		if (test_bit(vpc_bit, &vpc1)) {
+			if (vpc_bit == 9)
+				ideapad_sync_rfk_state(adevice);
+		}
+	}
+}
+
+static struct acpi_driver ideapad_acpi_driver = {
+	.name = "ideapad_acpi",
+	.class = "IdeaPad",
+	.ids = ideapad_device_ids,
+	.ops.add = ideapad_acpi_add,
+	.ops.remove = ideapad_acpi_remove,
+	.ops.notify = ideapad_acpi_notify,
+	.owner = THIS_MODULE,
+};
+
+
+static int __init ideapad_acpi_module_init(void)
+{
+	acpi_bus_register_driver(&ideapad_acpi_driver);
+
+	return 0;
+}
+
+
+static void __exit ideapad_acpi_module_exit(void)
+{
+	acpi_bus_unregister_driver(&ideapad_acpi_driver);
+
+}
+
+MODULE_AUTHOR("David Woodhouse <dwmw2@infradead.org>");
+MODULE_DESCRIPTION("IdeaPad ACPI Extras");
+MODULE_LICENSE("GPL");
+
+module_init(ideapad_acpi_module_init);
+module_exit(ideapad_acpi_module_exit);
-- 
1.7.0.4

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

[PATCH 8/8] ideapad: Change the driver name to ideapad_laptop

[Ike Panhc]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 20990 bytes --]

Since the platform drivers doing more for laptops than just using specific
ACPI device. It will be good to change the name from *_acpi to *_laptop.

Reference: http://lkml.org/lkml/2010/8/14/154

Signed-off-by: Ike Panhc <ike.pan@canonical.com>
---
 drivers/platform/x86/Kconfig          |    4 +-
 drivers/platform/x86/Makefile         |    2 +-
 drivers/platform/x86/ideapad_acpi.c   |  381 ---------------------------------
 drivers/platform/x86/ideapad_laptop.c |  381 +++++++++++++++++++++++++++++++++
 4 files changed, 384 insertions(+), 384 deletions(-)
 delete mode 100644 drivers/platform/x86/ideapad_acpi.c
 create mode 100644 drivers/platform/x86/ideapad_laptop.c

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 044f430..635d198 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -219,8 +219,8 @@ config SONYPI_COMPAT
 	  ---help---
 	  Build the sonypi driver compatibility code into the sony-laptop driver.
 
-config IDEAPAD_ACPI
-	tristate "Lenovo IdeaPad ACPI Laptop Extras"
+config IDEAPAD_LAPTOP
+	tristate "Lenovo IdeaPad Laptop Extras"
 	depends on ACPI
 	depends on RFKILL
 	help
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 85fb2b8..9846fa2 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -15,7 +15,7 @@ obj-$(CONFIG_ACERHDF)		+= acerhdf.o
 obj-$(CONFIG_HP_WMI)		+= hp-wmi.o
 obj-$(CONFIG_TC1100_WMI)	+= tc1100-wmi.o
 obj-$(CONFIG_SONY_LAPTOP)	+= sony-laptop.o
-obj-$(CONFIG_IDEAPAD_ACPI)	+= ideapad_acpi.o
+obj-$(CONFIG_IDEAPAD_LAPTOP)	+= ideapad_laptop.o
 obj-$(CONFIG_THINKPAD_ACPI)	+= thinkpad_acpi.o
 obj-$(CONFIG_FUJITSU_LAPTOP)	+= fujitsu-laptop.o
 obj-$(CONFIG_PANASONIC_LAPTOP)	+= panasonic-laptop.o
diff --git a/drivers/platform/x86/ideapad_acpi.c b/drivers/platform/x86/ideapad_acpi.c
deleted file mode 100644
index 7c414e5..0000000
--- a/drivers/platform/x86/ideapad_acpi.c
+++ /dev/null
@@ -1,381 +0,0 @@
-/*
- *  ideapad_acpi.c - Lenovo IdeaPad ACPI Extras
- *
- *  Copyright © 2010 Intel Corporation
- *  Copyright © 2010 David Woodhouse <dwmw2@infradead.org>
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation; either version 2 of the License, or
- *  (at your option) any later version.
- *
- *  This program is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
- *  02110-1301, USA.
- */
-
-#include <linux/kernel.h>
-#include <linux/module.h>
-#include <linux/init.h>
-#include <linux/types.h>
-#include <acpi/acpi_bus.h>
-#include <acpi/acpi_drivers.h>
-#include <linux/rfkill.h>
-
-#define IDEAPAD_DEV_CAMERA	0
-#define IDEAPAD_DEV_WLAN	1
-#define IDEAPAD_DEV_BLUETOOTH	2
-#define IDEAPAD_DEV_3G		3
-#define IDEAPAD_DEV_KILLSW	4
-
-struct ideapad_private {
-	acpi_handle handle;
-	struct rfkill *rfk[5];
-} *ideapad_priv;
-
-static struct {
-	char *name;
-	int cfgbit;
-	int opcode;
-	int type;
-} ideapad_rfk_data[] = {
-	{ "ideapad_camera",	19, 0x1E, NUM_RFKILL_TYPES },
-	{ "ideapad_wlan",	18, 0x15, RFKILL_TYPE_WLAN },
-	{ "ideapad_bluetooth",	16, 0x17, RFKILL_TYPE_BLUETOOTH },
-	{ "ideapad_3g",		17, 0x20, RFKILL_TYPE_WWAN },
-	{ "ideapad_killsw",	0,  0,    RFKILL_TYPE_WLAN }
-};
-
-/*
- * ACPI Helpers
- */
-#define IDEAPAD_EC_TIMEOUT (25) /* in ms */
-
-static int read_method_int(acpi_handle handle, const char *method, int *val)
-{
-	acpi_status status;
-	unsigned long long result;
-
-	status = acpi_evaluate_integer(handle, (char *)method, NULL, &result);
-	if (ACPI_FAILURE(status)) {
-		*val = -1;
-		return -1;
-	} else {
-		*val = result;
-		return 0;
-	}
-}
-
-static int method_vpcr(acpi_handle handle, int cmd, int *ret)
-{
-	acpi_status status;
-	unsigned long long result;
-	struct acpi_object_list params;
-	union acpi_object in_obj;
-
-	params.count = 1;
-	params.pointer = &in_obj;
-	in_obj.type = ACPI_TYPE_INTEGER;
-	in_obj.integer.value = cmd;
-
-	status = acpi_evaluate_integer(handle, "VPCR", &params, &result);
-
-	if (ACPI_FAILURE(status)) {
-		*ret = -1;
-		return -1;
-	} else {
-		*ret = result;
-		return 0;
-	}
-}
-
-static int method_vpcw(acpi_handle handle, int cmd, int data)
-{
-	struct acpi_object_list params;
-	union acpi_object in_obj[2];
-	acpi_status status;
-
-	params.count = 2;
-	params.pointer = in_obj;
-	in_obj[0].type = ACPI_TYPE_INTEGER;
-	in_obj[0].integer.value = cmd;
-	in_obj[1].type = ACPI_TYPE_INTEGER;
-	in_obj[1].integer.value = data;
-
-	status = acpi_evaluate_object(handle, "VPCW", &params, NULL);
-	if (status != AE_OK)
-		return -1;
-	return 0;
-}
-
-static int read_ec_data(acpi_handle handle, int cmd, unsigned long *data)
-{
-	int val;
-	unsigned long int start_jiffies, now_jiffies;
-
-	if (method_vpcw(handle, 1, cmd))
-		return -1;
-
-	for (start_jiffies = jiffies;; ) {
-		if (method_vpcr(handle, 1, &val))
-			return -1;
-		if (val == 0) {
-			if (method_vpcr(handle, 0, &val))
-				return -1;
-			*data = val;
-			return 0;
-		}
-		now_jiffies = jiffies;
-		if ((now_jiffies-start_jiffies) > (HZ)/IDEAPAD_EC_TIMEOUT+1) {
-			pr_err("timeout in read_ec_cmd\n");
-			return -1;
-		}
-	}
-}
-
-static int write_ec_cmd(acpi_handle handle, int cmd, unsigned long data)
-{
-	int val;
-	unsigned long int start_jiffies, now_jiffies;
-
-	if (method_vpcw(handle, 0, data))
-		return -1;
-	if (method_vpcw(handle, 1, cmd))
-		return -1;
-
-	for (start_jiffies = jiffies;; ) {
-		if (method_vpcr(handle, 1, &val))
-			return -1;
-		if (val == 0)
-			return 0;
-		now_jiffies = jiffies;
-		if ((now_jiffies-start_jiffies) > (HZ)/IDEAPAD_EC_TIMEOUT+1) {
-			pr_err("timeout in write_ec_cmd\n");
-			return -1;
-		}
-	}
-}
-/* the above is ACPI helpers */
-
-static ssize_t show_ideapad_cam(struct device *dev,
-				struct device_attribute *attr,
-				char *buf)
-{
-	struct ideapad_private *priv = dev_get_drvdata(dev);
-	acpi_handle handle = priv->handle;
-	unsigned long result;
-
-	if (read_ec_data(handle, 0x1D, &result))
-		return sprintf(buf, "-1\n");
-	return sprintf(buf, "%lu\n", result);
-}
-
-static ssize_t store_ideapad_cam(struct device *dev,
-				 struct device_attribute *attr,
-				 const char *buf, size_t count)
-{
-	struct ideapad_private *priv = dev_get_drvdata(dev);
-	acpi_handle handle = priv->handle;
-	int ret, state;
-
-	if (!count)
-		return 0;
-	if (sscanf(buf, "%i", &state) != 1)
-		return -EINVAL;
-	ret = write_ec_cmd(handle, 0x1E, state);
-	if (ret < 0)
-		return ret;
-	return count;
-}
-
-static DEVICE_ATTR(camera_power, 0644, show_ideapad_cam, store_ideapad_cam);
-
-static int ideapad_rfk_set(void *data, bool blocked)
-{
-	int device = (unsigned long)data;
-
-	if (device == IDEAPAD_DEV_KILLSW)
-		return -EINVAL;
-
-	return write_ec_cmd(ideapad_priv->handle,
-			    ideapad_rfk_data[device].opcode,
-			    !blocked);
-}
-
-static struct rfkill_ops ideapad_rfk_ops = {
-	.set_block = ideapad_rfk_set,
-};
-
-static void ideapad_sync_rfk_state(struct acpi_device *adevice)
-{
-	struct ideapad_private *priv = dev_get_drvdata(&adevice->dev);
-	acpi_handle handle = priv->handle;
-	unsigned long hw_blocked;
-	int i;
-
-	if (read_ec_data(handle, 0x23, &hw_blocked))
-		return;
-	hw_blocked = !hw_blocked;
-
-	for (i = IDEAPAD_DEV_WLAN; i <= IDEAPAD_DEV_KILLSW; i++)
-		if (priv->rfk[i])
-			rfkill_set_hw_state(priv->rfk[i], hw_blocked);
-}
-
-static int ideapad_register_rfkill(struct acpi_device *adevice, int dev)
-{
-	struct ideapad_private *priv = dev_get_drvdata(&adevice->dev);
-	int ret;
-
-	priv->rfk[dev] = rfkill_alloc(ideapad_rfk_data[dev].name, &adevice->dev,
-				      ideapad_rfk_data[dev].type, &ideapad_rfk_ops,
-				      (void *)(long)dev);
-	if (!priv->rfk[dev])
-		return -ENOMEM;
-
-	rfkill_init_sw_state(priv->rfk[dev], 0);
-	ret = rfkill_register(priv->rfk[dev]);
-	if (ret) {
-		rfkill_destroy(priv->rfk[dev]);
-		return ret;
-	}
-	return 0;
-}
-
-static void ideapad_unregister_rfkill(struct acpi_device *adevice, int dev)
-{
-	struct ideapad_private *priv = dev_get_drvdata(&adevice->dev);
-
-	if (!priv->rfk[dev])
-		return;
-
-	rfkill_unregister(priv->rfk[dev]);
-	rfkill_destroy(priv->rfk[dev]);
-}
-
-static const struct acpi_device_id ideapad_device_ids[] = {
-	{ "VPC2004", 0},
-	{ "", 0},
-};
-MODULE_DEVICE_TABLE(acpi, ideapad_device_ids);
-
-static int ideapad_acpi_add(struct acpi_device *adevice)
-{
-	int i, cfg;
-	int devs_present[5];
-	struct ideapad_private *priv;
-
-	if (read_method_int(adevice->handle, "_STA", &i))
-		return -ENODEV;
-	if (i != 0x0F)
-		return -ENODEV;
-
-	if (read_method_int(adevice->handle, "_CFG", &cfg))
-		return -ENODEV;
-
-	for (i = IDEAPAD_DEV_CAMERA; i < IDEAPAD_DEV_KILLSW; i++) {
-		if (test_bit(ideapad_rfk_data[i].cfgbit, (unsigned long *)&cfg))
-			devs_present[i] = 1;
-		else
-			devs_present[i] = 0;
-	}
-
-	/* The hardware switch is always present */
-	devs_present[IDEAPAD_DEV_KILLSW] = 1;
-
-	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
-	if (!priv)
-		return -ENOMEM;
-
-	if (devs_present[IDEAPAD_DEV_CAMERA]) {
-		int ret = device_create_file(&adevice->dev, &dev_attr_camera_power);
-		if (ret) {
-			kfree(priv);
-			return ret;
-		}
-	}
-
-	priv->handle = adevice->handle;
-	dev_set_drvdata(&adevice->dev, priv);
-	ideapad_priv = priv;
-	for (i = IDEAPAD_DEV_WLAN; i <= IDEAPAD_DEV_KILLSW; i++) {
-		if (!devs_present[i])
-			continue;
-
-		ideapad_register_rfkill(adevice, i);
-	}
-	ideapad_sync_rfk_state(adevice);
-	return 0;
-}
-
-static int ideapad_acpi_remove(struct acpi_device *adevice, int type)
-{
-	struct ideapad_private *priv = dev_get_drvdata(&adevice->dev);
-	int i;
-
-	device_remove_file(&adevice->dev, &dev_attr_camera_power);
-
-	for (i = IDEAPAD_DEV_WLAN; i <= IDEAPAD_DEV_KILLSW; i++)
-		ideapad_unregister_rfkill(adevice, i);
-
-	dev_set_drvdata(&adevice->dev, NULL);
-	kfree(priv);
-	return 0;
-}
-
-static void ideapad_acpi_notify(struct acpi_device *adevice, u32 event)
-{
-	acpi_handle handle = adevice->handle;
-	unsigned long vpc1, vpc2, vpc_bit;
-
-	if (read_ec_data(handle, 0x10, &vpc1))
-		return;
-	if (read_ec_data(handle, 0x1A, &vpc2))
-		return;
-
-	vpc1 = (vpc2 << 8) | vpc1;
-	for (vpc_bit = 0; vpc_bit < 16; vpc_bit++) {
-		if (test_bit(vpc_bit, &vpc1)) {
-			if (vpc_bit == 9)
-				ideapad_sync_rfk_state(adevice);
-		}
-	}
-}
-
-static struct acpi_driver ideapad_acpi_driver = {
-	.name = "ideapad_acpi",
-	.class = "IdeaPad",
-	.ids = ideapad_device_ids,
-	.ops.add = ideapad_acpi_add,
-	.ops.remove = ideapad_acpi_remove,
-	.ops.notify = ideapad_acpi_notify,
-	.owner = THIS_MODULE,
-};
-
-
-static int __init ideapad_acpi_module_init(void)
-{
-	acpi_bus_register_driver(&ideapad_acpi_driver);
-
-	return 0;
-}
-
-
-static void __exit ideapad_acpi_module_exit(void)
-{
-	acpi_bus_unregister_driver(&ideapad_acpi_driver);
-
-}
-
-MODULE_AUTHOR("David Woodhouse <dwmw2@infradead.org>");
-MODULE_DESCRIPTION("IdeaPad ACPI Extras");
-MODULE_LICENSE("GPL");
-
-module_init(ideapad_acpi_module_init);
-module_exit(ideapad_acpi_module_exit);
diff --git a/drivers/platform/x86/ideapad_laptop.c b/drivers/platform/x86/ideapad_laptop.c
new file mode 100644
index 0000000..7c414e5
--- /dev/null
+++ b/drivers/platform/x86/ideapad_laptop.c
@@ -0,0 +1,381 @@
+/*
+ *  ideapad_acpi.c - Lenovo IdeaPad ACPI Extras
+ *
+ *  Copyright © 2010 Intel Corporation
+ *  Copyright © 2010 David Woodhouse <dwmw2@infradead.org>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ *  02110-1301, USA.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/types.h>
+#include <acpi/acpi_bus.h>
+#include <acpi/acpi_drivers.h>
+#include <linux/rfkill.h>
+
+#define IDEAPAD_DEV_CAMERA	0
+#define IDEAPAD_DEV_WLAN	1
+#define IDEAPAD_DEV_BLUETOOTH	2
+#define IDEAPAD_DEV_3G		3
+#define IDEAPAD_DEV_KILLSW	4
+
+struct ideapad_private {
+	acpi_handle handle;
+	struct rfkill *rfk[5];
+} *ideapad_priv;
+
+static struct {
+	char *name;
+	int cfgbit;
+	int opcode;
+	int type;
+} ideapad_rfk_data[] = {
+	{ "ideapad_camera",	19, 0x1E, NUM_RFKILL_TYPES },
+	{ "ideapad_wlan",	18, 0x15, RFKILL_TYPE_WLAN },
+	{ "ideapad_bluetooth",	16, 0x17, RFKILL_TYPE_BLUETOOTH },
+	{ "ideapad_3g",		17, 0x20, RFKILL_TYPE_WWAN },
+	{ "ideapad_killsw",	0,  0,    RFKILL_TYPE_WLAN }
+};
+
+/*
+ * ACPI Helpers
+ */
+#define IDEAPAD_EC_TIMEOUT (25) /* in ms */
+
+static int read_method_int(acpi_handle handle, const char *method, int *val)
+{
+	acpi_status status;
+	unsigned long long result;
+
+	status = acpi_evaluate_integer(handle, (char *)method, NULL, &result);
+	if (ACPI_FAILURE(status)) {
+		*val = -1;
+		return -1;
+	} else {
+		*val = result;
+		return 0;
+	}
+}
+
+static int method_vpcr(acpi_handle handle, int cmd, int *ret)
+{
+	acpi_status status;
+	unsigned long long result;
+	struct acpi_object_list params;
+	union acpi_object in_obj;
+
+	params.count = 1;
+	params.pointer = &in_obj;
+	in_obj.type = ACPI_TYPE_INTEGER;
+	in_obj.integer.value = cmd;
+
+	status = acpi_evaluate_integer(handle, "VPCR", &params, &result);
+
+	if (ACPI_FAILURE(status)) {
+		*ret = -1;
+		return -1;
+	} else {
+		*ret = result;
+		return 0;
+	}
+}
+
+static int method_vpcw(acpi_handle handle, int cmd, int data)
+{
+	struct acpi_object_list params;
+	union acpi_object in_obj[2];
+	acpi_status status;
+
+	params.count = 2;
+	params.pointer = in_obj;
+	in_obj[0].type = ACPI_TYPE_INTEGER;
+	in_obj[0].integer.value = cmd;
+	in_obj[1].type = ACPI_TYPE_INTEGER;
+	in_obj[1].integer.value = data;
+
+	status = acpi_evaluate_object(handle, "VPCW", &params, NULL);
+	if (status != AE_OK)
+		return -1;
+	return 0;
+}
+
+static int read_ec_data(acpi_handle handle, int cmd, unsigned long *data)
+{
+	int val;
+	unsigned long int start_jiffies, now_jiffies;
+
+	if (method_vpcw(handle, 1, cmd))
+		return -1;
+
+	for (start_jiffies = jiffies;; ) {
+		if (method_vpcr(handle, 1, &val))
+			return -1;
+		if (val == 0) {
+			if (method_vpcr(handle, 0, &val))
+				return -1;
+			*data = val;
+			return 0;
+		}
+		now_jiffies = jiffies;
+		if ((now_jiffies-start_jiffies) > (HZ)/IDEAPAD_EC_TIMEOUT+1) {
+			pr_err("timeout in read_ec_cmd\n");
+			return -1;
+		}
+	}
+}
+
+static int write_ec_cmd(acpi_handle handle, int cmd, unsigned long data)
+{
+	int val;
+	unsigned long int start_jiffies, now_jiffies;
+
+	if (method_vpcw(handle, 0, data))
+		return -1;
+	if (method_vpcw(handle, 1, cmd))
+		return -1;
+
+	for (start_jiffies = jiffies;; ) {
+		if (method_vpcr(handle, 1, &val))
+			return -1;
+		if (val == 0)
+			return 0;
+		now_jiffies = jiffies;
+		if ((now_jiffies-start_jiffies) > (HZ)/IDEAPAD_EC_TIMEOUT+1) {
+			pr_err("timeout in write_ec_cmd\n");
+			return -1;
+		}
+	}
+}
+/* the above is ACPI helpers */
+
+static ssize_t show_ideapad_cam(struct device *dev,
+				struct device_attribute *attr,
+				char *buf)
+{
+	struct ideapad_private *priv = dev_get_drvdata(dev);
+	acpi_handle handle = priv->handle;
+	unsigned long result;
+
+	if (read_ec_data(handle, 0x1D, &result))
+		return sprintf(buf, "-1\n");
+	return sprintf(buf, "%lu\n", result);
+}
+
+static ssize_t store_ideapad_cam(struct device *dev,
+				 struct device_attribute *attr,
+				 const char *buf, size_t count)
+{
+	struct ideapad_private *priv = dev_get_drvdata(dev);
+	acpi_handle handle = priv->handle;
+	int ret, state;
+
+	if (!count)
+		return 0;
+	if (sscanf(buf, "%i", &state) != 1)
+		return -EINVAL;
+	ret = write_ec_cmd(handle, 0x1E, state);
+	if (ret < 0)
+		return ret;
+	return count;
+}
+
+static DEVICE_ATTR(camera_power, 0644, show_ideapad_cam, store_ideapad_cam);
+
+static int ideapad_rfk_set(void *data, bool blocked)
+{
+	int device = (unsigned long)data;
+
+	if (device == IDEAPAD_DEV_KILLSW)
+		return -EINVAL;
+
+	return write_ec_cmd(ideapad_priv->handle,
+			    ideapad_rfk_data[device].opcode,
+			    !blocked);
+}
+
+static struct rfkill_ops ideapad_rfk_ops = {
+	.set_block = ideapad_rfk_set,
+};
+
+static void ideapad_sync_rfk_state(struct acpi_device *adevice)
+{
+	struct ideapad_private *priv = dev_get_drvdata(&adevice->dev);
+	acpi_handle handle = priv->handle;
+	unsigned long hw_blocked;
+	int i;
+
+	if (read_ec_data(handle, 0x23, &hw_blocked))
+		return;
+	hw_blocked = !hw_blocked;
+
+	for (i = IDEAPAD_DEV_WLAN; i <= IDEAPAD_DEV_KILLSW; i++)
+		if (priv->rfk[i])
+			rfkill_set_hw_state(priv->rfk[i], hw_blocked);
+}
+
+static int ideapad_register_rfkill(struct acpi_device *adevice, int dev)
+{
+	struct ideapad_private *priv = dev_get_drvdata(&adevice->dev);
+	int ret;
+
+	priv->rfk[dev] = rfkill_alloc(ideapad_rfk_data[dev].name, &adevice->dev,
+				      ideapad_rfk_data[dev].type, &ideapad_rfk_ops,
+				      (void *)(long)dev);
+	if (!priv->rfk[dev])
+		return -ENOMEM;
+
+	rfkill_init_sw_state(priv->rfk[dev], 0);
+	ret = rfkill_register(priv->rfk[dev]);
+	if (ret) {
+		rfkill_destroy(priv->rfk[dev]);
+		return ret;
+	}
+	return 0;
+}
+
+static void ideapad_unregister_rfkill(struct acpi_device *adevice, int dev)
+{
+	struct ideapad_private *priv = dev_get_drvdata(&adevice->dev);
+
+	if (!priv->rfk[dev])
+		return;
+
+	rfkill_unregister(priv->rfk[dev]);
+	rfkill_destroy(priv->rfk[dev]);
+}
+
+static const struct acpi_device_id ideapad_device_ids[] = {
+	{ "VPC2004", 0},
+	{ "", 0},
+};
+MODULE_DEVICE_TABLE(acpi, ideapad_device_ids);
+
+static int ideapad_acpi_add(struct acpi_device *adevice)
+{
+	int i, cfg;
+	int devs_present[5];
+	struct ideapad_private *priv;
+
+	if (read_method_int(adevice->handle, "_STA", &i))
+		return -ENODEV;
+	if (i != 0x0F)
+		return -ENODEV;
+
+	if (read_method_int(adevice->handle, "_CFG", &cfg))
+		return -ENODEV;
+
+	for (i = IDEAPAD_DEV_CAMERA; i < IDEAPAD_DEV_KILLSW; i++) {
+		if (test_bit(ideapad_rfk_data[i].cfgbit, (unsigned long *)&cfg))
+			devs_present[i] = 1;
+		else
+			devs_present[i] = 0;
+	}
+
+	/* The hardware switch is always present */
+	devs_present[IDEAPAD_DEV_KILLSW] = 1;
+
+	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	if (devs_present[IDEAPAD_DEV_CAMERA]) {
+		int ret = device_create_file(&adevice->dev, &dev_attr_camera_power);
+		if (ret) {
+			kfree(priv);
+			return ret;
+		}
+	}
+
+	priv->handle = adevice->handle;
+	dev_set_drvdata(&adevice->dev, priv);
+	ideapad_priv = priv;
+	for (i = IDEAPAD_DEV_WLAN; i <= IDEAPAD_DEV_KILLSW; i++) {
+		if (!devs_present[i])
+			continue;
+
+		ideapad_register_rfkill(adevice, i);
+	}
+	ideapad_sync_rfk_state(adevice);
+	return 0;
+}
+
+static int ideapad_acpi_remove(struct acpi_device *adevice, int type)
+{
+	struct ideapad_private *priv = dev_get_drvdata(&adevice->dev);
+	int i;
+
+	device_remove_file(&adevice->dev, &dev_attr_camera_power);
+
+	for (i = IDEAPAD_DEV_WLAN; i <= IDEAPAD_DEV_KILLSW; i++)
+		ideapad_unregister_rfkill(adevice, i);
+
+	dev_set_drvdata(&adevice->dev, NULL);
+	kfree(priv);
+	return 0;
+}
+
+static void ideapad_acpi_notify(struct acpi_device *adevice, u32 event)
+{
+	acpi_handle handle = adevice->handle;
+	unsigned long vpc1, vpc2, vpc_bit;
+
+	if (read_ec_data(handle, 0x10, &vpc1))
+		return;
+	if (read_ec_data(handle, 0x1A, &vpc2))
+		return;
+
+	vpc1 = (vpc2 << 8) | vpc1;
+	for (vpc_bit = 0; vpc_bit < 16; vpc_bit++) {
+		if (test_bit(vpc_bit, &vpc1)) {
+			if (vpc_bit == 9)
+				ideapad_sync_rfk_state(adevice);
+		}
+	}
+}
+
+static struct acpi_driver ideapad_acpi_driver = {
+	.name = "ideapad_acpi",
+	.class = "IdeaPad",
+	.ids = ideapad_device_ids,
+	.ops.add = ideapad_acpi_add,
+	.ops.remove = ideapad_acpi_remove,
+	.ops.notify = ideapad_acpi_notify,
+	.owner = THIS_MODULE,
+};
+
+
+static int __init ideapad_acpi_module_init(void)
+{
+	acpi_bus_register_driver(&ideapad_acpi_driver);
+
+	return 0;
+}
+
+
+static void __exit ideapad_acpi_module_exit(void)
+{
+	acpi_bus_unregister_driver(&ideapad_acpi_driver);
+
+}
+
+MODULE_AUTHOR("David Woodhouse <dwmw2@infradead.org>");
+MODULE_DESCRIPTION("IdeaPad ACPI Extras");
+MODULE_LICENSE("GPL");
+
+module_init(ideapad_acpi_module_init);
+module_exit(ideapad_acpi_module_exit);
-- 
1.7.0.4

Re: [PATCH 5/8] ideapad: use EC command to control camera

[Oliver Neukum]

Am Mittwoch, 18. August 2010, 10:38:15 schrieb Ike Panhc:
> Signed-off-by: Ike Panhc <ike.pan@canonical.com>
> ---
>  drivers/platform/x86/ideapad_acpi.c |   16 +++++++++++-----
>  1 files changed, 11 insertions(+), 5 deletions(-)

Hi,

wouldn't it be appropriate to integrate such switches into the generic
power framework?

	Regards
		Oliver

Re: [PATCH 5/8] ideapad: use EC command to control camera

[Ike Panhc]

Could you give me an example that I can follow? Just point out which C file
I shall read. no much knowledge about generic power framework.

Thanks

On 08/18/2010 04:42 PM, Oliver Neukum wrote:
> Am Mittwoch, 18. August 2010, 10:38:15 schrieb Ike Panhc:
>> Signed-off-by: Ike Panhc <ike.pan@canonical.com>
>> ---
>>  drivers/platform/x86/ideapad_acpi.c |   16 +++++++++++-----
>>  1 files changed, 11 insertions(+), 5 deletions(-)
> 
> Hi,
> 
> wouldn't it be appropriate to integrate such switches into the generic
> power framework?
> 
> 	Regards
> 		Oliver

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[David Woodhouse]

On Wed, 2010-08-18 at 09:36 +0100, Ike Panhc wrote:
> 
> Once the rfkill of a laptop is set to block, it is no way to unblock with Linux
> without driver. Thanks for David Woodhouse wrote the first driver solving this.
> 
> But the \_SB_.GECN and \_SB_.DECN are only available on Lenovo ideapad S10-3.
> Using EC command to control rf/camera power is better because I believe every
> ideapads which has VPC2004 device in its DSDT has this common method.
> 
> This driver is tested and work fine on Lenovo ideapad B550 and ideapad S10-3.

Works for me too (on S10-3); thanks.

It all looks good, although should we have a delay or a schedule or at
least a cpu_relax() in the read_ec_data() and write_ec_cmd() loops?
Those loops should be using time_before() too, rather than open-coding
the comparison.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[David Woodhouse]

On Wed, 2010-08-18 at 09:36 +0100, Ike Panhc wrote:
> 
> Once the rfkill of a laptop is set to block, it is no way to unblock with Linux
> without driver. Thanks for David Woodhouse wrote the first driver solving this.
> 
> But the \_SB_.GECN and \_SB_.DECN are only available on Lenovo ideapad S10-3.
> Using EC command to control rf/camera power is better because I believe every
> ideapads which has VPC2004 device in its DSDT has this common method.
> 
> This driver is tested and work fine on Lenovo ideapad B550 and ideapad S10-3.

Works for me too (on S10-3); thanks.

It all looks good, although should we have a delay or a schedule or at
least a cpu_relax() in the read_ec_data() and write_ec_cmd() loops?
Those loops should be using time_before() too, rather than open-coding
the comparison.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Ike Panhc]

On 08/18/2010 06:35 PM, David Woodhouse wrote:
> On Wed, 2010-08-18 at 09:36 +0100, Ike Panhc wrote:
>>
>> Once the rfkill of a laptop is set to block, it is no way to unblock with Linux
>> without driver. Thanks for David Woodhouse wrote the first driver solving this.
>>
>> But the \_SB_.GECN and \_SB_.DECN are only available on Lenovo ideapad S10-3.
>> Using EC command to control rf/camera power is better because I believe every
>> ideapads which has VPC2004 device in its DSDT has this common method.
>>
>> This driver is tested and work fine on Lenovo ideapad B550 and ideapad S10-3.
> 
> Works for me too (on S10-3); thanks.
> 
> It all looks good, although should we have a delay or a schedule or at
> least a cpu_relax() in the read_ec_data() and write_ec_cmd() loops?
> Those loops should be using time_before() too, rather than open-coding
> the comparison.
> 
yeah, agree. polling from ec makes cpu busy, although its usually less then 10ms
a yield or relax will be good.

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Ike Panhc]

On 08/18/2010 06:35 PM, David Woodhouse wrote:
> On Wed, 2010-08-18 at 09:36 +0100, Ike Panhc wrote:
>>
>> Once the rfkill of a laptop is set to block, it is no way to unblock with Linux
>> without driver. Thanks for David Woodhouse wrote the first driver solving this.
>>
>> But the \_SB_.GECN and \_SB_.DECN are only available on Lenovo ideapad S10-3.
>> Using EC command to control rf/camera power is better because I believe every
>> ideapads which has VPC2004 device in its DSDT has this common method.
>>
>> This driver is tested and work fine on Lenovo ideapad B550 and ideapad S10-3.
> 
> Works for me too (on S10-3); thanks.
> 
> It all looks good, although should we have a delay or a schedule or at
> least a cpu_relax() in the read_ec_data() and write_ec_cmd() loops?
> Those loops should be using time_before() too, rather than open-coding
> the comparison.
> 
yeah, agree. polling from ec makes cpu busy, although its usually less then 10ms
a yield or relax will be good.

Re: [PATCH 3/8] ideapad: make sure we bind on the correct device

[Matthew Garrett]

On Wed, Aug 18, 2010 at 04:37:33PM +0800, Ike Panhc wrote:
> By reading from method _STA and _CFG to make sure we bind on the correct
> VPC2004 device.

I know some other drivers check _STA themselves, but it's unnecessary - 
if _STA didn't evaluate appropriately, the bus driver won't create the 
pnp object and there won't be anything for you to bind to in the first 
place.

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

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Mario 'BitKoenig' Holbe]

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

On Wed, Aug 18, 2010 at 11:35:19AM +0100, David Woodhouse wrote:
> On Wed, 2010-08-18 at 09:36 +0100, Ike Panhc wrote:
> > This driver is tested and work fine on Lenovo ideapad B550 and ideapad S10-3.
> Works for me too (on S10-3); thanks.

It works for me too on S12 w/ VIA Nano - at least somehow... I have two
issues with it:

1st: the camera is not detected:

$ dmesg | grep -i cam
[    3.062601] usb 1-4: Product: Lenovo EasyCamera
[    7.828202] uvcvideo: Found UVC 1.00 device Lenovo EasyCamera (5986:0241)
[    7.842987] input: Lenovo EasyCamera as /devices/pci0000:00/0000:00:10.4/usb1/1-4/1-4:1.0/input/input6
$ lsusb | grep -i cam
Bus 001 Device 002: ID 5986:0241 Acer, Inc BisonCam, NB Pro
$ rfkill list
0: ideapad_wlan: Wireless LAN
        Soft blocked: no
        Hard blocked: no
1: ideapad_bluetooth: Bluetooth
        Soft blocked: no
        Hard blocked: no
2: ideapad_killsw: Wireless LAN
        Soft blocked: no
        Hard blocked: no
3: hci0: Bluetooth
        Soft blocked: no
        Hard blocked: no
4: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no

Fn-Esc switches the Camera off and on, but there seems to be no soft
killswitch for it. I have no idea how to parse through acpidump to find
out whether there is some similar device listed or not.


2nd: both Bluetooth killswitches reproducibly disappear when I block
ideapad_bluetooth either via Gnome bluetooth-applet or via rfkill block
1 and subsequently reboot. After the reboot rfkill list shows:

0: ideapad_wlan: Wireless LAN
        Soft blocked: no
        Hard blocked: no
1: ideapad_killsw: Wireless LAN
        Soft blocked: no
        Hard blocked: no
2: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no

Powering the machine off and on again restores both killswitches.
Interesting is: this does not happen when I boot into single-user mode,
rfkill block 1 there and reboot. In this case, both killswitches are
back.


regards
   Mario
-- 
File names are infinite in length where infinity is set to 255 characters.
                                -- Peter Collinson, "The Unix File System"

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

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Mario 'BitKoenig' Holbe]

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

On Wed, Aug 18, 2010 at 11:35:19AM +0100, David Woodhouse wrote:
> On Wed, 2010-08-18 at 09:36 +0100, Ike Panhc wrote:
> > This driver is tested and work fine on Lenovo ideapad B550 and ideapad S10-3.
> Works for me too (on S10-3); thanks.

It works for me too on S12 w/ VIA Nano - at least somehow... I have two
issues with it:

1st: the camera is not detected:

$ dmesg | grep -i cam
[    3.062601] usb 1-4: Product: Lenovo EasyCamera
[    7.828202] uvcvideo: Found UVC 1.00 device Lenovo EasyCamera (5986:0241)
[    7.842987] input: Lenovo EasyCamera as /devices/pci0000:00/0000:00:10.4/usb1/1-4/1-4:1.0/input/input6
$ lsusb | grep -i cam
Bus 001 Device 002: ID 5986:0241 Acer, Inc BisonCam, NB Pro
$ rfkill list
0: ideapad_wlan: Wireless LAN
        Soft blocked: no
        Hard blocked: no
1: ideapad_bluetooth: Bluetooth
        Soft blocked: no
        Hard blocked: no
2: ideapad_killsw: Wireless LAN
        Soft blocked: no
        Hard blocked: no
3: hci0: Bluetooth
        Soft blocked: no
        Hard blocked: no
4: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no

Fn-Esc switches the Camera off and on, but there seems to be no soft
killswitch for it. I have no idea how to parse through acpidump to find
out whether there is some similar device listed or not.


2nd: both Bluetooth killswitches reproducibly disappear when I block
ideapad_bluetooth either via Gnome bluetooth-applet or via rfkill block
1 and subsequently reboot. After the reboot rfkill list shows:

0: ideapad_wlan: Wireless LAN
        Soft blocked: no
        Hard blocked: no
1: ideapad_killsw: Wireless LAN
        Soft blocked: no
        Hard blocked: no
2: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no

Powering the machine off and on again restores both killswitches.
Interesting is: this does not happen when I boot into single-user mode,
rfkill block 1 there and reboot. In this case, both killswitches are
back.


regards
   Mario
-- 
File names are infinite in length where infinity is set to 255 characters.
                                -- Peter Collinson, "The Unix File System"

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

Re: [PATCH 3/8] ideapad: make sure we bind on the correct device

[Ike Panhc]

On 08/18/2010 09:27 PM, Matthew Garrett wrote:
> On Wed, Aug 18, 2010 at 04:37:33PM +0800, Ike Panhc wrote:
>> By reading from method _STA and _CFG to make sure we bind on the correct
>> VPC2004 device.
> 
> I know some other drivers check _STA themselves, but it's unnecessary - 
> if _STA didn't evaluate appropriately, the bus driver won't create the 
> pnp object and there won't be anything for you to bind to in the first 
> place.
> 
yes, you are right. when add, acpi_bus will check for it and tell if the
device exist or not from its bits.

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Ike Panhc]

On 08/18/2010 11:51 PM, Mario 'BitKoenig' Holbe wrote:
> On Wed, Aug 18, 2010 at 11:35:19AM +0100, David Woodhouse wrote:
>> On Wed, 2010-08-18 at 09:36 +0100, Ike Panhc wrote:
>>> This driver is tested and work fine on Lenovo ideapad B550 and ideapad S10-3.
>> Works for me too (on S10-3); thanks.
> 
> It works for me too on S12 w/ VIA Nano - at least somehow... I have two
> issues with it:
> 
> 1st: the camera is not detected:
> 
> $ dmesg | grep -i cam
> [    3.062601] usb 1-4: Product: Lenovo EasyCamera
> [    7.828202] uvcvideo: Found UVC 1.00 device Lenovo EasyCamera (5986:0241)
> [    7.842987] input: Lenovo EasyCamera as /devices/pci0000:00/0000:00:10.4/usb1/1-4/1-4:1.0/input/input6
> $ lsusb | grep -i cam
> Bus 001 Device 002: ID 5986:0241 Acer, Inc BisonCam, NB Pro
> $ rfkill list
> 0: ideapad_wlan: Wireless LAN
>         Soft blocked: no
>         Hard blocked: no
> 1: ideapad_bluetooth: Bluetooth
>         Soft blocked: no
>         Hard blocked: no
> 2: ideapad_killsw: Wireless LAN
>         Soft blocked: no
>         Hard blocked: no
> 3: hci0: Bluetooth
>         Soft blocked: no
>         Hard blocked: no
> 4: phy0: Wireless LAN
>         Soft blocked: no
>         Hard blocked: no
> 
> Fn-Esc switches the Camera off and on, but there seems to be no soft
> killswitch for it. I have no idea how to parse through acpidump to find
> out whether there is some similar device listed or not.
rfkill for RF devices only. This driver will create an entry on sysfs to
control the camera power

You can find the entry by "find /sys/devices -name 'camera_power'"

> 
> 
> 2nd: both Bluetooth killswitches reproducibly disappear when I block
> ideapad_bluetooth either via Gnome bluetooth-applet or via rfkill block
> 1 and subsequently reboot. After the reboot rfkill list shows:
> 
> 0: ideapad_wlan: Wireless LAN
>         Soft blocked: no
>         Hard blocked: no
> 1: ideapad_killsw: Wireless LAN
>         Soft blocked: no
>         Hard blocked: no
> 2: phy0: Wireless LAN
>         Soft blocked: no
>         Hard blocked: no
> 
> Powering the machine off and on again restores both killswitches.
> Interesting is: this does not happen when I boot into single-user mode,
> rfkill block 1 there and reboot. In this case, both killswitches are
> back.
This is interesting. looks like the cfgbit will change on S12 if BIOS
remember it has to shutdown when booting. I will try if the same problem
happen on my ideapads.

> 
> 
> regards
>    Mario

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Ike Panhc]

On 08/18/2010 11:51 PM, Mario 'BitKoenig' Holbe wrote:
> On Wed, Aug 18, 2010 at 11:35:19AM +0100, David Woodhouse wrote:
>> On Wed, 2010-08-18 at 09:36 +0100, Ike Panhc wrote:
>>> This driver is tested and work fine on Lenovo ideapad B550 and ideapad S10-3.
>> Works for me too (on S10-3); thanks.
> 
> It works for me too on S12 w/ VIA Nano - at least somehow... I have two
> issues with it:
> 
> 1st: the camera is not detected:
> 
> $ dmesg | grep -i cam
> [    3.062601] usb 1-4: Product: Lenovo EasyCamera
> [    7.828202] uvcvideo: Found UVC 1.00 device Lenovo EasyCamera (5986:0241)
> [    7.842987] input: Lenovo EasyCamera as /devices/pci0000:00/0000:00:10.4/usb1/1-4/1-4:1.0/input/input6
> $ lsusb | grep -i cam
> Bus 001 Device 002: ID 5986:0241 Acer, Inc BisonCam, NB Pro
> $ rfkill list
> 0: ideapad_wlan: Wireless LAN
>         Soft blocked: no
>         Hard blocked: no
> 1: ideapad_bluetooth: Bluetooth
>         Soft blocked: no
>         Hard blocked: no
> 2: ideapad_killsw: Wireless LAN
>         Soft blocked: no
>         Hard blocked: no
> 3: hci0: Bluetooth
>         Soft blocked: no
>         Hard blocked: no
> 4: phy0: Wireless LAN
>         Soft blocked: no
>         Hard blocked: no
> 
> Fn-Esc switches the Camera off and on, but there seems to be no soft
> killswitch for it. I have no idea how to parse through acpidump to find
> out whether there is some similar device listed or not.
rfkill for RF devices only. This driver will create an entry on sysfs to
control the camera power

You can find the entry by "find /sys/devices -name 'camera_power'"

> 
> 
> 2nd: both Bluetooth killswitches reproducibly disappear when I block
> ideapad_bluetooth either via Gnome bluetooth-applet or via rfkill block
> 1 and subsequently reboot. After the reboot rfkill list shows:
> 
> 0: ideapad_wlan: Wireless LAN
>         Soft blocked: no
>         Hard blocked: no
> 1: ideapad_killsw: Wireless LAN
>         Soft blocked: no
>         Hard blocked: no
> 2: phy0: Wireless LAN
>         Soft blocked: no
>         Hard blocked: no
> 
> Powering the machine off and on again restores both killswitches.
> Interesting is: this does not happen when I boot into single-user mode,
> rfkill block 1 there and reboot. In this case, both killswitches are
> back.
This is interesting. looks like the cfgbit will change on S12 if BIOS
remember it has to shutdown when booting. I will try if the same problem
happen on my ideapads.

> 
> 
> regards
>    Mario

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[David Woodhouse]

On Thu, 2010-08-19 at 11:21 +0800, Ike Panhc wrote:
> 
> > 2nd: both Bluetooth killswitches reproducibly disappear when I block
> > ideapad_bluetooth either via Gnome bluetooth-applet or via rfkill block
> > 1 and subsequently reboot. After the reboot rfkill list shows:
> > 
> > 0: ideapad_wlan: Wireless LAN
> >         Soft blocked: no
> >         Hard blocked: no
> > 1: ideapad_killsw: Wireless LAN
> >         Soft blocked: no
> >         Hard blocked: no
> > 2: phy0: Wireless LAN
> >         Soft blocked: no
> >         Hard blocked: no
> > 
> > Powering the machine off and on again restores both killswitches.
> > Interesting is: this does not happen when I boot into single-user mode,
> > rfkill block 1 there and reboot. In this case, both killswitches are
> > back.
> This is interesting. looks like the cfgbit will change on S12 if BIOS
> remember it has to shutdown when booting. I will try if the same problem
> happen on my ideapads. 

If we can solve this, I'm inclined to suggest that we submit your code
to Linus to replace mine in 2.6.36. We needed *something* as a stopgap
to solve the rfkill issues, but this is better than what we have in
2-6.36-rc1.

-- 
dwmw2

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[David Woodhouse]

On Thu, 2010-08-19 at 11:21 +0800, Ike Panhc wrote:
> 
> > 2nd: both Bluetooth killswitches reproducibly disappear when I block
> > ideapad_bluetooth either via Gnome bluetooth-applet or via rfkill block
> > 1 and subsequently reboot. After the reboot rfkill list shows:
> > 
> > 0: ideapad_wlan: Wireless LAN
> >         Soft blocked: no
> >         Hard blocked: no
> > 1: ideapad_killsw: Wireless LAN
> >         Soft blocked: no
> >         Hard blocked: no
> > 2: phy0: Wireless LAN
> >         Soft blocked: no
> >         Hard blocked: no
> > 
> > Powering the machine off and on again restores both killswitches.
> > Interesting is: this does not happen when I boot into single-user mode,
> > rfkill block 1 there and reboot. In this case, both killswitches are
> > back.
> This is interesting. looks like the cfgbit will change on S12 if BIOS
> remember it has to shutdown when booting. I will try if the same problem
> happen on my ideapads. 

If we can solve this, I'm inclined to suggest that we submit your code
to Linus to replace mine in 2.6.36. We needed *something* as a stopgap
to solve the rfkill issues, but this is better than what we have in
2-6.36-rc1.

-- 
dwmw2

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Mario 'BitKoenig' Holbe]

[-- Attachment #1.1: Type: text/plain, Size: 5081 bytes --]

On Thu, Aug 19, 2010 at 11:21:01AM +0800, Ike Panhc wrote:
> On 08/18/2010 11:51 PM, Mario 'BitKoenig' Holbe wrote:
> > It works for me too on S12 w/ VIA Nano - at least somehow... I have two
...
> > Fn-Esc switches the Camera off and on, but there seems to be no soft
> > killswitch for it. I have no idea how to parse through acpidump to find
> You can find the entry by "find /sys/devices -name 'camera_power'"

Thanks a lot. I found it and it works.

> > 2nd: both Bluetooth killswitches reproducibly disappear when I block
> > ideapad_bluetooth either via Gnome bluetooth-applet or via rfkill block
> > 1 and subsequently reboot.

All right, I did some more testing...

I was not able to reproduce this with Windows somewhere in the game -
neither via switching BT off in Windows and rebooting to Windows nor via
switching BT off in Linux and rebooting to Windows nor via switching BT
off in Windows and rebooting to Linux.

> This is interesting. looks like the cfgbit will change on S12 if BIOS
> remember it has to shutdown when booting. I will try if the same problem
> happen on my ideapads.

Yes, the cfgbit changes. It's normally 0xd0000 and it's 0xc0000 when the
bluetooth switch is not detected.

It's not that reproducible as it first appeared to be. Sometimes it does
not happen, i.e. sometimes after rfkill block 1 and reboot the
bluetooth killswitch is available again.

If the bluetooth killswitch is not available, a second reboot usually
makes it available again.

Once the cfgbit is 0xc0000 it's stable, i.e. modprobe -r ideapad-laptop;
modprobe ideapad-laptop doesn't change anything.

I tried to enforce the existence of the bluetooth killswitch (the
attached diff is not for inclusion but to show what I did) with some
kind of success:

[  682.260288] ideapad_acpi_add(): cfg=0xc0000
[  682.260293] ideapad_acpi_add(): found: ideapad_camera
[  682.260297] ideapad_acpi_add(): found: ideapad_wlan
[  682.260301] ideapad_acpi_add(): forced: ideapad_bluetooth
[  682.856049] usb 4-1: new full speed USB device using uhci_hcd and address 2
[  683.028220] usb 4-1: New USB device found, idVendor=0a5c, idProduct=2150
[  683.028234] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  683.028244] usb 4-1: Product: BCM2046 Bluetooth Device

So, forcing the existence of the killswitch enables the bluetooth
device. I'm also able to switch if off again - the bluetooth device
disappears. Trying to switch it back on then fails - the bluetooth
device does not appear again. But this case doesn't work all that well
anyways even with cfgbit 0xd0000:

$ rfkill block 1
[  124.648059] usb 4-1: USB disconnect, address 2
[  124.648512] btusb_intr_complete: hci0 urb f6825700 failed to resubmit (19)
[  124.648531] btusb_bulk_complete: hci0 urb f697ee80 failed to resubmit (19)
[  124.649510] btusb_bulk_complete: hci0 urb f6872400 failed to resubmit (19)
[  124.650114] btusb_send_frame: hci0 urb f67acf00 submission failed
$ rfkill unblock 1
[  133.148059] usb 4-1: new full speed USB device using uhci_hcd and address 3
[  148.260042] usb 4-1: device descriptor read/64, error -110
$ rfkill block 1
[  151.092060] hub 4-0:1.0: unable to enumerate USB device on port 1
$ rfkill unblock 1
[  155.628052] usb 4-1: new full speed USB device using uhci_hcd and address 4
[  170.740049] usb 4-1: device descriptor read/64, error -110
[  185.956033] usb 4-1: device descriptor read/64, error -110

Sometimes it doesn't even come back at all on unblock. Seems like the
bluetooth device doesn't really like to be powered off and on that way.
Btw.: once I messed up the bluetooth device that way not even Windows
sees it anymore when I reboot to it.

From all this I'm inclined to assume it has more to do with the
bluetooth device's USB interface than with the killswitch handling
itself. I believe the S12 BIOS just probes the device(s) on it's own and
sets the cfgbit accordingly and sometimes it just doesn't find the
bluetooth device - why ever.

This all does btw. not happen when I use the hci0 killswitch instead.
The device doesn't disappear then, has no issues with re-initialization,
etc. Looks way more stable that way.
I'm not absolutely sure about the different implications of using the
one or the other killswitch - maybe using the ACPI killswitches saves
more power than using the device-specific killswitches because it powers
the device(s) down completely, but that's just a wild guess - maybe it's
absolutely wrong, though.
However, it would probably be worth thinking about not offering the
additional RF killswitches at all but just doing the initialization
stuff to make sure the devices power up and are thus able to be handled
via their own killswitches subsequently.

Please let me know if I can provide more testing - and what kind of :)


Mario
-- 
We know that communication is a problem, but the company is not going to
discuss it with the employees.
                       -- Switching supervisor, AT&T Long Lines Division

[-- Attachment #1.2: ideapad_laptop.diff --]
[-- Type: text/x-diff, Size: 920 bytes --]

--- ideapad_laptop.c.orig	2010-08-18 13:35:36.087735426 +0200
+++ ideapad_laptop.c	2010-08-19 20:06:59.762979357 +0200
@@ -279,11 +279,19 @@
 	if (read_method_int(adevice->handle, "_CFG", &cfg))
 		return -ENODEV;
 
+	printk(KERN_INFO "ideapad_acpi_add(): cfg=0x%x\n", cfg);
+
 	for (i = IDEAPAD_DEV_CAMERA; i < IDEAPAD_DEV_KILLSW; i++) {
-		if (test_bit(ideapad_rfk_data[i].cfgbit, (unsigned long *)&cfg))
+		if (test_bit(ideapad_rfk_data[i].cfgbit, (unsigned long *)&cfg)) {
 			devs_present[i] = 1;
-		else
-			devs_present[i] = 0;
+			printk(KERN_INFO "ideapad_acpi_add(): found: %s\n", ideapad_rfk_data[i].name);
+		} else {
+			if(ideapad_rfk_data[i].type == RFKILL_TYPE_BLUETOOTH) {
+				devs_present[i] = 1;
+				printk(KERN_INFO "ideapad_acpi_add(): forced: %s\n", ideapad_rfk_data[i].name);
+			} else
+				devs_present[i] = 0;
+		}
 	}
 
 	/* The hardware switch is always present */

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

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Mario 'BitKoenig' Holbe]

[-- Attachment #1.1: Type: text/plain, Size: 5081 bytes --]

On Thu, Aug 19, 2010 at 11:21:01AM +0800, Ike Panhc wrote:
> On 08/18/2010 11:51 PM, Mario 'BitKoenig' Holbe wrote:
> > It works for me too on S12 w/ VIA Nano - at least somehow... I have two
...
> > Fn-Esc switches the Camera off and on, but there seems to be no soft
> > killswitch for it. I have no idea how to parse through acpidump to find
> You can find the entry by "find /sys/devices -name 'camera_power'"

Thanks a lot. I found it and it works.

> > 2nd: both Bluetooth killswitches reproducibly disappear when I block
> > ideapad_bluetooth either via Gnome bluetooth-applet or via rfkill block
> > 1 and subsequently reboot.

All right, I did some more testing...

I was not able to reproduce this with Windows somewhere in the game -
neither via switching BT off in Windows and rebooting to Windows nor via
switching BT off in Linux and rebooting to Windows nor via switching BT
off in Windows and rebooting to Linux.

> This is interesting. looks like the cfgbit will change on S12 if BIOS
> remember it has to shutdown when booting. I will try if the same problem
> happen on my ideapads.

Yes, the cfgbit changes. It's normally 0xd0000 and it's 0xc0000 when the
bluetooth switch is not detected.

It's not that reproducible as it first appeared to be. Sometimes it does
not happen, i.e. sometimes after rfkill block 1 and reboot the
bluetooth killswitch is available again.

If the bluetooth killswitch is not available, a second reboot usually
makes it available again.

Once the cfgbit is 0xc0000 it's stable, i.e. modprobe -r ideapad-laptop;
modprobe ideapad-laptop doesn't change anything.

I tried to enforce the existence of the bluetooth killswitch (the
attached diff is not for inclusion but to show what I did) with some
kind of success:

[  682.260288] ideapad_acpi_add(): cfg=0xc0000
[  682.260293] ideapad_acpi_add(): found: ideapad_camera
[  682.260297] ideapad_acpi_add(): found: ideapad_wlan
[  682.260301] ideapad_acpi_add(): forced: ideapad_bluetooth
[  682.856049] usb 4-1: new full speed USB device using uhci_hcd and address 2
[  683.028220] usb 4-1: New USB device found, idVendor=0a5c, idProduct=2150
[  683.028234] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  683.028244] usb 4-1: Product: BCM2046 Bluetooth Device

So, forcing the existence of the killswitch enables the bluetooth
device. I'm also able to switch if off again - the bluetooth device
disappears. Trying to switch it back on then fails - the bluetooth
device does not appear again. But this case doesn't work all that well
anyways even with cfgbit 0xd0000:

$ rfkill block 1
[  124.648059] usb 4-1: USB disconnect, address 2
[  124.648512] btusb_intr_complete: hci0 urb f6825700 failed to resubmit (19)
[  124.648531] btusb_bulk_complete: hci0 urb f697ee80 failed to resubmit (19)
[  124.649510] btusb_bulk_complete: hci0 urb f6872400 failed to resubmit (19)
[  124.650114] btusb_send_frame: hci0 urb f67acf00 submission failed
$ rfkill unblock 1
[  133.148059] usb 4-1: new full speed USB device using uhci_hcd and address 3
[  148.260042] usb 4-1: device descriptor read/64, error -110
$ rfkill block 1
[  151.092060] hub 4-0:1.0: unable to enumerate USB device on port 1
$ rfkill unblock 1
[  155.628052] usb 4-1: new full speed USB device using uhci_hcd and address 4
[  170.740049] usb 4-1: device descriptor read/64, error -110
[  185.956033] usb 4-1: device descriptor read/64, error -110

Sometimes it doesn't even come back at all on unblock. Seems like the
bluetooth device doesn't really like to be powered off and on that way.
Btw.: once I messed up the bluetooth device that way not even Windows
sees it anymore when I reboot to it.

From all this I'm inclined to assume it has more to do with the
bluetooth device's USB interface than with the killswitch handling
itself. I believe the S12 BIOS just probes the device(s) on it's own and
sets the cfgbit accordingly and sometimes it just doesn't find the
bluetooth device - why ever.

This all does btw. not happen when I use the hci0 killswitch instead.
The device doesn't disappear then, has no issues with re-initialization,
etc. Looks way more stable that way.
I'm not absolutely sure about the different implications of using the
one or the other killswitch - maybe using the ACPI killswitches saves
more power than using the device-specific killswitches because it powers
the device(s) down completely, but that's just a wild guess - maybe it's
absolutely wrong, though.
However, it would probably be worth thinking about not offering the
additional RF killswitches at all but just doing the initialization
stuff to make sure the devices power up and are thus able to be handled
via their own killswitches subsequently.

Please let me know if I can provide more testing - and what kind of :)


Mario
-- 
We know that communication is a problem, but the company is not going to
discuss it with the employees.
                       -- Switching supervisor, AT&T Long Lines Division

[-- Attachment #1.2: ideapad_laptop.diff --]
[-- Type: text/x-diff, Size: 920 bytes --]

--- ideapad_laptop.c.orig	2010-08-18 13:35:36.087735426 +0200
+++ ideapad_laptop.c	2010-08-19 20:06:59.762979357 +0200
@@ -279,11 +279,19 @@
 	if (read_method_int(adevice->handle, "_CFG", &cfg))
 		return -ENODEV;
 
+	printk(KERN_INFO "ideapad_acpi_add(): cfg=0x%x\n", cfg);
+
 	for (i = IDEAPAD_DEV_CAMERA; i < IDEAPAD_DEV_KILLSW; i++) {
-		if (test_bit(ideapad_rfk_data[i].cfgbit, (unsigned long *)&cfg))
+		if (test_bit(ideapad_rfk_data[i].cfgbit, (unsigned long *)&cfg)) {
 			devs_present[i] = 1;
-		else
-			devs_present[i] = 0;
+			printk(KERN_INFO "ideapad_acpi_add(): found: %s\n", ideapad_rfk_data[i].name);
+		} else {
+			if(ideapad_rfk_data[i].type == RFKILL_TYPE_BLUETOOTH) {
+				devs_present[i] = 1;
+				printk(KERN_INFO "ideapad_acpi_add(): forced: %s\n", ideapad_rfk_data[i].name);
+			} else
+				devs_present[i] = 0;
+		}
 	}
 
 	/* The hardware switch is always present */

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

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Ike Panhc]

Hi Mario,

Could you attach or upload the DSDT of S12 somewhere I can reach?
I check DSDT for S10-3 and B550, return value of _CFG is fixed.

[Ref: http://people.ubuntu.com/~ikepanhc/DSDTs]

you may use "sudo cp /sys/firmware/acpi/tables/DSDT ." and
"sudo iasl -d /sys/firmware/acpi/tables/DSDT" to decode it.

On 08/20/2010 03:31 AM, Mario 'BitKoenig' Holbe wrote:
> On Thu, Aug 19, 2010 at 11:21:01AM +0800, Ike Panhc wrote:
>> On 08/18/2010 11:51 PM, Mario 'BitKoenig' Holbe wrote:
>>> 2nd: both Bluetooth killswitches reproducibly disappear when I block
>>> ideapad_bluetooth either via Gnome bluetooth-applet or via rfkill block
>>> 1 and subsequently reboot.
> 
> All right, I did some more testing...
> 
> I was not able to reproduce this with Windows somewhere in the game -
> neither via switching BT off in Windows and rebooting to Windows nor via
> switching BT off in Linux and rebooting to Windows nor via switching BT
> off in Windows and rebooting to Linux.
> 
>> This is interesting. looks like the cfgbit will change on S12 if BIOS
>> remember it has to shutdown when booting. I will try if the same problem
>> happen on my ideapads.
> 
> Yes, the cfgbit changes. It's normally 0xd0000 and it's 0xc0000 when the
> bluetooth switch is not detected.
> 
> It's not that reproducible as it first appeared to be. Sometimes it does
> not happen, i.e. sometimes after rfkill block 1 and reboot the
> bluetooth killswitch is available again.
> 
> If the bluetooth killswitch is not available, a second reboot usually
> makes it available again.
> 
> Once the cfgbit is 0xc0000 it's stable, i.e. modprobe -r ideapad-laptop;
> modprobe ideapad-laptop doesn't change anything.
sounds like we need an exception handle for detecting camera

> 
> I tried to enforce the existence of the bluetooth killswitch (the
> attached diff is not for inclusion but to show what I did) with some
> kind of success:
> 
> [  682.260288] ideapad_acpi_add(): cfg=0xc0000
As I know the cfgbit for lower 16bit shall not be all zero.

> [  682.260293] ideapad_acpi_add(): found: ideapad_camera
> [  682.260297] ideapad_acpi_add(): found: ideapad_wlan
> [  682.260301] ideapad_acpi_add(): forced: ideapad_bluetooth
> [  682.856049] usb 4-1: new full speed USB device using uhci_hcd and address 2
> [  683.028220] usb 4-1: New USB device found, idVendor=0a5c, idProduct=2150
> [  683.028234] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> [  683.028244] usb 4-1: Product: BCM2046 Bluetooth Device
> 
> So, forcing the existence of the killswitch enables the bluetooth
> device. I'm also able to switch if off again - the bluetooth device
> disappears. Trying to switch it back on then fails - the bluetooth
> device does not appear again. But this case doesn't work all that well
> anyways even with cfgbit 0xd0000:
bluetooth device shall disappear after disable from EC. But if can not be enabled
again, ahh.....

> 
> $ rfkill block 1
> [  124.648059] usb 4-1: USB disconnect, address 2
> [  124.648512] btusb_intr_complete: hci0 urb f6825700 failed to resubmit (19)
> [  124.648531] btusb_bulk_complete: hci0 urb f697ee80 failed to resubmit (19)
> [  124.649510] btusb_bulk_complete: hci0 urb f6872400 failed to resubmit (19)
> [  124.650114] btusb_send_frame: hci0 urb f67acf00 submission failed
> $ rfkill unblock 1
> [  133.148059] usb 4-1: new full speed USB device using uhci_hcd and address 3
> [  148.260042] usb 4-1: device descriptor read/64, error -110
> $ rfkill block 1
> [  151.092060] hub 4-0:1.0: unable to enumerate USB device on port 1
> $ rfkill unblock 1
> [  155.628052] usb 4-1: new full speed USB device using uhci_hcd and address 4
> [  170.740049] usb 4-1: device descriptor read/64, error -110
> [  185.956033] usb 4-1: device descriptor read/64, error -110
This looks like the device is power up, but usb host unable to recognize..

> 
> Sometimes it doesn't even come back at all on unblock. Seems like the
> bluetooth device doesn't really like to be powered off and on that way.
> Btw.: once I messed up the bluetooth device that way not even Windows
> sees it anymore when I reboot to it.
did you see any kernel message said timeout when it does not come back at all?

> 
> From all this I'm inclined to assume it has more to do with the
> bluetooth device's USB interface than with the killswitch handling
> itself. I believe the S12 BIOS just probes the device(s) on it's own and
> sets the cfgbit accordingly and sometimes it just doesn't find the
> bluetooth device - why ever.
I guess so. so I need DSDT for digging more.

> 
> This all does btw. not happen when I use the hci0 killswitch instead.
> The device doesn't disappear then, has no issues with re-initialization,
> etc. Looks way more stable that way.
when you use rfkill of hci0, it only disable PHY. The driver and MAC is still
there. The rfkill of ideapad-laptop will power down all the module. I believe
its normal.

> I'm not absolutely sure about the different implications of using the
> one or the other killswitch - maybe using the ACPI killswitches saves
> more power than using the device-specific killswitches because it powers
> the device(s) down completely, but that's just a wild guess - maybe it's
> absolutely wrong, though.
I think it shall be correct.

If the rfkill for the whole bluetooth module makes trouble, I prefer not to
do it. User will feel confused if the device does not come back and the
rfkill of hci0 offers the function user need.

> However, it would probably be worth thinking about not offering the
> additional RF killswitches at all but just doing the initialization
> stuff to make sure the devices power up and are thus able to be handled
> via their own killswitches subsequently.
> 
> Please let me know if I can provide more testing - and what kind of :)
> 
> 
> Mario

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Ike Panhc]

Hi Mario,

Could you attach or upload the DSDT of S12 somewhere I can reach?
I check DSDT for S10-3 and B550, return value of _CFG is fixed.

[Ref: http://people.ubuntu.com/~ikepanhc/DSDTs]

you may use "sudo cp /sys/firmware/acpi/tables/DSDT ." and
"sudo iasl -d /sys/firmware/acpi/tables/DSDT" to decode it.

On 08/20/2010 03:31 AM, Mario 'BitKoenig' Holbe wrote:
> On Thu, Aug 19, 2010 at 11:21:01AM +0800, Ike Panhc wrote:
>> On 08/18/2010 11:51 PM, Mario 'BitKoenig' Holbe wrote:
>>> 2nd: both Bluetooth killswitches reproducibly disappear when I block
>>> ideapad_bluetooth either via Gnome bluetooth-applet or via rfkill block
>>> 1 and subsequently reboot.
> 
> All right, I did some more testing...
> 
> I was not able to reproduce this with Windows somewhere in the game -
> neither via switching BT off in Windows and rebooting to Windows nor via
> switching BT off in Linux and rebooting to Windows nor via switching BT
> off in Windows and rebooting to Linux.
> 
>> This is interesting. looks like the cfgbit will change on S12 if BIOS
>> remember it has to shutdown when booting. I will try if the same problem
>> happen on my ideapads.
> 
> Yes, the cfgbit changes. It's normally 0xd0000 and it's 0xc0000 when the
> bluetooth switch is not detected.
> 
> It's not that reproducible as it first appeared to be. Sometimes it does
> not happen, i.e. sometimes after rfkill block 1 and reboot the
> bluetooth killswitch is available again.
> 
> If the bluetooth killswitch is not available, a second reboot usually
> makes it available again.
> 
> Once the cfgbit is 0xc0000 it's stable, i.e. modprobe -r ideapad-laptop;
> modprobe ideapad-laptop doesn't change anything.
sounds like we need an exception handle for detecting camera

> 
> I tried to enforce the existence of the bluetooth killswitch (the
> attached diff is not for inclusion but to show what I did) with some
> kind of success:
> 
> [  682.260288] ideapad_acpi_add(): cfg=0xc0000
As I know the cfgbit for lower 16bit shall not be all zero.

> [  682.260293] ideapad_acpi_add(): found: ideapad_camera
> [  682.260297] ideapad_acpi_add(): found: ideapad_wlan
> [  682.260301] ideapad_acpi_add(): forced: ideapad_bluetooth
> [  682.856049] usb 4-1: new full speed USB device using uhci_hcd and address 2
> [  683.028220] usb 4-1: New USB device found, idVendor=0a5c, idProduct=2150
> [  683.028234] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> [  683.028244] usb 4-1: Product: BCM2046 Bluetooth Device
> 
> So, forcing the existence of the killswitch enables the bluetooth
> device. I'm also able to switch if off again - the bluetooth device
> disappears. Trying to switch it back on then fails - the bluetooth
> device does not appear again. But this case doesn't work all that well
> anyways even with cfgbit 0xd0000:
bluetooth device shall disappear after disable from EC. But if can not be enabled
again, ahh.....

> 
> $ rfkill block 1
> [  124.648059] usb 4-1: USB disconnect, address 2
> [  124.648512] btusb_intr_complete: hci0 urb f6825700 failed to resubmit (19)
> [  124.648531] btusb_bulk_complete: hci0 urb f697ee80 failed to resubmit (19)
> [  124.649510] btusb_bulk_complete: hci0 urb f6872400 failed to resubmit (19)
> [  124.650114] btusb_send_frame: hci0 urb f67acf00 submission failed
> $ rfkill unblock 1
> [  133.148059] usb 4-1: new full speed USB device using uhci_hcd and address 3
> [  148.260042] usb 4-1: device descriptor read/64, error -110
> $ rfkill block 1
> [  151.092060] hub 4-0:1.0: unable to enumerate USB device on port 1
> $ rfkill unblock 1
> [  155.628052] usb 4-1: new full speed USB device using uhci_hcd and address 4
> [  170.740049] usb 4-1: device descriptor read/64, error -110
> [  185.956033] usb 4-1: device descriptor read/64, error -110
This looks like the device is power up, but usb host unable to recognize..

> 
> Sometimes it doesn't even come back at all on unblock. Seems like the
> bluetooth device doesn't really like to be powered off and on that way.
> Btw.: once I messed up the bluetooth device that way not even Windows
> sees it anymore when I reboot to it.
did you see any kernel message said timeout when it does not come back at all?

> 
> From all this I'm inclined to assume it has more to do with the
> bluetooth device's USB interface than with the killswitch handling
> itself. I believe the S12 BIOS just probes the device(s) on it's own and
> sets the cfgbit accordingly and sometimes it just doesn't find the
> bluetooth device - why ever.
I guess so. so I need DSDT for digging more.

> 
> This all does btw. not happen when I use the hci0 killswitch instead.
> The device doesn't disappear then, has no issues with re-initialization,
> etc. Looks way more stable that way.
when you use rfkill of hci0, it only disable PHY. The driver and MAC is still
there. The rfkill of ideapad-laptop will power down all the module. I believe
its normal.

> I'm not absolutely sure about the different implications of using the
> one or the other killswitch - maybe using the ACPI killswitches saves
> more power than using the device-specific killswitches because it powers
> the device(s) down completely, but that's just a wild guess - maybe it's
> absolutely wrong, though.
I think it shall be correct.

If the rfkill for the whole bluetooth module makes trouble, I prefer not to
do it. User will feel confused if the device does not come back and the
rfkill of hci0 offers the function user need.

> However, it would probably be worth thinking about not offering the
> additional RF killswitches at all but just doing the initialization
> stuff to make sure the devices power up and are thus able to be handled
> via their own killswitches subsequently.
> 
> Please let me know if I can provide more testing - and what kind of :)
> 
> 
> Mario

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Mario 'BitKoenig' Holbe]

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

On Fri, Aug 20, 2010 at 03:01:07PM +0800, Ike Panhc wrote:
> Could you attach or upload the DSDT of S12 somewhere I can reach?

http://sandbox.fem.tu-ilmenau.de/s12/dsdt-s12-via.dsl

> I check DSDT for S10-3 and B550, return value of _CFG is fixed.
> [Ref: http://people.ubuntu.com/~ikepanhc/DSDTs]

Looks more fixed than on my S12, indeed.
I don't really speak AML, but while S10-3 ILDD (called from _CFG) seems
to read fixed values only, here on S12 PHSR (called from _CFG) seems to
do some kind of I/O operation. I'm not sure about this, but it somehow
looks like.

> On 08/20/2010 03:31 AM, Mario 'BitKoenig' Holbe wrote:
> > Once the cfgbit is 0xc0000 it's stable, i.e. modprobe -r ideapad-laptop;
> > modprobe ideapad-laptop doesn't change anything.
> sounds like we need an exception handle for detecting camera

Why? The camera is always detected - bit 19 is always set, 0xc0000 and
0xd0000 only differ in bit 16. Bit 19 btw. seems to be the only fixed
bit in S12-VIA _CFG :)

> > [  682.260288] ideapad_acpi_add(): cfg=0xc0000
> As I know the cfgbit for lower 16bit shall not be all zero.

Mh, judging from S12-VIA _CFG they definitely are zero here.

> > So, forcing the existence of the killswitch enables the bluetooth
> > device. I'm also able to switch if off again - the bluetooth device
> > disappears. Trying to switch it back on then fails - the bluetooth
> > device does not appear again. But this case doesn't work all that well
> > anyways even with cfgbit 0xd0000:
> bluetooth device shall disappear after disable from EC. But if can not be enabled
> again, ahh.....

> > [  155.628052] usb 4-1: new full speed USB device using uhci_hcd and address 4
> > [  170.740049] usb 4-1: device descriptor read/64, error -110
> > [  185.956033] usb 4-1: device descriptor read/64, error -110
> This looks like the device is power up, but usb host unable to recognize..

The bluetooth device seems not to initialize well enough to answer (110
is ETIMEDOUT).

> > Sometimes it doesn't even come back at all on unblock. Seems like the
> > bluetooth device doesn't really like to be powered off and on that way.
> did you see any kernel message said timeout when it does not come back at all?

No, when I said "does not appear again" and "it does not come back at
all" I meant I see not a single message in dmesg about anything
happening.

> If the rfkill for the whole bluetooth module makes trouble, I prefer not to
> do it. User will feel confused if the device does not come back and the
> rfkill of hci0 offers the function user need.

Hmmm, maybe provide a module parm to block rfkill devices and default it
to 1 on S12? Users would not need to care too much then but can change
it if they like...

> > Please let me know if I can provide more testing - and what kind of :)

Okay, did some more...

I played with the hardware killswitch under Linux. The bluetooth device
disappears and re-appears there and always seems to initialize
correctly. No USB read errors this way.

I also played with the soft killswitch under Windows. The bluetooth
device disappears from device manager and re-appears on unblock
(together with the Windows device plug sounds). This looks to me like
the ACPI killswitch is used for it.
No initialization-problems here, the device always comes back fully
operational. So, Windows doesn't seem to suffer from a bad
initialization.

I'm not exactly sure what this means - especially because I don't know
how the hardware killswitch works internally.
It *could* mean, the initialization problem is proably something that
could be dealt with in the USB layer long term (and would then probably
not have to be worked around anymore in ideapad_laptop). I'm not sure
about this, because this would mean the hard killswitch power-cut
somehow differs from the soft killswitch power-cut.


Mario
-- 
As a rule, the more bizarre a thing is, the less mysterious it proves to be.
                                    -- Sherlock Holmes by Arthur Conan Doyle

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

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Mario 'BitKoenig' Holbe]

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

On Fri, Aug 20, 2010 at 03:01:07PM +0800, Ike Panhc wrote:
> Could you attach or upload the DSDT of S12 somewhere I can reach?

http://sandbox.fem.tu-ilmenau.de/s12/dsdt-s12-via.dsl

> I check DSDT for S10-3 and B550, return value of _CFG is fixed.
> [Ref: http://people.ubuntu.com/~ikepanhc/DSDTs]

Looks more fixed than on my S12, indeed.
I don't really speak AML, but while S10-3 ILDD (called from _CFG) seems
to read fixed values only, here on S12 PHSR (called from _CFG) seems to
do some kind of I/O operation. I'm not sure about this, but it somehow
looks like.

> On 08/20/2010 03:31 AM, Mario 'BitKoenig' Holbe wrote:
> > Once the cfgbit is 0xc0000 it's stable, i.e. modprobe -r ideapad-laptop;
> > modprobe ideapad-laptop doesn't change anything.
> sounds like we need an exception handle for detecting camera

Why? The camera is always detected - bit 19 is always set, 0xc0000 and
0xd0000 only differ in bit 16. Bit 19 btw. seems to be the only fixed
bit in S12-VIA _CFG :)

> > [  682.260288] ideapad_acpi_add(): cfg=0xc0000
> As I know the cfgbit for lower 16bit shall not be all zero.

Mh, judging from S12-VIA _CFG they definitely are zero here.

> > So, forcing the existence of the killswitch enables the bluetooth
> > device. I'm also able to switch if off again - the bluetooth device
> > disappears. Trying to switch it back on then fails - the bluetooth
> > device does not appear again. But this case doesn't work all that well
> > anyways even with cfgbit 0xd0000:
> bluetooth device shall disappear after disable from EC. But if can not be enabled
> again, ahh.....

> > [  155.628052] usb 4-1: new full speed USB device using uhci_hcd and address 4
> > [  170.740049] usb 4-1: device descriptor read/64, error -110
> > [  185.956033] usb 4-1: device descriptor read/64, error -110
> This looks like the device is power up, but usb host unable to recognize..

The bluetooth device seems not to initialize well enough to answer (110
is ETIMEDOUT).

> > Sometimes it doesn't even come back at all on unblock. Seems like the
> > bluetooth device doesn't really like to be powered off and on that way.
> did you see any kernel message said timeout when it does not come back at all?

No, when I said "does not appear again" and "it does not come back at
all" I meant I see not a single message in dmesg about anything
happening.

> If the rfkill for the whole bluetooth module makes trouble, I prefer not to
> do it. User will feel confused if the device does not come back and the
> rfkill of hci0 offers the function user need.

Hmmm, maybe provide a module parm to block rfkill devices and default it
to 1 on S12? Users would not need to care too much then but can change
it if they like...

> > Please let me know if I can provide more testing - and what kind of :)

Okay, did some more...

I played with the hardware killswitch under Linux. The bluetooth device
disappears and re-appears there and always seems to initialize
correctly. No USB read errors this way.

I also played with the soft killswitch under Windows. The bluetooth
device disappears from device manager and re-appears on unblock
(together with the Windows device plug sounds). This looks to me like
the ACPI killswitch is used for it.
No initialization-problems here, the device always comes back fully
operational. So, Windows doesn't seem to suffer from a bad
initialization.

I'm not exactly sure what this means - especially because I don't know
how the hardware killswitch works internally.
It *could* mean, the initialization problem is proably something that
could be dealt with in the USB layer long term (and would then probably
not have to be worked around anymore in ideapad_laptop). I'm not sure
about this, because this would mean the hard killswitch power-cut
somehow differs from the soft killswitch power-cut.


Mario
-- 
As a rule, the more bizarre a thing is, the less mysterious it proves to be.
                                    -- Sherlock Holmes by Arthur Conan Doyle

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

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Ike Panhc]

On 08/20/2010 05:08 PM, Mario 'BitKoenig' Holbe wrote:
> On Fri, Aug 20, 2010 at 03:01:07PM +0800, Ike Panhc wrote:
>> Could you attach or upload the DSDT of S12 somewhere I can reach?
> 
> http://sandbox.fem.tu-ilmenau.de/s12/dsdt-s12-via.dsl
Thanks for the DSDT and the following information.

I am not an expert on AML but after looking to the DSDT, I think I will
focus on what XCMD do.

I notice there are some interesting method/variable (Ex: BTEN/BTST..)
about bluetooth, but not have a good story about what's going on.

I think the only problem we have now is bluetooth sometimes not coming
back when rebooting after turn off bluetooth via sw rfkill. Try to find
out if there is anything need to be done before turn it on.

> 
>> I check DSDT for S10-3 and B550, return value of _CFG is fixed.
>> [Ref: http://people.ubuntu.com/~ikepanhc/DSDTs]
> 
> Looks more fixed than on my S12, indeed.
> I don't really speak AML, but while S10-3 ILDD (called from _CFG) seems
> to read fixed values only, here on S12 PHSR (called from _CFG) seems to
> do some kind of I/O operation. I'm not sure about this, but it somehow
> looks like.
> 
>> On 08/20/2010 03:31 AM, Mario 'BitKoenig' Holbe wrote:
>>> Once the cfgbit is 0xc0000 it's stable, i.e. modprobe -r ideapad-laptop;
>>> modprobe ideapad-laptop doesn't change anything.
>> sounds like we need an exception handle for detecting camera
> 
> Why? The camera is always detected - bit 19 is always set, 0xc0000 and
> 0xd0000 only differ in bit 16. Bit 19 btw. seems to be the only fixed
> bit in S12-VIA _CFG :)
> 
>>> [  682.260288] ideapad_acpi_add(): cfg=0xc0000
>> As I know the cfgbit for lower 16bit shall not be all zero.
> 
> Mh, judging from S12-VIA _CFG they definitely are zero here.
> 
>>> So, forcing the existence of the killswitch enables the bluetooth
>>> device. I'm also able to switch if off again - the bluetooth device
>>> disappears. Trying to switch it back on then fails - the bluetooth
>>> device does not appear again. But this case doesn't work all that well
>>> anyways even with cfgbit 0xd0000:
>> bluetooth device shall disappear after disable from EC. But if can not be enabled
>> again, ahh.....
> 
>>> [  155.628052] usb 4-1: new full speed USB device using uhci_hcd and address 4
>>> [  170.740049] usb 4-1: device descriptor read/64, error -110
>>> [  185.956033] usb 4-1: device descriptor read/64, error -110
>> This looks like the device is power up, but usb host unable to recognize..
> 
> The bluetooth device seems not to initialize well enough to answer (110
> is ETIMEDOUT).
> 
>>> Sometimes it doesn't even come back at all on unblock. Seems like the
>>> bluetooth device doesn't really like to be powered off and on that way.
>> did you see any kernel message said timeout when it does not come back at all?
> 
> No, when I said "does not appear again" and "it does not come back at
> all" I meant I see not a single message in dmesg about anything
> happening.
> 
>> If the rfkill for the whole bluetooth module makes trouble, I prefer not to
>> do it. User will feel confused if the device does not come back and the
>> rfkill of hci0 offers the function user need.
> 
> Hmmm, maybe provide a module parm to block rfkill devices and default it
> to 1 on S12? Users would not need to care too much then but can change
> it if they like...
> 
>>> Please let me know if I can provide more testing - and what kind of :)
> 
> Okay, did some more...
> 
> I played with the hardware killswitch under Linux. The bluetooth device
> disappears and re-appears there and always seems to initialize
> correctly. No USB read errors this way.
> 
> I also played with the soft killswitch under Windows. The bluetooth
> device disappears from device manager and re-appears on unblock
> (together with the Windows device plug sounds). This looks to me like
> the ACPI killswitch is used for it.
> No initialization-problems here, the device always comes back fully
> operational. So, Windows doesn't seem to suffer from a bad
> initialization.
> 
> I'm not exactly sure what this means - especially because I don't know
> how the hardware killswitch works internally.
> It *could* mean, the initialization problem is proably something that
> could be dealt with in the USB layer long term (and would then probably
> not have to be worked around anymore in ideapad_laptop). I'm not sure
> about this, because this would mean the hard killswitch power-cut
> somehow differs from the soft killswitch power-cut.
> 
> 
> Mario

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Ike Panhc]

On 08/20/2010 05:08 PM, Mario 'BitKoenig' Holbe wrote:
> On Fri, Aug 20, 2010 at 03:01:07PM +0800, Ike Panhc wrote:
>> Could you attach or upload the DSDT of S12 somewhere I can reach?
> 
> http://sandbox.fem.tu-ilmenau.de/s12/dsdt-s12-via.dsl
Thanks for the DSDT and the following information.

I am not an expert on AML but after looking to the DSDT, I think I will
focus on what XCMD do.

I notice there are some interesting method/variable (Ex: BTEN/BTST..)
about bluetooth, but not have a good story about what's going on.

I think the only problem we have now is bluetooth sometimes not coming
back when rebooting after turn off bluetooth via sw rfkill. Try to find
out if there is anything need to be done before turn it on.

> 
>> I check DSDT for S10-3 and B550, return value of _CFG is fixed.
>> [Ref: http://people.ubuntu.com/~ikepanhc/DSDTs]
> 
> Looks more fixed than on my S12, indeed.
> I don't really speak AML, but while S10-3 ILDD (called from _CFG) seems
> to read fixed values only, here on S12 PHSR (called from _CFG) seems to
> do some kind of I/O operation. I'm not sure about this, but it somehow
> looks like.
> 
>> On 08/20/2010 03:31 AM, Mario 'BitKoenig' Holbe wrote:
>>> Once the cfgbit is 0xc0000 it's stable, i.e. modprobe -r ideapad-laptop;
>>> modprobe ideapad-laptop doesn't change anything.
>> sounds like we need an exception handle for detecting camera
> 
> Why? The camera is always detected - bit 19 is always set, 0xc0000 and
> 0xd0000 only differ in bit 16. Bit 19 btw. seems to be the only fixed
> bit in S12-VIA _CFG :)
> 
>>> [  682.260288] ideapad_acpi_add(): cfg=0xc0000
>> As I know the cfgbit for lower 16bit shall not be all zero.
> 
> Mh, judging from S12-VIA _CFG they definitely are zero here.
> 
>>> So, forcing the existence of the killswitch enables the bluetooth
>>> device. I'm also able to switch if off again - the bluetooth device
>>> disappears. Trying to switch it back on then fails - the bluetooth
>>> device does not appear again. But this case doesn't work all that well
>>> anyways even with cfgbit 0xd0000:
>> bluetooth device shall disappear after disable from EC. But if can not be enabled
>> again, ahh.....
> 
>>> [  155.628052] usb 4-1: new full speed USB device using uhci_hcd and address 4
>>> [  170.740049] usb 4-1: device descriptor read/64, error -110
>>> [  185.956033] usb 4-1: device descriptor read/64, error -110
>> This looks like the device is power up, but usb host unable to recognize..
> 
> The bluetooth device seems not to initialize well enough to answer (110
> is ETIMEDOUT).
> 
>>> Sometimes it doesn't even come back at all on unblock. Seems like the
>>> bluetooth device doesn't really like to be powered off and on that way.
>> did you see any kernel message said timeout when it does not come back at all?
> 
> No, when I said "does not appear again" and "it does not come back at
> all" I meant I see not a single message in dmesg about anything
> happening.
> 
>> If the rfkill for the whole bluetooth module makes trouble, I prefer not to
>> do it. User will feel confused if the device does not come back and the
>> rfkill of hci0 offers the function user need.
> 
> Hmmm, maybe provide a module parm to block rfkill devices and default it
> to 1 on S12? Users would not need to care too much then but can change
> it if they like...
> 
>>> Please let me know if I can provide more testing - and what kind of :)
> 
> Okay, did some more...
> 
> I played with the hardware killswitch under Linux. The bluetooth device
> disappears and re-appears there and always seems to initialize
> correctly. No USB read errors this way.
> 
> I also played with the soft killswitch under Windows. The bluetooth
> device disappears from device manager and re-appears on unblock
> (together with the Windows device plug sounds). This looks to me like
> the ACPI killswitch is used for it.
> No initialization-problems here, the device always comes back fully
> operational. So, Windows doesn't seem to suffer from a bad
> initialization.
> 
> I'm not exactly sure what this means - especially because I don't know
> how the hardware killswitch works internally.
> It *could* mean, the initialization problem is proably something that
> could be dealt with in the USB layer long term (and would then probably
> not have to be worked around anymore in ideapad_laptop). I'm not sure
> about this, because this would mean the hard killswitch power-cut
> somehow differs from the soft killswitch power-cut.
> 
> 
> Mario

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Ike Panhc]

On 08/20/2010 05:08 PM, Mario 'BitKoenig' Holbe wrote:
> On Fri, Aug 20, 2010 at 03:01:07PM +0800, Ike Panhc wrote:
>> Could you attach or upload the DSDT of S12 somewhere I can reach?
> 
> http://sandbox.fem.tu-ilmenau.de/s12/dsdt-s12-via.dsl
> 
>> I check DSDT for S10-3 and B550, return value of _CFG is fixed.
>> [Ref: http://people.ubuntu.com/~ikepanhc/DSDTs]
> 
> Looks more fixed than on my S12, indeed.
> I don't really speak AML, but while S10-3 ILDD (called from _CFG) seems
> to read fixed values only, here on S12 PHSR (called from _CFG) seems to
> do some kind of I/O operation. I'm not sure about this, but it somehow
> looks like.
> 
It accesses something in system memory, but I have no idea what will happen
after writing..

>> On 08/20/2010 03:31 AM, Mario 'BitKoenig' Holbe wrote:
>>> Once the cfgbit is 0xc0000 it's stable, i.e. modprobe -r ideapad-laptop;
>>> modprobe ideapad-laptop doesn't change anything.
>> sounds like we need an exception handle for detecting camera
> 
> Why? The camera is always detected - bit 19 is always set, 0xc0000 and
> 0xd0000 only differ in bit 16. Bit 19 btw. seems to be the only fixed
> bit in S12-VIA _CFG :)
> 
That's my misunderstanding.

>>> [  682.260288] ideapad_acpi_add(): cfg=0xc0000
>> As I know the cfgbit for lower 16bit shall not be all zero.
> 
> Mh, judging from S12-VIA _CFG they definitely are zero here.
> 
>>> So, forcing the existence of the killswitch enables the bluetooth
>>> device. I'm also able to switch if off again - the bluetooth device
>>> disappears. Trying to switch it back on then fails - the bluetooth
>>> device does not appear again. But this case doesn't work all that well
>>> anyways even with cfgbit 0xd0000:
>> bluetooth device shall disappear after disable from EC. But if can not be enabled
>> again, ahh.....
> 
>>> [  155.628052] usb 4-1: new full speed USB device using uhci_hcd and address 4
>>> [  170.740049] usb 4-1: device descriptor read/64, error -110
>>> [  185.956033] usb 4-1: device descriptor read/64, error -110
>> This looks like the device is power up, but usb host unable to recognize..
> 
> The bluetooth device seems not to initialize well enough to answer (110
> is ETIMEDOUT).
> 
There are two variables need to be written for turning on/off bluetooth. They are
BTST(in memory) and BTEN(is EC register). I will guess there are some sync failed
when enable bluetooth.

>>> Sometimes it doesn't even come back at all on unblock. Seems like the
>>> bluetooth device doesn't really like to be powered off and on that way.
>> did you see any kernel message said timeout when it does not come back at all?
> 
> No, when I said "does not appear again" and "it does not come back at
> all" I meant I see not a single message in dmesg about anything
> happening.
> 
>> If the rfkill for the whole bluetooth module makes trouble, I prefer not to
>> do it. User will feel confused if the device does not come back and the
>> rfkill of hci0 offers the function user need.
> 
> Hmmm, maybe provide a module parm to block rfkill devices and default it
> to 1 on S12? Users would not need to care too much then but can change
> it if they like...
This could be a plan. I have several idea to go and need your help.
- Add some debug message to read BTST/BTEN when turning on/off bluetooth.
- Force to set BTST/BTEN before reading _CFG
- Provide a module parm to force enable rf devices.

Will have the drivers and please test it and let me know the result.

> 
>>> Please let me know if I can provide more testing - and what kind of :)
> 
> Okay, did some more...
> 
> I played with the hardware killswitch under Linux. The bluetooth device
> disappears and re-appears there and always seems to initialize
> correctly. No USB read errors this way.
> 
> I also played with the soft killswitch under Windows. The bluetooth
> device disappears from device manager and re-appears on unblock
> (together with the Windows device plug sounds). This looks to me like
> the ACPI killswitch is used for it.
> No initialization-problems here, the device always comes back fully
> operational. So, Windows doesn't seem to suffer from a bad
> initialization.
> 
> I'm not exactly sure what this means - especially because I don't know
> how the hardware killswitch works internally.
> It *could* mean, the initialization problem is proably something that
> could be dealt with in the USB layer long term (and would then probably
> not have to be worked around anymore in ideapad_laptop). I'm not sure
> about this, because this would mean the hard killswitch power-cut
> somehow differs from the soft killswitch power-cut.
Usually the hw rf switch turning off PHY only. When turning off, device and
its driver is still there. I believe S12 is designed in this way after
reading your test result.

> 
> 
> Mario

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Ike Panhc]

On 08/20/2010 05:08 PM, Mario 'BitKoenig' Holbe wrote:
> On Fri, Aug 20, 2010 at 03:01:07PM +0800, Ike Panhc wrote:
>> Could you attach or upload the DSDT of S12 somewhere I can reach?
> 
> http://sandbox.fem.tu-ilmenau.de/s12/dsdt-s12-via.dsl
> 
>> I check DSDT for S10-3 and B550, return value of _CFG is fixed.
>> [Ref: http://people.ubuntu.com/~ikepanhc/DSDTs]
> 
> Looks more fixed than on my S12, indeed.
> I don't really speak AML, but while S10-3 ILDD (called from _CFG) seems
> to read fixed values only, here on S12 PHSR (called from _CFG) seems to
> do some kind of I/O operation. I'm not sure about this, but it somehow
> looks like.
> 
It accesses something in system memory, but I have no idea what will happen
after writing..

>> On 08/20/2010 03:31 AM, Mario 'BitKoenig' Holbe wrote:
>>> Once the cfgbit is 0xc0000 it's stable, i.e. modprobe -r ideapad-laptop;
>>> modprobe ideapad-laptop doesn't change anything.
>> sounds like we need an exception handle for detecting camera
> 
> Why? The camera is always detected - bit 19 is always set, 0xc0000 and
> 0xd0000 only differ in bit 16. Bit 19 btw. seems to be the only fixed
> bit in S12-VIA _CFG :)
> 
That's my misunderstanding.

>>> [  682.260288] ideapad_acpi_add(): cfg=0xc0000
>> As I know the cfgbit for lower 16bit shall not be all zero.
> 
> Mh, judging from S12-VIA _CFG they definitely are zero here.
> 
>>> So, forcing the existence of the killswitch enables the bluetooth
>>> device. I'm also able to switch if off again - the bluetooth device
>>> disappears. Trying to switch it back on then fails - the bluetooth
>>> device does not appear again. But this case doesn't work all that well
>>> anyways even with cfgbit 0xd0000:
>> bluetooth device shall disappear after disable from EC. But if can not be enabled
>> again, ahh.....
> 
>>> [  155.628052] usb 4-1: new full speed USB device using uhci_hcd and address 4
>>> [  170.740049] usb 4-1: device descriptor read/64, error -110
>>> [  185.956033] usb 4-1: device descriptor read/64, error -110
>> This looks like the device is power up, but usb host unable to recognize..
> 
> The bluetooth device seems not to initialize well enough to answer (110
> is ETIMEDOUT).
> 
There are two variables need to be written for turning on/off bluetooth. They are
BTST(in memory) and BTEN(is EC register). I will guess there are some sync failed
when enable bluetooth.

>>> Sometimes it doesn't even come back at all on unblock. Seems like the
>>> bluetooth device doesn't really like to be powered off and on that way.
>> did you see any kernel message said timeout when it does not come back at all?
> 
> No, when I said "does not appear again" and "it does not come back at
> all" I meant I see not a single message in dmesg about anything
> happening.
> 
>> If the rfkill for the whole bluetooth module makes trouble, I prefer not to
>> do it. User will feel confused if the device does not come back and the
>> rfkill of hci0 offers the function user need.
> 
> Hmmm, maybe provide a module parm to block rfkill devices and default it
> to 1 on S12? Users would not need to care too much then but can change
> it if they like...
This could be a plan. I have several idea to go and need your help.
- Add some debug message to read BTST/BTEN when turning on/off bluetooth.
- Force to set BTST/BTEN before reading _CFG
- Provide a module parm to force enable rf devices.

Will have the drivers and please test it and let me know the result.

> 
>>> Please let me know if I can provide more testing - and what kind of :)
> 
> Okay, did some more...
> 
> I played with the hardware killswitch under Linux. The bluetooth device
> disappears and re-appears there and always seems to initialize
> correctly. No USB read errors this way.
> 
> I also played with the soft killswitch under Windows. The bluetooth
> device disappears from device manager and re-appears on unblock
> (together with the Windows device plug sounds). This looks to me like
> the ACPI killswitch is used for it.
> No initialization-problems here, the device always comes back fully
> operational. So, Windows doesn't seem to suffer from a bad
> initialization.
> 
> I'm not exactly sure what this means - especially because I don't know
> how the hardware killswitch works internally.
> It *could* mean, the initialization problem is proably something that
> could be dealt with in the USB layer long term (and would then probably
> not have to be worked around anymore in ideapad_laptop). I'm not sure
> about this, because this would mean the hard killswitch power-cut
> somehow differs from the soft killswitch power-cut.
Usually the hw rf switch turning off PHY only. When turning off, device and
its driver is still there. I believe S12 is designed in this way after
reading your test result.

> 
> 
> Mario

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Ike Panhc]

On 08/20/2010 05:08 PM, Mario 'BitKoenig' Holbe wrote:
> On Fri, Aug 20, 2010 at 03:01:07PM +0800, Ike Panhc wrote:
>> Could you attach or upload the DSDT of S12 somewhere I can reach?
> 
> http://sandbox.fem.tu-ilmenau.de/s12/dsdt-s12-via.dsl
> 
>> I check DSDT for S10-3 and B550, return value of _CFG is fixed.
>> [Ref: http://people.ubuntu.com/~ikepanhc/DSDTs]
> 
> Looks more fixed than on my S12, indeed.
> I don't really speak AML, but while S10-3 ILDD (called from _CFG) seems
> to read fixed values only, here on S12 PHSR (called from _CFG) seems to
> do some kind of I/O operation. I'm not sure about this, but it somehow
> looks like.
> 
It accesses something in system memory, but I have no idea what will happen
after writing..

>> On 08/20/2010 03:31 AM, Mario 'BitKoenig' Holbe wrote:
>>> Once the cfgbit is 0xc0000 it's stable, i.e. modprobe -r ideapad-laptop;
>>> modprobe ideapad-laptop doesn't change anything.
>> sounds like we need an exception handle for detecting camera
> 
> Why? The camera is always detected - bit 19 is always set, 0xc0000 and
> 0xd0000 only differ in bit 16. Bit 19 btw. seems to be the only fixed
> bit in S12-VIA _CFG :)
> 
That's my misunderstanding.

>>> [  682.260288] ideapad_acpi_add(): cfg=0xc0000
>> As I know the cfgbit for lower 16bit shall not be all zero.
> 
> Mh, judging from S12-VIA _CFG they definitely are zero here.
> 
>>> So, forcing the existence of the killswitch enables the bluetooth
>>> device. I'm also able to switch if off again - the bluetooth device
>>> disappears. Trying to switch it back on then fails - the bluetooth
>>> device does not appear again. But this case doesn't work all that well
>>> anyways even with cfgbit 0xd0000:
>> bluetooth device shall disappear after disable from EC. But if can not be enabled
>> again, ahh.....
> 
>>> [  155.628052] usb 4-1: new full speed USB device using uhci_hcd and address 4
>>> [  170.740049] usb 4-1: device descriptor read/64, error -110
>>> [  185.956033] usb 4-1: device descriptor read/64, error -110
>> This looks like the device is power up, but usb host unable to recognize..
> 
> The bluetooth device seems not to initialize well enough to answer (110
> is ETIMEDOUT).
> 
There are two variables need to be written for turning on/off bluetooth. They are
BTST(in memory) and BTEN(is EC register). I will guess there are some sync failed
when enable bluetooth.

>>> Sometimes it doesn't even come back at all on unblock. Seems like the
>>> bluetooth device doesn't really like to be powered off and on that way.
>> did you see any kernel message said timeout when it does not come back at all?
> 
> No, when I said "does not appear again" and "it does not come back at
> all" I meant I see not a single message in dmesg about anything
> happening.
> 
>> If the rfkill for the whole bluetooth module makes trouble, I prefer not to
>> do it. User will feel confused if the device does not come back and the
>> rfkill of hci0 offers the function user need.
> 
> Hmmm, maybe provide a module parm to block rfkill devices and default it
> to 1 on S12? Users would not need to care too much then but can change
> it if they like...
This could be a plan. I have several idea to go and need your help.
- Add some debug message to read BTST/BTEN when turning on/off bluetooth.
- Force to set BTST/BTEN before reading _CFG
- Provide a module parm to force enable rf devices.

Will have the drivers and please test it and let me know the result.

> 
>>> Please let me know if I can provide more testing - and what kind of :)
> 
> Okay, did some more...
> 
> I played with the hardware killswitch under Linux. The bluetooth device
> disappears and re-appears there and always seems to initialize
> correctly. No USB read errors this way.
> 
> I also played with the soft killswitch under Windows. The bluetooth
> device disappears from device manager and re-appears on unblock
> (together with the Windows device plug sounds). This looks to me like
> the ACPI killswitch is used for it.
> No initialization-problems here, the device always comes back fully
> operational. So, Windows doesn't seem to suffer from a bad
> initialization.
> 
> I'm not exactly sure what this means - especially because I don't know
> how the hardware killswitch works internally.
> It *could* mean, the initialization problem is proably something that
> could be dealt with in the USB layer long term (and would then probably
> not have to be worked around anymore in ideapad_laptop). I'm not sure
> about this, because this would mean the hard killswitch power-cut
> somehow differs from the soft killswitch power-cut.
Usually the hw rf switch turning off PHY only. When turning off, device and
its driver is still there. I believe S12 is designed in this way after
reading your test result.

> 
> 
> Mario

Re: [PATCH 8/8] ideapad: Change the driver name to ideapad_laptop

[Len Brown]

>  drivers/platform/x86/ideapad_acpi.c   |  381 ---------------------------------
>  drivers/platform/x86/ideapad_laptop.c |  381 +++++++++++++++++++++++++++++++++

Acked-by: Len Brown <len.brown@intel.com>

thanks,
Len Brown, Intel Open Source Technology Center

Re: [PATCH 8/8] ideapad: Change the driver name to ideapad_laptop

[Corentin Chary]

On Wed, Aug 25, 2010 at 10:56 PM, Len Brown <lenb@kernel.org> wrote:
>>  drivers/platform/x86/ideapad_acpi.c   |  381 ---------------------------------
>>  drivers/platform/x86/ideapad_laptop.c |  381 +++++++++++++++++++++++++++++++++
>
> Acked-by: Len Brown <len.brown@intel.com>
>
> thanks,
> Len Brown, Intel Open Source Technology Center
>
> --
> 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
>

Probably not very important .. but .. other drivers are called *-laptop.c, not
*_laptop.c ..

asus-laptop.c classmate-laptop.c compal-laptop.c dell-laptop.c eeepc-laptop.c
fujitsu-laptop.c msi-laptop.c panasonic-laptop.c sony-laptop.c topstar-laptop.c

-- 
Corentin Chary
http://xf.iksaif.net
--
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

Re: [PATCH 8/8] ideapad: Change the driver name to ideapad_laptop

[Corentin Chary]

On Wed, Aug 25, 2010 at 10:56 PM, Len Brown <lenb@kernel.org> wrote:
>>  drivers/platform/x86/ideapad_acpi.c   |  381 ---------------------------------
>>  drivers/platform/x86/ideapad_laptop.c |  381 +++++++++++++++++++++++++++++++++
>
> Acked-by: Len Brown <len.brown@intel.com>
>
> thanks,
> Len Brown, Intel Open Source Technology Center
>
> --
> 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
>

Probably not very important .. but .. other drivers are called *-laptop.c, not
*_laptop.c ..

asus-laptop.c classmate-laptop.c compal-laptop.c dell-laptop.c eeepc-laptop.c
fujitsu-laptop.c msi-laptop.c panasonic-laptop.c sony-laptop.c topstar-laptop.c

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

Re: [PATCH 8/8] ideapad: Change the driver name to ideapad_laptop

[Ike Panhc]

On 08/26/2010 01:43 PM, Corentin Chary wrote:
> On Wed, Aug 25, 2010 at 10:56 PM, Len Brown <lenb@kernel.org> wrote:
>>>  drivers/platform/x86/ideapad_acpi.c   |  381 ---------------------------------
>>>  drivers/platform/x86/ideapad_laptop.c |  381 +++++++++++++++++++++++++++++++++
>>
>> Acked-by: Len Brown <len.brown@intel.com>
>>
>> thanks,
>> Len Brown, Intel Open Source Technology Center
>>
>> --
>> 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
>>
> 
> Probably not very important .. but .. other drivers are called *-laptop.c, not
> *_laptop.c ..
> 
> asus-laptop.c classmate-laptop.c compal-laptop.c dell-laptop.c eeepc-laptop.c
> fujitsu-laptop.c msi-laptop.c panasonic-laptop.c sony-laptop.c topstar-laptop.c
> 
I choose _laptop.c not -laptop.c because when modprobe. We are using
"modprobe asus-laptop", but when removing, using "modprobe asus_laptop".

Re: [PATCH 8/8] ideapad: Change the driver name to ideapad_laptop

[Corentin Chary]

On Thu, Aug 26, 2010 at 8:16 AM, Ike Panhc <ike.pan@canonical.com> wrote:
> On 08/26/2010 01:43 PM, Corentin Chary wrote:
>> On Wed, Aug 25, 2010 at 10:56 PM, Len Brown <lenb@kernel.org> wrote:
>>>>  drivers/platform/x86/ideapad_acpi.c   |  381 ---------------------------------
>>>>  drivers/platform/x86/ideapad_laptop.c |  381 +++++++++++++++++++++++++++++++++
>>>
>>> Acked-by: Len Brown <len.brown@intel.com>
>>>
>>> thanks,
>>> Len Brown, Intel Open Source Technology Center
>>>
>>> --
>>> 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
>>>
>>
>> Probably not very important .. but .. other drivers are called *-laptop.c, not
>> *_laptop.c ..
>>
>> asus-laptop.c classmate-laptop.c compal-laptop.c dell-laptop.c eeepc-laptop.c
>> fujitsu-laptop.c msi-laptop.c panasonic-laptop.c sony-laptop.c topstar-laptop.c
>>
> I choose _laptop.c not -laptop.c because when modprobe. We are using
> "modprobe asus-laptop", but when removing, using "modprobe asus_laptop".
>

Hum, that's a "bug" in asus-laptop, because I used KBUILD_MODNAME
(asus_laptop) instead
of "asus-laptop" as the driver name. And I don't know if I can change
that now without breaking
backward compatibility.

But other drivers should work (I tested sony-laptop).

-- 
Corentin Chary
http://xf.iksaif.net
--
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

Re: [PATCH 8/8] ideapad: Change the driver name to ideapad_laptop

[Corentin Chary]

On Thu, Aug 26, 2010 at 8:16 AM, Ike Panhc <ike.pan@canonical.com> wrote:
> On 08/26/2010 01:43 PM, Corentin Chary wrote:
>> On Wed, Aug 25, 2010 at 10:56 PM, Len Brown <lenb@kernel.org> wrote:
>>>>  drivers/platform/x86/ideapad_acpi.c   |  381 ---------------------------------
>>>>  drivers/platform/x86/ideapad_laptop.c |  381 +++++++++++++++++++++++++++++++++
>>>
>>> Acked-by: Len Brown <len.brown@intel.com>
>>>
>>> thanks,
>>> Len Brown, Intel Open Source Technology Center
>>>
>>> --
>>> 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
>>>
>>
>> Probably not very important .. but .. other drivers are called *-laptop.c, not
>> *_laptop.c ..
>>
>> asus-laptop.c classmate-laptop.c compal-laptop.c dell-laptop.c eeepc-laptop.c
>> fujitsu-laptop.c msi-laptop.c panasonic-laptop.c sony-laptop.c topstar-laptop.c
>>
> I choose _laptop.c not -laptop.c because when modprobe. We are using
> "modprobe asus-laptop", but when removing, using "modprobe asus_laptop".
>

Hum, that's a "bug" in asus-laptop, because I used KBUILD_MODNAME
(asus_laptop) instead
of "asus-laptop" as the driver name. And I don't know if I can change
that now without breaking
backward compatibility.

But other drivers should work (I tested sony-laptop).

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

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Mario 'BitKoenig' Holbe]

[-- Attachment #1.1: Type: text/plain, Size: 4172 bytes --]

Hello Ike,

On Wed, Aug 25, 2010 at 07:59:30PM +0800, Ike Panhc wrote:
> On 08/20/2010 05:08 PM, Mario 'BitKoenig' Holbe wrote:
> > On Fri, Aug 20, 2010 at 03:01:07PM +0800, Ike Panhc wrote:
> >> Could you attach or upload the DSDT of S12 somewhere I can reach?
> > 
> > http://sandbox.fem.tu-ilmenau.de/s12/dsdt-s12-via.dsl
> > 
> >> I check DSDT for S10-3 and B550, return value of _CFG is fixed.
> >> [Ref: http://people.ubuntu.com/~ikepanhc/DSDTs]
> > 
> > Looks more fixed than on my S12, indeed.
> > I don't really speak AML, but while S10-3 ILDD (called from _CFG) seems
> > to read fixed values only, here on S12 PHSR (called from _CFG) seems to
> > do some kind of I/O operation. I'm not sure about this, but it somehow
> > looks like.
> > 
> It accesses something in system memory, but I have no idea what will happen
> after writing..

Well, the pattern looks like I/O - mmapped I/O.
        Store (Arg1, \_SB.INF0)
        Store (Arg0, \_SB.BCMD)
        Store (Zero, \_SB.SMIC)
        Store (\_SB.INF0, Local0)

Note that INF0 is written before and read after writing SMIC. Hence,
for this to be useful, something must have happened inbetween, i.e.
I/O :)

> There are two variables need to be written for turning on/off bluetooth. They are
> BTST(in memory) and BTEN(is EC register). I will guess there are some sync failed
> when enable bluetooth.

What exactly do you mean with "there are some sync failed"? I don't see
anything like that in the logs.

> This could be a plan. I have several idea to go and need your help.
> - Add some debug message to read BTST/BTEN when turning on/off bluetooth.
> - Force to set BTST/BTEN before reading _CFG
> - Provide a module parm to force enable rf devices.
> 
> Will have the drivers and please test it and let me know the result.

Hmmm, I don't know if I got you right. I didn't find any new drivers to
test, so I tried to add some more debug code myself. Hope this helps.
I added some code to show_ideapad_cam() to be able to asynchronously
trigger reading of BTST, BTEN, and BTPS. As before: the patch attached
is not for inclusion but to show what I did. I'm usually not a kernel
hacker, so please take a serious look at what I did before trusting the
results :)

I attached a full protocol of actions I performed including kernel
dmesges. Typed commands are prepended by #, manual actions and comments
are enclosed in <>, kernel messages are timestamped, the rest is output
of the commands.
Basically I did the following:
0. I started with a fresh powered up system, all RF devices powered on.
1. I hw-switched RF off and back on, which went okay.
2. I sw-switched BT off and back on, which resulted in erroneous
initialization.
3. I again sw-switched BT off and back on, which resulted in BT being
completely gone.
4. I hw-switched RF off and back on, which brought BT back and
operational.

> > I played with the hardware killswitch under Linux. The bluetooth device
> > disappears and re-appears there and always seems to initialize
> > correctly. No USB read errors this way.
...
> > I'm not exactly sure what this means - especially because I don't know
> > how the hardware killswitch works internally.
> > It *could* mean, the initialization problem is proably something that
> > could be dealt with in the USB layer long term (and would then probably
> > not have to be worked around anymore in ideapad_laptop). I'm not sure
> > about this, because this would mean the hard killswitch power-cut
> > somehow differs from the soft killswitch power-cut.
> Usually the hw rf switch turning off PHY only. When turning off, device and
> its driver is still there. I believe S12 is designed in this way after
> reading your test result.

Hmmm, I don't understand your reasoning here.
I said the device disappears and re-appears when using the hw rf switch,
this doesn't look like it would turn off PHY only.


best regards
   Mario
-- 
We know that communication is a problem, but the company is not going to
discuss it with the employees.
                       -- Switching supervisor, AT&T Long Lines Division

[-- Attachment #1.2: ideapad_laptop.diff --]
[-- Type: text/x-diff, Size: 1696 bytes --]

--- ideapad_laptop.c.orig	2010-08-18 13:35:36.087735426 +0200
+++ ideapad_laptop.c	2010-08-30 19:05:53.116031145 +0200
@@ -170,6 +170,18 @@ static ssize_t show_ideapad_cam(struct d
 	struct ideapad_private *priv = dev_get_drvdata(dev);
 	acpi_handle handle = priv->handle;
 	unsigned long result;
+	acpi_status res;
+	u64 res64;
+
+	res = acpi_evaluate_integer(handle, "\\_SB.BTST", NULL, &res64);
+	if(!ACPI_FAILURE(res))
+		printk(KERN_INFO "BTST: 0x%llx\n", res64);
+	res = acpi_evaluate_integer(handle, "\\_SB.BTPS", NULL, &res64);
+	if(!ACPI_FAILURE(res))
+		printk(KERN_INFO "BTPS: 0x%llx\n", res64);
+	res = acpi_evaluate_integer(handle, "\\_SB.PCI0.PIB.EC0.BTEN", NULL, &res64);
+	if(!ACPI_FAILURE(res))
+		printk(KERN_INFO "BTEN: 0x%llx\n", res64);
 
 	if (read_ec_data(handle, 0x1D, &result))
 		return sprintf(buf, "-1\n");
@@ -279,11 +291,19 @@ static int ideapad_acpi_add(struct acpi_
 	if (read_method_int(adevice->handle, "_CFG", &cfg))
 		return -ENODEV;
 
+	printk(KERN_INFO "ideapad_acpi_add(): cfg=0x%x\n", cfg);
+
 	for (i = IDEAPAD_DEV_CAMERA; i < IDEAPAD_DEV_KILLSW; i++) {
-		if (test_bit(ideapad_rfk_data[i].cfgbit, (unsigned long *)&cfg))
+		if (test_bit(ideapad_rfk_data[i].cfgbit, (unsigned long *)&cfg)) {
 			devs_present[i] = 1;
-		else
-			devs_present[i] = 0;
+			printk(KERN_INFO "ideapad_acpi_add(): found: %s\n", ideapad_rfk_data[i].name);
+		} else {
+			if(ideapad_rfk_data[i].type == RFKILL_TYPE_BLUETOOTH) {
+				devs_present[i] = 1;
+				printk(KERN_INFO "ideapad_acpi_add(): forced: %s\n", ideapad_rfk_data[i].name);
+			} else
+				devs_present[i] = 0;
+		}
 	}
 
 	/* The hardware switch is always present */

[-- Attachment #1.3: protocol --]
[-- Type: text/plain, Size: 5754 bytes --]

<fresh powered up system>
# cat $(find /sys -name camera_power)
[  140.121467] BTST: 0x1
[  140.121475] BTPS: 0x1
[  140.122378] BTEN: 0x1
1
<hw killswitch off>
[  199.296090] usb 4-1: USB disconnect, address 2
[  199.296789] btusb_intr_complete: hci0 urb f6990300 failed to resubmit (19)
[  199.296808] btusb_bulk_complete: hci0 urb f6990380 failed to resubmit (19)
[  199.297789] btusb_bulk_complete: hci0 urb f6990000 failed to resubmit (19)
[  199.297991] btusb_send_frame: hci0 urb f6766200 submission failed
[  199.784704] wlan0: deauthenticating from 00:1c:f0:e4:3d:a9 by local choice (reason=3)
[  199.786981] cfg80211: Calling CRDA to update world regulatory domain
[  200.852176] b43-phy0: Radio hardware status changed to DISABLED
# cat $(find /sys -name camera_power)
[  219.129098] BTST: 0x1
[  219.129105] BTPS: 0x1
[  219.130017] BTEN: 0x1
1
<hw killswitch on>
[  257.968055] usb 4-1: new full speed USB device using uhci_hcd and address 3
[  258.141407] usb 4-1: New USB device found, idVendor=0a5c, idProduct=2150
[  258.141420] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  258.141431] usb 4-1: Product: BCM2046 Bluetooth Device
[  258.141440] usb 4-1: Manufacturer: Broadcom Corp
[  258.141448] usb 4-1: SerialNumber: 0C6076DC9FD0
[  260.852114] b43-phy0: Radio hardware status changed to ENABLED
[  261.076117] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
[  266.592252] b43-pci-bridge 0000:02:00.0: PCI: Disallowing DAC for device
[  266.592264] b43-phy0: DMA mask fallback from 64-bit to 32-bit
[  266.633509] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  269.380720] wlan0: authenticate with 00:1c:f0:e4:3d:a9 (try 1)
[  269.382273] wlan0: authenticated
[  269.382689] wlan0: associate with 00:1c:f0:e4:3d:a9 (try 1)
[  269.385522] wlan0: RX AssocResp from 00:1c:f0:e4:3d:a9 (capab=0x431 status=0 aid=1)
[  269.385534] wlan0: associated
[  269.392770] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  279.928033] wlan0: no IPv6 routers present
# cat $(find /sys -name camera_power)
[  291.431607] BTST: 0x1
[  291.431614] BTPS: 0x1
[  291.433096] BTEN: 0x1
1
# rfkill block $(rfkill list | awk -F: '/ideapad_bluetooth/{print $1}')
[  341.416077] usb 4-1: USB disconnect, address 3
[  341.416547] btusb_intr_complete: hci0 urb f6747b80 failed to resubmit (19)
[  341.416559] btusb_bulk_complete: hci0 urb f6798300 failed to resubmit (19)
[  341.417546] btusb_bulk_complete: hci0 urb f674e080 failed to resubmit (19)
[  341.417944] btusb_send_frame: hci0 urb f67e5500 submission failed
# cat $(find /sys -name camera_power)
[  364.592492] BTST: 0x0
[  364.592499] BTPS: 0x1
[  364.593586] BTEN: 0x0
1
# rfkill unblock $(rfkill list | awk -F: '/ideapad_bluetooth/{print $1}')
[  392.192070] usb 4-1: new full speed USB device using uhci_hcd and address 4
[  392.312040] usb 4-1: device descriptor read/64, error -71
[  392.536066] usb 4-1: device descriptor read/64, error -71
[  392.752073] usb 4-1: new full speed USB device using uhci_hcd and address 5
[  392.872077] usb 4-1: device descriptor read/64, error -71
[  393.096059] usb 4-1: device descriptor read/64, error -71
[  393.312043] usb 4-1: new full speed USB device using uhci_hcd and address 6
[  393.720143] usb 4-1: device not accepting address 6, error -71
[  393.832051] usb 4-1: new full speed USB device using uhci_hcd and address 7
[  394.240083] usb 4-1: device not accepting address 7, error -71
[  394.240105] hub 4-0:1.0: unable to enumerate USB device on port 1
# cat $(find /sys -name camera_power)
[  458.669365] BTST: 0x1
[  458.669372] BTPS: 0x1
[  458.670744] BTEN: 0x1
1
# rfkill block $(rfkill list | awk -F: '/ideapad_bluetooth/{print $1}')
<absolutely no messages, no errors, nothing>
# cat $(find /sys -name camera_power)
[  576.981559] BTST: 0x0
[  576.981567] BTPS: 0x1
[  576.982900] BTEN: 0x0
1
# rfkill unblock $(rfkill list | awk -F: '/ideapad_bluetooth/{print $1}')
<absolutely no messages, device does not appear, no errors, nothing>
# cat $(find /sys -name camera_power)
[  652.939495] BTST: 0x1
[  652.939503] BTPS: 0x1
[  652.941192] BTEN: 0x1
1
<hw killswitch off>
[  701.234772] wlan0: deauthenticating from 00:1c:f0:e4:3d:a9 by local choice (reason=3)
[  701.237446] cfg80211: Calling CRDA to update world regulatory domain
[  702.036108] b43-phy0: Radio hardware status changed to DISABLED
# cat $(find /sys -name camera_power)
[  722.962717] BTST: 0x1
[  722.962724] BTPS: 0x1
[  722.964822] BTEN: 0x1
1
<hw killswitch on>
[  757.028180] b43-phy0: Radio hardware status changed to ENABLED
[  757.379142] usb 4-1: new full speed USB device using uhci_hcd and address 8
[  757.432136] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
[  757.552383] usb 4-1: New USB device found, idVendor=0a5c, idProduct=2150
[  757.552396] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  757.552407] usb 4-1: Product: BCM2046 Bluetooth Device
[  757.552415] usb 4-1: Manufacturer: Broadcom Corp
[  757.552423] usb 4-1: SerialNumber: 0C6076DC9FD0
[  762.952258] b43-pci-bridge 0000:02:00.0: PCI: Disallowing DAC for device
[  762.952271] b43-phy0: DMA mask fallback from 64-bit to 32-bit
[  762.985688] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  765.728762] wlan0: authenticate with 00:1c:f0:e4:3d:a9 (try 1)
[  765.730314] wlan0: authenticated
[  765.730738] wlan0: associate with 00:1c:f0:e4:3d:a9 (try 1)
[  765.734126] wlan0: RX AssocResp from 00:1c:f0:e4:3d:a9 (capab=0x431 status=0 aid=1)
[  765.734137] wlan0: associated
[  765.738373] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  775.760029] wlan0: no IPv6 routers present
# cat $(find /sys -name camera_power)
[  797.842123] BTST: 0x1
[  797.842131] BTPS: 0x1
[  797.843030] BTEN: 0x1
1

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

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Mario 'BitKoenig' Holbe]

[-- Attachment #1.1: Type: text/plain, Size: 4172 bytes --]

Hello Ike,

On Wed, Aug 25, 2010 at 07:59:30PM +0800, Ike Panhc wrote:
> On 08/20/2010 05:08 PM, Mario 'BitKoenig' Holbe wrote:
> > On Fri, Aug 20, 2010 at 03:01:07PM +0800, Ike Panhc wrote:
> >> Could you attach or upload the DSDT of S12 somewhere I can reach?
> > 
> > http://sandbox.fem.tu-ilmenau.de/s12/dsdt-s12-via.dsl
> > 
> >> I check DSDT for S10-3 and B550, return value of _CFG is fixed.
> >> [Ref: http://people.ubuntu.com/~ikepanhc/DSDTs]
> > 
> > Looks more fixed than on my S12, indeed.
> > I don't really speak AML, but while S10-3 ILDD (called from _CFG) seems
> > to read fixed values only, here on S12 PHSR (called from _CFG) seems to
> > do some kind of I/O operation. I'm not sure about this, but it somehow
> > looks like.
> > 
> It accesses something in system memory, but I have no idea what will happen
> after writing..

Well, the pattern looks like I/O - mmapped I/O.
        Store (Arg1, \_SB.INF0)
        Store (Arg0, \_SB.BCMD)
        Store (Zero, \_SB.SMIC)
        Store (\_SB.INF0, Local0)

Note that INF0 is written before and read after writing SMIC. Hence,
for this to be useful, something must have happened inbetween, i.e.
I/O :)

> There are two variables need to be written for turning on/off bluetooth. They are
> BTST(in memory) and BTEN(is EC register). I will guess there are some sync failed
> when enable bluetooth.

What exactly do you mean with "there are some sync failed"? I don't see
anything like that in the logs.

> This could be a plan. I have several idea to go and need your help.
> - Add some debug message to read BTST/BTEN when turning on/off bluetooth.
> - Force to set BTST/BTEN before reading _CFG
> - Provide a module parm to force enable rf devices.
> 
> Will have the drivers and please test it and let me know the result.

Hmmm, I don't know if I got you right. I didn't find any new drivers to
test, so I tried to add some more debug code myself. Hope this helps.
I added some code to show_ideapad_cam() to be able to asynchronously
trigger reading of BTST, BTEN, and BTPS. As before: the patch attached
is not for inclusion but to show what I did. I'm usually not a kernel
hacker, so please take a serious look at what I did before trusting the
results :)

I attached a full protocol of actions I performed including kernel
dmesges. Typed commands are prepended by #, manual actions and comments
are enclosed in <>, kernel messages are timestamped, the rest is output
of the commands.
Basically I did the following:
0. I started with a fresh powered up system, all RF devices powered on.
1. I hw-switched RF off and back on, which went okay.
2. I sw-switched BT off and back on, which resulted in erroneous
initialization.
3. I again sw-switched BT off and back on, which resulted in BT being
completely gone.
4. I hw-switched RF off and back on, which brought BT back and
operational.

> > I played with the hardware killswitch under Linux. The bluetooth device
> > disappears and re-appears there and always seems to initialize
> > correctly. No USB read errors this way.
...
> > I'm not exactly sure what this means - especially because I don't know
> > how the hardware killswitch works internally.
> > It *could* mean, the initialization problem is proably something that
> > could be dealt with in the USB layer long term (and would then probably
> > not have to be worked around anymore in ideapad_laptop). I'm not sure
> > about this, because this would mean the hard killswitch power-cut
> > somehow differs from the soft killswitch power-cut.
> Usually the hw rf switch turning off PHY only. When turning off, device and
> its driver is still there. I believe S12 is designed in this way after
> reading your test result.

Hmmm, I don't understand your reasoning here.
I said the device disappears and re-appears when using the hw rf switch,
this doesn't look like it would turn off PHY only.


best regards
   Mario
-- 
We know that communication is a problem, but the company is not going to
discuss it with the employees.
                       -- Switching supervisor, AT&T Long Lines Division

[-- Attachment #1.2: ideapad_laptop.diff --]
[-- Type: text/x-diff, Size: 1696 bytes --]

--- ideapad_laptop.c.orig	2010-08-18 13:35:36.087735426 +0200
+++ ideapad_laptop.c	2010-08-30 19:05:53.116031145 +0200
@@ -170,6 +170,18 @@ static ssize_t show_ideapad_cam(struct d
 	struct ideapad_private *priv = dev_get_drvdata(dev);
 	acpi_handle handle = priv->handle;
 	unsigned long result;
+	acpi_status res;
+	u64 res64;
+
+	res = acpi_evaluate_integer(handle, "\\_SB.BTST", NULL, &res64);
+	if(!ACPI_FAILURE(res))
+		printk(KERN_INFO "BTST: 0x%llx\n", res64);
+	res = acpi_evaluate_integer(handle, "\\_SB.BTPS", NULL, &res64);
+	if(!ACPI_FAILURE(res))
+		printk(KERN_INFO "BTPS: 0x%llx\n", res64);
+	res = acpi_evaluate_integer(handle, "\\_SB.PCI0.PIB.EC0.BTEN", NULL, &res64);
+	if(!ACPI_FAILURE(res))
+		printk(KERN_INFO "BTEN: 0x%llx\n", res64);
 
 	if (read_ec_data(handle, 0x1D, &result))
 		return sprintf(buf, "-1\n");
@@ -279,11 +291,19 @@ static int ideapad_acpi_add(struct acpi_
 	if (read_method_int(adevice->handle, "_CFG", &cfg))
 		return -ENODEV;
 
+	printk(KERN_INFO "ideapad_acpi_add(): cfg=0x%x\n", cfg);
+
 	for (i = IDEAPAD_DEV_CAMERA; i < IDEAPAD_DEV_KILLSW; i++) {
-		if (test_bit(ideapad_rfk_data[i].cfgbit, (unsigned long *)&cfg))
+		if (test_bit(ideapad_rfk_data[i].cfgbit, (unsigned long *)&cfg)) {
 			devs_present[i] = 1;
-		else
-			devs_present[i] = 0;
+			printk(KERN_INFO "ideapad_acpi_add(): found: %s\n", ideapad_rfk_data[i].name);
+		} else {
+			if(ideapad_rfk_data[i].type == RFKILL_TYPE_BLUETOOTH) {
+				devs_present[i] = 1;
+				printk(KERN_INFO "ideapad_acpi_add(): forced: %s\n", ideapad_rfk_data[i].name);
+			} else
+				devs_present[i] = 0;
+		}
 	}
 
 	/* The hardware switch is always present */

[-- Attachment #1.3: protocol --]
[-- Type: text/plain, Size: 5754 bytes --]

<fresh powered up system>
# cat $(find /sys -name camera_power)
[  140.121467] BTST: 0x1
[  140.121475] BTPS: 0x1
[  140.122378] BTEN: 0x1
1
<hw killswitch off>
[  199.296090] usb 4-1: USB disconnect, address 2
[  199.296789] btusb_intr_complete: hci0 urb f6990300 failed to resubmit (19)
[  199.296808] btusb_bulk_complete: hci0 urb f6990380 failed to resubmit (19)
[  199.297789] btusb_bulk_complete: hci0 urb f6990000 failed to resubmit (19)
[  199.297991] btusb_send_frame: hci0 urb f6766200 submission failed
[  199.784704] wlan0: deauthenticating from 00:1c:f0:e4:3d:a9 by local choice (reason=3)
[  199.786981] cfg80211: Calling CRDA to update world regulatory domain
[  200.852176] b43-phy0: Radio hardware status changed to DISABLED
# cat $(find /sys -name camera_power)
[  219.129098] BTST: 0x1
[  219.129105] BTPS: 0x1
[  219.130017] BTEN: 0x1
1
<hw killswitch on>
[  257.968055] usb 4-1: new full speed USB device using uhci_hcd and address 3
[  258.141407] usb 4-1: New USB device found, idVendor=0a5c, idProduct=2150
[  258.141420] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  258.141431] usb 4-1: Product: BCM2046 Bluetooth Device
[  258.141440] usb 4-1: Manufacturer: Broadcom Corp
[  258.141448] usb 4-1: SerialNumber: 0C6076DC9FD0
[  260.852114] b43-phy0: Radio hardware status changed to ENABLED
[  261.076117] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
[  266.592252] b43-pci-bridge 0000:02:00.0: PCI: Disallowing DAC for device
[  266.592264] b43-phy0: DMA mask fallback from 64-bit to 32-bit
[  266.633509] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  269.380720] wlan0: authenticate with 00:1c:f0:e4:3d:a9 (try 1)
[  269.382273] wlan0: authenticated
[  269.382689] wlan0: associate with 00:1c:f0:e4:3d:a9 (try 1)
[  269.385522] wlan0: RX AssocResp from 00:1c:f0:e4:3d:a9 (capab=0x431 status=0 aid=1)
[  269.385534] wlan0: associated
[  269.392770] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  279.928033] wlan0: no IPv6 routers present
# cat $(find /sys -name camera_power)
[  291.431607] BTST: 0x1
[  291.431614] BTPS: 0x1
[  291.433096] BTEN: 0x1
1
# rfkill block $(rfkill list | awk -F: '/ideapad_bluetooth/{print $1}')
[  341.416077] usb 4-1: USB disconnect, address 3
[  341.416547] btusb_intr_complete: hci0 urb f6747b80 failed to resubmit (19)
[  341.416559] btusb_bulk_complete: hci0 urb f6798300 failed to resubmit (19)
[  341.417546] btusb_bulk_complete: hci0 urb f674e080 failed to resubmit (19)
[  341.417944] btusb_send_frame: hci0 urb f67e5500 submission failed
# cat $(find /sys -name camera_power)
[  364.592492] BTST: 0x0
[  364.592499] BTPS: 0x1
[  364.593586] BTEN: 0x0
1
# rfkill unblock $(rfkill list | awk -F: '/ideapad_bluetooth/{print $1}')
[  392.192070] usb 4-1: new full speed USB device using uhci_hcd and address 4
[  392.312040] usb 4-1: device descriptor read/64, error -71
[  392.536066] usb 4-1: device descriptor read/64, error -71
[  392.752073] usb 4-1: new full speed USB device using uhci_hcd and address 5
[  392.872077] usb 4-1: device descriptor read/64, error -71
[  393.096059] usb 4-1: device descriptor read/64, error -71
[  393.312043] usb 4-1: new full speed USB device using uhci_hcd and address 6
[  393.720143] usb 4-1: device not accepting address 6, error -71
[  393.832051] usb 4-1: new full speed USB device using uhci_hcd and address 7
[  394.240083] usb 4-1: device not accepting address 7, error -71
[  394.240105] hub 4-0:1.0: unable to enumerate USB device on port 1
# cat $(find /sys -name camera_power)
[  458.669365] BTST: 0x1
[  458.669372] BTPS: 0x1
[  458.670744] BTEN: 0x1
1
# rfkill block $(rfkill list | awk -F: '/ideapad_bluetooth/{print $1}')
<absolutely no messages, no errors, nothing>
# cat $(find /sys -name camera_power)
[  576.981559] BTST: 0x0
[  576.981567] BTPS: 0x1
[  576.982900] BTEN: 0x0
1
# rfkill unblock $(rfkill list | awk -F: '/ideapad_bluetooth/{print $1}')
<absolutely no messages, device does not appear, no errors, nothing>
# cat $(find /sys -name camera_power)
[  652.939495] BTST: 0x1
[  652.939503] BTPS: 0x1
[  652.941192] BTEN: 0x1
1
<hw killswitch off>
[  701.234772] wlan0: deauthenticating from 00:1c:f0:e4:3d:a9 by local choice (reason=3)
[  701.237446] cfg80211: Calling CRDA to update world regulatory domain
[  702.036108] b43-phy0: Radio hardware status changed to DISABLED
# cat $(find /sys -name camera_power)
[  722.962717] BTST: 0x1
[  722.962724] BTPS: 0x1
[  722.964822] BTEN: 0x1
1
<hw killswitch on>
[  757.028180] b43-phy0: Radio hardware status changed to ENABLED
[  757.379142] usb 4-1: new full speed USB device using uhci_hcd and address 8
[  757.432136] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
[  757.552383] usb 4-1: New USB device found, idVendor=0a5c, idProduct=2150
[  757.552396] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  757.552407] usb 4-1: Product: BCM2046 Bluetooth Device
[  757.552415] usb 4-1: Manufacturer: Broadcom Corp
[  757.552423] usb 4-1: SerialNumber: 0C6076DC9FD0
[  762.952258] b43-pci-bridge 0000:02:00.0: PCI: Disallowing DAC for device
[  762.952271] b43-phy0: DMA mask fallback from 64-bit to 32-bit
[  762.985688] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  765.728762] wlan0: authenticate with 00:1c:f0:e4:3d:a9 (try 1)
[  765.730314] wlan0: authenticated
[  765.730738] wlan0: associate with 00:1c:f0:e4:3d:a9 (try 1)
[  765.734126] wlan0: RX AssocResp from 00:1c:f0:e4:3d:a9 (capab=0x431 status=0 aid=1)
[  765.734137] wlan0: associated
[  765.738373] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  775.760029] wlan0: no IPv6 routers present
# cat $(find /sys -name camera_power)
[  797.842123] BTST: 0x1
[  797.842131] BTPS: 0x1
[  797.843030] BTEN: 0x1
1

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

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Ike Panhc]

On 08/31/2010 02:19 AM, Mario 'BitKoenig' Holbe wrote:
> Hello Ike,
> 
> On Wed, Aug 25, 2010 at 07:59:30PM +0800, Ike Panhc wrote:
>> On 08/20/2010 05:08 PM, Mario 'BitKoenig' Holbe wrote:
>>> On Fri, Aug 20, 2010 at 03:01:07PM +0800, Ike Panhc wrote:
>>>> Could you attach or upload the DSDT of S12 somewhere I can reach?
>>>
>>> http://sandbox.fem.tu-ilmenau.de/s12/dsdt-s12-via.dsl
>>>
>>>> I check DSDT for S10-3 and B550, return value of _CFG is fixed.
>>>> [Ref: http://people.ubuntu.com/~ikepanhc/DSDTs]
>>>
>>> Looks more fixed than on my S12, indeed.
>>> I don't really speak AML, but while S10-3 ILDD (called from _CFG) seems
>>> to read fixed values only, here on S12 PHSR (called from _CFG) seems to
>>> do some kind of I/O operation. I'm not sure about this, but it somehow
>>> looks like.
>>>
>> It accesses something in system memory, but I have no idea what will happen
>> after writing..
> 
> Well, the pattern looks like I/O - mmapped I/O.
>         Store (Arg1, \_SB.INF0)
>         Store (Arg0, \_SB.BCMD)
>         Store (Zero, \_SB.SMIC)
>         Store (\_SB.INF0, Local0)
> 
> Note that INF0 is written before and read after writing SMIC. Hence,
> for this to be useful, something must have happened inbetween, i.e.
> I/O :)
> 
Yes, I have the same feeling. The problem is that I have no idea what happen after
writing.

>> There are two variables need to be written for turning on/off bluetooth. They are
>> BTST(in memory) and BTEN(is EC register). I will guess there are some sync failed
>> when enable bluetooth.
> 
> What exactly do you mean with "there are some sync failed"? I don't see
> anything like that in the logs.
> 
Oh, maybe I choose wrong word. Usually after some I/O writing, we have to wait for
some signal or time to make sure device complete operation. But it seems reading
right after writing. This is not important, just some nagging..

>> This could be a plan. I have several idea to go and need your help.
>> - Add some debug message to read BTST/BTEN when turning on/off bluetooth.
>> - Force to set BTST/BTEN before reading _CFG
>> - Provide a module parm to force enable rf devices.
>>
>> Will have the drivers and please test it and let me know the result.
> 
> Hmmm, I don't know if I got you right. I didn't find any new drivers to
> test, so I tried to add some more debug code myself. Hope this helps.
> I added some code to show_ideapad_cam() to be able to asynchronously
> trigger reading of BTST, BTEN, and BTPS. As before: the patch attached
> is not for inclusion but to show what I did. I'm usually not a kernel
> hacker, so please take a serious look at what I did before trusting the
> results :)
Sorry, I took some day off for a rest. And thank you, you did exactly
what I plan to do. From your log the values of BTST/BTEN match what it
shall be.

> 
> I attached a full protocol of actions I performed including kernel
> dmesges. Typed commands are prepended by #, manual actions and comments
> are enclosed in <>, kernel messages are timestamped, the rest is output
> of the commands.
> Basically I did the following:
> 0. I started with a fresh powered up system, all RF devices powered on.
> 1. I hw-switched RF off and back on, which went okay.
> 2. I sw-switched BT off and back on, which resulted in erroneous
> initialization.
> 3. I again sw-switched BT off and back on, which resulted in BT being
> completely gone.
> 4. I hw-switched RF off and back on, which brought BT back and
> operational.
Your log tells a lot. It tells me if the bluetooth init failed. Then we
have to turning off and power on again by hw switch to make it alive again.

So, I believe we have two issue here.
* when rfkill unblock, sometimes bluetooth init failed.
* power up system after rfkill block bluetooth, sometimes the cfgbit = 0xc0000
Am I correct?

> 
>>> I played with the hardware killswitch under Linux. The bluetooth device
>>> disappears and re-appears there and always seems to initialize
>>> correctly. No USB read errors this way.
> ...
>>> I'm not exactly sure what this means - especially because I don't know
>>> how the hardware killswitch works internally.
>>> It *could* mean, the initialization problem is proably something that
>>> could be dealt with in the USB layer long term (and would then probably
>>> not have to be worked around anymore in ideapad_laptop). I'm not sure
>>> about this, because this would mean the hard killswitch power-cut
>>> somehow differs from the soft killswitch power-cut.
>> Usually the hw rf switch turning off PHY only. When turning off, device and
>> its driver is still there. I believe S12 is designed in this way after
>> reading your test result.
> 
> Hmmm, I don't understand your reasoning here.
> I said the device disappears and re-appears when using the hw rf switch,
> this doesn't look like it would turn off PHY only.
I saw the USB disconnect in your log. You are right, the hw rf switch power
down the whole module.

Just check with B550, the hw rf switch power down the whole bluetooth, but
only turn off PHY for wifi. Looks like I can not take design for bluetooth
and wifi are the same. Thanks for let me check it again.

> 
> 
> best regards
>    Mario

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Ike Panhc]

On 08/31/2010 02:19 AM, Mario 'BitKoenig' Holbe wrote:
> Hello Ike,
> 
> On Wed, Aug 25, 2010 at 07:59:30PM +0800, Ike Panhc wrote:
>> On 08/20/2010 05:08 PM, Mario 'BitKoenig' Holbe wrote:
>>> On Fri, Aug 20, 2010 at 03:01:07PM +0800, Ike Panhc wrote:
>>>> Could you attach or upload the DSDT of S12 somewhere I can reach?
>>>
>>> http://sandbox.fem.tu-ilmenau.de/s12/dsdt-s12-via.dsl
>>>
>>>> I check DSDT for S10-3 and B550, return value of _CFG is fixed.
>>>> [Ref: http://people.ubuntu.com/~ikepanhc/DSDTs]
>>>
>>> Looks more fixed than on my S12, indeed.
>>> I don't really speak AML, but while S10-3 ILDD (called from _CFG) seems
>>> to read fixed values only, here on S12 PHSR (called from _CFG) seems to
>>> do some kind of I/O operation. I'm not sure about this, but it somehow
>>> looks like.
>>>
>> It accesses something in system memory, but I have no idea what will happen
>> after writing..
> 
> Well, the pattern looks like I/O - mmapped I/O.
>         Store (Arg1, \_SB.INF0)
>         Store (Arg0, \_SB.BCMD)
>         Store (Zero, \_SB.SMIC)
>         Store (\_SB.INF0, Local0)
> 
> Note that INF0 is written before and read after writing SMIC. Hence,
> for this to be useful, something must have happened inbetween, i.e.
> I/O :)
> 
Yes, I have the same feeling. The problem is that I have no idea what happen after
writing.

>> There are two variables need to be written for turning on/off bluetooth. They are
>> BTST(in memory) and BTEN(is EC register). I will guess there are some sync failed
>> when enable bluetooth.
> 
> What exactly do you mean with "there are some sync failed"? I don't see
> anything like that in the logs.
> 
Oh, maybe I choose wrong word. Usually after some I/O writing, we have to wait for
some signal or time to make sure device complete operation. But it seems reading
right after writing. This is not important, just some nagging..

>> This could be a plan. I have several idea to go and need your help.
>> - Add some debug message to read BTST/BTEN when turning on/off bluetooth.
>> - Force to set BTST/BTEN before reading _CFG
>> - Provide a module parm to force enable rf devices.
>>
>> Will have the drivers and please test it and let me know the result.
> 
> Hmmm, I don't know if I got you right. I didn't find any new drivers to
> test, so I tried to add some more debug code myself. Hope this helps.
> I added some code to show_ideapad_cam() to be able to asynchronously
> trigger reading of BTST, BTEN, and BTPS. As before: the patch attached
> is not for inclusion but to show what I did. I'm usually not a kernel
> hacker, so please take a serious look at what I did before trusting the
> results :)
Sorry, I took some day off for a rest. And thank you, you did exactly
what I plan to do. From your log the values of BTST/BTEN match what it
shall be.

> 
> I attached a full protocol of actions I performed including kernel
> dmesges. Typed commands are prepended by #, manual actions and comments
> are enclosed in <>, kernel messages are timestamped, the rest is output
> of the commands.
> Basically I did the following:
> 0. I started with a fresh powered up system, all RF devices powered on.
> 1. I hw-switched RF off and back on, which went okay.
> 2. I sw-switched BT off and back on, which resulted in erroneous
> initialization.
> 3. I again sw-switched BT off and back on, which resulted in BT being
> completely gone.
> 4. I hw-switched RF off and back on, which brought BT back and
> operational.
Your log tells a lot. It tells me if the bluetooth init failed. Then we
have to turning off and power on again by hw switch to make it alive again.

So, I believe we have two issue here.
* when rfkill unblock, sometimes bluetooth init failed.
* power up system after rfkill block bluetooth, sometimes the cfgbit = 0xc0000
Am I correct?

> 
>>> I played with the hardware killswitch under Linux. The bluetooth device
>>> disappears and re-appears there and always seems to initialize
>>> correctly. No USB read errors this way.
> ...
>>> I'm not exactly sure what this means - especially because I don't know
>>> how the hardware killswitch works internally.
>>> It *could* mean, the initialization problem is proably something that
>>> could be dealt with in the USB layer long term (and would then probably
>>> not have to be worked around anymore in ideapad_laptop). I'm not sure
>>> about this, because this would mean the hard killswitch power-cut
>>> somehow differs from the soft killswitch power-cut.
>> Usually the hw rf switch turning off PHY only. When turning off, device and
>> its driver is still there. I believe S12 is designed in this way after
>> reading your test result.
> 
> Hmmm, I don't understand your reasoning here.
> I said the device disappears and re-appears when using the hw rf switch,
> this doesn't look like it would turn off PHY only.
I saw the USB disconnect in your log. You are right, the hw rf switch power
down the whole module.

Just check with B550, the hw rf switch power down the whole bluetooth, but
only turn off PHY for wifi. Looks like I can not take design for bluetooth
and wifi are the same. Thanks for let me check it again.

> 
> 
> best regards
>    Mario

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Ike Panhc]

On 08/31/2010 02:19 AM, Mario 'BitKoenig' Holbe wrote:
> Hello Ike,
> 
> On Wed, Aug 25, 2010 at 07:59:30PM +0800, Ike Panhc wrote:
>> On 08/20/2010 05:08 PM, Mario 'BitKoenig' Holbe wrote:
>>> On Fri, Aug 20, 2010 at 03:01:07PM +0800, Ike Panhc wrote:
>>>> Could you attach or upload the DSDT of S12 somewhere I can reach?
>>>
>>> http://sandbox.fem.tu-ilmenau.de/s12/dsdt-s12-via.dsl
>>>
>>>> I check DSDT for S10-3 and B550, return value of _CFG is fixed.
>>>> [Ref: http://people.ubuntu.com/~ikepanhc/DSDTs]
>>>
>>> Looks more fixed than on my S12, indeed.
>>> I don't really speak AML, but while S10-3 ILDD (called from _CFG) seems
>>> to read fixed values only, here on S12 PHSR (called from _CFG) seems to
>>> do some kind of I/O operation. I'm not sure about this, but it somehow
>>> looks like.
>>>
>> It accesses something in system memory, but I have no idea what will happen
>> after writing..
> 
> Well, the pattern looks like I/O - mmapped I/O.
>         Store (Arg1, \_SB.INF0)
>         Store (Arg0, \_SB.BCMD)
>         Store (Zero, \_SB.SMIC)
>         Store (\_SB.INF0, Local0)
> 
> Note that INF0 is written before and read after writing SMIC. Hence,
> for this to be useful, something must have happened inbetween, i.e.
> I/O :)
> 
Yes, I have the same feeling. The problem is that I have no idea what happen after
writing.

>> There are two variables need to be written for turning on/off bluetooth. They are
>> BTST(in memory) and BTEN(is EC register). I will guess there are some sync failed
>> when enable bluetooth.
> 
> What exactly do you mean with "there are some sync failed"? I don't see
> anything like that in the logs.
> 
Oh, maybe I choose wrong word. Usually after some I/O writing, we have to wait for
some signal or time to make sure device complete operation. But it seems reading
right after writing. This is not important, just some nagging..

>> This could be a plan. I have several idea to go and need your help.
>> - Add some debug message to read BTST/BTEN when turning on/off bluetooth.
>> - Force to set BTST/BTEN before reading _CFG
>> - Provide a module parm to force enable rf devices.
>>
>> Will have the drivers and please test it and let me know the result.
> 
> Hmmm, I don't know if I got you right. I didn't find any new drivers to
> test, so I tried to add some more debug code myself. Hope this helps.
> I added some code to show_ideapad_cam() to be able to asynchronously
> trigger reading of BTST, BTEN, and BTPS. As before: the patch attached
> is not for inclusion but to show what I did. I'm usually not a kernel
> hacker, so please take a serious look at what I did before trusting the
> results :)
Sorry, I took some day off for a rest. And thank you, you did exactly
what I plan to do. From your log the values of BTST/BTEN match what it
shall be.

> 
> I attached a full protocol of actions I performed including kernel
> dmesges. Typed commands are prepended by #, manual actions and comments
> are enclosed in <>, kernel messages are timestamped, the rest is output
> of the commands.
> Basically I did the following:
> 0. I started with a fresh powered up system, all RF devices powered on.
> 1. I hw-switched RF off and back on, which went okay.
> 2. I sw-switched BT off and back on, which resulted in erroneous
> initialization.
> 3. I again sw-switched BT off and back on, which resulted in BT being
> completely gone.
> 4. I hw-switched RF off and back on, which brought BT back and
> operational.
Your log tells a lot. It tells me if the bluetooth init failed. Then we
have to turning off and power on again by hw switch to make it alive again.

So, I believe we have two issue here.
* when rfkill unblock, sometimes bluetooth init failed.
* power up system after rfkill block bluetooth, sometimes the cfgbit = 0xc0000
Am I correct?

> 
>>> I played with the hardware killswitch under Linux. The bluetooth device
>>> disappears and re-appears there and always seems to initialize
>>> correctly. No USB read errors this way.
> ...
>>> I'm not exactly sure what this means - especially because I don't know
>>> how the hardware killswitch works internally.
>>> It *could* mean, the initialization problem is proably something that
>>> could be dealt with in the USB layer long term (and would then probably
>>> not have to be worked around anymore in ideapad_laptop). I'm not sure
>>> about this, because this would mean the hard killswitch power-cut
>>> somehow differs from the soft killswitch power-cut.
>> Usually the hw rf switch turning off PHY only. When turning off, device and
>> its driver is still there. I believe S12 is designed in this way after
>> reading your test result.
> 
> Hmmm, I don't understand your reasoning here.
> I said the device disappears and re-appears when using the hw rf switch,
> this doesn't look like it would turn off PHY only.
I saw the USB disconnect in your log. You are right, the hw rf switch power
down the whole module.

Just check with B550, the hw rf switch power down the whole bluetooth, but
only turn off PHY for wifi. Looks like I can not take design for bluetooth
and wifi are the same. Thanks for let me check it again.

> 
> 
> best regards
>    Mario

Re: [PATCH 8/8] ideapad: Change the driver name to ideapad_laptop

[Ike Panhc]

On 08/26/2010 03:43 PM, Corentin Chary wrote:
> On Thu, Aug 26, 2010 at 8:16 AM, Ike Panhc <ike.pan@canonical.com> wrote:
>> On 08/26/2010 01:43 PM, Corentin Chary wrote:
>>> On Wed, Aug 25, 2010 at 10:56 PM, Len Brown <lenb@kernel.org> wrote:
>>>>>  drivers/platform/x86/ideapad_acpi.c   |  381 ---------------------------------
>>>>>  drivers/platform/x86/ideapad_laptop.c |  381 +++++++++++++++++++++++++++++++++
>>>>
>>>> Acked-by: Len Brown <len.brown@intel.com>
>>>>
>>>> thanks,
>>>> Len Brown, Intel Open Source Technology Center
>>>>
>>>> --
>>>> 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
>>>>
>>>
>>> Probably not very important .. but .. other drivers are called *-laptop.c, not
>>> *_laptop.c ..
>>>
>>> asus-laptop.c classmate-laptop.c compal-laptop.c dell-laptop.c eeepc-laptop.c
>>> fujitsu-laptop.c msi-laptop.c panasonic-laptop.c sony-laptop.c topstar-laptop.c
>>>
>> I choose _laptop.c not -laptop.c because when modprobe. We are using
>> "modprobe asus-laptop", but when removing, using "modprobe asus_laptop".
>>
> 
> Hum, that's a "bug" in asus-laptop, because I used KBUILD_MODNAME
> (asus_laptop) instead
> of "asus-laptop" as the driver name. And I don't know if I can change
> that now without breaking
> backward compatibility.
> 
> But other drivers should work (I tested sony-laptop).
> 
Looks like I have some misunderstanding on this. Thank you for correcting it.
When I resend patches, I will change the name to *-laptop. :)

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Mario 'BitKoenig' Holbe]

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

On Wed, Sep 01, 2010 at 07:49:52PM +0800, Ike Panhc wrote:
> Your log tells a lot. It tells me if the bluetooth init failed. Then we
> have to turning off and power on again by hw switch to make it alive again.
> 
> So, I believe we have two issue here.
> * when rfkill unblock, sometimes bluetooth init failed.

Yes.

> * power up system after rfkill block bluetooth, sometimes the cfgbit = 0xc0000
> Am I correct?

Not completely.

* reboot system after rfkill block bluetooth, sometimes the cfgbit = 0xc0000

I never had cfgbit = 0xc0000 when I power-cycled the system, only when I
rebooted it.
This is why I belive the second point has virtually the same reason as
the first point: bluetooth device initialization fails and thus its
detection by BIOS fails and thus ACPI returns 0xc0000 cfg.
Hence, I belive chances are high that solving the first point does also
solve the second.

While thinking about it... the init problems persisting a reboot could
also mean that not the unblock operation is the real issue but the block
operation - which probably leaves the bluetooth device in kind of a
semi-disabled state or something like that.


regards
   Mario
-- 
Do I contradict myself?
Very well, then I contradict myself, I am large, I contain multitudes.
                                                       -- Walt Whitman

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

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Mario 'BitKoenig' Holbe]

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

On Wed, Sep 01, 2010 at 07:49:52PM +0800, Ike Panhc wrote:
> Your log tells a lot. It tells me if the bluetooth init failed. Then we
> have to turning off and power on again by hw switch to make it alive again.
> 
> So, I believe we have two issue here.
> * when rfkill unblock, sometimes bluetooth init failed.

Yes.

> * power up system after rfkill block bluetooth, sometimes the cfgbit = 0xc0000
> Am I correct?

Not completely.

* reboot system after rfkill block bluetooth, sometimes the cfgbit = 0xc0000

I never had cfgbit = 0xc0000 when I power-cycled the system, only when I
rebooted it.
This is why I belive the second point has virtually the same reason as
the first point: bluetooth device initialization fails and thus its
detection by BIOS fails and thus ACPI returns 0xc0000 cfg.
Hence, I belive chances are high that solving the first point does also
solve the second.

While thinking about it... the init problems persisting a reboot could
also mean that not the unblock operation is the real issue but the block
operation - which probably leaves the bluetooth device in kind of a
semi-disabled state or something like that.


regards
   Mario
-- 
Do I contradict myself?
Very well, then I contradict myself, I am large, I contain multitudes.
                                                       -- Walt Whitman

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

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Ike Panhc]

Hi Mario,

I look at the DSDT again and again but unfortunately can not find anything
may cause the bluetooth device initial failed. BTEN looks like the switch
for EC to turn on/off bluetooth, BTST records the status of BTEN and BTPS
means bluetooth present. But no idea why initial failed after BTEN=1

So I fall back to your suggestion. Have a module parameter to tell module
not to register rfkill for bluetooth.

I prepare the driver and please spend some time testing. Driver is at

http://kernel.ubuntu.com/git?p=ikepanhc/ideapad-laptop.git;a=blob;f=drivers/platform/x86/ideapad-laptop.c;h=c4cf46a363f3f72d6db5339ec326d282d7e58183;hb=26a58948693b7d25960299a8025e569e68f28937

and you may use "insmod ideapad-laptop.ko no_bt_rfkill=1" for your S12.

For more information, please see the following link:

http://kernel.ubuntu.com/git?p=ikepanhc/ideapad-laptop.git;a=commit;h=26a58948693b7d25960299a8025e569e68f28937

On 09/02/2010 03:56 AM, Mario 'BitKoenig' Holbe wrote:
> On Wed, Sep 01, 2010 at 07:49:52PM +0800, Ike Panhc wrote:
>> Your log tells a lot. It tells me if the bluetooth init failed. Then we
>> have to turning off and power on again by hw switch to make it alive again.
>>
>> So, I believe we have two issue here.
>> * when rfkill unblock, sometimes bluetooth init failed.
> 
> Yes.
> 
>> * power up system after rfkill block bluetooth, sometimes the cfgbit = 0xc0000
>> Am I correct?
> 
> Not completely.
> 
> * reboot system after rfkill block bluetooth, sometimes the cfgbit = 0xc0000
> 
> I never had cfgbit = 0xc0000 when I power-cycled the system, only when I
> rebooted it.
> This is why I belive the second point has virtually the same reason as
> the first point: bluetooth device initialization fails and thus its
> detection by BIOS fails and thus ACPI returns 0xc0000 cfg.
> Hence, I belive chances are high that solving the first point does also
> solve the second.
> 
> While thinking about it... the init problems persisting a reboot could
> also mean that not the unblock operation is the real issue but the block
> operation - which probably leaves the bluetooth device in kind of a
> semi-disabled state or something like that.
> 
> 
> regards
>    Mario

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Ike Panhc]

Hi Mario,

I look at the DSDT again and again but unfortunately can not find anything
may cause the bluetooth device initial failed. BTEN looks like the switch
for EC to turn on/off bluetooth, BTST records the status of BTEN and BTPS
means bluetooth present. But no idea why initial failed after BTEN=1

So I fall back to your suggestion. Have a module parameter to tell module
not to register rfkill for bluetooth.

I prepare the driver and please spend some time testing. Driver is at

http://kernel.ubuntu.com/git?p=ikepanhc/ideapad-laptop.git;a=blob;f=drivers/platform/x86/ideapad-laptop.c;h=c4cf46a363f3f72d6db5339ec326d282d7e58183;hb=26a58948693b7d25960299a8025e569e68f28937

and you may use "insmod ideapad-laptop.ko no_bt_rfkill=1" for your S12.

For more information, please see the following link:

http://kernel.ubuntu.com/git?p=ikepanhc/ideapad-laptop.git;a=commit;h=26a58948693b7d25960299a8025e569e68f28937

On 09/02/2010 03:56 AM, Mario 'BitKoenig' Holbe wrote:
> On Wed, Sep 01, 2010 at 07:49:52PM +0800, Ike Panhc wrote:
>> Your log tells a lot. It tells me if the bluetooth init failed. Then we
>> have to turning off and power on again by hw switch to make it alive again.
>>
>> So, I believe we have two issue here.
>> * when rfkill unblock, sometimes bluetooth init failed.
> 
> Yes.
> 
>> * power up system after rfkill block bluetooth, sometimes the cfgbit = 0xc0000
>> Am I correct?
> 
> Not completely.
> 
> * reboot system after rfkill block bluetooth, sometimes the cfgbit = 0xc0000
> 
> I never had cfgbit = 0xc0000 when I power-cycled the system, only when I
> rebooted it.
> This is why I belive the second point has virtually the same reason as
> the first point: bluetooth device initialization fails and thus its
> detection by BIOS fails and thus ACPI returns 0xc0000 cfg.
> Hence, I belive chances are high that solving the first point does also
> solve the second.
> 
> While thinking about it... the init problems persisting a reboot could
> also mean that not the unblock operation is the real issue but the block
> operation - which probably leaves the bluetooth device in kind of a
> semi-disabled state or something like that.
> 
> 
> regards
>    Mario

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Ike Panhc]

Hi Mario,

I look at the DSDT again and again but unfortunately can not find anything
may cause the bluetooth device initial failed. BTEN looks like the switch
for EC to turn on/off bluetooth, BTST records the status of BTEN and BTPS
means bluetooth present. But no idea why initial failed after BTEN=1

So I fall back to your suggestion. Have a module parameter to tell module
not to register rfkill for bluetooth.

I prepare the driver and please spend some time testing. Driver is at

http://kernel.ubuntu.com/git?p=ikepanhc/ideapad-laptop.git;a=blob;f=drivers/platform/x86/ideapad-laptop.c;h=c4cf46a363f3f72d6db5339ec326d282d7e58183;hb=26a58948693b7d25960299a8025e569e68f28937

and you may use "insmod ideapad-laptop.ko no_bt_rfkill=1" for your S12.

For more information, please see the following link:

http://kernel.ubuntu.com/git?p=ikepanhc/ideapad-laptop.git;a=commit;h=26a58948693b7d25960299a8025e569e68f28937

On 09/02/2010 03:56 AM, Mario 'BitKoenig' Holbe wrote:
> On Wed, Sep 01, 2010 at 07:49:52PM +0800, Ike Panhc wrote:
>> Your log tells a lot. It tells me if the bluetooth init failed. Then we
>> have to turning off and power on again by hw switch to make it alive again.
>>
>> So, I believe we have two issue here.
>> * when rfkill unblock, sometimes bluetooth init failed.
> 
> Yes.
> 
>> * power up system after rfkill block bluetooth, sometimes the cfgbit = 0xc0000
>> Am I correct?
> 
> Not completely.
> 
> * reboot system after rfkill block bluetooth, sometimes the cfgbit = 0xc0000
> 
> I never had cfgbit = 0xc0000 when I power-cycled the system, only when I
> rebooted it.
> This is why I belive the second point has virtually the same reason as
> the first point: bluetooth device initialization fails and thus its
> detection by BIOS fails and thus ACPI returns 0xc0000 cfg.
> Hence, I belive chances are high that solving the first point does also
> solve the second.
> 
> While thinking about it... the init problems persisting a reboot could
> also mean that not the unblock operation is the real issue but the block
> operation - which probably leaves the bluetooth device in kind of a
> semi-disabled state or something like that.
> 
> 
> regards
>    Mario

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Mario 'BitKoenig' Holbe]

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

On Fri, Sep 03, 2010 at 05:06:09PM +0800, Ike Panhc wrote:
> I look at the DSDT again and again but unfortunately can not find anything
> may cause the bluetooth device initial failed. BTEN looks like the switch
> for EC to turn on/off bluetooth, BTST records the status of BTEN and BTPS
> means bluetooth present. But no idea why initial failed after BTEN=1

Is there some way to trace ACPI calls under Windows (XP Home)?
I could then have a look at what happens when I Fn-F5 BT off.

> So I fall back to your suggestion. Have a module parameter to tell module
> not to register rfkill for bluetooth.
> I prepare the driver and please spend some time testing. Driver is at
> http://kernel.ubuntu.com/git?p=ikepanhc/ideapad-laptop.git;a=blob;f=drivers/platform/x86/ideapad-laptop.c;h=c4cf46a363f3f72d6db5339ec326d282d7e58183;hb=26a58948693b7d25960299a8025e569e68f28937
> and you may use "insmod ideapad-laptop.ko no_bt_rfkill=1" for your S12.

Hmmm, with this version and no_bt_rfkill=1 I run into the same problem
as without the ideapad module: If I switch BT off in Windows and reboot
to Linux, the device remains invisible and I have no chance to switch it
back on again :/
I guess this is because the initial device activation does currently
only happen in ideapad_register_rfkill() via rfkill_init_sw_state()
which is not called if no_bt_rfkill=1.
A manual call to ideapad_rfk_set() (or ideapad_sync_rfk_state()?) in the
no_bt_rfkill=1 case would very likely solve this, but I don't know how
to provide this call with the correct arguments.


regards
   Mario
-- 
... aber nur deshalb blueht Autoritaet, weil die meisten Menschen
Feiglinge und manche Menschen Diebe sind.
                                              -- Robert A. Wilson

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

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Mario 'BitKoenig' Holbe]

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

On Fri, Sep 03, 2010 at 05:06:09PM +0800, Ike Panhc wrote:
> I look at the DSDT again and again but unfortunately can not find anything
> may cause the bluetooth device initial failed. BTEN looks like the switch
> for EC to turn on/off bluetooth, BTST records the status of BTEN and BTPS
> means bluetooth present. But no idea why initial failed after BTEN=1

Is there some way to trace ACPI calls under Windows (XP Home)?
I could then have a look at what happens when I Fn-F5 BT off.

> So I fall back to your suggestion. Have a module parameter to tell module
> not to register rfkill for bluetooth.
> I prepare the driver and please spend some time testing. Driver is at
> http://kernel.ubuntu.com/git?p=ikepanhc/ideapad-laptop.git;a=blob;f=drivers/platform/x86/ideapad-laptop.c;h=c4cf46a363f3f72d6db5339ec326d282d7e58183;hb=26a58948693b7d25960299a8025e569e68f28937
> and you may use "insmod ideapad-laptop.ko no_bt_rfkill=1" for your S12.

Hmmm, with this version and no_bt_rfkill=1 I run into the same problem
as without the ideapad module: If I switch BT off in Windows and reboot
to Linux, the device remains invisible and I have no chance to switch it
back on again :/
I guess this is because the initial device activation does currently
only happen in ideapad_register_rfkill() via rfkill_init_sw_state()
which is not called if no_bt_rfkill=1.
A manual call to ideapad_rfk_set() (or ideapad_sync_rfk_state()?) in the
no_bt_rfkill=1 case would very likely solve this, but I don't know how
to provide this call with the correct arguments.


regards
   Mario
-- 
... aber nur deshalb blueht Autoritaet, weil die meisten Menschen
Feiglinge und manche Menschen Diebe sind.
                                              -- Robert A. Wilson

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

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Ike Panhc]

On 09/10/2010 02:17 AM, Mario 'BitKoenig' Holbe wrote:
> On Fri, Sep 03, 2010 at 05:06:09PM +0800, Ike Panhc wrote:
>> I look at the DSDT again and again but unfortunately can not find anything
>> may cause the bluetooth device initial failed. BTEN looks like the switch
>> for EC to turn on/off bluetooth, BTST records the status of BTEN and BTPS
>> means bluetooth present. But no idea why initial failed after BTEN=1
> 
> Is there some way to trace ACPI calls under Windows (XP Home)?
> I could then have a look at what happens when I Fn-F5 BT off.
> 

I heard that we can install the driver in virtual machine for study its behavior.
But dont know the detail - it means we need to have a pseudo device there.

Sorry, I do not know much about Windows.

>> So I fall back to your suggestion. Have a module parameter to tell module
>> not to register rfkill for bluetooth.
>> I prepare the driver and please spend some time testing. Driver is at
>> http://kernel.ubuntu.com/git?p=ikepanhc/ideapad-laptop.git;a=blob;f=drivers/platform/x86/ideapad-laptop.c;h=c4cf46a363f3f72d6db5339ec326d282d7e58183;hb=26a58948693b7d25960299a8025e569e68f28937
>> and you may use "insmod ideapad-laptop.ko no_bt_rfkill=1" for your S12.
> 
> Hmmm, with this version and no_bt_rfkill=1 I run into the same problem
> as without the ideapad module: If I switch BT off in Windows and reboot
> to Linux, the device remains invisible and I have no chance to switch it
> back on again :/

The no_bt_rfkill is a stopgap for dual OS user. when BT is default on, user
still have the BT sw rfkill registered as hci0. when BT is defualt off, user
can re-insert module with no_bt_rfkill=0.

> I guess this is because the initial device activation does currently
> only happen in ideapad_register_rfkill() via rfkill_init_sw_state()
> which is not called if no_bt_rfkill=1.
> A manual call to ideapad_rfk_set() (or ideapad_sync_rfk_state()?) in the
> no_bt_rfkill=1 case would very likely solve this, but I don't know how
> to provide this call with the correct arguments.

Sorry I do not get the point of a manual call. Could you explain more on this?

ideapad_rfk_set is called when user update /sys/class/rfkill/rfkill?/state and
ideapad_sync_rfk_state is called when user touch the hw rfkill switch.

> 
> 
> regards
>    Mario

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Ike Panhc]

On 09/10/2010 02:17 AM, Mario 'BitKoenig' Holbe wrote:
> On Fri, Sep 03, 2010 at 05:06:09PM +0800, Ike Panhc wrote:
>> I look at the DSDT again and again but unfortunately can not find anything
>> may cause the bluetooth device initial failed. BTEN looks like the switch
>> for EC to turn on/off bluetooth, BTST records the status of BTEN and BTPS
>> means bluetooth present. But no idea why initial failed after BTEN=1
> 
> Is there some way to trace ACPI calls under Windows (XP Home)?
> I could then have a look at what happens when I Fn-F5 BT off.
> 

I heard that we can install the driver in virtual machine for study its behavior.
But dont know the detail - it means we need to have a pseudo device there.

Sorry, I do not know much about Windows.

>> So I fall back to your suggestion. Have a module parameter to tell module
>> not to register rfkill for bluetooth.
>> I prepare the driver and please spend some time testing. Driver is at
>> http://kernel.ubuntu.com/git?p=ikepanhc/ideapad-laptop.git;a=blob;f=drivers/platform/x86/ideapad-laptop.c;h=c4cf46a363f3f72d6db5339ec326d282d7e58183;hb=26a58948693b7d25960299a8025e569e68f28937
>> and you may use "insmod ideapad-laptop.ko no_bt_rfkill=1" for your S12.
> 
> Hmmm, with this version and no_bt_rfkill=1 I run into the same problem
> as without the ideapad module: If I switch BT off in Windows and reboot
> to Linux, the device remains invisible and I have no chance to switch it
> back on again :/

The no_bt_rfkill is a stopgap for dual OS user. when BT is default on, user
still have the BT sw rfkill registered as hci0. when BT is defualt off, user
can re-insert module with no_bt_rfkill=0.

> I guess this is because the initial device activation does currently
> only happen in ideapad_register_rfkill() via rfkill_init_sw_state()
> which is not called if no_bt_rfkill=1.
> A manual call to ideapad_rfk_set() (or ideapad_sync_rfk_state()?) in the
> no_bt_rfkill=1 case would very likely solve this, but I don't know how
> to provide this call with the correct arguments.

Sorry I do not get the point of a manual call. Could you explain more on this?

ideapad_rfk_set is called when user update /sys/class/rfkill/rfkill?/state and
ideapad_sync_rfk_state is called when user touch the hw rfkill switch.

> 
> 
> regards
>    Mario

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Ike Panhc]

On 09/10/2010 02:17 AM, Mario 'BitKoenig' Holbe wrote:
> On Fri, Sep 03, 2010 at 05:06:09PM +0800, Ike Panhc wrote:
>> I look at the DSDT again and again but unfortunately can not find anything
>> may cause the bluetooth device initial failed. BTEN looks like the switch
>> for EC to turn on/off bluetooth, BTST records the status of BTEN and BTPS
>> means bluetooth present. But no idea why initial failed after BTEN=1
> 
> Is there some way to trace ACPI calls under Windows (XP Home)?
> I could then have a look at what happens when I Fn-F5 BT off.
> 

I heard that we can install the driver in virtual machine for study its behavior.
But dont know the detail - it means we need to have a pseudo device there.

Sorry, I do not know much about Windows.

>> So I fall back to your suggestion. Have a module parameter to tell module
>> not to register rfkill for bluetooth.
>> I prepare the driver and please spend some time testing. Driver is at
>> http://kernel.ubuntu.com/git?p=ikepanhc/ideapad-laptop.git;a=blob;f=drivers/platform/x86/ideapad-laptop.c;h=c4cf46a363f3f72d6db5339ec326d282d7e58183;hb=26a58948693b7d25960299a8025e569e68f28937
>> and you may use "insmod ideapad-laptop.ko no_bt_rfkill=1" for your S12.
> 
> Hmmm, with this version and no_bt_rfkill=1 I run into the same problem
> as without the ideapad module: If I switch BT off in Windows and reboot
> to Linux, the device remains invisible and I have no chance to switch it
> back on again :/

The no_bt_rfkill is a stopgap for dual OS user. when BT is default on, user
still have the BT sw rfkill registered as hci0. when BT is defualt off, user
can re-insert module with no_bt_rfkill=0.

> I guess this is because the initial device activation does currently
> only happen in ideapad_register_rfkill() via rfkill_init_sw_state()
> which is not called if no_bt_rfkill=1.
> A manual call to ideapad_rfk_set() (or ideapad_sync_rfk_state()?) in the
> no_bt_rfkill=1 case would very likely solve this, but I don't know how
> to provide this call with the correct arguments.

Sorry I do not get the point of a manual call. Could you explain more on this?

ideapad_rfk_set is called when user update /sys/class/rfkill/rfkill?/state and
ideapad_sync_rfk_state is called when user touch the hw rfkill switch.

> 
> 
> regards
>    Mario

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Mario 'BitKoenig' Holbe]

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

On Fri, Sep 10, 2010 at 02:44:16PM +0800, Ike Panhc wrote:
> On 09/10/2010 02:17 AM, Mario 'BitKoenig' Holbe wrote:
> > Hmmm, with this version and no_bt_rfkill=1 I run into the same problem
> > as without the ideapad module: If I switch BT off in Windows and reboot
> > to Linux, the device remains invisible and I have no chance to switch it
> > back on again :/
> 
> The no_bt_rfkill is a stopgap for dual OS user. when BT is default on, user
> still have the BT sw rfkill registered as hci0. when BT is defualt off, user
> can re-insert module with no_bt_rfkill=0.
> 
> > I guess this is because the initial device activation does currently
> > only happen in ideapad_register_rfkill() via rfkill_init_sw_state()
> > which is not called if no_bt_rfkill=1.
> > A manual call to ideapad_rfk_set() (or ideapad_sync_rfk_state()?) in the
> > no_bt_rfkill=1 case would very likely solve this, but I don't know how
> > to provide this call with the correct arguments.
> 
> Sorry I do not get the point of a manual call. Could you explain more on this?
> 
> ideapad_rfk_set is called when user update /sys/class/rfkill/rfkill?/state and
> ideapad_sync_rfk_state is called when user touch the hw rfkill switch.

ideapad_rfk_set is also called in ideapad_register_rfkill:

static int ideapad_register_rfkill(struct acpi_device *adevice, int dev)
{
...
	if (no_bt_rfkill && (ideapad_rfk_data[dev].type == RFKILL_TYPE_BLUETOOTH))
		return 0;
...
	rfkill_init_sw_state(priv->rfk[dev], 0);
}

The rfkill_init_sw_state call to unblock the device finally calls
ideapad_rfk_set. In the no_bt_rfkill=1 case rfkill_init_sw_state isn't
called, thus the device is not unblocked if it was blocked before.
Hence, if I prior disabled BT in Windows, the device remains invisible.
This is why I think a manual call to ideapad_rfk_set in the
no_bt_rfkill=1 case would make the BT device visible.

"manual" in terms of:
	if (no_bt_rfkill && (ideapad_rfk_data[dev].type == RFKILL_TYPE_BLUETOOTH))
	{
		ideapad_rfk_set(???, 0);
		return 0;
	}

But I don't know what to provide as "???".


Mario
-- 
"Why are we hiding from the police, daddy?"      | J. E. Guenther
"Because we use SuSE son, they use SYSVR4."      | de.alt.sysadmin.recovery

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

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Mario 'BitKoenig' Holbe]

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

On Fri, Sep 10, 2010 at 02:44:16PM +0800, Ike Panhc wrote:
> On 09/10/2010 02:17 AM, Mario 'BitKoenig' Holbe wrote:
> > Hmmm, with this version and no_bt_rfkill=1 I run into the same problem
> > as without the ideapad module: If I switch BT off in Windows and reboot
> > to Linux, the device remains invisible and I have no chance to switch it
> > back on again :/
> 
> The no_bt_rfkill is a stopgap for dual OS user. when BT is default on, user
> still have the BT sw rfkill registered as hci0. when BT is defualt off, user
> can re-insert module with no_bt_rfkill=0.
> 
> > I guess this is because the initial device activation does currently
> > only happen in ideapad_register_rfkill() via rfkill_init_sw_state()
> > which is not called if no_bt_rfkill=1.
> > A manual call to ideapad_rfk_set() (or ideapad_sync_rfk_state()?) in the
> > no_bt_rfkill=1 case would very likely solve this, but I don't know how
> > to provide this call with the correct arguments.
> 
> Sorry I do not get the point of a manual call. Could you explain more on this?
> 
> ideapad_rfk_set is called when user update /sys/class/rfkill/rfkill?/state and
> ideapad_sync_rfk_state is called when user touch the hw rfkill switch.

ideapad_rfk_set is also called in ideapad_register_rfkill:

static int ideapad_register_rfkill(struct acpi_device *adevice, int dev)
{
...
	if (no_bt_rfkill && (ideapad_rfk_data[dev].type == RFKILL_TYPE_BLUETOOTH))
		return 0;
...
	rfkill_init_sw_state(priv->rfk[dev], 0);
}

The rfkill_init_sw_state call to unblock the device finally calls
ideapad_rfk_set. In the no_bt_rfkill=1 case rfkill_init_sw_state isn't
called, thus the device is not unblocked if it was blocked before.
Hence, if I prior disabled BT in Windows, the device remains invisible.
This is why I think a manual call to ideapad_rfk_set in the
no_bt_rfkill=1 case would make the BT device visible.

"manual" in terms of:
	if (no_bt_rfkill && (ideapad_rfk_data[dev].type == RFKILL_TYPE_BLUETOOTH))
	{
		ideapad_rfk_set(???, 0);
		return 0;
	}

But I don't know what to provide as "???".


Mario
-- 
"Why are we hiding from the police, daddy?"      | J. E. Guenther
"Because we use SuSE son, they use SYSVR4."      | de.alt.sysadmin.recovery

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

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Ike Panhc]

On 09/10/2010 03:11 PM, Mario 'BitKoenig' Holbe wrote:
> 
> ideapad_rfk_set is also called in ideapad_register_rfkill:
> 
> static int ideapad_register_rfkill(struct acpi_device *adevice, int dev)
> {
> ...
> 	if (no_bt_rfkill && (ideapad_rfk_data[dev].type == RFKILL_TYPE_BLUETOOTH))
> 		return 0;
> ...
> 	rfkill_init_sw_state(priv->rfk[dev], 0);
> }

eh.. after review the code, the rfkill_init_sw_state shall not give 0 as the default
value. I shall read the value from EC and set reasonable value.

> 
> The rfkill_init_sw_state call to unblock the device finally calls
> ideapad_rfk_set. In the no_bt_rfkill=1 case rfkill_init_sw_state isn't
> called, thus the device is not unblocked if it was blocked before.
> Hence, if I prior disabled BT in Windows, the device remains invisible.
> This is why I think a manual call to ideapad_rfk_set in the
> no_bt_rfkill=1 case would make the BT device visible.
> 
> "manual" in terms of:
> 	if (no_bt_rfkill && (ideapad_rfk_data[dev].type == RFKILL_TYPE_BLUETOOTH))
> 	{
> 		ideapad_rfk_set(???, 0);
> 		return 0;
> 	}
> 
> But I don't know what to provide as "???".

Do you mean driver still setup the rfkill for bluetooth, but we can not block
bluetooth when module parameter set to 1? This idea is better then no_bt_rfkill.
Will modify the driver.

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Ike Panhc]

On 09/10/2010 03:11 PM, Mario 'BitKoenig' Holbe wrote:
> 
> ideapad_rfk_set is also called in ideapad_register_rfkill:
> 
> static int ideapad_register_rfkill(struct acpi_device *adevice, int dev)
> {
> ...
> 	if (no_bt_rfkill && (ideapad_rfk_data[dev].type == RFKILL_TYPE_BLUETOOTH))
> 		return 0;
> ...
> 	rfkill_init_sw_state(priv->rfk[dev], 0);
> }

eh.. after review the code, the rfkill_init_sw_state shall not give 0 as the default
value. I shall read the value from EC and set reasonable value.

> 
> The rfkill_init_sw_state call to unblock the device finally calls
> ideapad_rfk_set. In the no_bt_rfkill=1 case rfkill_init_sw_state isn't
> called, thus the device is not unblocked if it was blocked before.
> Hence, if I prior disabled BT in Windows, the device remains invisible.
> This is why I think a manual call to ideapad_rfk_set in the
> no_bt_rfkill=1 case would make the BT device visible.
> 
> "manual" in terms of:
> 	if (no_bt_rfkill && (ideapad_rfk_data[dev].type == RFKILL_TYPE_BLUETOOTH))
> 	{
> 		ideapad_rfk_set(???, 0);
> 		return 0;
> 	}
> 
> But I don't know what to provide as "???".

Do you mean driver still setup the rfkill for bluetooth, but we can not block
bluetooth when module parameter set to 1? This idea is better then no_bt_rfkill.
Will modify the driver.

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Ike Panhc]

On 09/10/2010 03:11 PM, Mario 'BitKoenig' Holbe wrote:
> 
> ideapad_rfk_set is also called in ideapad_register_rfkill:
> 
> static int ideapad_register_rfkill(struct acpi_device *adevice, int dev)
> {
> ...
> 	if (no_bt_rfkill && (ideapad_rfk_data[dev].type == RFKILL_TYPE_BLUETOOTH))
> 		return 0;
> ...
> 	rfkill_init_sw_state(priv->rfk[dev], 0);
> }

eh.. after review the code, the rfkill_init_sw_state shall not give 0 as the default
value. I shall read the value from EC and set reasonable value.

> 
> The rfkill_init_sw_state call to unblock the device finally calls
> ideapad_rfk_set. In the no_bt_rfkill=1 case rfkill_init_sw_state isn't
> called, thus the device is not unblocked if it was blocked before.
> Hence, if I prior disabled BT in Windows, the device remains invisible.
> This is why I think a manual call to ideapad_rfk_set in the
> no_bt_rfkill=1 case would make the BT device visible.
> 
> "manual" in terms of:
> 	if (no_bt_rfkill && (ideapad_rfk_data[dev].type == RFKILL_TYPE_BLUETOOTH))
> 	{
> 		ideapad_rfk_set(???, 0);
> 		return 0;
> 	}
> 
> But I don't know what to provide as "???".

Do you mean driver still setup the rfkill for bluetooth, but we can not block
bluetooth when module parameter set to 1? This idea is better then no_bt_rfkill.
Will modify the driver.

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Mario 'BitKoenig' Holbe]

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

On Wed, Sep 15, 2010 at 06:13:43PM +0800, Ike Panhc wrote:
> On 09/10/2010 03:11 PM, Mario 'BitKoenig' Holbe wrote:
> > 	rfkill_init_sw_state(priv->rfk[dev], 0);
> eh.. after review the code, the rfkill_init_sw_state shall not give 0 as the default
> value. I shall read the value from EC and set reasonable value.

Well - probably :)
The current behaviour results in each device becoming unblocked no
matter what state it had before.

> > 	if (no_bt_rfkill && (ideapad_rfk_data[dev].type == RFKILL_TYPE_BLUETOOTH))
> > 		ideapad_rfk_set(???, 0);
> Do you mean driver still setup the rfkill for bluetooth, but we can not block
> bluetooth when module parameter set to 1? This idea is better then no_bt_rfkill.
> Will modify the driver.

Well, not really... I mean: in the no_bt_rfkill=1 case the driver should
(try to) unblock the bluetooth device in order to activate it to make it
further manageable via it's own (hci) rfkill switch.
I don't think setting up the ideapad_bluetooth rfkill is necessary for
that. Not setting it up is IMHO the right direction. Just the device
activation is missing.


Mario
-- 
Tower: "Say fuelstate." Pilot: "Fuelstate."
Tower: "Say again." Pilot: "Again."
Tower: "Arghl, give me your fuel!" Pilot: "Sorry, need it by myself..."

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

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Mario 'BitKoenig' Holbe]

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

On Wed, Sep 15, 2010 at 06:13:43PM +0800, Ike Panhc wrote:
> On 09/10/2010 03:11 PM, Mario 'BitKoenig' Holbe wrote:
> > 	rfkill_init_sw_state(priv->rfk[dev], 0);
> eh.. after review the code, the rfkill_init_sw_state shall not give 0 as the default
> value. I shall read the value from EC and set reasonable value.

Well - probably :)
The current behaviour results in each device becoming unblocked no
matter what state it had before.

> > 	if (no_bt_rfkill && (ideapad_rfk_data[dev].type == RFKILL_TYPE_BLUETOOTH))
> > 		ideapad_rfk_set(???, 0);
> Do you mean driver still setup the rfkill for bluetooth, but we can not block
> bluetooth when module parameter set to 1? This idea is better then no_bt_rfkill.
> Will modify the driver.

Well, not really... I mean: in the no_bt_rfkill=1 case the driver should
(try to) unblock the bluetooth device in order to activate it to make it
further manageable via it's own (hci) rfkill switch.
I don't think setting up the ideapad_bluetooth rfkill is necessary for
that. Not setting it up is IMHO the right direction. Just the device
activation is missing.


Mario
-- 
Tower: "Say fuelstate." Pilot: "Fuelstate."
Tower: "Say again." Pilot: "Again."
Tower: "Arghl, give me your fuel!" Pilot: "Sorry, need it by myself..."

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

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Ike Panhc]

On 09/15/2010 07:48 PM, Mario 'BitKoenig' Holbe wrote:
> On Wed, Sep 15, 2010 at 06:13:43PM +0800, Ike Panhc wrote:
>> On 09/10/2010 03:11 PM, Mario 'BitKoenig' Holbe wrote:
>>> 	rfkill_init_sw_state(priv->rfk[dev], 0);
>> eh.. after review the code, the rfkill_init_sw_state shall not give 0 as the default
>> value. I shall read the value from EC and set reasonable value.
> 
> Well - probably :)
> The current behaviour results in each device becoming unblocked no
> matter what state it had before.
> 
>>> 	if (no_bt_rfkill && (ideapad_rfk_data[dev].type == RFKILL_TYPE_BLUETOOTH))
>>> 		ideapad_rfk_set(???, 0);
>> Do you mean driver still setup the rfkill for bluetooth, but we can not block
>> bluetooth when module parameter set to 1? This idea is better then no_bt_rfkill.
>> Will modify the driver.
> 
> Well, not really... I mean: in the no_bt_rfkill=1 case the driver should
> (try to) unblock the bluetooth device in order to activate it to make it
> further manageable via it's own (hci) rfkill switch.
> I don't think setting up the ideapad_bluetooth rfkill is necessary for
> that. Not setting it up is IMHO the right direction. Just the device
> activation is missing.

This sounds even better, will modify the driver in this way - force enable
bluetooth and no setup rfkill for bluetooth when no_bt_rfkill.

> 
> 
> Mario

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Ike Panhc]

On 09/15/2010 07:48 PM, Mario 'BitKoenig' Holbe wrote:
> On Wed, Sep 15, 2010 at 06:13:43PM +0800, Ike Panhc wrote:
>> On 09/10/2010 03:11 PM, Mario 'BitKoenig' Holbe wrote:
>>> 	rfkill_init_sw_state(priv->rfk[dev], 0);
>> eh.. after review the code, the rfkill_init_sw_state shall not give 0 as the default
>> value. I shall read the value from EC and set reasonable value.
> 
> Well - probably :)
> The current behaviour results in each device becoming unblocked no
> matter what state it had before.
> 
>>> 	if (no_bt_rfkill && (ideapad_rfk_data[dev].type == RFKILL_TYPE_BLUETOOTH))
>>> 		ideapad_rfk_set(???, 0);
>> Do you mean driver still setup the rfkill for bluetooth, but we can not block
>> bluetooth when module parameter set to 1? This idea is better then no_bt_rfkill.
>> Will modify the driver.
> 
> Well, not really... I mean: in the no_bt_rfkill=1 case the driver should
> (try to) unblock the bluetooth device in order to activate it to make it
> further manageable via it's own (hci) rfkill switch.
> I don't think setting up the ideapad_bluetooth rfkill is necessary for
> that. Not setting it up is IMHO the right direction. Just the device
> activation is missing.

This sounds even better, will modify the driver in this way - force enable
bluetooth and no setup rfkill for bluetooth when no_bt_rfkill.

> 
> 
> Mario

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Ike Panhc]

Hi Mario,

I have modified the driver[1]. Please kindly have a test and see if it is ok for you.

[1] http://kernel.ubuntu.com/git?p=ikepanhc/ideapad-laptop.git;a=blob;f=drivers/platform/x86/ideapad-laptop.c;h=0e1f60bb53fd483bffb0e0f914254a589baa152a;hb=9dc37c9289c3edd2a171a6fd7872578107cf3063

--
Ike Panhc

On 09/15/2010 07:48 PM, Mario 'BitKoenig' Holbe wrote:
> On Wed, Sep 15, 2010 at 06:13:43PM +0800, Ike Panhc wrote:
>> On 09/10/2010 03:11 PM, Mario 'BitKoenig' Holbe wrote:
>>> 	rfkill_init_sw_state(priv->rfk[dev], 0);
>> eh.. after review the code, the rfkill_init_sw_state shall not give 0 as the default
>> value. I shall read the value from EC and set reasonable value.
> 
> Well - probably :)
> The current behaviour results in each device becoming unblocked no
> matter what state it had before.
> 
>>> 	if (no_bt_rfkill && (ideapad_rfk_data[dev].type == RFKILL_TYPE_BLUETOOTH))
>>> 		ideapad_rfk_set(???, 0);
>> Do you mean driver still setup the rfkill for bluetooth, but we can not block
>> bluetooth when module parameter set to 1? This idea is better then no_bt_rfkill.
>> Will modify the driver.
> 
> Well, not really... I mean: in the no_bt_rfkill=1 case the driver should
> (try to) unblock the bluetooth device in order to activate it to make it
> further manageable via it's own (hci) rfkill switch.
> I don't think setting up the ideapad_bluetooth rfkill is necessary for
> that. Not setting it up is IMHO the right direction. Just the device
> activation is missing.
> 
> 
> Mario

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Ike Panhc]

Hi Mario,

I have modified the driver[1]. Please kindly have a test and see if it is ok for you.

[1] http://kernel.ubuntu.com/git?p=ikepanhc/ideapad-laptop.git;a=blob;f=drivers/platform/x86/ideapad-laptop.c;h=0e1f60bb53fd483bffb0e0f914254a589baa152a;hb=9dc37c9289c3edd2a171a6fd7872578107cf3063

--
Ike Panhc

On 09/15/2010 07:48 PM, Mario 'BitKoenig' Holbe wrote:
> On Wed, Sep 15, 2010 at 06:13:43PM +0800, Ike Panhc wrote:
>> On 09/10/2010 03:11 PM, Mario 'BitKoenig' Holbe wrote:
>>> 	rfkill_init_sw_state(priv->rfk[dev], 0);
>> eh.. after review the code, the rfkill_init_sw_state shall not give 0 as the default
>> value. I shall read the value from EC and set reasonable value.
> 
> Well - probably :)
> The current behaviour results in each device becoming unblocked no
> matter what state it had before.
> 
>>> 	if (no_bt_rfkill && (ideapad_rfk_data[dev].type == RFKILL_TYPE_BLUETOOTH))
>>> 		ideapad_rfk_set(???, 0);
>> Do you mean driver still setup the rfkill for bluetooth, but we can not block
>> bluetooth when module parameter set to 1? This idea is better then no_bt_rfkill.
>> Will modify the driver.
> 
> Well, not really... I mean: in the no_bt_rfkill=1 case the driver should
> (try to) unblock the bluetooth device in order to activate it to make it
> further manageable via it's own (hci) rfkill switch.
> I don't think setting up the ideapad_bluetooth rfkill is necessary for
> that. Not setting it up is IMHO the right direction. Just the device
> activation is missing.
> 
> 
> Mario

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Mario 'BitKoenig' Holbe]

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

Hi Ike,

On Thu, Sep 16, 2010 at 07:59:00PM +0800, Ike Panhc wrote:
> I have modified the driver[1]. Please kindly have a test and see if it is ok for you.

This new driver works well for me. Forced enable works well with
no_bt_rfkill=1 and keeping the state does also work well without
no_bt_rfkill.

Sorry for the delay and thanks for your work.


best regards
   Mario
-- 
<Sique> Huch? 802.1q? Was sucht das denn hier? Wie kommt das ans TAGgeslicht?

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

Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Mario 'BitKoenig' Holbe]

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

Hi Ike,

On Thu, Sep 16, 2010 at 07:59:00PM +0800, Ike Panhc wrote:
> I have modified the driver[1]. Please kindly have a test and see if it is ok for you.

This new driver works well for me. Forced enable works well with
no_bt_rfkill=1 and keeping the state does also work well without
no_bt_rfkill.

Sorry for the delay and thanks for your work.


best regards
   Mario
-- 
<Sique> Huch? 802.1q? Was sucht das denn hier? Wie kommt das ans TAGgeslicht?

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