[PATCH 0/25] sony-laptop: code improvements and support extension for newer Vaios

[PATCH 0/25] sony-laptop: code improvements and support extension for newer Vaios

[Marco Chiappero]

Hello,

this set of patches aims to reorganize and clean the driver code where 
necessary [patches 1-9, 13], improve some functionalities [patches 
10-12] and add some others present on recent Vaios (TT, Y1, Z1, F1, S1, 
SA/SB/SC, CA/SB and possibly others), such as ALS driven backlight 
control, HDD shock protection control and Battery charge control.

During the development of these patches a long list of new handles has 
been found and analyzed (the list can be read here: 
http://absence.it/vaio-acpi/handles_list.txt), many of them are now well 
known and mostly implemented by patches from 14 to 24.

During the development, this code has been made publicly available for a 
few months at http://code.google.com/p/vaio-f11-linux/issues/detail?id=6 
and http://www.absence.it/vaio-acpi/source/ where many people 
contributed with feedback and testing. The coded is now stable and well 
tested, even though improvements are still possible (and can be 
introduced later).

Some functionalities may require a userspace Vaio specific daemon (for 
ALS based backlight control, visual notifications, etc.), which is under 
development at http://git.zx2c4.com/sony-acpid/

All the code is written by me, with the exception of patch #23, written 
by me and Javier Achirica. Javier Achirica has been also a major 
contributor in the analysis of the ALS part (patch #23) and the 
"HighSpeed Charging" functionality (patch #18).

The patches are also available here: 
http://www.absence.it/vaio-acpi/source/patches/patchset/

[PATCH 1/25] sony-laptop: use usigned data type when calling ACPI methods

[Marco Chiappero]

Data exchanges with the SNC device should use unsigned data types: to 
avoid any implicit cast, this patch removes any int usage in favor of 
unsigned int or u32.

Signed-off-by: Marco Chiappero <marco@absence.it>
---

--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -689,7 +689,8 @@ static struct acpi_device *sony_nc_acpi_
  /*
   * acpi_evaluate_object wrappers
   */
-static int acpi_callgetfunc(acpi_handle handle, char *name, int *result)
+static int acpi_callgetfunc(acpi_handle handle, char *name,
+				unsigned int *result)
  {
  	struct acpi_buffer output;
  	union acpi_object out_obj;
@@ -709,8 +710,8 @@ static int acpi_callgetfunc(acpi_handle
  	return -1;
  }

-static int acpi_callsetfunc(acpi_handle handle, char *name, int value,
-			    int *result)
+static int acpi_callsetfunc(acpi_handle handle, char *name, u32 value,
+				unsigned int *result)
  {
  	struct acpi_object_list params;
  	union acpi_object in_obj;
@@ -767,8 +768,7 @@ static ssize_t sony_nc_handles_show(stru

  static int sony_nc_handles_setup(struct platform_device *pd)
  {
-	int i;
-	int result;
+	unsigned int i, result;

  	handles = kzalloc(sizeof(*handles), GFP_KERNEL);
  	if (!handles)
@@ -830,7 +830,9 @@ static int sony_find_snc_handle(int hand
  	return -1;
  }

-static int sony_call_snc_handle(int handle, int argument, int *result)
+/* call command method SN07, accepts a 32 bit integer, returns a integer */
+static int sony_call_snc_handle(int handle, unsigned int argument,
+				unsigned int *result)
  {
  	int ret = 0;
  	int offset = sony_find_snc_handle(handle);
@@ -838,6 +840,7 @@ static int sony_call_snc_handle(int hand
  	if (offset < 0)
  		return -1;

+	/* max 32 bit wide argument, for wider input use SN06 */
  	ret = acpi_callsetfunc(sony_nc_acpi_handle, "SN07", offset | argument,
  			result);
  	dprintk("called SN07 with 0x%.4x (result: 0x%.4x)\n", offset | argument,
@@ -886,7 +889,7 @@ static int boolean_validate(const int di
  static ssize_t sony_nc_sysfs_show(struct device *dev, struct 
device_attribute *attr,
  			      char *buffer)
  {
-	int value;
+	unsigned int value;
  	struct sony_nc_value *item =
  	    container_of(attr, struct sony_nc_value, devattr);

@@ -906,7 +909,7 @@ static ssize_t sony_nc_sysfs_store(struc
  			       struct device_attribute *attr,
  			       const char *buffer, size_t count)
  {
-	int value;
+	unsigned long value;
  	struct sony_nc_value *item =
  	    container_of(attr, struct sony_nc_value, devattr);

@@ -951,7 +954,7 @@ static int sony_backlight_update_status(

  static int sony_backlight_get_brightness(struct backlight_device *bd)
  {
-	int value;
+	unsigned int value;

  	if (acpi_callgetfunc(sony_nc_acpi_handle, "GBRT", &value))
  		return 0;
@@ -961,7 +964,7 @@ static int sony_backlight_get_brightness

  static int sony_nc_get_brightness_ng(struct backlight_device *bd)
  {
-	int result;
+	unsigned int result;
  	struct sony_backlight_props *sdev =
  		(struct sony_backlight_props *)bl_get_data(bd);

@@ -972,7 +975,7 @@ static int sony_nc_get_brightness_ng(str

  static int sony_nc_update_status_ng(struct backlight_device *bd)
  {
-	int value, result;
+	unsigned int value, result;
  	struct sony_backlight_props *sdev =
  		(struct sony_backlight_props *)bl_get_data(bd);

@@ -1069,7 +1072,7 @@ static void sony_nc_notify(struct acpi_d

  	if (ev >= 0x90) {
  		/* New-style event */
-		int result;
+		unsigned int result;
  		int key_handle = 0;
  		ev -= 0x90;

@@ -1139,7 +1142,7 @@ static acpi_status sony_walk_callback(ac
   */
  static int sony_nc_function_setup(struct acpi_device *device)
  {
-	int result;
+	unsigned int result;

  	/* Enable all events */
  	acpi_callsetfunc(sony_nc_acpi_handle, "SN02", 0xffff, &result);
@@ -1206,8 +1209,8 @@ static void sony_nc_rfkill_cleanup(void)

  static int sony_nc_rfkill_set(void *data, bool blocked)
  {
-	int result;
-	int argument = sony_rfkill_address[(long) data] + 0x100;
+	unsigned int result;
+	unsigned int argument = sony_rfkill_address[(long) data] + 0x100;

  	if (!blocked)
  		argument |= 0xff0000;
@@ -1226,7 +1229,7 @@ static int sony_nc_setup_rfkill(struct a
  	struct rfkill *rfk;
  	enum rfkill_type type;
  	const char *name;
-	int result;
+	unsigned int result;
  	bool hwblock;

  	switch (nc_type) {
@@ -1271,14 +1274,14 @@ static int sony_nc_setup_rfkill(struct a
  static void sony_nc_rfkill_update(void)
  {
  	enum sony_nc_rfkill i;
-	int result;
+	unsigned int result;
  	bool hwblock;

  	sony_call_snc_handle(sony_rfkill_handle, 0x200, &result);
  	hwblock = !(result & 0x1);

  	for (i = 0; i < N_SONY_RFKILL; i++) {
-		int argument = sony_rfkill_address[i];
+		unsigned int argument = sony_rfkill_address[i];

  		if (!sony_rfkill_devices[i])
  			continue;
@@ -1390,7 +1393,7 @@ static struct kbd_backlight *kbdbl_handl

  static ssize_t __sony_nc_kbd_backlight_mode_set(u8 value)
  {
-	int result;
+	unsigned int result;

  	if (value > 1)
  		return -EINVAL;
@@ -1438,7 +1441,7 @@ static ssize_t sony_nc_kbd_backlight_mod

  static int __sony_nc_kbd_backlight_timeout_set(u8 value)
  {
-	int result;
+	unsigned int result;

  	if (value > 3)
  		return -EINVAL;
@@ -1482,7 +1485,7 @@ static ssize_t sony_nc_kbd_backlight_tim

  static int sony_nc_kbd_backlight_setup(struct platform_device *pd)
  {
-	int result;
+	unsigned int result;

  	if (sony_call_snc_handle(KBDBL_HANDLER, KBDBL_PRESENT, &result))
  		return 0;
@@ -1527,7 +1530,7 @@ outkzalloc:
  static int sony_nc_kbd_backlight_cleanup(struct platform_device *pd)
  {
  	if (kbdbl_handle) {
-		int result;
+		unsigned int result;

  		device_remove_file(&pd->dev, &kbdbl_handle->mode_attr);
  		device_remove_file(&pd->dev, &kbdbl_handle->timeout_attr);
@@ -1543,7 +1546,7 @@ static int sony_nc_kbd_backlight_cleanup

  static void sony_nc_kbd_backlight_resume(void)
  {
-	int ignore = 0;
+	unsigned int ignore = 0;

  	if (!kbdbl_handle)
  		return;
@@ -2659,7 +2662,7 @@ static long sonypi_misc_ioctl(struct fil
  	void __user *argp = (void __user *)arg;
  	u8 val8;
  	u16 val16;
-	int value;
+	unsigned int value;

  	mutex_lock(&spic_dev.lock);
  	switch (cmd) {

[PATCH 2/25] sony-laptop: simple_strtoul replaced by strict_strtoul

[Marco Chiappero]

Any occurrence of simple_strtoul has been replaced with the better 
strict_strtoul.

Signed-off-by: Marco Chiappero <marco@absence.it>
---

--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -919,7 +919,8 @@ static ssize_t sony_nc_sysfs_store(struc
  	if (count > 31)
  		return -EINVAL;

-	value = simple_strtoul(buffer, NULL, 10);
+	if (strict_strtoul(buffer, 10, &value))
+		return -EINVAL;

  	if (item->validate)
  		value = item->validate(SNC_VALIDATE_IN, value);
@@ -2437,7 +2438,9 @@ static ssize_t sony_pic_wwanpower_store(
  	if (count > 31)
  		return -EINVAL;

-	value = simple_strtoul(buffer, NULL, 10);
+	if (strict_strtoul(buffer, 10, &value))
+		return -EINVAL;
+
  	mutex_lock(&spic_dev.lock);
  	__sony_pic_set_wwanpower(value);
  	mutex_unlock(&spic_dev.lock);
@@ -2474,7 +2477,9 @@ static ssize_t sony_pic_bluetoothpower_s
  	if (count > 31)
  		return -EINVAL;

-	value = simple_strtoul(buffer, NULL, 10);
+	if (strict_strtoul(buffer, 10, &value))
+		return -EINVAL;
+
  	mutex_lock(&spic_dev.lock);
  	__sony_pic_set_bluetoothpower(value);
  	mutex_unlock(&spic_dev.lock);
@@ -2513,7 +2518,9 @@ static ssize_t sony_pic_fanspeed_store(s
  	if (count > 31)
  		return -EINVAL;

-	value = simple_strtoul(buffer, NULL, 10);
+	if (strict_strtoul(buffer, 10, &value))
+		return -EINVAL;
+
  	if (sony_pic_set_fanspeed(value))
  		return -EIO;

[PATCH 3/25] sony-laptop: new ACPI SN06 method helper functions

[Marco Chiappero]

SN06 method related code moved from sony_nc_rfkill_setup to 
acpi_callsetfunc_buffer; a new helper sony_call_snc_handle_buffer added 
too, to be used by different handles and not just the rfkill handles.

Signed-off-by: Marco Chiappero <marco@absence.it>
---

--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -744,6 +744,72 @@ static int acpi_callsetfunc(acpi_handle
  	return -1;
  }

+static int acpi_callsetfunc_buffer(acpi_handle handle, u64 value,
+					u8 array[], unsigned int size)
+{
+	u8 buffer[sizeof(value)];
+	int length = -1;
+	struct acpi_object_list params;
+	union acpi_object in_obj;
+	union acpi_object *values;
+	struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL};
+	acpi_status status;
+
+	if (!array || !size)
+		return length;
+
+	/* use a buffer type as parameter to overcome any 32 bits ACPI limit */
+	memcpy(buffer, &value, sizeof(buffer));
+
+	params.count = 1;
+	params.pointer = &in_obj;
+	in_obj.type = ACPI_TYPE_BUFFER;
+	in_obj.buffer.length = sizeof(buffer);
+	in_obj.buffer.pointer = buffer;
+
+	/* since SN06 is the only known method returning a buffer we
+	 * can hard code it, it is not necessary to have a parameter
+	 */
+	status = acpi_evaluate_object(sony_nc_acpi_handle, "SN06", &params,
+			&output);
+	values = (union acpi_object *) output.pointer;
+	if (ACPI_FAILURE(status) || !values) {
+		dprintk("acpi_evaluate_object failed\n");
+		goto error;
+	}
+
+	/* some buggy DSDTs return integer when the output does
+	   not execede the 4 bytes size
+	*/
+	if (values->type == ACPI_TYPE_BUFFER) {
+		if (values->buffer.length <= 0)
+			goto error;
+
+		length = size > values->buffer.length ?
+			values->buffer.length : size;
+
+		memcpy(array, values->buffer.pointer, length);
+	} else if (values->type == ACPI_TYPE_INTEGER) {
+		u32 result = values->integer.value;
+		if (size < 4)
+			goto error;
+
+		length = 0;
+		while (length != 4) {
+			array[length] = result & 0xff;
+			result >>= 8;
+			length++;
+		}
+	} else {
+		pr_err("Invalid return object 0x%.2x\n", values->type);
+		goto error;
+	}
+
+error:
+	kfree(output.pointer);
+	return length;
+}
+
  struct sony_nc_handles {
  	u16 cap[0x10];
  	struct device_attribute devattr;
@@ -848,6 +914,24 @@ static int sony_call_snc_handle(int hand
  	return ret;
  }

+/* call command method SN06, accepts a wide input buffer, returns a 
buffer */
+static int sony_call_snc_handle_buffer(int handle, u64 argument, u8 
result[],
+					unsigned int size)
+{
+	int ret = 0;
+	int offset = sony_find_snc_handle(handle);
+
+	if (offset < 0)
+		return -1;
+
+	ret = acpi_callsetfunc_buffer(sony_nc_acpi_handle,
+			offset | argument, result, size);
+	dprintk("called SN06 with 0x%.4llx (%u bytes read)\n",
+			offset | argument, ret);
+
+	return ret;
+}
+
  /*
   * sony_nc_values input/output validate functions
   */
@@ -1300,21 +1384,17 @@ static void sony_nc_rfkill_update(void)
  	}
  }

-static void sony_nc_rfkill_setup(struct acpi_device *device)
+static int sony_nc_rfkill_setup(struct acpi_device *device)
  {
+#define	RFKILL_BUFF_SIZE 8
+	u8 dev_code, i, buff[RFKILL_BUFF_SIZE] = { 0 };
  	int offset;
-	u8 dev_code, i;
-	acpi_status status;
-	struct acpi_object_list params;
-	union acpi_object in_obj;
-	union acpi_object *device_enum;
-	struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };

  	offset = sony_find_snc_handle(0x124);
  	if (offset == -1) {
  		offset = sony_find_snc_handle(0x135);
  		if (offset == -1)
-			return;
+			return 0;
  		else
  			sony_rfkill_handle = 0x135;
  	} else
@@ -1324,34 +1404,16 @@ static void sony_nc_rfkill_setup(struct
  	/* need to read the whole buffer returned by the acpi call to SN06
  	 * here otherwise we may miss some features
  	 */
-	params.count = 1;
-	params.pointer = &in_obj;
-	in_obj.type = ACPI_TYPE_INTEGER;
-	in_obj.integer.value = offset;
-	status = acpi_evaluate_object(sony_nc_acpi_handle, "SN06", &params,
-			&buffer);
-	if (ACPI_FAILURE(status)) {
-		dprintk("Radio device enumeration failed\n");
-		return;
-	}
-
-	device_enum = (union acpi_object *) buffer.pointer;
-	if (!device_enum) {
-		pr_err("No SN06 return object\n");
-		goto out_no_enum;
-	}
-	if (device_enum->type != ACPI_TYPE_BUFFER) {
-		pr_err("Invalid SN06 return object 0x%.2x\n",
-		       device_enum->type);
-		goto out_no_enum;
-	}
+	if (sony_call_snc_handle_buffer(sony_rfkill_handle, 0x000,
+					buff, RFKILL_BUFF_SIZE) < 0)
+		return -EIO;

  	/* the buffer is filled with magic numbers describing the devices
  	 * available, 0xff terminates the enumeration
  	 */
-	for (i = 0; i < device_enum->buffer.length; i++) {
+	for (i = 0; i < RFKILL_BUFF_SIZE; i++) {

-		dev_code = *(device_enum->buffer.pointer + i);
+		dev_code = buff[i];
  		if (dev_code == 0xff)
  			break;

@@ -1371,9 +1433,7 @@ static void sony_nc_rfkill_setup(struct
  			sony_nc_setup_rfkill(device, SONY_WIMAX);
  	}

-out_no_enum:
-	kfree(buffer.pointer);
-	return;
+	return 0;
  }

  /* Keyboard backlight feature */

[PATCH 4/25] sony-laptop: new SNC setup and cleanup functions

[Marco Chiappero]

New SNC setup and cleanup functions, sony_nc_snc_setup and 
sony_nc_snc_cleanup, to avoid eccessive tainting of sony_nc_add and 
sony_nc_remove, with cleaner and easier to read code, better event 
initialization and better error handling.

Signed-off-by: Marco Chiappero <marco@absence.it>
---

--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -1736,6 +1736,66 @@ static void sony_nc_backlight_cleanup(vo
  		backlight_device_unregister(sony_bl_props.dev);
  }

+static int sony_nc_snc_setup(struct platform_device *pd)
+{
+	unsigned int i, string[4], bitmask, result;
+
+	for (i = 0; i < 4; i++) {
+		if (acpi_callsetfunc(sony_nc_acpi_handle,
+				"SN00", i, &string[i]))
+			return -EIO;
+	}
+	if (strncmp("SncSupported", (char *) string, 0x10)) {
+		pr_info("SNC device present but not supported by hardware");
+		return -1;
+	}
+
+	if (!acpi_callsetfunc(sony_nc_acpi_handle, "SN00", 0x04, &result)) {
+		unsigned int model, i;
+		for (model = 0, i = 0; i < 4; i++)
+			model |= ((result >> (i * 8)) & 0xff) << ((3 - i) * 8);
+		pr_info("found Vaio model ID: %u\n", model);
+	}
+
+	/* retrieve the implemented offsets mask */
+	if (acpi_callsetfunc(sony_nc_acpi_handle, "SN00", 0x10, &bitmask))
+		return -EIO;
+
+	/* retrieve the available handles, otherwise return */
+	if (sony_nc_handles_setup(pd))
+		return -2;
+
+	/* setup found handles here */
+	sony_nc_kbd_backlight_setup(pd);
+	sony_nc_function_setup(sony_nc_acpi_device);
+	sony_nc_rfkill_setup(sony_nc_acpi_device);
+
+	/* Enable all events for the found handles, otherwise return */
+	if (acpi_callsetfunc(sony_nc_acpi_handle, "SN02", bitmask, &result))
+		return -EIO;
+
+	return 0;
+}
+
+static int sony_nc_snc_cleanup(struct platform_device *pd)
+{
+	unsigned int result, bitmask;
+
+	/* retrieve the event enabled handles */
+	acpi_callgetfunc(sony_nc_acpi_handle, "SN01", &bitmask);
+
+	/* disable the event generation	for every handle */
+	acpi_callsetfunc(sony_nc_acpi_handle, "SN03", bitmask, &result);
+
+	/* cleanup handles here */
+	sony_nc_kbd_backlight_cleanup(pd);
+	sony_nc_rfkill_cleanup();
+
+	sony_nc_handles_cleanup(pd);
+
+	return 0;
+}
+
  static int sony_nc_add(struct acpi_device *device)
  {
  	acpi_status status;
@@ -1783,21 +1843,16 @@ static int sony_nc_add(struct acpi_devic
  	if (ACPI_SUCCESS(acpi_get_handle(sony_nc_acpi_handle, "SN00",
  					 &handle))) {
  		dprintk("Doing SNC setup\n");
-		result = sony_nc_handles_setup(sony_pf_device);
-		if (result)
-			goto outpresent;
-		result = sony_nc_kbd_backlight_setup(sony_pf_device);
-		if (result)
+
+		if (sony_nc_snc_setup(sony_pf_device))
  			goto outsnc;
-		sony_nc_function_setup(device);
-		sony_nc_rfkill_setup(device);
  	}

  	/* setup input devices and helper fifo */
  	result = sony_laptop_setup_input(device);
  	if (result) {
  		pr_err("Unable to create input devices\n");
-		goto outkbdbacklight;
+		goto outsnc;
  	}

  	if (acpi_video_backlight_support()) {
@@ -1855,17 +1910,13 @@ static int sony_nc_add(struct acpi_devic

  	sony_laptop_remove_input();

-      outkbdbacklight:
-	sony_nc_kbd_backlight_cleanup(sony_pf_device);
-
        outsnc:
-	sony_nc_handles_cleanup(sony_pf_device);
+	sony_nc_snc_cleanup(sony_pf_device);

        outpresent:
  	sony_pf_remove();

        outwalk:
-	sony_nc_rfkill_cleanup();
  	return result;
  }

@@ -1881,11 +1932,9 @@ static int sony_nc_remove(struct acpi_de
  		device_remove_file(&sony_pf_device->dev, &item->devattr);
  	}

-	sony_nc_kbd_backlight_cleanup(sony_pf_device);
-	sony_nc_handles_cleanup(sony_pf_device);
+	sony_nc_snc_cleanup(sony_pf_device);
  	sony_pf_remove();
  	sony_laptop_remove_input();
-	sony_nc_rfkill_cleanup();
  	dprintk(SONY_NC_DRIVER_NAME " removed.\n");

  	return 0;

[PATCH 5/25] sony-laptop: new handles setup and cleanup functions

[Marco Chiappero]

New sony_nc_snc_setup_handles and sony_nc_snc_cleanup_handles, dealing 
with the initialization and cleanup of the model specific handles in a 
clear and extensible way.

Signed-off-by: Marco Chiappero <marco@absence.it>
---

--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -1736,6 +1736,69 @@ static void sony_nc_backlight_cleanup(vo
  		backlight_device_unregister(sony_bl_props.dev);
  }

+static void sony_nc_snc_setup_handles(struct platform_device *pd)
+{
+	unsigned int i;
+
+	for (i = 0; i < ARRAY_SIZE(handles->cap); i++) {
+		int ret = 0;
+		int unsigned handle = handles->cap[i];
+
+		if (!handle)
+			continue;
+
+		dprintk("looking at handle 0x%.4x\n", handle);
+
+		switch (handle) {
+		case 0x0137:
+			ret = sony_nc_kbd_backlight_setup(pd);
+			break;
+		case 0x0124:
+		case 0x0135:
+			ret = sony_nc_rfkill_setup(sony_nc_acpi_device);
+			break;
+		default:
+			continue;
+		}
+
+		if (ret < 0) {
+			pr_warn("handle 0x%.4x setup failed (ret: %i)",
+								handle, ret);
+		} else {
+			dprintk("handle 0x%.4x setup completed\n", handle);
+		}
+	}
+}
+
+static void sony_nc_snc_cleanup_handles(struct platform_device *pd)
+{
+	unsigned int i;
+
+	for (i = 0; i < ARRAY_SIZE(handles->cap); i++) {
+
+		int unsigned handle = handles->cap[i];
+
+		if (!handle)
+			continue;
+
+		dprintk("looking at handle 0x%.4x\n", handle);
+
+		switch (handle) {
+		case 0x0137:
+			sony_nc_kbd_backlight_cleanup(pd);
+			break;
+		case 0x0124:
+		case 0x0135:
+			sony_nc_rfkill_cleanup();
+			break;
+		default:
+			continue;
+		}
+
+		dprintk("handle 0x%.4x deconfigured\n", handle);
+	}
+}
+
  static int sony_nc_snc_setup(struct platform_device *pd)
  {
  	unsigned int i, string[4], bitmask, result;
@@ -1766,9 +1829,8 @@ static int sony_nc_snc_setup(struct plat
  		return -2;

  	/* setup found handles here */
-	sony_nc_kbd_backlight_setup(pd);
  	sony_nc_function_setup(sony_nc_acpi_device);
-	sony_nc_rfkill_setup(sony_nc_acpi_device);
+	sony_nc_snc_setup_handles(pd);

  	/* Enable all events for the found handles, otherwise return */
  	if (acpi_callsetfunc(sony_nc_acpi_handle, "SN02", bitmask, &result))
@@ -1788,8 +1850,7 @@ static int sony_nc_snc_cleanup(struct pl
  	acpi_callsetfunc(sony_nc_acpi_handle, "SN03", bitmask, &result);

  	/* cleanup handles here */
-	sony_nc_kbd_backlight_cleanup(pd);
-	sony_nc_rfkill_cleanup();
+	sony_nc_snc_cleanup_handles(pd);

  	sony_nc_handles_cleanup(pd);

[PATCH 6/25] sony-laptop: new notebook controller resume function

[Marco Chiappero]

New SNC resume function (sony_nc_resume) for better event and handle 
re-initialization called by sony_nc_resume, now pushed downwards near 
sony_nc_add and sony_nc_cleanup for better readability and fewer 
function prototypes.

Signed-off-by: Marco Chiappero <marco@absence.it>
---

--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -1241,45 +1241,6 @@ static int sony_nc_function_setup(struct
  	return 0;
  }

-static int sony_nc_resume(struct acpi_device *device)
-{
-	struct sony_nc_value *item;
-	acpi_handle handle;
-
-	for (item = sony_nc_values; item->name; item++) {
-		int ret;
-
-		if (!item->valid)
-			continue;
-		ret = acpi_callsetfunc(sony_nc_acpi_handle, *item->acpiset,
-				       item->value, NULL);
-		if (ret < 0) {
-			pr_err("%s: %d\n", __func__, ret);
-			break;
-		}
-	}
-
-	if (ACPI_SUCCESS(acpi_get_handle(sony_nc_acpi_handle, "ECON",
-					 &handle))) {
-		if (acpi_callsetfunc(sony_nc_acpi_handle, "ECON", 1, NULL))
-			dprintk("ECON Method failed\n");
-	}
-
-	if (ACPI_SUCCESS(acpi_get_handle(sony_nc_acpi_handle, "SN00",
-					 &handle))) {
-		dprintk("Doing SNC setup\n");
-		sony_nc_function_setup(device);
-	}
-
-	/* re-read rfkill state */
-	sony_nc_rfkill_update();
-
-	/* restore kbd backlight states */
-	sony_nc_kbd_backlight_resume();
-
-	return 0;
-}
-
  static void sony_nc_rfkill_cleanup(void)
  {
  	int i;
@@ -1857,6 +1818,45 @@ static int sony_nc_snc_cleanup(struct pl
  	return 0;
  }

+static int sony_nc_snc_resume(void)
+{
+	unsigned int i, result, bitmask;
+
+	/* retrieve the implemented offsets mask */
+	if (acpi_callsetfunc(sony_nc_acpi_handle, "SN00", 0x10, &bitmask))
+		return -EIO;
+
+	/* Enable all events, otherwise return */
+	if (acpi_callsetfunc(sony_nc_acpi_handle, "SN02", bitmask, &result))
+		return -EIO;
+
+	for (i = 0; i < ARRAY_SIZE(handles->cap); i++) {
+		int unsigned handle = handles->cap[i];
+
+		if (!handle)
+			continue;
+
+		dprintk("looking at handle 0x%.4x\n", handle);
+
+		switch (handle) {
+		case 0x0124:
+		case 0x0135:
+			/* re-read rfkill state */
+			sony_nc_rfkill_update();
+			break;
+		case 0x0137: /* kbd + als */
+			sony_nc_kbd_backlight_resume();
+			break;
+		default:
+			continue;
+		}
+
+		dprintk("handle 0x%.4x updated\n", handle);
+	}
+
+	return 0;
+}
+
  static int sony_nc_add(struct acpi_device *device)
  {
  	acpi_status status;
@@ -2001,6 +2001,40 @@ static int sony_nc_remove(struct acpi_de
  	return 0;
  }

+static int sony_nc_resume(struct acpi_device *device)
+{
+	struct sony_nc_value *item;
+	acpi_handle handle;
+
+	for (item = sony_nc_values; item->name; item++) {
+		int ret;
+
+		if (!item->valid)
+			continue;
+		ret = acpi_callsetfunc(sony_nc_acpi_handle, *item->acpiset,
+				       item->value, NULL);
+		if (ret < 0) {
+			pr_err("%s: %d\n", __func__, ret);
+			break;
+		}
+	}
+
+	if (ACPI_SUCCESS(acpi_get_handle(sony_nc_acpi_handle, "ECON",
+					 &handle))) {
+		if (acpi_callsetfunc(sony_nc_acpi_handle, "ECON", 1, NULL))
+			dprintk("ECON Method failed\n");
+	}
+
+	if (ACPI_SUCCESS(acpi_get_handle(sony_nc_acpi_handle, "SN00",
+					 &handle))) {
+		dprintk("Doing SNC setup\n");
+		sony_nc_function_setup(device);
+		sony_nc_snc_resume();
+	}
+
+	return 0;
+}
+
  static const struct acpi_device_id sony_device_ids[] = {
  	{SONY_NC_HID, 0},
  	{SONY_PIC_HID, 0},

[PATCH 7/25] sony-laptop: sony_nc_function_setup modifications

[Marco Chiappero]

Removed every init code, already present in sony_nc_snc_setup and 
sony_nc_snc_resume. Now calling only the handles present on the device, 
using the new setup and resume code.

Signed-off-by: Marco Chiappero <marco@absence.it>
---

--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -1225,18 +1225,14 @@ static acpi_status sony_walk_callback(ac
  /*
   * ACPI device
   */
-static int sony_nc_function_setup(struct acpi_device *device)
+static int sony_nc_function_setup(unsigned int handle)
  {
  	unsigned int result;

-	/* Enable all events */
-	acpi_callsetfunc(sony_nc_acpi_handle, "SN02", 0xffff, &result);
-
-	/* Setup hotkeys */
-	sony_call_snc_handle(0x0100, 0, &result);
-	sony_call_snc_handle(0x0101, 0, &result);
-	sony_call_snc_handle(0x0102, 0x100, &result);
-	sony_call_snc_handle(0x0127, 0, &result);
+	if (handle == 0x0102)
+		sony_call_snc_handle(0x0102, 0x100, &result);
+	else
+		sony_call_snc_handle(handle, 0, &result);

  	return 0;
  }
@@ -1711,6 +1707,12 @@ static void sony_nc_snc_setup_handles(st
  		dprintk("looking at handle 0x%.4x\n", handle);

  		switch (handle) {
+		case 0x0100:
+		case 0x0127:
+		case 0x0101:
+		case 0x0102:
+			ret = sony_nc_function_setup(handle);
+			break;
  		case 0x0137:
  			ret = sony_nc_kbd_backlight_setup(pd);
  			break;
@@ -1790,7 +1792,6 @@ static int sony_nc_snc_setup(struct plat
  		return -2;

  	/* setup found handles here */
-	sony_nc_function_setup(sony_nc_acpi_device);
  	sony_nc_snc_setup_handles(pd);

  	/* Enable all events for the found handles, otherwise return */
@@ -1839,6 +1840,12 @@ static int sony_nc_snc_resume(void)
  		dprintk("looking at handle 0x%.4x\n", handle);

  		switch (handle) {
+		case 0x0100:
+		case 0x0127:
+		case 0x0101:
+		case 0x0102:
+			sony_nc_function_setup(handle);
+			break;
  		case 0x0124:
  		case 0x0135:
  			/* re-read rfkill state */
@@ -2028,7 +2035,7 @@ static int sony_nc_resume(struct acpi_de
  	if (ACPI_SUCCESS(acpi_get_handle(sony_nc_acpi_handle, "SN00",
  					 &handle))) {
  		dprintk("Doing SNC setup\n");
-		sony_nc_function_setup(device);
+
  		sony_nc_snc_resume();
  	}

[PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Marco Chiappero]

sony_nc_notify rewritten (and placed near the other acpi callbacks), the 
hotkey decoding code move to a new function sony_nc_hotkeys_decode. Now 
generating acpi netlink events too.

Signed-off-by: Marco Chiappero <marco@absence.it>
---

--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -1151,62 +1151,6 @@ static struct sony_nc_event sony_127_eve
  /*
   * ACPI callbacks
   */
-static void sony_nc_notify(struct acpi_device *device, u32 event)
-{
-	u32 ev = event;
-
-	if (ev >= 0x90) {
-		/* New-style event */
-		unsigned int result;
-		int key_handle = 0;
-		ev -= 0x90;
-
-		if (sony_find_snc_handle(0x100) == ev)
-			key_handle = 0x100;
-		if (sony_find_snc_handle(0x127) == ev)
-			key_handle = 0x127;
-
-		if (key_handle) {
-			struct sony_nc_event *key_event;
-
-			if (sony_call_snc_handle(key_handle, 0x200, &result)) {
-				dprintk("sony_nc_notify, unable to decode"
-					" event 0x%.2x 0x%.2x\n", key_handle,
-					ev);
-				/* restore the original event */
-				ev = event;
-			} else {
-				ev = result & 0xFF;
-
-				if (key_handle == 0x100)
-					key_event = sony_100_events;
-				else
-					key_event = sony_127_events;
-
-				for (; key_event->data; key_event++) {
-					if (key_event->data == ev) {
-						ev = key_event->event;
-						break;
-					}
-				}
-
-				if (!key_event->data)
-					pr_info("Unknown event: 0x%x 0x%x\n",
-						key_handle, ev);
-				else
-					sony_laptop_report_input_event(ev);
-			}
-		} else if (sony_find_snc_handle(sony_rfkill_handle) == ev) {
-			sony_nc_rfkill_update();
-			return;
-		}
-	} else
-		sony_laptop_report_input_event(ev);
-
-	dprintk("sony_nc_notify, event: 0x%.2x\n", ev);
-	acpi_bus_generate_proc_event(sony_nc_acpi_device, 1, ev);
-}
-
  static acpi_status sony_walk_callback(acpi_handle handle, u32 level,
  				      void *context, void **return_value)
  {
@@ -1237,6 +1181,42 @@ static int sony_nc_function_setup(unsign
  	return 0;
  }

+static int sony_nc_hotkeys_decode(unsigned int handle)
+{
+	int ret = 0;
+	unsigned int result = 0;
+	struct sony_nc_event *key_event;
+
+	if (sony_call_snc_handle(handle, 0x200, &result)) {
+		dprintk("sony_nc_hotkeys_decode,"
+				" unable to retrieve the hotkey\n");
+		ret = -1;
+	} else {
+		result &= 0xff;
+
+		if (handle == 0x100)
+			key_event = sony_100_events;
+		else
+			key_event = sony_127_events;
+
+		for (; key_event->data; key_event++) {
+			if (key_event->data == result) {
+				ret = key_event->event;
+				break;
+			}
+		}
+
+		if (!key_event->data)
+			pr_info("Unknown hotkey 0x%.2x (handle 0x%.2x)\n",
+							result, handle);
+		else
+			dprintk("sony_nc_hotkeys_decode, hotkey 0x%.2x decoded "
+					"to event 0x%.2x\n", result, ret);
+	}
+
+	return ret;
+}
+
  static void sony_nc_rfkill_cleanup(void)
  {
  	int i;
@@ -1864,6 +1844,52 @@ static int sony_nc_snc_resume(void)
  	return 0;
  }

+static void sony_nc_notify(struct acpi_device *device, u32 event)
+{
+	u8 ev = 0;
+	int value = 0;
+
+	dprintk("sony_nc_notify, event: 0x%.2x\n", event);
+
+	/* handles related events */
+	if (event >= 0x90) {
+		unsigned int result = 0, handle = 0;
+
+		/* the event should corrispond to the offset of the method */
+		unsigned int offset = event - 0x90;
+
+		handle = handles->cap[offset];
+		switch (handle) {
+		/* list of handles known for generating events */
+		case 0x0100:
+		case 0x0127:
+			/* hotkey event, a key has been pressed, retrieve it */
+			value = sony_nc_hotkeys_decode(handle);
+			if (value > 0) /* known event */
+				sony_laptop_report_input_event(value);
+			/* else unknown event or failure, do nothing */
+			ev = 1;
+			break;
+
+		default:
+			value = event;
+			dprintk("Unknowk event for handle: 0x%x\n", handle);
+			break;
+		}
+
+		/* clear the event (and the event reason when present) */
+		acpi_callsetfunc(sony_nc_acpi_handle, "SN05", 1 << offset,
+				&result);
+	} else {
+		ev = 1;
+		sony_laptop_report_input_event(event);
+	}
+
+	acpi_bus_generate_proc_event(device, ev, value);
+	acpi_bus_generate_netlink_event(device->pnp.device_class,
+					dev_name(&device->dev), ev, value);
+}
+
  static int sony_nc_add(struct acpi_device *device)
  {
  	acpi_status status;

[PATCH 9/25] sony-laptop: sony_walk_callback moved for better readability

[Marco Chiappero]

sony_walk_callback moved to stay close to the other ACPI callbacks for 
better code readability.

Signed-off-by: Marco Chiappero <marco@absence.it>
---

--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -1149,24 +1149,6 @@ static struct sony_nc_event sony_127_eve
  };

  /*
- * ACPI callbacks
- */
-static acpi_status sony_walk_callback(acpi_handle handle, u32 level,
-				      void *context, void **return_value)
-{
-	struct acpi_device_info *info;
-
-	if (ACPI_SUCCESS(acpi_get_object_info(handle, &info))) {
-		pr_warn("method: name: %4.4s, args %X\n",
-			(char *)&info->name, info->param_count);
-
-		kfree(info);
-	}
-
-	return AE_OK;
-}
-
-/*
   * ACPI device
   */
  static int sony_nc_function_setup(unsigned int handle)
@@ -1844,6 +1826,24 @@ static int sony_nc_snc_resume(void)
  	return 0;
  }

+/*
+ * ACPI callbacks
+ */
+static acpi_status sony_walk_callback(acpi_handle handle, u32 level,
+				      void *context, void **return_value)
+{
+	struct acpi_device_info *info;
+
+	if (ACPI_SUCCESS(acpi_get_object_info(handle, &info))) {
+		pr_warn("method: name: %4.4s, args %X\n",
+			(char *)&info->name, info->param_count);
+
+		kfree(info);
+	}
+
+	return AE_OK;
+}
+
  static void sony_nc_notify(struct acpi_device *device, u32 event)
  {
  	u8 ev = 0;

[PATCH 10/25] sony-laptop: keyboard backlight support extended to newer Vaios

[Marco Chiappero]

Added support for handle 0x0143 (Vaio SA/SB/SC, CA/CB). Minor 
corrections included.

Signed-off-by: Marco Chiappero <marco@absence.it>
---

--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -127,7 +127,7 @@ MODULE_PARM_DESC(minor,
  		 "default is -1 (automatic)");
  #endif

-static int kbd_backlight;	/* = 1 */
+static int kbd_backlight;	/* = 0 */
  module_param(kbd_backlight, int, 0444);
  MODULE_PARM_DESC(kbd_backlight,
  		 "set this to 0 to disable keyboard backlight, "
@@ -140,15 +140,6 @@ MODULE_PARM_DESC(kbd_backlight_timeout,
  		 "1 for 30 seconds, 2 for 60 seconds and 3 to disable timeout "
  		 "(default: 0)");

-static void sony_nc_kbd_backlight_resume(void);
-
-enum sony_nc_rfkill {
-	SONY_WIFI,
-	SONY_BLUETOOTH,
-	SONY_WWAN,
-	SONY_WIMAX,
-	N_SONY_RFKILL,
-};

  static int sony_rfkill_handle;
  static struct rfkill *sony_rfkill_devices[N_SONY_RFKILL];
@@ -1356,38 +1347,33 @@ static int sony_nc_rfkill_setup(struct a
  }

  /* Keyboard backlight feature */
-#define KBDBL_HANDLER	0x137
-#define KBDBL_PRESENT	0xB00
-#define	SET_MODE	0xC00
-#define SET_STATE	0xD00
-#define SET_TIMEOUT	0xE00
-
  struct kbd_backlight {
-	int mode;
-	int timeout;
+	unsigned int base;
+	unsigned int mode;
+	unsigned int timeout;
  	struct device_attribute mode_attr;
  	struct device_attribute timeout_attr;
  };
-
  static struct kbd_backlight *kbdbl_handle;
+static int sony_kbd_handle = -1;

-static ssize_t __sony_nc_kbd_backlight_mode_set(u8 value)
+static int __sony_nc_kbd_backlight_mode_set(u8 value)
  {
  	unsigned int result;

  	if (value > 1)
  		return -EINVAL;

-	if (sony_call_snc_handle(KBDBL_HANDLER,
-				(value << 0x10) | SET_MODE, &result))
+	if (sony_call_snc_handle(sony_kbd_handle, (value << 0x10) |
+				(kbdbl_handle->base), &result))
  		return -EIO;

-	/* Try to turn the light on/off immediately */
-	sony_call_snc_handle(KBDBL_HANDLER, (value << 0x10) | SET_STATE,
-			&result);
-
  	kbdbl_handle->mode = value;

+	/* Try to turn the light on/off immediately */
+	sony_call_snc_handle(sony_kbd_handle, (value << 0x10) |
+				(kbdbl_handle->base + 0x100), &result);
+
  	return 0;
  }

@@ -1415,7 +1401,9 @@ static ssize_t sony_nc_kbd_backlight_mod
  		struct device_attribute *attr, char *buffer)
  {
  	ssize_t count = 0;
+
  	count = snprintf(buffer, PAGE_SIZE, "%d\n", kbdbl_handle->mode);
+
  	return count;
  }

@@ -1426,8 +1414,8 @@ static int __sony_nc_kbd_backlight_timeo
  	if (value > 3)
  		return -EINVAL;

-	if (sony_call_snc_handle(KBDBL_HANDLER,
-				(value << 0x10) | SET_TIMEOUT, &result))
+	if (sony_call_snc_handle(sony_kbd_handle, (value << 0x10) |
+				(kbdbl_handle->base + 0x200), &result))
  		return -EIO;

  	kbdbl_handle->timeout = value;
@@ -1459,18 +1447,36 @@ static ssize_t sony_nc_kbd_backlight_tim
  		struct device_attribute *attr, char *buffer)
  {
  	ssize_t count = 0;
+
  	count = snprintf(buffer, PAGE_SIZE, "%d\n", kbdbl_handle->timeout);
+
  	return count;
  }

  static int sony_nc_kbd_backlight_setup(struct platform_device *pd)
  {
-	unsigned int result;
+	unsigned int result, base_cmd;
+	bool found = false;

-	if (sony_call_snc_handle(KBDBL_HANDLER, KBDBL_PRESENT, &result))
-		return 0;
-	if (!(result & 0x02))
+	/* verify the kbd backlight presence, some models do not have it */
+	if (sony_kbd_handle == 0x0137) {
+		if (sony_call_snc_handle(sony_kbd_handle, 0x0B00, &result))
+			return -EIO;
+
+		found = !!(result & 0x02);
+		base_cmd = 0x0C00;
+	} else {
+		if (sony_call_snc_handle(sony_kbd_handle, 0x0100, &result))
+			return -EIO;
+
+		found = result & 0x01;
+		base_cmd = 0x4000;
+	}
+
+	if (!found) {
+		dprintk("no backlight keyboard found\n");
  		return 0;
+	}

  	kbdbl_handle = kzalloc(sizeof(*kbdbl_handle), GFP_KERNEL);
  	if (!kbdbl_handle)
@@ -1494,6 +1500,8 @@ static int sony_nc_kbd_backlight_setup(s
  	if (device_create_file(&pd->dev, &kbdbl_handle->timeout_attr))
  		goto outmode;

+	kbdbl_handle->base = base_cmd;
+
  	__sony_nc_kbd_backlight_mode_set(kbd_backlight);
  	__sony_nc_kbd_backlight_timeout_set(kbd_backlight_timeout);

@@ -1516,28 +1524,32 @@ static int sony_nc_kbd_backlight_cleanup
  		device_remove_file(&pd->dev, &kbdbl_handle->timeout_attr);

  		/* restore the default hw behaviour */
-		sony_call_snc_handle(KBDBL_HANDLER, 0x1000 | SET_MODE, &result);
-		sony_call_snc_handle(KBDBL_HANDLER, SET_TIMEOUT, &result);
+		sony_call_snc_handle(sony_kbd_handle,
+				kbdbl_handle->base | 0x10000, &result);
+		sony_call_snc_handle(sony_kbd_handle,
+				kbdbl_handle->base + 0x200, &result);

  		kfree(kbdbl_handle);
+		kbdbl_handle = NULL;
  	}
  	return 0;
  }

  static void sony_nc_kbd_backlight_resume(void)
  {
-	unsigned int ignore = 0;
+	unsigned int result;

  	if (!kbdbl_handle)
  		return;

  	if (kbdbl_handle->mode == 0)
-		sony_call_snc_handle(KBDBL_HANDLER, SET_MODE, &ignore);
+		sony_call_snc_handle(sony_kbd_handle,
+				kbdbl_handle->base, &result);

  	if (kbdbl_handle->timeout != 0)
-		sony_call_snc_handle(KBDBL_HANDLER,
-				(kbdbl_handle->timeout << 0x10) | SET_TIMEOUT,
-				&ignore);
+		sony_call_snc_handle(sony_kbd_handle,
+				(kbdbl_handle->base + 0x200) |
+				(kbdbl_handle->timeout << 0x10), &result);
  }

  static void sony_nc_backlight_ng_read_limits(int handle,
@@ -1676,6 +1688,8 @@ static void sony_nc_snc_setup_handles(st
  			ret = sony_nc_function_setup(handle);
  			break;
  		case 0x0137:
+		case 0x0143:
+			sony_kbd_handle = handle;
  			ret = sony_nc_kbd_backlight_setup(pd);
  			break;
  		case 0x0124:
@@ -1710,6 +1724,7 @@ static void sony_nc_snc_cleanup_handles(

  		switch (handle) {
  		case 0x0137:
+		case 0x0143:
  			sony_nc_kbd_backlight_cleanup(pd);
  			break;
  		case 0x0124:
@@ -1814,6 +1829,7 @@ static int sony_nc_snc_resume(void)
  			sony_nc_rfkill_update();
  			break;
  		case 0x0137: /* kbd + als */
+		case 0x0143:
  			sony_nc_kbd_backlight_resume();
  			break;
  		default:

[PATCH 11/25] sony-laptop: rfkill improvements

[Marco Chiappero]

- added sony_nc_get_rfkill_hwblock helper function
- rfkill type now persistent, using the hardware stored device power state
- added support for newer WWAN modules
- handle detection removed because no longer necessary
- now notifying rfkill events to the acpi bus

Signed-off-by: Marco Chiappero <marco@absence.it>
---

--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -141,10 +141,7 @@ MODULE_PARM_DESC(kbd_backlight_timeout,
  		 "(default: 0)");


-static int sony_rfkill_handle;
-static struct rfkill *sony_rfkill_devices[N_SONY_RFKILL];
-static int sony_rfkill_address[N_SONY_RFKILL] = {0x300, 0x500, 0x700, 
0x900};
-static void sony_nc_rfkill_update(void);
+static int sony_rfkill_handle = -1;

  /*********** Input Devices ***********/

@@ -1190,6 +1187,26 @@ static int sony_nc_hotkeys_decode(unsign
  	return ret;
  }

+enum sony_nc_rfkill {
+	SONY_WIFI,
+	SONY_BLUETOOTH,
+	SONY_WWAN,
+	SONY_WIMAX,
+	N_SONY_RFKILL,
+};
+static struct rfkill *sony_rfkill_devices[N_SONY_RFKILL];
+static int sony_rfkill_address[N_SONY_RFKILL] = {0x300, 0x500, 0x700, 
0x900};
+
+static int sony_nc_get_rfkill_hwblock(void)
+{
+	unsigned int result;
+
+	if (sony_call_snc_handle(sony_rfkill_handle, 0x200, &result))
+		return -1;
+
+	return result & 0x1;
+}
+
  static void sony_nc_rfkill_cleanup(void)
  {
  	int i;
@@ -1204,9 +1221,14 @@ static void sony_nc_rfkill_cleanup(void)

  static int sony_nc_rfkill_set(void *data, bool blocked)
  {
-	unsigned int result;
-	unsigned int argument = sony_rfkill_address[(long) data] + 0x100;
+	unsigned int result, argument = sony_rfkill_address[(long) data];

+	/* do not force an already set state */
+	sony_call_snc_handle(sony_rfkill_handle, argument, &result);
+	if ((result & 0x1) == !blocked)
+		return 0;
+
+	argument += 0x100;
  	if (!blocked)
  		argument |= 0xff0000;

@@ -1225,7 +1247,7 @@ static int sony_nc_setup_rfkill(struct a
  	enum rfkill_type type;
  	const char *name;
  	unsigned int result;
-	bool hwblock;
+	bool hwblock, swblock;

  	switch (nc_type) {
  	case SONY_WIFI:
@@ -1255,6 +1277,13 @@ static int sony_nc_setup_rfkill(struct a

  	sony_call_snc_handle(sony_rfkill_handle, 0x200, &result);
  	hwblock = !(result & 0x1);
+
+	result = 0;
+	sony_call_snc_handle(sony_rfkill_handle, sony_rfkill_address[nc_type],
+				&result);
+	swblock = !(result & 0x2);
+
+	rfkill_init_sw_state(rfk, swblock);
  	rfkill_set_hw_state(rfk, hwblock);

  	err = rfkill_register(rfk);
@@ -1281,16 +1310,9 @@ static void sony_nc_rfkill_update(void)
  		if (!sony_rfkill_devices[i])
  			continue;

-		if (hwblock) {
-			if (rfkill_set_hw_state(sony_rfkill_devices[i], true)) {
-				/* we already know we're blocked */
-			}
-			continue;
-		}
-
  		sony_call_snc_handle(sony_rfkill_handle, argument, &result);
  		rfkill_set_states(sony_rfkill_devices[i],
-				  !(result & 0xf), false);
+				  !(result & 0x2), hwblock);
  	}
  }

@@ -1298,17 +1320,7 @@ static int sony_nc_rfkill_setup(struct a
  {
  #define	RFKILL_BUFF_SIZE 8
  	u8 dev_code, i, buff[RFKILL_BUFF_SIZE] = { 0 };
-	int offset;

-	offset = sony_find_snc_handle(0x124);
-	if (offset == -1) {
-		offset = sony_find_snc_handle(0x135);
-		if (offset == -1)
-			return 0;
-		else
-			sony_rfkill_handle = 0x135;
-	} else
-		sony_rfkill_handle = 0x124;
  	dprintk("Found rkfill handle: 0x%.4x\n", sony_rfkill_handle);

  	/* need to read the whole buffer returned by the acpi call to SN06
@@ -1327,6 +1339,25 @@ static int sony_nc_rfkill_setup(struct a
  		if (dev_code == 0xff)
  			break;

+		/*
+		   known codes:
+
+		   0x00	WLAN
+		   0x10 BLUETOOTH
+		   0x20 WWAN GPRS-EDGE
+		   0x21 WWAN HSDPA
+		   0x22 WWAN EV-DO
+		   0x23 WWAN GPS
+		   0x25	Gobi WWAN no GPS
+		   0x26 Gobi WWAN + GPS
+		   0x28	Gobi WWAN no GPS
+		   0x29 Gobi WWAN + GPS
+		   0x50	Gobi WWAN no GPS
+		   0x51 Gobi WWAN + GPS
+		   0x30	WIMAX
+		   0x70 no SIM card slot
+		   0x71 SIM card slot
+		*/
  		dprintk("Radio devices, looking at 0x%.2x\n", dev_code);

  		if (dev_code == 0 && !sony_rfkill_devices[SONY_WIFI])
@@ -1335,7 +1366,7 @@ static int sony_nc_rfkill_setup(struct a
  		if (dev_code == 0x10 && !sony_rfkill_devices[SONY_BLUETOOTH])
  			sony_nc_setup_rfkill(device, SONY_BLUETOOTH);

-		if ((0xf0 & dev_code) == 0x20 &&
+		if (((0xf0 & dev_code) == 0x20 || (0xf0 & dev_code) == 0x50) &&
  				!sony_rfkill_devices[SONY_WWAN])
  			sony_nc_setup_rfkill(device, SONY_WWAN);

@@ -1694,6 +1725,7 @@ static void sony_nc_snc_setup_handles(st
  			break;
  		case 0x0124:
  		case 0x0135:
+			sony_rfkill_handle = handle;
  			ret = sony_nc_rfkill_setup(sony_nc_acpi_device);
  			break;
  		default:
@@ -1887,6 +1919,30 @@ static void sony_nc_notify(struct acpi_d
  			ev = 1;
  			break;

+		case 0x0124:
+		case 0x0135:
+			sony_call_snc_handle(sony_rfkill_handle, 0x0100,
+						&result);
+			result &= 0x03;
+			dprintk("sony_nc_notify, RFKILL event received "
+					"(reason: %s)\n", result == 1 ?
+					"switch state changed" : "battery");
+
+			if (result == 1) { /* hw swtich event */
+				sony_nc_rfkill_update();
+				sony_laptop_report_input_event(
+						SONYPI_EVENT_RFKILL_ALL);
+				value = sony_nc_get_rfkill_hwblock();
+			} else if (result == 2) { /* battery event */
+				/*  we should change the WWAN rfkill
+				    state when the battery state changes
+				 */
+				return;
+			}
+
+			ev = 2;
+			break;
+
  		default:
  			value = event;
  			dprintk("Unknowk event for handle: 0x%x\n", handle);

[PATCH 12/25] sony-laptop: input core improvements improvements

[Marco Chiappero]

The code is now forwarding the SW_RFKILL_ALL event; added a couple of Fn 
combos too.

Signed-off-by: Marco Chiappero <marco@absence.it>
---

--- a/include/linux/sonypi.h
+++ b/include/linux/sonypi.h
@@ -114,6 +114,7 @@
  #define SONYPI_EVENT_BRIGHTNESS_PRESSED		71
  #define SONYPI_EVENT_MEDIA_PRESSED		72
  #define SONYPI_EVENT_VENDOR_PRESSED		73
+#define SONYPI_EVENT_RFKILL_ALL			74

  /* get/set brightness */
  #define SONYPI_IOCGBRT		_IOR('v', 0, __u8)
--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -142,6 +142,7 @@ MODULE_PARM_DESC(kbd_backlight_timeout,


  static int sony_rfkill_handle = -1;
+static int sony_nc_get_rfkill_hwblock(void);

  /*********** Input Devices ***********/

@@ -241,7 +242,8 @@ static int sony_laptop_input_index[] = {
  	57,	/* 70 SONYPI_EVENT_VOLUME_DEC_PRESSED */
  	-1,	/* 71 SONYPI_EVENT_BRIGHTNESS_PRESSED */
  	58,	/* 72 SONYPI_EVENT_MEDIA_PRESSED */
-	59,	/* 72 SONYPI_EVENT_VENDOR_PRESSED */
+	59,	/* 73 SONYPI_EVENT_VENDOR_PRESSED */
+	-1,	/* 74 SONYPI_EVENT_RFKILL_ALL */
  };

  static int sony_laptop_input_keycode_map[] = {
@@ -335,6 +337,7 @@ static void sony_laptop_report_input_eve
  	struct input_dev *jog_dev = sony_laptop_input.jog_dev;
  	struct input_dev *key_dev = sony_laptop_input.key_dev;
  	struct sony_laptop_keypress kp = { NULL };
+	int rfk_switch;

  	if (event == SONYPI_EVENT_FNKEY_RELEASED ||
  			event == SONYPI_EVENT_ANYBUTTON_RELEASED) {
@@ -363,6 +366,14 @@ static void sony_laptop_report_input_eve
  		kp.dev = jog_dev;
  		break;

+	case SONYPI_EVENT_RFKILL_ALL:
+		rfk_switch = sony_nc_get_rfkill_hwblock();
+		if (!(rfk_switch < 0)) {
+			input_report_switch(key_dev, SW_RFKILL_ALL, rfk_switch);
+			input_sync(key_dev);
+		}
+		return;
+
  	default:
  		if (event >= ARRAY_SIZE(sony_laptop_input_index)) {
  			dprintk("sony_laptop_report_input_event, event not known: %d\n", 
event);
@@ -438,6 +449,14 @@ static int sony_laptop_setup_input(struc
  		__set_bit(sony_laptop_input_keycode_map[i], key_dev->keybit);
  	__clear_bit(KEY_RESERVED, key_dev->keybit);

+	if (sony_rfkill_handle != -1) {
+		int rfk_switch;
+
+		rfk_switch = sony_nc_get_rfkill_hwblock();
+		input_set_capability(key_dev, EV_SW, SW_RFKILL_ALL);
+		input_report_switch(key_dev, SW_RFKILL_ALL, rfk_switch);
+	}
+
  	error = input_register_device(key_dev);
  	if (error)
  		goto err_free_keydev;
@@ -1079,10 +1098,6 @@ struct sony_nc_event {
  };

  static struct sony_nc_event sony_100_events[] = {
-	{ 0x90, SONYPI_EVENT_PKEY_P1 },
-	{ 0x10, SONYPI_EVENT_ANYBUTTON_RELEASED },
-	{ 0x91, SONYPI_EVENT_PKEY_P2 },
-	{ 0x11, SONYPI_EVENT_ANYBUTTON_RELEASED },
  	{ 0x81, SONYPI_EVENT_FNKEY_F1 },
  	{ 0x01, SONYPI_EVENT_FNKEY_RELEASED },
  	{ 0x82, SONYPI_EVENT_FNKEY_F2 },
@@ -1097,12 +1112,20 @@ static struct sony_nc_event sony_100_eve
  	{ 0x06, SONYPI_EVENT_FNKEY_RELEASED },
  	{ 0x87, SONYPI_EVENT_FNKEY_F7 },
  	{ 0x07, SONYPI_EVENT_FNKEY_RELEASED },
+	{ 0x88, SONYPI_EVENT_FNKEY_F8 },
+	{ 0x08, SONYPI_EVENT_FNKEY_RELEASED },
  	{ 0x89, SONYPI_EVENT_FNKEY_F9 },
  	{ 0x09, SONYPI_EVENT_FNKEY_RELEASED },
  	{ 0x8A, SONYPI_EVENT_FNKEY_F10 },
  	{ 0x0A, SONYPI_EVENT_FNKEY_RELEASED },
+	{ 0x8B, SONYPI_EVENT_FNKEY_F11 },
+	{ 0x0B, SONYPI_EVENT_FNKEY_RELEASED },
  	{ 0x8C, SONYPI_EVENT_FNKEY_F12 },
  	{ 0x0C, SONYPI_EVENT_FNKEY_RELEASED },
+	{ 0x90, SONYPI_EVENT_PKEY_P1 },
+	{ 0x10, SONYPI_EVENT_ANYBUTTON_RELEASED },
+	{ 0x91, SONYPI_EVENT_PKEY_P2 },
+	{ 0x11, SONYPI_EVENT_ANYBUTTON_RELEASED },
  	{ 0x9d, SONYPI_EVENT_ZOOM_PRESSED },
  	{ 0x1d, SONYPI_EVENT_ANYBUTTON_RELEASED },
  	{ 0x9f, SONYPI_EVENT_CD_EJECT_PRESSED },

[PATCH 13/25] sony-laptop: code style fixes

[Marco Chiappero]

This patch fixes many style ERROR and WARNING complains by checkpatch 
about the old code.

Signed-off-by: Marco Chiappero <marco@absence.it>
---

--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -63,7 +63,7 @@
  #include <linux/slab.h>
  #include <acpi/acpi_drivers.h>
  #include <acpi/acpi_bus.h>
-#include <asm/uaccess.h>
+#include <linux/uaccess.h>
  #include <linux/sonypi.h>
  #include <linux/sony-laptop.h>
  #include <linux/rfkill.h>
@@ -376,7 +376,8 @@ static void sony_laptop_report_input_eve

  	default:
  		if (event >= ARRAY_SIZE(sony_laptop_input_index)) {
-			dprintk("sony_laptop_report_input_event, event not known: %d\n", event);
+			dprintk("sony_laptop_report_input_event, "
+				"event not known: %d\n", event);
  			break;
  		}
  		if (sony_laptop_input_index[event] != -1) {
@@ -572,12 +573,12 @@ static int sony_pf_add(void)

  	return 0;

-      out_platform_alloced:
+out_platform_alloced:
  	platform_device_put(sony_pf_device);
  	sony_pf_device = NULL;
-      out_platform_registered:
+out_platform_registered:
  	platform_driver_unregister(&sony_pf_driver);
-      out:
+out:
  	atomic_dec(&sony_pf_users);
  	return ret;
  }
@@ -671,7 +672,8 @@ static struct sony_nc_value sony_nc_valu
  	SNC_HANDLE(brightness_default, snc_brightness_def_get,
  			snc_brightness_def_set, brightness_default_validate, 0),
  	SNC_HANDLE(fnkey, snc_fnkey_get, NULL, NULL, 0),
-	SNC_HANDLE(cdpower, snc_cdpower_get, snc_cdpower_set, 
boolean_validate, 0),
+	SNC_HANDLE(cdpower, snc_cdpower_get, snc_cdpower_set,
+			boolean_validate, 0),
  	SNC_HANDLE(audiopower, snc_audiopower_get, snc_audiopower_set,
  			boolean_validate, 0),
  	SNC_HANDLE(lanpower, snc_lanpower_get, snc_lanpower_set,
@@ -691,7 +693,7 @@ static struct sony_nc_value sony_nc_valu
  };

  static acpi_handle sony_nc_acpi_handle;
-static struct acpi_device *sony_nc_acpi_device = NULL;
+static struct acpi_device *sony_nc_acpi_device;

  /*
   * acpi_evaluate_object wrappers
@@ -738,7 +740,8 @@ static int acpi_callsetfunc(acpi_handle
  	if (status == AE_OK) {
  		if (result != NULL) {
  			if (out_obj.type != ACPI_TYPE_INTEGER) {
-				pr_warn("acpi_evaluate_object bad return type\n");
+				pr_warn("acpi_evaluate_object bad "
+					"return type\n");
  				return -1;
  			}
  			*result = out_obj.integer.value;
@@ -951,11 +954,11 @@ static int sony_call_snc_handle_buffer(i
  static int brightness_default_validate(const int direction, const int 
value)
  {
  	switch (direction) {
-		case SNC_VALIDATE_OUT:
-			return value - 1;
-		case SNC_VALIDATE_IN:
-			if (value >= 0 && value < SONY_MAX_BRIGHTNESS)
-				return value + 1;
+	case SNC_VALIDATE_OUT:
+		return value - 1;
+	case SNC_VALIDATE_IN:
+		if (value >= 0 && value < SONY_MAX_BRIGHTNESS)
+			return value + 1;
  	}
  	return -EINVAL;
  }
@@ -977,8 +980,9 @@ static int boolean_validate(const int di
  /*
   * Sysfs show/store common to all sony_nc_values
   */
-static ssize_t sony_nc_sysfs_show(struct device *dev, struct 
device_attribute *attr,
-			      char *buffer)
+static ssize_t sony_nc_sysfs_show(struct device *dev,
+					struct device_attribute *attr,
+					char *buffer)
  {
  	unsigned int value;
  	struct sony_nc_value *item =
@@ -1019,7 +1023,8 @@ static ssize_t sony_nc_sysfs_store(struc
  	if (value < 0)
  		return value;

-	if (acpi_callsetfunc(sony_nc_acpi_handle, *item->acpiset, value, NULL) 
< 0)
+	if (acpi_callsetfunc(sony_nc_acpi_handle,
+				*item->acpiset, value, NULL) < 0)
  		return -EIO;
  	item->value = value;
  	item->valid = 1;
@@ -2001,7 +2006,8 @@ static int sony_nc_add(struct acpi_devic

  	/* read device status */
  	result = acpi_bus_get_status(device);
-	/* bail IFF the above call was successful and the device is not present */
+	/* bail IFF the above call was successful
+	   and the device is not present */
  	if (!result && !device->status.present) {
  		dprintk("Device not present\n");
  		result = -ENODEV;
@@ -2045,7 +2051,8 @@ static int sony_nc_add(struct acpi_devic
  	}

  	if (acpi_video_backlight_support()) {
-		pr_info("brightness ignored, must be controlled by ACPI video driver\n");
+		pr_info("brightness ignored, must be "
+			"controlled by ACPI video driver\n");
  	} else {
  		sony_nc_backlight_setup();
  	}
@@ -2091,21 +2098,21 @@ static int sony_nc_add(struct acpi_devic

  	return 0;

-      out_sysfs:
-	for (item = sony_nc_values; item->name; ++item) {
+out_sysfs:
+	for (item = sony_nc_values; item->name; ++item)
  		device_remove_file(&sony_pf_device->dev, &item->devattr);
-	}
+
  	sony_nc_backlight_cleanup();

  	sony_laptop_remove_input();

-      outsnc:
+outsnc:
  	sony_nc_snc_cleanup(sony_pf_device);

-      outpresent:
+outpresent:
  	sony_pf_remove();

-      outwalk:
+outwalk:
  	return result;
  }

@@ -2117,9 +2124,8 @@ static int sony_nc_remove(struct acpi_de

  	sony_nc_acpi_device = NULL;

-	for (item = sony_nc_values; item->name; ++item) {
+	for (item = sony_nc_values; item->name; ++item)
  		device_remove_file(&sony_pf_device->dev, &item->devattr);
-	}

  	sony_nc_snc_cleanup(sony_pf_device);
  	sony_pf_remove();
@@ -2501,11 +2507,14 @@ static u8 sony_pic_call3(u8 dev, u8 fn,
  {
  	u8 v1;

-	wait_on_command(inb_p(spic_dev.cur_ioport->io1.minimum + 4) & 2, 
ITERATIONS_LONG);
+	wait_on_command(inb_p(spic_dev.cur_ioport->io1.minimum + 4) & 2,
+			ITERATIONS_LONG);
  	outb(dev, spic_dev.cur_ioport->io1.minimum + 4);
-	wait_on_command(inb_p(spic_dev.cur_ioport->io1.minimum + 4) & 2, 
ITERATIONS_LONG);
+	wait_on_command(inb_p(spic_dev.cur_ioport->io1.minimum + 4) & 2,
+			ITERATIONS_LONG);
  	outb(fn, spic_dev.cur_ioport->io1.minimum);
-	wait_on_command(inb_p(spic_dev.cur_ioport->io1.minimum + 4) & 2, 
ITERATIONS_LONG);
+	wait_on_command(inb_p(spic_dev.cur_ioport->io1.minimum + 4) & 2,
+			ITERATIONS_LONG);
  	outb(v, spic_dev.cur_ioport->io1.minimum);
  	v1 = inb_p(spic_dev.cur_ioport->io1.minimum);
  	dprintk("sony_pic_call3(0x%.2x - 0x%.2x - 0x%.2x): 0x%.4x\n",
@@ -2619,19 +2628,19 @@ out:
  /* the rest don't need a loop until not 0xff */
  #define SONYPI_CAMERA_AGC			6
  #define SONYPI_CAMERA_AGC_MASK			0x30
-#define SONYPI_CAMERA_SHUTTER_MASK 		0x7
+#define SONYPI_CAMERA_SHUTTER_MASK		0x7

  #define SONYPI_CAMERA_SHUTDOWN_REQUEST		7
  #define SONYPI_CAMERA_CONTROL			0x10

-#define SONYPI_CAMERA_STATUS 			7
-#define SONYPI_CAMERA_STATUS_READY 		0x2
+#define SONYPI_CAMERA_STATUS			7
+#define SONYPI_CAMERA_STATUS_READY		0x2
  #define SONYPI_CAMERA_STATUS_POSITION		0x4

-#define SONYPI_DIRECTION_BACKWARDS 		0x4
+#define SONYPI_DIRECTION_BACKWARDS		0x4

-#define SONYPI_CAMERA_REVISION 			8
-#define SONYPI_CAMERA_ROMVERSION 		9
+#define SONYPI_CAMERA_REVISION			8
+#define SONYPI_CAMERA_ROMVERSION		9

  static int __sony_pic_camera_ready(void)
  {
@@ -2715,28 +2724,28 @@ int sony_pic_camera_command(int command,
  			__sony_pic_camera_off();
  		break;
  	case SONY_PIC_COMMAND_SETCAMERABRIGHTNESS:
-		wait_on_command(sony_pic_call3(0x90, SONYPI_CAMERA_BRIGHTNESS, value),
-				ITERATIONS_SHORT);
+		wait_on_command(sony_pic_call3(0x90, SONYPI_CAMERA_BRIGHTNESS,
+				value),	ITERATIONS_SHORT);
  		break;
  	case SONY_PIC_COMMAND_SETCAMERACONTRAST:
-		wait_on_command(sony_pic_call3(0x90, SONYPI_CAMERA_CONTRAST, value),
-				ITERATIONS_SHORT);
+		wait_on_command(sony_pic_call3(0x90, SONYPI_CAMERA_CONTRAST,
+				value),	ITERATIONS_SHORT);
  		break;
  	case SONY_PIC_COMMAND_SETCAMERAHUE:
  		wait_on_command(sony_pic_call3(0x90, SONYPI_CAMERA_HUE, value),
  				ITERATIONS_SHORT);
  		break;
  	case SONY_PIC_COMMAND_SETCAMERACOLOR:
-		wait_on_command(sony_pic_call3(0x90, SONYPI_CAMERA_COLOR, value),
-				ITERATIONS_SHORT);
+		wait_on_command(sony_pic_call3(0x90, SONYPI_CAMERA_COLOR,
+				value),	ITERATIONS_SHORT);
  		break;
  	case SONY_PIC_COMMAND_SETCAMERASHARPNESS:
-		wait_on_command(sony_pic_call3(0x90, SONYPI_CAMERA_SHARPNESS, value),
-				ITERATIONS_SHORT);
+		wait_on_command(sony_pic_call3(0x90, SONYPI_CAMERA_SHARPNESS,
+				value),	ITERATIONS_SHORT);
  		break;
  	case SONY_PIC_COMMAND_SETCAMERAPICTURE:
-		wait_on_command(sony_pic_call3(0x90, SONYPI_CAMERA_PICTURE, value),
-				ITERATIONS_SHORT);
+		wait_on_command(sony_pic_call3(0x90, SONYPI_CAMERA_PICTURE,
+				value),	ITERATIONS_SHORT);
  		break;
  	case SONY_PIC_COMMAND_SETCAMERAAGC:
  		wait_on_command(sony_pic_call3(0x90, SONYPI_CAMERA_AGC, value),
@@ -3203,7 +3212,8 @@ sony_pic_read_possible_resource(struct a
  	case ACPI_RESOURCE_TYPE_START_DEPENDENT:
  		{
  			/* start IO enumeration */
-			struct sony_pic_ioport *ioport = kzalloc(sizeof(*ioport), GFP_KERNEL);
+			struct sony_pic_ioport *ioport =
+					kzalloc(sizeof(*ioport), GFP_KERNEL);
  			if (!ioport)
  				return AE_ERROR;

@@ -3251,7 +3261,8 @@ sony_pic_read_possible_resource(struct a
  		{
  			struct acpi_resource_io *io = &resource->data.io;
  			struct sony_pic_ioport *ioport =
-				list_first_entry(&dev->ioports, struct sony_pic_ioport, list);
+				list_first_entry(&dev->ioports,
+						struct sony_pic_ioport, list);
  			if (!io) {
  				dprintk("Blank IO resource\n");
  				return AE_OK;
@@ -3259,16 +3270,17 @@ sony_pic_read_possible_resource(struct a

  			if (!ioport->io1.minimum) {
  				memcpy(&ioport->io1, io, sizeof(*io));
-				dprintk("IO1 at 0x%.4x (0x%.2x)\n", ioport->io1.minimum,
+				dprintk("IO1 at 0x%.4x (0x%.2x)\n",
+						ioport->io1.minimum,
  						ioport->io1.address_length);
-			}
-			else if (!ioport->io2.minimum) {
+			} else if (!ioport->io2.minimum) {
  				memcpy(&ioport->io2, io, sizeof(*io));
-				dprintk("IO2 at 0x%.4x (0x%.2x)\n", ioport->io2.minimum,
+				dprintk("IO2 at 0x%.4x (0x%.2x)\n",
+						ioport->io2.minimum,
  						ioport->io2.address_length);
-			}
-			else {
-				pr_err("Unknown SPIC Type, more than 2 IO Ports\n");
+			} else {
+				pr_err("Unknown SPIC Type, "
+					"more than 2 IO Ports\n");
  				return AE_ERROR;
  			}
  			return AE_OK;
@@ -3591,24 +3603,26 @@ static int sony_pic_add(struct acpi_devi
  			/* Type 1 have 2 ioports */
  			if (io->io2.minimum) {
  				if (request_region(io->io2.minimum,
-						io->io2.address_length,
-						"Sony Programmable I/O Device")) {
-					dprintk("I/O port2: 0x%.4x (0x%.4x) + 0x%.2x\n",
-							io->io2.minimum, io->io2.maximum,
+					io->io2.address_length,
+					"Sony Programmable I/O Device")) {
+					dprintk("I/O port2: 0x%.4x (0x%.4x) "
+							"+ 0x%.2x\n",
+							io->io2.minimum,
+							io->io2.maximum,
  							io->io2.address_length);
  					spic_dev.cur_ioport = io;
  					break;
-				}
-				else {
+				} else {
  					dprintk("Unable to get I/O port2: "
-							"0x%.4x (0x%.4x) + 0x%.2x\n",
-							io->io2.minimum, io->io2.maximum,
+							"0x%.4x (0x%.4x) "
+							"+ 0x%.2x\n",
+							io->io2.minimum,
+							io->io2.maximum,
  							io->io2.address_length);
  					release_region(io->io1.minimum,
  							io->io1.address_length);
  				}
-			}
-			else {
+			} else {
  				spic_dev.cur_ioport = io;
  				break;
  			}
@@ -3623,7 +3637,7 @@ static int sony_pic_add(struct acpi_devi
  	/* request IRQ */
  	list_for_each_entry_reverse(irq, &spic_dev.interrupts, list) {
  		if (!request_irq(irq->irq.interrupts[0], sony_pic_irq,
-					IRQF_DISABLED, "sony-laptop", &spic_dev)) {
+				IRQF_DISABLED, "sony-laptop", &spic_dev)) {
  			dprintk("IRQ: %d - triggering: %d - "
  					"polarity: %d - shr: %d\n",
  					irq->irq.interrupts[0],
@@ -3653,7 +3667,8 @@ static int sony_pic_add(struct acpi_devi
  	if (result)
  		goto err_disable_device;

-	result = sysfs_create_group(&sony_pf_device->dev.kobj, 
&spic_attribute_group);
+	result = sysfs_create_group(&sony_pf_device->dev.kobj,
+					&spic_attribute_group);
  	if (result)
  		goto err_remove_pf;

[PATCH 14/25] sony-laptop: battery care functionality added

[Marco Chiappero]

This functionality (handles 0x0115, 0x0136, 0x013f), present on almost 
every Vaio, allows to extend the battery life by limiting the maximum 
battery charge level to a selectable value (80% and 50%).

Signed-off-by: Marco Chiappero <marco@absence.it>
---

--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -1611,6 +1611,143 @@ static void sony_nc_kbd_backlight_resume
  				(kbdbl_handle->timeout << 0x10), &result);
  }

+static struct device_attribute *bcare_attrs;
+static int sony_bc_handle = -1;
+
+static ssize_t sony_nc_battery_care_limit_store(struct device *dev,
+		struct device_attribute *attr,
+		const char *buffer, size_t count)
+{
+	unsigned int result, cmd;
+	unsigned long value;
+
+	if (count > 31)
+		return -EINVAL;
+	if (strict_strtoul(buffer, 10, &value))
+		return -EINVAL;
+
+	/*  limit values (2 bits):
+	 *  00 - none
+	 *  01 - 80%
+	 *  10 - 50%
+	 *  11 - 100%
+	 *
+	 *  bit 0: 0 disable BCL, 1 enable BCL
+	 *  bit 1: 1 tell to store the battery limit (see bits 6,7) too
+	 *  bits 2,3: reserved
+	 *  bits 4,5: store the limit into the EC
+	 *  bits 6,7: store the limit into the battery
+	 */
+
+	/*
+	 * handle 0x0115 should allow storing on battery too;
+	 * handle 0x0136 same as 0x0115 + health status;
+	 * handle 0x013f, same as 0x0136 but no storing on the battery
+	 *
+	 * Store only inside the EC for now, regardless the handle number
+	 */
+	switch (value) {
+	case 0:	/* disable */
+		cmd = 0x00;
+		break;
+	case 1: /* enable, 80% charge limit */
+		cmd = 0x11;
+		break;
+	case 2: /* enable, 50% charge limit */
+		cmd = 0x21;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	if (sony_call_snc_handle(sony_bc_handle, (cmd << 0x10) | 0x0100,
+				&result))
+		return -EIO;
+
+	return count;
+}
+
+static ssize_t sony_nc_battery_care_limit_show(struct device *dev,
+		struct device_attribute *attr, char *buffer)
+{
+	ssize_t count = 0;
+	unsigned int result, status;
+
+	if (sony_call_snc_handle(sony_bc_handle, 0x0000, &result))
+		return -EIO;
+
+	/* if disabled 0, else take the limit bits */
+	status = !(result & 0x01) ? 0 : ((result & 0x30) >> 0x04);
+
+	count = snprintf(buffer, PAGE_SIZE, "%d\n", status);
+	return count;
+}
+
+static ssize_t sony_nc_battery_care_health_show(struct device *dev,
+		struct device_attribute *attr, char *buffer)
+{
+	ssize_t count = 0;
+	unsigned int health;
+
+	if (sony_call_snc_handle(sony_bc_handle, 0x0200, &health))
+		return -EIO;
+
+	count = snprintf(buffer, PAGE_SIZE, "%d\n", health & 0xff);
+
+	return count;
+}
+
+static int sony_nc_battery_care_setup(struct platform_device *pd)
+{
+	bcare_attrs = kzalloc(sizeof(struct device_attribute) * 2, GFP_KERNEL);
+	if (!bcare_attrs)
+		return -ENOMEM;
+
+	sysfs_attr_init(&bcare_attrs[0].attr);
+	bcare_attrs[0].attr.name = "battery_care_limiter";
+	bcare_attrs[0].attr.mode = S_IRUGO | S_IWUSR;
+	bcare_attrs[0].show = sony_nc_battery_care_limit_show;
+	bcare_attrs[0].store = sony_nc_battery_care_limit_store;
+
+	if (device_create_file(&pd->dev, &bcare_attrs[0]))
+		goto outkzalloc;
+
+	if (sony_bc_handle == 0x0115) /* no health indication */
+		return 0;
+
+	sysfs_attr_init(&bcare_attrs[1].attr);
+	bcare_attrs[1].attr.name = "battery_care_health";
+	bcare_attrs[1].attr.mode = S_IRUGO;
+	bcare_attrs[1].show = sony_nc_battery_care_health_show;
+
+	if (device_create_file(&pd->dev, &bcare_attrs[1]))
+		goto outlimiter;
+
+	return 0;
+
+outlimiter:
+	device_remove_file(&pd->dev, &bcare_attrs[0]);
+outkzalloc:
+	kfree(bcare_attrs);
+	bcare_attrs = NULL;
+
+	return -1;
+}
+
+static int sony_nc_battery_care_cleanup(struct platform_device *pd)
+{
+	if (sony_bc_handle != -1) {
+		device_remove_file(&pd->dev, &bcare_attrs[0]);
+		if (sony_bc_handle != 0x0115)
+			device_remove_file(&pd->dev, &bcare_attrs[1]);
+
+		kfree(bcare_attrs);
+		bcare_attrs = NULL;
+	}
+
+	return 0;
+}
+
  static void sony_nc_backlight_ng_read_limits(int handle,
  		struct sony_backlight_props *props)
  {
@@ -1746,6 +1883,12 @@ static void sony_nc_snc_setup_handles(st
  		case 0x0102:
  			ret = sony_nc_function_setup(handle);
  			break;
+		case 0x0115:
+		case 0x0136:
+		case 0x013f:
+			sony_bc_handle = handle;
+			ret = sony_nc_battery_care_setup(pd);
+			break;
  		case 0x0137:
  		case 0x0143:
  			sony_kbd_handle = handle;
@@ -1783,6 +1926,11 @@ static void sony_nc_snc_cleanup_handles(
  		dprintk("looking at handle 0x%.4x\n", handle);

  		switch (handle) {
+		case 0x0115:
+		case 0x0136:
+		case 0x013f:
+			sony_nc_battery_care_cleanup(pd);
+			break;
  		case 0x0137:
  		case 0x0143:
  			sony_nc_kbd_backlight_cleanup(pd);

[PATCH 15/25] sony-laptop: add thermal control feature

[Marco Chiappero]

This feature is present on many Vaio notebooks and allows to choose 
between different thermal profiles (performance, silent, balanced) 
depending on the notebook capability.

Signed-off-by: Marco Chiappero <marco@absence.it>
---

--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -1748,6 +1748,166 @@ static int sony_nc_battery_care_cleanup(
  	return 0;
  }

+struct thermal_ctrl {
+	unsigned int mode;
+	unsigned int profiles;
+	struct device_attribute mode_attr;
+	struct device_attribute profiles_attr;
+};
+static struct thermal_ctrl *th_handle;
+
+static int sony_nc_thermal_mode_set(unsigned int profile)
+{
+	unsigned int cmd, result;
+
+	/* to avoid the 1 value hole when only 2 profiles are available */
+	switch (profile) {
+	case 1: /* performance */
+		cmd = 2;
+		break;
+	case 2: /* silent */
+		cmd = 1;
+		break;
+	default: /* balanced */
+		cmd = 0;
+		break;
+	}
+
+	if (sony_call_snc_handle(0x0122, cmd << 0x10 | 0x0200, &result))
+		return -EIO;
+
+	th_handle->mode = profile;
+
+	return 0;
+}
+
+static int sony_nc_thermal_mode_get(unsigned int *profile)
+{
+	unsigned int result;
+
+	if (sony_call_snc_handle(0x0122, 0x0100, &result))
+		return -EIO;
+
+	/* to avoid the 1 value hole when only 2 profiles are available */
+	switch (result & 0xff) {
+	case 2: /* performance */
+		*profile = 1;
+		break;
+	case 1: /* silent */
+		*profile = 2;
+		break;
+	default: /* balanced */
+		*profile = 0;
+		break;
+	}
+
+	return 0;
+}
+
+static ssize_t sony_nc_thermal_profiles_show(struct device *dev,
+		struct device_attribute *attr, char *buffer)
+{
+	return snprintf(buffer, PAGE_SIZE, "%u\n", th_handle->profiles);
+}
+
+static ssize_t sony_nc_thermal_mode_store(struct device *dev,
+		struct device_attribute *attr,
+		const char *buffer, size_t count)
+{
+	unsigned long value;
+
+	if (count > 31)
+		return -EINVAL;
+	if (strict_strtoul(buffer, 10, &value) ||
+		value > (th_handle->profiles - 1))
+		return -EINVAL;
+
+	if (sony_nc_thermal_mode_set(value))
+		return -EIO;
+
+	return count;
+}
+
+static ssize_t sony_nc_thermal_mode_show(struct device *dev,
+		struct device_attribute *attr, char *buffer)
+{
+	ssize_t count = 0;
+	unsigned int profile;
+
+	if (sony_nc_thermal_mode_get(&profile))
+		return -EIO;
+
+	count = snprintf(buffer, PAGE_SIZE, "%d\n", profile);
+
+	return count;
+}
+
+static int sony_nc_thermal_setup(struct platform_device *pd)
+{
+	th_handle = kzalloc(sizeof(struct thermal_ctrl), GFP_KERNEL);
+	if (!th_handle)
+		return -ENOMEM;
+
+	if (sony_call_snc_handle(0x0122, 0x0000, &th_handle->profiles)) {
+		pr_warn("unable to retrieve the available profiles\n");
+		goto outkzalloc;
+	}
+
+	if (sony_nc_thermal_mode_get(&th_handle->mode)) {
+		pr_warn("unable to retrieve the current profile");
+		goto outkzalloc;
+	}
+
+	sysfs_attr_init(&th_handle->profiles_attr.attr);
+	th_handle->profiles_attr.attr.name = "thermal_profiles";
+	th_handle->profiles_attr.attr.mode = S_IRUGO;
+	th_handle->profiles_attr.show = sony_nc_thermal_profiles_show;
+
+	sysfs_attr_init(&th_handle->mode_attr.attr);
+	th_handle->mode_attr.attr.name = "thermal_control";
+	th_handle->mode_attr.attr.mode = S_IRUGO | S_IWUSR;
+	th_handle->mode_attr.show = sony_nc_thermal_mode_show;
+	th_handle->mode_attr.store = sony_nc_thermal_mode_store;
+
+	if (device_create_file(&pd->dev, &th_handle->profiles_attr))
+		goto outkzalloc;
+
+	if (device_create_file(&pd->dev, &th_handle->mode_attr))
+		goto outprofiles;
+
+	return 0;
+
+outprofiles:
+	device_remove_file(&pd->dev, &th_handle->profiles_attr);
+outkzalloc:
+	kfree(th_handle);
+	th_handle = NULL;
+	return -1;
+}
+
+static int sony_nc_thermal_cleanup(struct platform_device *pd)
+{
+	if (th_handle) {
+		device_remove_file(&pd->dev, &th_handle->profiles_attr);
+		device_remove_file(&pd->dev, &th_handle->mode_attr);
+		kfree(th_handle);
+		th_handle = NULL;
+	}
+
+	return 0;
+}
+
+static void sony_nc_thermal_resume(void)
+{
+	unsigned int status;
+
+	sony_nc_thermal_mode_get(&status);
+
+	if (status != th_handle->mode)
+		sony_nc_thermal_mode_set(th_handle->mode);
+}
+
+
  static void sony_nc_backlight_ng_read_limits(int handle,
  		struct sony_backlight_props *props)
  {
@@ -1889,6 +2049,9 @@ static void sony_nc_snc_setup_handles(st
  			sony_bc_handle = handle;
  			ret = sony_nc_battery_care_setup(pd);
  			break;
+		case 0x0122:
+			ret = sony_nc_thermal_setup(pd);
+			break;
  		case 0x0137:
  		case 0x0143:
  			sony_kbd_handle = handle;
@@ -1931,6 +2094,9 @@ static void sony_nc_snc_cleanup_handles(
  		case 0x013f:
  			sony_nc_battery_care_cleanup(pd);
  			break;
+		case 0x0122:
+			sony_nc_thermal_cleanup(pd);
+			break;
  		case 0x0137:
  		case 0x0143:
  			sony_nc_kbd_backlight_cleanup(pd);
@@ -2031,6 +2197,9 @@ static int sony_nc_snc_resume(void)
  		case 0x0102:
  			sony_nc_function_setup(handle);
  			break;
+		case 0x0122:
+			sony_nc_thermal_resume();
+			break;
  		case 0x0124:
  		case 0x0135:
  			/* re-read rfkill state */

[PATCH 16/25] sony-laptop: add HDD shock protection

[Marco Chiappero]

Vaio S models can unload the HDD heads by means of the SATA power 
connector and an accelerometer, using the Embedded Controller. This 
patch provides the necessary controls for this functionality and the 
shock event notification to userspace.

Signed-off-by: Marco Chiappero <marco@absence.it>
---

--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -140,6 +140,13 @@ MODULE_PARM_DESC(kbd_backlight_timeout,
  		 "1 for 30 seconds, 2 for 60 seconds and 3 to disable timeout "
  		 "(default: 0)");

+static int force_shock_notifications;	/* = 0 */
+module_param(force_shock_notifications, int, 0);
+MODULE_PARM_DESC(force_shock_notifications,
+		"set this to 1 to force the generation of shock protection "
+		"events, even though the notebook do not support head "
+		"unloading for the installed drive drive");
+

  static int sony_rfkill_handle = -1;
  static int sony_nc_get_rfkill_hwblock(void);
@@ -1611,6 +1618,362 @@ static void sony_nc_kbd_backlight_resume
  				(kbdbl_handle->timeout << 0x10), &result);
  }

+/*	GSensor, HDD Shock Protection	*/
+enum axis {
+	X_AXIS = 4,	/* frontal  */
+	Y_AXIS,		/* lateral  */
+	Z_AXIS		/* vertical */
+};
+
+struct gsensor_control {
+	unsigned int attrs_num;
+	struct device_attribute *attrs;
+};
+static struct gsensor_control *gs_handle;
+static int sony_gs_handle = -1;
+
+/* the EC uses pin #11 of the SATA power connector to command the
+   immediate idle feature; however some drives do not implement it
+   and pin #11 is NC. Let's verify, otherwise no automatic
+   protection is possible by the hardware
+*/
+static int sony_nc_gsensor_support_get(unsigned int *support)
+{
+	unsigned int result;
+
+	if (sony_call_snc_handle(sony_gs_handle, 0x0200, &result))
+		return -EIO;
+
+	*support = sony_gs_handle == 0x0134
+			? !!(result & 0x20)
+			: !!(result & 0x01);
+
+	return 0;
+}
+
+static int sony_nc_gsensor_status_set(int value)
+{
+	unsigned int result, capable, reg, arg;
+	bool update = false;
+
+	if (sony_nc_gsensor_support_get(&capable))
+		return -EIO;
+
+	if (!capable)
+		pr_warn("hardware protection not available, the HDD"
+			       " do not support this feature\n");
+
+	/* do not return immediately even though there is no HW
+	 * capability, userspace can thus receive the shock
+	 * notifications and call the ATA7 immediate idle command to
+	 * unload the heads. Just return after enabling notifications
+	*/
+	reg = sony_gs_handle == 0x0134 ? (!value << 0x08) : (value << 0x10);
+
+	if (sony_call_snc_handle(sony_gs_handle, reg, &result))
+		return -EIO;
+
+	if (!capable)
+		return 0;
+
+	/* if the requested protection setting is different
+	   from the current one
+	*/
+	reg = sony_gs_handle == 0x0134 ? 0x0200 : 0x0400;
+	if (sony_call_snc_handle(sony_gs_handle, reg, &result))
+		return -EIO;
+
+	if (sony_gs_handle == 0x0134) {
+		if (!!(result & 0x04) != value) {
+			arg = (result & 0x1B) | (value << 0x02);
+			update = true;
+		}
+	} else {
+		if ((result & 0x01) != value) {
+			arg = value;
+			update = true;
+		}
+	}
+
+	if (update && sony_call_snc_handle(sony_gs_handle,
+			(arg << 0x10) | 0x0300, &result))
+		return -EIO;
+
+	return 0;
+}
+
+static int sony_nc_gsensor_axis_get(enum axis name)
+{
+	unsigned int result;
+
+	if (sony_call_snc_handle(sony_gs_handle, name << 0x08, &result))
+		return -EIO;
+
+	return result;
+}
+
+/*			G sensor sys interface			*/
+static ssize_t sony_nc_gsensor_type_show(struct device *dev,
+		struct device_attribute *attr, char *buffer)
+{
+	ssize_t count = 0;
+	unsigned int result;
+
+	if (sony_call_snc_handle(sony_gs_handle, 0x0200, &result))
+		return -EIO;
+
+	count = snprintf(buffer, PAGE_SIZE, "%d\n", (result >> 0x03) & 0x03);
+
+	return count;
+}
+
+static ssize_t sony_nc_gsensor_type_store(struct device *dev,
+		struct device_attribute *attr,
+		const char *buffer, size_t count)
+{
+	/*
+	 *  axis out type control file:
+	 *  0: raw values, 1: acc values 2: threshold values
+	 */
+	unsigned int result;
+	unsigned long value;
+
+	/* sanity checks and conversion */
+	if (count > 31 || strict_strtoul(buffer, 10, &value) || value > 2)
+		return -EINVAL;
+
+	value <<= 0x03;
+
+	/* retrieve the current state / settings */
+	if (sony_call_snc_handle(sony_gs_handle, 0x0200, &result))
+		return -EIO;
+
+	if ((result & 0x18) != value) {
+		/* the last 3 bits need to be preserved */
+		value |= (result & 0x07);
+
+		if (sony_call_snc_handle(sony_gs_handle,
+				(value << 0x10) | 0x0300, &result))
+				return -EIO;
+	}
+
+	return count;
+}
+
+static ssize_t sony_nc_gsensor_axis_show(struct device *dev,
+		struct device_attribute *attr, char *buffer)
+{
+	ssize_t count = 0;
+	unsigned int result;
+	enum axis arg;
+
+	/* file being read for axis selection */
+	if (!strcmp(attr->attr.name, "gsensor_xval"))
+		arg = X_AXIS;
+	else if (!strcmp(attr->attr.name, "gsensor_yval"))
+		arg = Y_AXIS;
+	else if (!strcmp(attr->attr.name, "gsensor_zval"))
+		arg = Z_AXIS;
+	else
+		return count;
+
+	result = sony_nc_gsensor_axis_get(arg);
+	if (result < 0)
+		return -EIO;
+
+	count = snprintf(buffer, PAGE_SIZE, "%d\n", result);
+
+	return count;
+}
+
+static ssize_t sony_nc_gsensor_status_show(struct device *dev,
+		struct device_attribute *attr, char *buffer)
+{
+	ssize_t count = 0;
+	unsigned int result;
+
+	if (sony_gs_handle == 0x0134) {
+		if (sony_call_snc_handle(sony_gs_handle, 0x0200,
+					&result))
+			return -EIO;
+
+		result = !!(result & 0x04);
+	} else {
+		if (sony_call_snc_handle(sony_gs_handle, 0x0400,
+					&result))
+			return -EIO;
+
+		result &= 0x01;
+	}
+
+	count = snprintf(buffer, PAGE_SIZE, "%d\n", result);
+
+	return count;
+}
+
+static ssize_t sony_nc_gsensor_status_store(struct device *dev,
+		struct device_attribute *attr,
+		const char *buffer, size_t count)
+{
+	int ret;
+	unsigned long value;
+
+	if (count > 31)
+		return -EINVAL;
+	if (strict_strtoul(buffer, 10, &value) || value > 1)
+		return -EINVAL;
+
+	ret = sony_nc_gsensor_status_set(value);
+	if (ret)
+		return ret;
+
+	return count;
+}
+
+static ssize_t sony_nc_gsensor_sensitivity_show(struct device *dev,
+		struct device_attribute *attr, char *buffer)
+{
+	ssize_t count = 0;
+	unsigned int result;
+
+	if (sony_call_snc_handle(sony_gs_handle, 0x0200, &result))
+		return -EINVAL;
+
+	count = snprintf(buffer, PAGE_SIZE, "%d\n", result & 0x03);
+	return count;
+}
+
+static ssize_t sony_nc_gsensor_sensitivity_store(struct device *dev,
+		struct device_attribute *attr,
+		const char *buffer, size_t count)
+{
+	unsigned int result;
+	unsigned long value;
+
+	if (count > 31)
+		return -EINVAL;
+	if (strict_strtoul(buffer, 10, &value) || value > 2)
+		return -EINVAL;
+
+	/* retrieve the other parameters to be stored as well */
+	if (sony_call_snc_handle(sony_gs_handle, 0x0200, &result))
+		return -EIO;
+	value |= (result & 0x1C); /* preserve only the needed bits */
+
+	if (sony_call_snc_handle(sony_gs_handle, (value << 0x10)
+		| 0x0300, &result))
+		return -EIO;
+
+	return count;
+}
+
+static int sony_nc_gsensor_setup(struct platform_device *pd)
+{
+	int i, enable, support;
+
+	gs_handle = kzalloc(sizeof(struct gsensor_control), GFP_KERNEL);
+
+	if (!gs_handle)
+		return -ENOMEM;
+
+	gs_handle->attrs_num = sony_gs_handle == 0x0134	? 6 : 1;
+
+	gs_handle->attrs = kzalloc(sizeof(struct device_attribute)
+				* gs_handle->attrs_num, GFP_KERNEL);
+	if (!gs_handle->attrs)
+		goto memerror;
+
+	/* check the storing device support */
+	if (sony_nc_gsensor_support_get(&support))
+		return -EIO;
+
+	/* enable the HDD protection and notification by default
+	   when hardware driven protection is possible */
+	enable = support ? 1 : force_shock_notifications;
+	if (sony_nc_gsensor_status_set(enable))
+		if (enable)
+			pr_warn("failed to enable the HDD shock protection\n");
+
+	/* activation control	*/
+	sysfs_attr_init(&gs_handle->attrs[0].attr);
+	gs_handle->attrs[0].attr.name = "gsensor_protection";
+	gs_handle->attrs[0].attr.mode = S_IRUGO | S_IWUSR;
+	gs_handle->attrs[0].show = sony_nc_gsensor_status_show;
+	gs_handle->attrs[0].store = sony_nc_gsensor_status_store;
+
+	if (gs_handle->attrs_num > 1) {
+		/* sensitivity selection */
+		sysfs_attr_init(&gs_handle->attrs[1].attr);
+		gs_handle->attrs[1].attr.name = "gsensor_sensitivity";
+		gs_handle->attrs[1].attr.mode = S_IRUGO | S_IWUSR;
+		gs_handle->attrs[1].show = sony_nc_gsensor_sensitivity_show;
+		gs_handle->attrs[1].store = sony_nc_gsensor_sensitivity_store;
+		/* x/y/z output selection */
+		sysfs_attr_init(&gs_handle->attrs[2].attr);
+		gs_handle->attrs[2].attr.name = "gsensor_val_type";
+		gs_handle->attrs[2].attr.mode = S_IRUGO | S_IWUSR;
+		gs_handle->attrs[2].show = sony_nc_gsensor_type_show;
+		gs_handle->attrs[2].store = sony_nc_gsensor_type_store;
+
+		sysfs_attr_init(&gs_handle->attrs[3].attr);
+		gs_handle->attrs[3].attr.name = "gsensor_xval";
+		gs_handle->attrs[3].attr.mode = S_IRUGO;
+		gs_handle->attrs[3].show = sony_nc_gsensor_axis_show;
+
+		sysfs_attr_init(&gs_handle->attrs[4].attr);
+		gs_handle->attrs[4].attr.name = "gsensor_yval";
+		gs_handle->attrs[4].attr.mode = S_IRUGO;
+		gs_handle->attrs[4].show = sony_nc_gsensor_axis_show;
+
+		sysfs_attr_init(&gs_handle->attrs[5].attr);
+		gs_handle->attrs[5].attr.name = "gsensor_zval";
+		gs_handle->attrs[5].attr.mode = S_IRUGO;
+		gs_handle->attrs[5].show = sony_nc_gsensor_axis_show;
+	}
+
+	for (i = 0; i < gs_handle->attrs_num; i++) {
+		if (device_create_file(&pd->dev, &gs_handle->attrs[i]))
+			goto attrserror;
+	}
+
+	return 0;
+
+attrserror:
+	for (; i > 0; i--)
+		device_remove_file(&pd->dev, &gs_handle->attrs[i]);
+
+	kfree(gs_handle->attrs);
+memerror:
+	kfree(gs_handle);
+	gs_handle = NULL;
+
+	return -1;
+}
+
+static int sony_nc_gsensor_cleanup(struct platform_device *pd)
+{
+	if (sony_gs_handle != -1) {
+		unsigned int i, result, reg;
+
+		for (i = 0; i < gs_handle->attrs_num; i++)
+			device_remove_file(&pd->dev, &gs_handle->attrs[i]);
+
+		/* disable the event generation,
+		 * preserve any other setting
+		 */
+		reg = sony_gs_handle == 0x0134 ? 0x0100 : 0x0000;
+
+		sony_call_snc_handle(sony_gs_handle, reg, &result);
+
+		kfree(gs_handle->attrs);
+		kfree(gs_handle);
+		gs_handle = NULL;
+	}
+
+	return 0;
+}
+/*			end G sensor code			*/
+
  static struct device_attribute *bcare_attrs;
  static int sony_bc_handle = -1;

@@ -2057,6 +2420,11 @@ static void sony_nc_snc_setup_handles(st
  			sony_kbd_handle = handle;
  			ret = sony_nc_kbd_backlight_setup(pd);
  			break;
+		case 0x0134:
+		case 0x0147:
+			sony_gs_handle = handle;
+			ret = sony_nc_gsensor_setup(pd);
+			break;
  		case 0x0124:
  		case 0x0135:
  			sony_rfkill_handle = handle;
@@ -2101,6 +2469,10 @@ static void sony_nc_snc_cleanup_handles(
  		case 0x0143:
  			sony_nc_kbd_backlight_cleanup(pd);
  			break;
+		case 0x0134:
+		case 0x0147:
+			sony_nc_gsensor_cleanup(pd);
+			break;
  		case 0x0124:
  		case 0x0135:
  			sony_nc_rfkill_cleanup();
@@ -2288,6 +2660,13 @@ static void sony_nc_notify(struct acpi_d
  			ev = 2;
  			break;

+		case 0x0134:
+		case 0x0147:
+			ev = 4;
+			value = 1;
+			/* hdd protection event, notify userspace */
+			break;
+
  		default:
  			value = event;
  			dprintk("Unknowk event for handle: 0x%x\n", handle);

[PATCH 17/25] sony-laptop: add resume from S4/S3 when opening the lid

[Marco Chiappero]

A few models offer the chance to set whether to resume from S3 and/or S4 
when opening the lid, this patch add a control file for this feature.

Signed-off-by: Marco Chiappero <marco@absence.it>
---

--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -2270,6 +2270,78 @@ static void sony_nc_thermal_resume(void)
  		sony_nc_thermal_mode_set(th_handle->mode);
  }

+static struct device_attribute *lid_handle;
+
+static ssize_t sony_nc_lid_resume_store(struct device *dev,
+		struct device_attribute *attr,
+		const char *buffer, size_t count)
+{
+	unsigned int result;
+	unsigned long value;
+
+	if (count > 31)
+		return -EINVAL;
+	if (strict_strtoul(buffer, 10, &value) || value > 3)
+		return -EINVAL;
+
+	/* 00 <- disabled
+	   01 <- resume from S4
+	   10 <- resume from S3
+	   11 <- resume from S4 and S3
+	*/
+	/* we must set bit 1 and 2 (bit 0 is for S5), so shift one bit more */
+	if (sony_call_snc_handle(0x0119, value << 0x11 | 0x0100, &result))
+		return -EIO;
+
+	return count;
+}
+
+static ssize_t sony_nc_lid_resume_show(struct device *dev,
+		struct device_attribute *attr, char *buffer)
+{
+	ssize_t count = 0;
+	unsigned int result;
+
+	if (sony_call_snc_handle(0x0119, 0x0000, &result))
+		return -EIO;
+
+	count = snprintf(buffer, PAGE_SIZE, "%d\n", (result >> 1) & 0x03);
+
+	return count;
+}
+
+static int sony_nc_lid_resume_setup(struct platform_device *pd)
+{
+	lid_handle = kzalloc(sizeof(struct device_attribute), GFP_KERNEL);
+	if (!lid_handle)
+		return -ENOMEM;
+
+	sysfs_attr_init(&lid_handle->attr);
+	lid_handle->attr.name = "lid_resume_control";
+	lid_handle->attr.mode = S_IRUGO | S_IWUSR;
+	lid_handle->show = sony_nc_lid_resume_show;
+	lid_handle->store = sony_nc_lid_resume_store;
+
+	if (device_create_file(&pd->dev, lid_handle)) {
+		kfree(lid_handle);
+		lid_handle = NULL;
+		return -1;
+	}
+
+	return 0;
+}
+
+static int sony_nc_lid_resume_cleanup(struct platform_device *pd)
+{
+	if (lid_handle) {
+		device_remove_file(&pd->dev, lid_handle);
+		kfree(lid_handle);
+		lid_handle = NULL;
+	}
+
+	return 0;
+}
+

  static void sony_nc_backlight_ng_read_limits(int handle,
  		struct sony_backlight_props *props)
@@ -2412,6 +2484,9 @@ static void sony_nc_snc_setup_handles(st
  			sony_bc_handle = handle;
  			ret = sony_nc_battery_care_setup(pd);
  			break;
+		case 0x0119:
+			ret = sony_nc_lid_resume_setup(pd);
+			break;
  		case 0x0122:
  			ret = sony_nc_thermal_setup(pd);
  			break;
@@ -2462,6 +2537,9 @@ static void sony_nc_snc_cleanup_handles(
  		case 0x013f:
  			sony_nc_battery_care_cleanup(pd);
  			break;
+		case 0x0119:
+			sony_nc_lid_resume_cleanup(pd);
+			break;
  		case 0x0122:
  			sony_nc_thermal_cleanup(pd);
  			break;

[PATCH 18/25] sony-laptop: add control file for the HighSpeed Charging feature

[Marco Chiappero]

Vaio TT models allow to enable the HighSpeed Charging feature, this 
patch adds a control file. Feature discovered and tested by Javier Achirica

Signed-off-by: Marco Chiappero <marco@absence.it>
---

--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -2342,6 +2342,79 @@ static int sony_nc_lid_resume_cleanup(st
  	return 0;
  }

+static struct device_attribute *hsc_handle;
+
+static ssize_t sony_nc_highspeed_charging_store(struct device *dev,
+		struct device_attribute *attr,
+		const char *buffer, size_t count)
+{
+	unsigned int result;
+	unsigned long value;
+
+	if (count > 31)
+		return -EINVAL;
+	if (strict_strtoul(buffer, 10, &value) || value > 1)
+		return -EINVAL;
+
+	if (sony_call_snc_handle(0x0131, value << 0x10 | 0x0200, &result))
+		return -EIO;
+
+	return count;
+}
+
+static ssize_t sony_nc_highspeed_charging_show(struct device *dev,
+		struct device_attribute *attr, char *buffer)
+{
+	ssize_t count = 0;
+	unsigned int result;
+
+	if (sony_call_snc_handle(0x0131, 0x0100, &result))
+		return -EIO;
+
+	count = snprintf(buffer, PAGE_SIZE, "%d\n", result & 0x01);
+
+	return count;
+}
+
+static int sony_nc_highspeed_charging_setup(struct platform_device *pd)
+{
+	unsigned int result;
+
+	if (sony_call_snc_handle(0x0131, 0x0000, &result) || !(result & 0x01)) {
+		pr_info("no High Speed Charging capability found\n");
+		return 0;
+	}
+
+	hsc_handle = kzalloc(sizeof(struct device_attribute), GFP_KERNEL);
+	if (!hsc_handle)
+		return -ENOMEM;
+
+	sysfs_attr_init(&hsc_handle->attr);
+	hsc_handle->attr.name = "battery_highspeed_charging";
+	hsc_handle->attr.mode = S_IRUGO | S_IWUSR;
+	hsc_handle->show = sony_nc_highspeed_charging_show;
+	hsc_handle->store = sony_nc_highspeed_charging_store;
+
+	if (device_create_file(&pd->dev, hsc_handle)) {
+		kfree(hsc_handle);
+		hsc_handle = NULL;
+		return -1;
+	}
+
+	return 0;
+}
+
+static int sony_nc_highspeed_charging_cleanup(struct platform_device *pd)
+{
+	if (hsc_handle) {
+		device_remove_file(&pd->dev, hsc_handle);
+		kfree(hsc_handle);
+		hsc_handle = NULL;
+	}
+
+	return 0;
+}
+

  static void sony_nc_backlight_ng_read_limits(int handle,
  		struct sony_backlight_props *props)
@@ -2495,6 +2568,9 @@ static void sony_nc_snc_setup_handles(st
  			sony_kbd_handle = handle;
  			ret = sony_nc_kbd_backlight_setup(pd);
  			break;
+		case 0x0131:
+			ret = sony_nc_highspeed_charging_setup(pd);
+			break;
  		case 0x0134:
  		case 0x0147:
  			sony_gs_handle = handle;
@@ -2547,6 +2623,9 @@ static void sony_nc_snc_cleanup_handles(
  		case 0x0143:
  			sony_nc_kbd_backlight_cleanup(pd);
  			break;
+		case 0x0131:
+			sony_nc_highspeed_charging_cleanup(pd);
+			break;
  		case 0x0134:
  		case 0x0147:
  			sony_nc_gsensor_cleanup(pd);

[PATCH 19/25] sony-laptop: add touchpad enable/disable control file

[Marco Chiappero]

Handle 0x0105 allows to change (and store persistently) the touchpad 
state, while notebooks with handle 0x0148 also provides the Fn-F1 combo 
to change the touchpad state, but the key driven change is not handled 
by this patch.

Signed-off-by: Marco Chiappero <marco@absence.it>
---

--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -2415,6 +2415,75 @@ static int sony_nc_highspeed_charging_cl
  	return 0;
  }

+static struct device_attribute *tpad_handle;
+static int sony_tpad_handle = -1;
+
+static ssize_t sony_nc_touchpad_store(struct device *dev,
+		struct device_attribute *attr,
+		const char *buffer, size_t count)
+{
+	unsigned int result;
+	unsigned long value;
+
+	if (count > 31)
+		return -EINVAL;
+	if (strict_strtoul(buffer, 10, &value) || value > 1)
+		return -EINVAL;
+
+	/* sysfs: 0 disabled, 1 enabled; EC: 0 enabled, 1 disabled */
+	if (sony_call_snc_handle(sony_tpad_handle,
+				(!value << 0x10) | 0x100, &result))
+		return -EIO;
+
+	return count;
+}
+
+static ssize_t sony_nc_touchpad_show(struct device *dev,
+		struct device_attribute *attr, char *buffer)
+{
+	ssize_t count = 0;
+	unsigned int result;
+
+	if (sony_call_snc_handle(sony_tpad_handle, 0x000, &result))
+		return -EINVAL;
+
+	/* 1 tpad off, 0 tpad on */
+	count = snprintf(buffer, PAGE_SIZE, "%d\n", !(result & 0x01));
+	return count;
+}
+
+static int sony_nc_touchpad_setup(struct platform_device *pd)
+{
+	tpad_handle = kzalloc(sizeof(struct device_attribute), GFP_KERNEL);
+	if (!tpad_handle)
+		return -ENOMEM;
+
+	sysfs_attr_init(&tpad_handle->attr);
+	tpad_handle->attr.name = "touchpad";
+	tpad_handle->attr.mode = S_IRUGO | S_IWUSR;
+	tpad_handle->show = sony_nc_touchpad_show;
+	tpad_handle->store = sony_nc_touchpad_store;
+
+	if (device_create_file(&pd->dev, tpad_handle)) {
+		kfree(tpad_handle);
+		tpad_handle = NULL;
+		return -1;
+	}
+
+	return 0;
+}
+
+static int sony_nc_touchpad_cleanup(struct platform_device *pd)
+{
+	if (tpad_handle) {
+		device_remove_file(&pd->dev, tpad_handle);
+		kfree(tpad_handle);
+		tpad_handle = NULL;
+	}
+
+	return 0;
+}
+

  static void sony_nc_backlight_ng_read_limits(int handle,
  		struct sony_backlight_props *props)
@@ -2551,6 +2620,11 @@ static void sony_nc_snc_setup_handles(st
  		case 0x0102:
  			ret = sony_nc_function_setup(handle);
  			break;
+		case 0x0105:
+		case 0x0148: /* same as 0x0105 + Fn-F1 combo */
+			sony_tpad_handle = handle;
+			ret = sony_nc_touchpad_setup(pd);
+			break;
  		case 0x0115:
  		case 0x0136:
  		case 0x013f:
@@ -2608,6 +2682,10 @@ static void sony_nc_snc_cleanup_handles(
  		dprintk("looking at handle 0x%.4x\n", handle);

  		switch (handle) {
+		case 0x0105:
+		case 0x0148:
+			sony_nc_touchpad_cleanup(pd);
+			break;
  		case 0x0115:
  		case 0x0136:
  		case 0x013f:

[PATCH 20/25] sony-laptop: add fan related controls

[Marco Chiappero]

This patch exposes fan speed reading and speed selection when possible: 
a list of fan speeds is provided by the DSDT and exposed, a particular 
speed can be selected using its sequence number, while 0 corresponds to 
auto fan control.

Signed-off-by: Marco Chiappero <marco@absence.it>
---

--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -2484,6 +2484,149 @@ static int sony_nc_touchpad_cleanup(stru
  	return 0;
  }

+#define SONY_FAN_HANDLE 0x0149
+#define FAN_SPEEDS_NUM	4	/* leave some more room */
+#define FAN_ATTRS_NUM	3
+
+struct fan_control {
+	unsigned int speeds_num;
+	unsigned int speeds[4];
+	struct device_attribute	attrs[3];
+};
+static struct fan_control *fan_handle;
+
+static ssize_t sony_nc_fan_control_store(struct device *dev,
+		struct device_attribute *attr,
+		const char *buffer, size_t count)
+{
+	unsigned int result;
+	unsigned long value;
+
+	if (count > 31)
+		return -EINVAL;
+	if (strict_strtoul(buffer, 10, &value)
+		|| value > fan_handle->speeds_num)
+		return -EINVAL;
+
+	if (sony_call_snc_handle(SONY_FAN_HANDLE,
+				(value << 0x10) | 0x0200, &result))
+		return -EIO;
+
+	return count;
+}
+
+static ssize_t sony_nc_fan_control_show(struct device *dev,
+		struct device_attribute *attr, char *buffer)
+{
+	ssize_t count = 0;
+	unsigned int result;
+
+	if (sony_call_snc_handle(SONY_FAN_HANDLE, 0x0100, &result))
+		return -EINVAL;
+
+	count = snprintf(buffer, PAGE_SIZE, "%d\n", result & 0xff);
+	return count;
+}
+
+static ssize_t sony_nc_fan_profiles_show(struct device *dev,
+		struct device_attribute *attr, char *buffer)
+{
+	ssize_t count = 0;
+	unsigned int i;
+
+	for (i = 0; i < fan_handle->speeds_num; i++)
+		count += snprintf(buffer + count, PAGE_SIZE - count,
+				"%.4u ", fan_handle->speeds[i] * 100);
+
+	count += snprintf(buffer + count, PAGE_SIZE - count, "\n");
+
+	return count;
+}
+
+static ssize_t sony_nc_fan_speed_show(struct device *dev,
+		struct device_attribute *attr, char *buffer)
+{
+	ssize_t count = 0;
+	unsigned int result;
+
+	if (sony_call_snc_handle(SONY_FAN_HANDLE, 0x0300, &result))
+		return -EINVAL;
+
+	count = snprintf(buffer, PAGE_SIZE, "%d\n",
+				(result & 0xff) * 100);
+	return count;
+}
+
+static int sony_nc_fan_setup(struct platform_device *pd)
+{
+	int ret;
+	unsigned int i, found;
+	u8 list[FAN_SPEEDS_NUM * 2] = { 0 };
+
+	fan_handle = kzalloc(sizeof(struct fan_control), GFP_KERNEL);
+	if (!fan_handle)
+		return -ENOMEM;
+
+	ret = sony_call_snc_handle_buffer(SONY_FAN_HANDLE, 0x0000,
+					list, FAN_SPEEDS_NUM * 2);
+	if (ret < 0)
+		pr_info("unable to retrieve fan profiles table\n");
+
+	for (i = 0, found = 0;
+		list[i] != 0 && found < FAN_SPEEDS_NUM; i += 2, found++) {
+
+		fan_handle->speeds[found] = list[i+1];
+	}
+	fan_handle->speeds_num = found;
+
+	sysfs_attr_init(&fan_handle->attrs[0].attr);
+	fan_handle->attrs[0].attr.name = "fan_speed";
+	fan_handle->attrs[0].attr.mode = S_IRUGO;
+	fan_handle->attrs[0].show = sony_nc_fan_speed_show;
+
+	sysfs_attr_init(&fan_handle->attrs[1].attr);
+	fan_handle->attrs[1].attr.name = "fan_profiles";
+	fan_handle->attrs[1].attr.mode = S_IRUGO;
+	fan_handle->attrs[1].show = sony_nc_fan_profiles_show;
+
+	sysfs_attr_init(&fan_handle->attrs[2].attr);
+	fan_handle->attrs[2].attr.name = "fan_control";
+	fan_handle->attrs[2].attr.mode = S_IRUGO | S_IWUSR;
+	fan_handle->attrs[2].show = sony_nc_fan_control_show;
+	fan_handle->attrs[2].store = sony_nc_fan_control_store;
+
+	for (i = 0; i < FAN_ATTRS_NUM; i++) {
+		if (device_create_file(&pd->dev, &fan_handle->attrs[i]))
+			goto attrserror;
+	}
+
+	return 0;
+
+attrserror:
+	for (; i > 0; i--)
+		device_remove_file(&pd->dev, &fan_handle->attrs[i]);
+
+	kfree(fan_handle);
+	fan_handle = NULL;
+
+	return -1;
+}
+
+static int sony_nc_fan_cleanup(struct platform_device *pd)
+{
+	if (fan_handle) {
+		int i;
+
+		for (i = 0; i < FAN_ATTRS_NUM; i++)
+			device_remove_file(&pd->dev, &fan_handle->attrs[i]);
+
+		kfree(fan_handle);
+		fan_handle = NULL;
+	}
+
+	return 0;
+}
+

  static void sony_nc_backlight_ng_read_limits(int handle,
  		struct sony_backlight_props *props)
@@ -2650,6 +2793,9 @@ static void sony_nc_snc_setup_handles(st
  			sony_gs_handle = handle;
  			ret = sony_nc_gsensor_setup(pd);
  			break;
+		case 0x0149:
+			ret = sony_nc_fan_setup(pd);
+			break;
  		case 0x0124:
  		case 0x0135:
  			sony_rfkill_handle = handle;
@@ -2708,6 +2854,9 @@ static void sony_nc_snc_cleanup_handles(
  		case 0x0147:
  			sony_nc_gsensor_cleanup(pd);
  			break;
+		case 0x0149:
+			sony_nc_fan_cleanup(pd);
+			break;
  		case 0x0124:
  		case 0x0135:
  			sony_nc_rfkill_cleanup();

[PATCH 21/25] sony-laptop: add optical device power control

[Marco Chiappero]

Vaio S and Z Series allow to turn off the optical device to save battery 
power, this patch exposes a control file to power on and off the device.


On Windows OS this feature is well integrated with the power management 
system, how to do the same on Linux? Moreover no media presence control 
and bus disconnection is performed (the DSDT provides the SATA 
controller the drive is connected to), should we do this in the driver 
or inside a userspace daemon?


Signed-off-by: Marco Chiappero <marco@absence.it>
---

--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -2627,6 +2627,118 @@ static int sony_nc_fan_cleanup(struct pl
  	return 0;
  }

+struct odd {
+	unsigned int vendor_id;
+	unsigned int model_id;
+	struct device_attribute status_attr;
+};
+static struct odd *odd_handle;
+
+static ssize_t sony_nc_odd_status_store(struct device *dev,
+		struct device_attribute *attr,
+		const char *buffer, size_t count)
+{
+	unsigned int result;
+	unsigned long value;
+
+	if (count > 31)
+		return -EINVAL;
+	if (strict_strtoul(buffer, 10, &value) || value > 1)
+		return -EINVAL;
+
+	/* 0x200 turn on (sysfs: 1), 0x300 turn off (sysfs: 0) */
+	value = (!value << 0x08) + 0x200;
+
+	/* the MSB have to be high */
+	if (sony_call_snc_handle(0x126, (1 << 0x10) | value, &result))
+		return -EIO;
+
+	return count;
+}
+
+static ssize_t sony_nc_odd_status_show(struct device *dev,
+		struct device_attribute *attr, char *buffer)
+{
+	ssize_t count = 0;
+	unsigned int result;
+
+	if (sony_call_snc_handle(0x126, 0x100, &result))
+		return -EINVAL;
+
+	count = snprintf(buffer, PAGE_SIZE, "%d\n", result & 0x01);
+	return count;
+}
+
+static int sony_nc_odd_setup(struct platform_device *pd)
+{
+#define ODD_TAB_SIZE 32
+	u8 list[ODD_TAB_SIZE] = { 0 };
+	int ret = 0;
+	int found = 0;
+	int i = 0;
+	unsigned int vendor = 0;
+	unsigned int model = 0;
+	u16 word = 0;
+
+	ret = sony_call_snc_handle_buffer(0x126, 0x0000, list, ODD_TAB_SIZE);
+	if (ret < 0) {
+		pr_info("unable to retrieve the odd table\n");
+		return -EIO;
+	}
+
+	/* parse the table looking for optical devices */
+	do {
+		word = (list[i+1] << 8) | list[i];
+
+		if (word == 1) { /* 1 DWord device data following */
+			vendor = (list[i+3] << 8) | list[i+2];
+			model = (list[i+5] << 8) | list[i+4];
+			found++;
+			i += 6;
+		} else {
+			i += 2;
+		}
+	} while (word != 0xff00);
+
+	if (found)
+		dprintk("one optical device found, connected to: %x:%x\n",
+				vendor, model);
+	else
+		return 0;
+
+	odd_handle = kzalloc(sizeof(*odd_handle), GFP_KERNEL);
+	if (!odd_handle)
+		return -ENOMEM;
+
+	odd_handle->vendor_id = vendor;
+	odd_handle->model_id = model;
+
+	sysfs_attr_init(&odd_handle->status_attr.attr);
+	odd_handle->status_attr.attr.name = "odd_power";
+	odd_handle->status_attr.attr.mode = S_IRUGO | S_IWUSR;
+	odd_handle->status_attr.show = sony_nc_odd_status_show;
+	odd_handle->status_attr.store = sony_nc_odd_status_store;
+
+	if (device_create_file(&pd->dev, &odd_handle->status_attr)) {
+		kfree(odd_handle);
+		odd_handle = NULL;
+		return -1;
+	}
+
+	return 0;
+}
+
+static int sony_nc_odd_cleanup(struct platform_device *pd)
+{
+	if (odd_handle) {
+		device_remove_file(&pd->dev, &odd_handle->status_attr);
+		kfree(odd_handle);
+		odd_handle = NULL;
+	}
+
+	return 0;
+}
+

  static void sony_nc_backlight_ng_read_limits(int handle,
  		struct sony_backlight_props *props)
@@ -2780,6 +2892,9 @@ static void sony_nc_snc_setup_handles(st
  		case 0x0122:
  			ret = sony_nc_thermal_setup(pd);
  			break;
+		case 0x0126:
+			ret = sony_nc_odd_setup(pd);
+			break;
  		case 0x0137:
  		case 0x0143:
  			sony_kbd_handle = handle;
@@ -2843,6 +2958,9 @@ static void sony_nc_snc_cleanup_handles(
  		case 0x0122:
  			sony_nc_thermal_cleanup(pd);
  			break;
+		case 0x0126:
+			sony_nc_odd_cleanup(pd);
+			break;
  		case 0x0137:
  		case 0x0143:
  			sony_nc_kbd_backlight_cleanup(pd);

[PATCH 22/25] sony-laptop: forward Hybrid GFX notifications to userspace

[Marco Chiappero]

Some Vaios come with both integrated and discrete graphics, plus a 
switch for choosing one of the two. When the switch position is changed, 
a notification is generated, now forwarded to userspace for example for 
visual notifications, user scripts, and so on.

Signed-off-by: Marco Chiappero <marco@absence.it>
---

--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -3118,6 +3118,14 @@ static void sony_nc_notify(struct acpi_d

  	dprintk("sony_nc_notify, event: 0x%.2x\n", event);

+	/* events codes list
+	 * 1    Hotkeys
+	 * 2    RFKILL
+	 * 3    ALS
+	 * 4    HDD protection
+	 * 5	Hybrid GFX
+	 */
+
  	/* handles related events */
  	if (event >= 0x90) {
  		unsigned int result = 0, handle = 0;
@@ -3169,6 +3177,23 @@ static void sony_nc_notify(struct acpi_d
  			/* hdd protection event, notify userspace */
  			break;

+		case 0x0128:
+		case 0x0146:
+			/* Hybrid GFX switching, 1 */
+			sony_call_snc_handle(handle, 0x0000, &result);
+			dprintk("sony_nc_notify, Hybrid GFX event received "
+					"(reason: %s)\n", (result & 0x01) ?
+					"switch position change" : "unknown");
+
+			/* verify the switch state
+			   (1: discrete GFX, 0: integrated GFX)*/
+			result = 0;
+			sony_call_snc_handle(handle, 0x0100, &result);
+
+			ev = 5;
+			value = result & 0xff;
+			break;
+
  		default:
  			value = event;
  			dprintk("Unknowk event for handle: 0x%x\n", handle);

[PATCH 23/25] sony-laptop: add ALS support

[Marco Chiappero]

Vaio S1, F1, Z1, TT and probably some others are equipped with an 
ambient light sensor and full access to the sensor is provided via 
0x012F or 0x0137 handle. On newer SA/SB/SC and CA/CB series, only the 
lux reading is provided. This patch provides full support for both 
types, including a driver for TAOS devices used in conjunction with 
handles 0x012F and 0x0137, and a generic layer that exposes control 
files for every handle. Some other model specific parameters provided by 
the hardware, to be used for ALS based backlight regulation, are exposed 
too.

This patch has been written by Marco Chiappero and Javier Achirica.

Signed-off-by: Marco Chiappero <marco@absence.it>
---

--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -1412,6 +1412,1009 @@ static int sony_nc_rfkill_setup(struct a
  	return 0;
  }

+/*	ALS controlled backlight feature	*/
+/* generic ALS data and interface */
+#define ALS_TABLE_SIZE	25
+
+struct als_device_ops {
+	int (*init)(const u8 defaults[]);
+	int (*exit)(void);
+	int (*event_handler)(void);
+	int (*set_power)(unsigned int);
+	int (*get_power)(unsigned int *);
+	int (*get_lux)(unsigned int *, unsigned int *);
+	int (*get_kelvin)(unsigned int *);
+};
+
+struct als_device {
+	unsigned int power;
+	unsigned int managed;
+
+	unsigned int levels_num;
+	u8 *levels;
+	unsigned int defaults_num;
+	u8 *defaults;
+	u8 parameters[ALS_TABLE_SIZE];
+
+	/* common device operations */
+	const struct als_device_ops *ops;
+
+	/* basic ALS sys interface */
+	unsigned int attrs_num;
+	struct device_attribute attrs[7];
+};
+
+static struct als_device *als_handle;
+static int sony_als_handle = -1;
+
+/*
+	model specific ALS data and controls
+	TAOS TSL256x device data
+*/
+#define LUX_SHIFT_BITS		16	/* for non-floating point math */
+/* scale 100000 multiplied fractional coefficients rounding the values */
+#define SCALE(u)	((((((u64) u) << LUX_SHIFT_BITS) / 10000) + 5) / 10)
+
+#define TSL256X_REG_CTRL	0x00
+#define TSL256X_REG_TIMING	0x01
+#define TSL256X_REG_TLOW	0x02
+#define TSL256X_REG_THIGH	0x04
+#define TSL256X_REG_INT		0x06
+#define TSL256X_REG_ID		0x0a
+#define TSL256X_REG_DATA0	0x0c
+#define TSL256X_REG_DATA1	0x0e
+
+#define TSL256X_POWER_ON	0x03
+#define TSL256X_POWER_OFF	0x00
+
+#define TSL256X_POWER_MASK	0x03
+#define TSL256X_INT_MASK	0x10
+
+struct tsl256x_coeff {
+	u32 ratio;
+	u32 ch0;
+	u32 ch1;
+	u32 ka;
+	s32 kb;
+};
+
+struct tsl256x_data {
+	unsigned int gaintime;
+	unsigned int periods;
+	u8 *defaults;
+	struct tsl256x_coeff const *coeff_table;
+};
+static struct tsl256x_data *tsl256x_handle;
+
+static const struct tsl256x_coeff tsl256x_coeff_fn[] = {
+	{
+		.ratio	= SCALE(12500),	/* 0.125 * 2^LUX_SHIFT_BITS  */
+		.ch0	= SCALE(3040),	/* 0.0304 * 2^LUX_SHIFT_BITS */
+		.ch1	= SCALE(2720),	/* 0.0272 * 2^LUX_SHIFT_BITS */
+		.ka	= SCALE(313550000),
+		.kb	= -10651,
+	}, {
+		.ratio	= SCALE(25000),	/* 0.250 * 2^LUX_SHIFT_BITS  */
+		.ch0	= SCALE(3250),	/* 0.0325 * 2^LUX_SHIFT_BITS */
+		.ch1	= SCALE(4400),	/* 0.0440 * 2^LUX_SHIFT_BITS */
+		.ka	= SCALE(203390000),
+		.kb	= -2341,
+	}, {
+		.ratio	= SCALE(37500),	/* 0.375 * 2^LUX_SHIFT_BITS  */
+		.ch0	= SCALE(3510),	/* 0.0351 * 2^LUX_SHIFT_BITS */
+		.ch1	= SCALE(5440),	/* 0.0544 * 2^LUX_SHIFT_BITS */
+		.ka	= SCALE(152180000),
+		.kb	= 157,
+	}, {
+		.ratio	= SCALE(50000),	/* 0.50 * 2^LUX_SHIFT_BITS   */
+		.ch0	= SCALE(3810),	/* 0.0381 * 2^LUX_SHIFT_BITS */
+		.ch1	= SCALE(6240),	/* 0.0624 * 2^LUX_SHIFT_BITS */
+		.ka	= SCALE(163580000),
+		.kb	= -145,
+	}, {
+		.ratio	= SCALE(61000),	/* 0.61 * 2^LUX_SHIFT_BITS   */
+		.ch0	= SCALE(2240),	/* 0.0224 * 2^LUX_SHIFT_BITS */
+		.ch1	= SCALE(3100),	/* 0.0310 * 2^LUX_SHIFT_BITS */
+		.ka	= SCALE(180800000),
+		.kb	= -495,
+	}, {
+		.ratio	= SCALE(80000),	/* 0.80 * 2^LUX_SHIFT_BITS   */
+		.ch0	= SCALE(1280),	/* 0.0128 * 2^LUX_SHIFT_BITS */
+		.ch1	= SCALE(1530),	/* 0.0153 * 2^LUX_SHIFT_BITS */
+		.ka	= SCALE(197340000),
+		.kb	= -765
+	}, {
+		.ratio	= SCALE(130000),/* 1.3 * 2^LUX_SHIFT_BITS     */
+		.ch0	= SCALE(146),	/* 0.00146 * 2^LUX_SHIFT_BITS */
+		.ch1	= SCALE(112),	/* 0.00112 * 2^LUX_SHIFT_BITS */
+		.ka	= SCALE(182900000),
+		.kb	= -608,
+	}, {
+		.ratio	= UINT_MAX,	/* for higher ratios */
+		.ch0	= 0,
+		.ch1	= 0,
+		.ka	= 0,
+		.kb	= 830,
+	}
+};
+
+static const struct tsl256x_coeff tsl256x_coeff_cs[] = {
+	{
+		.ratio  = SCALE(13000),	/* 0.130 * 2^LUX_SHIFT_BITS  */
+		.ch0    = SCALE(3150),	/* 0.0315 * 2^LUX_SHIFT_BITS */
+		.ch1    = SCALE(2620),	/* 0.0262 * 2^LUX_SHIFT_BITS */
+		.ka	= SCALE(300370000),
+		.kb	= -9587,
+	}, {
+		.ratio  = SCALE(26000),	/* 0.260 * 2^LUX_SHIFT_BITS  */
+		.ch0    = SCALE(3370),	/* 0.0337 * 2^LUX_SHIFT_BITS */
+		.ch1    = SCALE(4300),	/* 0.0430 * 2^LUX_SHIFT_BITS */
+		.ka	= SCALE(194270000),
+		.kb	= -1824,
+	}, {
+		.ratio  = SCALE(39000),	/* 0.390 * 2^LUX_SHIFT_BITS  */
+		.ch0    = SCALE(3630),	/* 0.0363 * 2^LUX_SHIFT_BITS */
+		.ch1    = SCALE(5290),	/* 0.0529 * 2^LUX_SHIFT_BITS */
+		.ka	= SCALE(152520000),
+		.kb	= 145,
+	}, {
+		.ratio  = SCALE(52000),	/* 0.520 * 2^LUX_SHIFT_BITS  */
+		.ch0    = SCALE(3920),	/* 0.0392 * 2^LUX_SHIFT_BITS */
+		.ch1    = SCALE(6050),	/* 0.0605 * 2^LUX_SHIFT_BITS */
+		.ka	= SCALE(165960000),
+		.kb	= -200,
+	}, {
+		.ratio  = SCALE(65000),	/* 0.650 * 2^LUX_SHIFT_BITS  */
+		.ch0    = SCALE(2290),	/* 0.0229 * 2^LUX_SHIFT_BITS */
+		.ch1    = SCALE(2910),	/* 0.0291 * 2^LUX_SHIFT_BITS */
+		.ka	= SCALE(184800000),
+		.kb	= -566,
+	}, {
+		.ratio  = SCALE(80000),	/* 0.800 * 2^LUX_SHIFT_BITS  */
+		.ch0    = SCALE(1570),	/* 0.0157 * 2^LUX_SHIFT_BITS */
+		.ch1    = SCALE(1800),	/* 0.0180 * 2^LUX_SHIFT_BITS */
+		.ka	= SCALE(199220000),
+		.kb	= -791,
+	}, {
+		.ratio  = SCALE(130000),/* 0.130 * 2^LUX_SHIFT_BITS  */
+		.ch0    = SCALE(338),	/* 0.00338 * 2^LUX_SHIFT_BITS */
+		.ch1    = SCALE(260),	/* 0.00260 * 2^LUX_SHIFT_BITS */
+		.ka	= SCALE(182900000),
+		.kb	= -608,
+	}, {
+		.ratio  = UINT_MAX,	/* for higher ratios */
+		.ch0    = 0,
+		.ch1    = 0,
+		.ka	= 0,
+		.kb	= 830,
+	}
+};
+
+/*	TAOS helper & control functions		*/
+static inline int tsl256x_exec_writebyte(unsigned int reg,
+						unsigned int const *value)
+{
+	unsigned int result;
+
+	return (sony_call_snc_handle(sony_als_handle, (*value << 0x18) |
+		(reg << 0x10) | 0x800500, &result) || !(result & 0x01))
+		? -EIO : 0;
+}
+
+static inline int tsl256x_exec_writeword(unsigned int reg,
+						unsigned int const *value)
+{
+	u8 result[1];
+	u64 arg = *value;
+
+	/* using sony_call_snc_handle_buffer due to possible input overflows */
+	return ((sony_call_snc_handle_buffer(sony_als_handle, (arg << 0x18) |
+				(reg << 0x10) | 0xA00700, result, 1) < 0) ||
+				!(result[0] & 0x01)) ? -EIO : 0;
+}
+
+static inline int tsl256x_exec_readbyte(unsigned int reg, unsigned int 
*result)
+{
+	if (sony_call_snc_handle(sony_als_handle, (reg << 0x10)
+		| 0x800400, result) || !(*result & 0x01))
+		return -EIO;
+	*result = (*result >> 0x08) & 0xFF;
+
+	return 0;
+}
+
+static inline int tsl256x_exec_readword(unsigned int reg, unsigned int 
*result)
+{
+	if (sony_call_snc_handle(sony_als_handle, (reg << 0x10)
+		| 0xA00600, result) || !(*result & 0x01))
+		return -EIO;
+	*result = (*result >> 0x08) & 0xFFFF;
+
+	return 0;
+}
+
+static int tsl256x_interrupt_ctrls(unsigned int *interrupt,
+					unsigned int *periods)
+{
+	unsigned int value, result;
+
+	/* if no interrupt parameter, retrieve interrupt status */
+	if (!interrupt) {
+		if (tsl256x_exec_readbyte(TSL256X_REG_INT, &result))
+			return -EIO;
+
+		value = (result & TSL256X_INT_MASK);
+	} else {
+		value = *interrupt << 0x04;
+	}
+
+	/* if no periods provided use the last one set */
+	value |= (periods ? *periods : tsl256x_handle->periods);
+
+	if (tsl256x_exec_writebyte(TSL256X_REG_INT, &value))
+		return -EIO;
+
+	if (periods)
+		tsl256x_handle->periods = *periods;
+
+	return 0;
+}
+
+static int tsl256x_setup(void)
+{
+	unsigned int interr = 1, zero = 0;
+
+	/*
+	 *   reset the threshold settings to trigger an event as soon
+	 *   as the event goes on, forcing a backlight adaptation to
+	 *   the current lighting conditions
+	 */
+	tsl256x_exec_writeword(TSL256X_REG_TLOW, &zero);
+	tsl256x_exec_writeword(TSL256X_REG_THIGH, &zero);
+
+	/* set gain and time */
+	if (tsl256x_exec_writebyte(TSL256X_REG_TIMING,
+				&tsl256x_handle->gaintime))
+		return -EIO;
+
+	/* restore persistence value and enable the interrupt generation */
+	if (tsl256x_interrupt_ctrls(&interr, &tsl256x_handle->periods))
+		return -EIO;
+
+	return 0;
+}
+
+static int tsl256x_set_power(unsigned int status)
+{
+	int ret;
+
+	if (status) {
+		ret = tsl256x_setup();
+		if (ret)
+			return ret;
+	}
+
+	status = status ? TSL256X_POWER_ON : TSL256X_POWER_OFF;
+	ret = tsl256x_exec_writebyte(TSL256X_REG_CTRL, &status);
+
+	return ret;
+}
+
+static int tsl256x_get_power(unsigned int *status)
+{
+	if (tsl256x_exec_readbyte(TSL256X_REG_CTRL, status))
+		return -EIO;
+
+	*status = ((*status & TSL256X_POWER_MASK) == TSL256X_POWER_ON) ? 1 : 0;
+
+	return 0;
+}
+
+static int tsl256x_get_raw_data(unsigned int *ch0, unsigned int *ch1)
+{
+	if (!ch0)
+		return -1;
+
+	if (tsl256x_exec_readword(TSL256X_REG_DATA0, ch0))
+		return -EIO;
+
+	if (ch1) {
+		if (tsl256x_exec_readword(TSL256X_REG_DATA1, ch1))
+			return -EIO;
+	}
+
+	return 0;
+}
+
+static int tsl256x_set_thresholds(const unsigned int *ch0)
+{
+	unsigned int tlow, thigh;
+
+	tlow = (*ch0 * tsl256x_handle->defaults[0]) / 100;
+	thigh = ((*ch0 * tsl256x_handle->defaults[1]) / 100) + 1;
+
+	if (thigh > 0xffff)
+		thigh = 0xffff;
+
+	if (tsl256x_exec_writeword(TSL256X_REG_TLOW, &tlow) ||
+		tsl256x_exec_writeword(TSL256X_REG_THIGH, &thigh))
+		return -EIO;
+
+	return 0;
+}
+
+#define MAX_LUX 1500
+static void tsl256x_calculate_lux(const u32 ch0, const u32 ch1,
+				unsigned int *integ, unsigned int *fract)
+{
+	/* the raw output from the sensor is just a "count" value, as
+	   it is the result of the integration of the analog sensor
+	   signal, the counts-to-lux curve (and its approximation can
+	   be found on the datasheet.
+	*/
+	const struct tsl256x_coeff *coeff = tsl256x_handle->coeff_table;
+	u32 ratio, temp, integer, fractional;
+
+	if (ch0 >= 65535 || ch1 >= 65535)
+		goto saturation;
+
+	/* STEP 1: ratio calculation, for ch0 & ch1 coeff selection */
+
+	/* protect against division by 0 */
+	ratio = ch0 ? ((ch1 << (LUX_SHIFT_BITS + 1)) / ch0) : UINT_MAX;
+	/* round the ratio value */
+	ratio = (ratio + 1) >> 1;
+
+	/* coeff selection rule */
+	while (coeff->ratio < ratio)
+		coeff++;
+
+	/* STEP 2: lux calculation formula using the right coeffcients */
+	temp = (ch0 * coeff->ch0) - (ch1 * coeff->ch1);
+	/* the sensor is placed under a plastic or glass cover which filters
+	   a certain ammount of light (depending on that particular material).
+	   To have an accurate reading, we need to compensate for this loss,
+	   multiplying for compensation parameter, taken from the DSDT.
+	*/
+	temp *= tsl256x_handle->defaults[3] / 10;
+
+	/* STEP 3: separate integer and fractional part */
+	/* remove the integer part and multiply for the 10^N, N decimals  */
+	fractional = (temp % (1 << LUX_SHIFT_BITS)) * 100; /* two decimals */
+	/* scale down the value */
+	fractional >>= LUX_SHIFT_BITS;
+
+	/* strip off fractional portion to obtain the integer part */
+	integer = temp >> LUX_SHIFT_BITS;
+
+	if (integer > MAX_LUX)
+		goto saturation;
+
+	*integ = integer;
+	*fract = fractional;
+
+	return;
+
+saturation:
+	*integ = MAX_LUX;
+	*fract = 0;
+}
+
+static void tsl256x_calculate_kelvin(const u32 *ch0, const u32 *ch1,
+					unsigned int *temperature)
+{
+	const struct tsl256x_coeff *coeff = tsl256x_handle->coeff_table;
+	u32 ratio;
+
+	/* protect against division by 0 */
+	ratio = *ch0 ? ((*ch1 << (LUX_SHIFT_BITS + 1)) / *ch0) : UINT_MAX;
+	/* round the ratio value */
+	ratio = (ratio + 1) >> 1;
+
+	/* coeff selection rule */
+	while (coeff->ratio < ratio)
+		coeff++;
+
+	*temperature = ratio ? coeff->ka / ratio + coeff->kb : 0;
+}
+
+static int tsl256x_get_lux(unsigned int *integ, unsigned int *fract)
+{
+	int ret = 0;
+	unsigned int ch0, ch1;
+
+	if (!integ || !fract)
+		return -1;
+
+	ret = tsl256x_get_raw_data(&ch0, &ch1);
+	if (!ret)
+		tsl256x_calculate_lux(ch0, ch1, integ, fract);
+
+	return ret;
+}
+
+static int tsl256x_get_kelvin(unsigned int *temperature)
+{
+	int ret = -1;
+	unsigned int ch0, ch1;
+
+	if (!temperature)
+		return ret;
+
+	ret = tsl256x_get_raw_data(&ch0, &ch1);
+	if (!ret)
+		tsl256x_calculate_kelvin(&ch0, &ch1, temperature);
+
+	return ret;
+}
+
+static int tsl256x_get_id(char *model, unsigned int *id, bool *cs)
+{
+	int ret;
+	unsigned int result;
+	char *name = NULL;
+	bool unknown = false;
+	bool type_cs = false;
+
+	ret = tsl256x_exec_readbyte(TSL256X_REG_ID, &result);
+	if (ret)
+		return ret;
+
+	switch ((result >> 0x04) & 0x0F) {
+	case 11:
+		name = "TAOS TSL2569";
+		break;
+	case 5:
+		name = "TAOS TSL2561";
+		break;
+	case 3:
+		name = "TAOS TSL2563";
+		break;
+	case 0:
+		type_cs = true;
+		name = "TAOS TSL2560CS";
+		break;
+	default:
+		unknown = true;
+		break;
+	}
+
+	if (id)
+		*id = result;
+	if (cs)
+		*cs = type_cs;
+	if (model && name)
+		strcpy(model, name);
+
+	return unknown;
+}
+
+static int tsl256x_event_handler(void)
+{
+	unsigned int ch0, interr = 1;
+
+	/* wait for the EC to clear the interrupt */
+/*      schedule_timeout_interruptible(msecs_to_jiffies(100));	*/
+	/* ...or force the interrupt clear immediately */
+	sony_call_snc_handle(sony_als_handle, 0x04C60500, &interr);
+
+	/* read the raw data */
+	tsl256x_get_raw_data(&ch0, NULL);
+
+	/* set the thresholds */
+	tsl256x_set_thresholds(&ch0);
+
+	/* enable interrupt */
+	tsl256x_interrupt_ctrls(&interr, NULL);
+
+	return 0;
+}
+
+static int tsl256x_init(const u8 defaults[])
+{
+	unsigned int id;
+	int ret = 0;
+	bool cs; /* if CS package choose CS coefficients */
+	char model[64];
+
+	/* detect the device */
+	ret = tsl256x_get_id(model, &id, &cs);
+	if (ret < 0)
+		return ret;
+	if (ret) {
+		dprintk("unsupported ALS found (unknown model "
+			"number %u rev. %u\n", id >> 4, id & 0x0F);
+		return ret;
+	} else {
+		dprintk("found ALS model number %u rev. %u (%s)\n",
+				id >> 4, id & 0x0F, model);
+	}
+
+	tsl256x_handle = kzalloc(sizeof(struct tsl256x_data), GFP_KERNEL);
+	if (!tsl256x_handle)
+		return -ENOMEM;
+
+	tsl256x_handle->defaults = kzalloc(sizeof(u8) * 4, GFP_KERNEL);
+	if (!tsl256x_handle->defaults) {
+		kfree(tsl256x_handle);
+		return -ENOMEM;
+	}
+
+	/* populate the device data */
+	tsl256x_handle->defaults[0] = defaults[3];  /* low threshold % */
+	tsl256x_handle->defaults[1] = defaults[4];  /* high threshold % */
+	tsl256x_handle->defaults[2] = defaults[9];  /* sensor interrupt rate */
+	tsl256x_handle->defaults[3] = defaults[10]; /* light compensat. rate */
+	tsl256x_handle->gaintime = 0x12;
+	tsl256x_handle->periods = defaults[9];
+	tsl256x_handle->coeff_table = cs ? tsl256x_coeff_cs : tsl256x_coeff_fn;
+
+	ret = tsl256x_setup();
+
+	return ret;
+}
+
+static int tsl256x_exit(void)
+{
+	unsigned int interr = 0, periods = tsl256x_handle->defaults[2];
+
+	/* disable the interrupt generation, restore defaults */
+	tsl256x_interrupt_ctrls(&interr, &periods);
+
+	tsl256x_handle->coeff_table = NULL;
+	kfree(tsl256x_handle->defaults);
+	tsl256x_handle->defaults = NULL;
+	kfree(tsl256x_handle);
+
+	return 0;
+}
+
+/* TAOS TSL256x specific ops */
+static const struct als_device_ops tsl256x_ops = {
+	.init = tsl256x_init,
+	.exit = tsl256x_exit,
+	.event_handler = tsl256x_event_handler,
+	.set_power = tsl256x_set_power,
+	.get_power = tsl256x_get_power,
+	.get_lux = tsl256x_get_lux,
+	.get_kelvin = tsl256x_get_kelvin,
+};
+
+/* unknown ALS sensors controlled by the EC present on newer Vaios */
+static inline int ngals_get_raw_data(unsigned int *data)
+{
+	if (sony_call_snc_handle(sony_als_handle, 0x1000, data))
+		return -EIO;
+
+	return 0;
+}
+
+static int ngals_get_lux(unsigned int *integ, unsigned int *fract)
+{
+	unsigned int data;
+
+	if (sony_call_snc_handle(sony_als_handle, 0x1000, &data))
+		return -EIO;
+
+	/* if we have a valid lux data */
+	if (!!(data & 0xff0000) == 0x01) {
+		*integ = 0xffff & data;
+		*fract = 0;
+	} else {
+		return -1;
+	}
+
+	return 0;
+}
+
+static const struct als_device_ops ngals_ops = {
+	.init = NULL,
+	.exit = NULL,
+	.event_handler = NULL,
+	.set_power = NULL,
+	.get_power = NULL,
+	.get_lux = ngals_get_lux,
+	.get_kelvin = NULL,
+};
+
+/*	ALS common data and functions	*/
+static int sony_nc_als_event_handler(void)
+{
+	/* call the device handler */
+	if (als_handle->ops->event_handler)
+		als_handle->ops->event_handler();
+
+	return 0;
+}
+
+static int sony_nc_als_power_set(unsigned int status)
+{
+	if (!als_handle->ops->set_power)
+		return -EPERM;
+
+	if (als_handle->ops->set_power(status))
+		return -EIO;
+
+	als_handle->power = status;
+
+	return 0;
+}
+
+static int sony_nc_als_managed_set(unsigned int status)
+{
+	int ret = 0;
+	unsigned int result, cmd;
+	static bool was_on;
+
+	/*  turn on/off the event notification
+	 *  (and enable als_backlight writes)
+	 */
+	cmd = sony_als_handle == 0x0143 ? 0x2200 : 0x0900;
+	if (sony_call_snc_handle(sony_als_handle,
+		(status << 0x10) | cmd, &result))
+		return -EIO;
+
+	als_handle->managed = status;
+
+	/* turn on the ALS; this will also enable the interrupt generation */
+	if (status) /* store the power state else check the previous state */
+		was_on = als_handle->power;
+	else if (was_on)
+		return 0;
+
+	ret = sony_nc_als_power_set(status);
+	if (ret == -EPERM) /* new models do not allow power control */
+		ret = 0;
+
+	return ret;
+}
+
+/*	ALS sys interface	*/
+static ssize_t sony_nc_als_power_show(struct device *dev,
+		struct device_attribute *attr, char *buffer)
+{
+	ssize_t count = 0;
+	int status;
+
+	if (!als_handle->ops->get_power)
+		return -EPERM;
+
+	if (als_handle->ops->get_power(&status))
+		return -EIO;
+
+	count = snprintf(buffer, PAGE_SIZE, "%d\n", status);
+
+	return count;
+}
+
+static ssize_t sony_nc_als_power_store(struct device *dev,
+		struct device_attribute *attr,
+		const char *buffer, size_t count)
+{
+	int ret;
+	unsigned long value;
+
+	if (count > 31)
+		return -EINVAL;
+
+	if (strict_strtoul(buffer, 10, &value) || value > 1)
+		return -EINVAL;
+
+	/* no action if already set */
+	if (value == als_handle->power)
+		return count;
+
+	ret = sony_nc_als_power_set(value);
+	if (ret)
+		return ret;
+
+	return count;
+}
+
+static ssize_t sony_nc_als_managed_show(struct device *dev,
+		struct device_attribute *attr, char *buffer)
+{
+	ssize_t count = 0;
+	unsigned int status, cmd;
+
+	cmd = sony_als_handle == 0x0143 ? 0x2100 : 0x0A00;
+	if (sony_call_snc_handle(sony_als_handle, cmd, &status))
+		return -EIO;
+
+	count = snprintf(buffer, PAGE_SIZE, "%d\n", status & 0x01);
+
+	return count;
+}
+
+static ssize_t sony_nc_als_managed_store(struct device *dev,
+		struct device_attribute *attr,
+		const char *buffer, size_t count)
+{
+	unsigned long value;
+
+	if (count > 31)
+		return -EINVAL;
+
+	if (strict_strtoul(buffer, 10, &value) || value > 1)
+		return -EINVAL;
+
+	if (als_handle->managed != value) {
+		int ret = sony_nc_als_managed_set(value);
+		if (ret)
+			return ret;
+	}
+
+	return count;
+}
+
+static ssize_t sony_nc_als_lux_show(struct device *dev,
+		struct device_attribute *attr, char *buffer)
+{
+	ssize_t count = 0;
+	unsigned int integ = 0, fract = 0;
+
+	if (als_handle->power)
+		/* als_handle->ops->get_lux is mandatory, no check */
+		als_handle->ops->get_lux(&integ, &fract);
+
+	count = snprintf(buffer, PAGE_SIZE, "%u.%.2u\n", integ, fract);
+
+	return count;
+}
+
+static ssize_t sony_nc_als_parameters_show(struct device *dev,
+		struct device_attribute *attr, char *buffer)
+{
+	ssize_t count = 0;
+	unsigned int i, num;
+	u8 *list;
+
+	if (!strcmp(attr->attr.name, "als_defaults")) {
+		list = als_handle->defaults;
+		num = als_handle->defaults_num;
+	} else { /* als_backlight_levels */
+		list = als_handle->levels;
+		num = als_handle->levels_num;
+	}
+
+	for (i = 0; i < num; i++)
+		count += snprintf(buffer + count, PAGE_SIZE - count,
+				"0x%.2x ", list[i]);
+
+	count += snprintf(buffer + count, PAGE_SIZE - count, "\n");
+
+	return count;
+}
+
+static ssize_t sony_nc_als_backlight_show(struct device *dev,
+		struct device_attribute *attr, char *buffer)
+{
+	ssize_t count = 0;
+	unsigned int result, cmd;
+
+	cmd = sony_als_handle == 0x0143 ? 0x3100 : 0x0200;
+	if (sony_call_snc_handle(sony_als_handle, cmd, &result))
+		return -EIO;
+
+	count = snprintf(buffer, PAGE_SIZE, "%d\n", result & 0xff);
+
+	return count;
+}
+
+static ssize_t sony_nc_als_backlight_store(struct device *dev,
+		struct device_attribute *attr,
+		const char *buffer, size_t count)
+{
+	unsigned long value;
+	unsigned int result, cmd, max = als_handle->levels_num - 1;
+
+	if (count > 31)
+		return -EINVAL;
+
+	if (strict_strtoul(buffer, 10, &value))
+		return -EINVAL;
+
+	if (!als_handle->managed)
+		return -EPERM;
+
+	/* verify that the provided value falls inside the model
+	   specific backlight range */
+	if ((value < als_handle->levels[0])
+			|| (value > als_handle->levels[max]))
+		return -EINVAL;
+
+	cmd = sony_als_handle == 0x0143 ? 0x3000 : 0x0100;
+	if (sony_call_snc_handle(sony_als_handle, (value << 0x10) | cmd,
+				&result))
+		return -EIO;
+
+	return count;
+}
+
+static ssize_t sony_nc_als_kelvin_show(struct device *dev,
+		struct device_attribute *attr, char *buffer)
+{
+	ssize_t count = 0;
+	unsigned int kelvin = 0;
+
+	if (als_handle->ops->get_kelvin && als_handle->power)
+		als_handle->ops->get_kelvin(&kelvin);
+
+	count = snprintf(buffer, PAGE_SIZE, "%d\n", kelvin);
+
+	return count;
+}
+
+
+/*	ALS attach/detach functions	*/
+static int sony_nc_als_setup(struct platform_device *pd)
+{
+	int i = 0;
+
+	/* check the device presence */
+	if (sony_als_handle == 0x0137) {
+		unsigned int result;
+
+		if (sony_call_snc_handle(sony_als_handle, 0xB00, &result))
+			return -EIO;
+
+		if (!(result & 0x01)) {
+			pr_info("no ALS present\n");
+			return 0;
+		}
+	}
+
+	als_handle = kzalloc(sizeof(struct als_device), GFP_KERNEL);
+	if (!als_handle)
+		return -ENOMEM;
+
+	/* set model specific data */
+	/* if handle 0x012f or 0x0137 use tsl256x_ops, else new als controls */
+	if (sony_als_handle == 0x0143) {
+		als_handle->ops = &ngals_ops;
+		als_handle->levels_num = 16;
+		als_handle->defaults_num = 9;
+	} else {
+		als_handle->ops = &tsl256x_ops;
+		als_handle->levels_num = 9;
+		als_handle->defaults_num = 13;
+	}
+	/* backlight levels are the first levels_num values, the remaining
+	   defaults_num values are default settings for als regulation
+	*/
+	als_handle->levels = als_handle->parameters;
+	als_handle->defaults = als_handle->parameters + als_handle->levels_num;
+
+	/* get power state */
+	if (als_handle->ops->get_power) {
+		if (als_handle->ops->get_power(&als_handle->power))
+			pr_warn("unable to retrieve the power status\n");
+	}
+
+	/* set managed to 0, userspace daemon should enable it */
+	sony_nc_als_managed_set(0);
+
+	/* get ALS parameters */
+	if (sony_call_snc_handle_buffer(sony_als_handle, 0x0000,
+		als_handle->parameters, ALS_TABLE_SIZE) < 0)
+		goto nosensor;
+
+	/* initial device configuration */
+	if (als_handle->ops->init)
+		if (als_handle->ops->init(als_handle->defaults)) {
+			pr_warn("ALS setup failed\n");
+			goto nosensor;
+		}
+
+	/* set up the sys interface */
+
+	/* notifications and backlight enable control file */
+	sysfs_attr_init(&als_handle->attrs[0].attr);
+	als_handle->attrs[0].attr.name = "als_managed";
+	als_handle->attrs[0].attr.mode = S_IRUGO | S_IWUSR;
+	als_handle->attrs[0].show = sony_nc_als_managed_show;
+	als_handle->attrs[0].store = sony_nc_als_managed_store;
+	/* lux equivalent value */
+	sysfs_attr_init(&als_handle->attrs[1].attr);
+	als_handle->attrs[1].attr.name = "als_lux";
+	als_handle->attrs[1].attr.mode = S_IRUGO;
+	als_handle->attrs[1].show = sony_nc_als_lux_show;
+	/* ALS default parameters */
+	sysfs_attr_init(&als_handle->attrs[2].attr);
+	als_handle->attrs[2].attr.name = "als_defaults";
+	als_handle->attrs[2].attr.mode = S_IRUGO;
+	als_handle->attrs[2].show = sony_nc_als_parameters_show;
+	/* ALS default backlight levels */
+	sysfs_attr_init(&als_handle->attrs[3].attr);
+	als_handle->attrs[3].attr.name = "als_backlight_levels";
+	als_handle->attrs[3].attr.mode = S_IRUGO;
+	als_handle->attrs[3].show = sony_nc_als_parameters_show;
+	/* als backlight control */
+	sysfs_attr_init(&als_handle->attrs[4].attr);
+	als_handle->attrs[4].attr.name = "als_backlight";
+	als_handle->attrs[4].attr.mode = S_IRUGO | S_IWUSR;
+	als_handle->attrs[4].show = sony_nc_als_backlight_show;
+	als_handle->attrs[4].store = sony_nc_als_backlight_store;
+
+	als_handle->attrs_num = 5;
+	/* end mandatory sys interface */
+
+	if (als_handle->ops->get_power || als_handle->ops->set_power) {
+		int i = als_handle->attrs_num++;
+
+		/* als power control */
+		sysfs_attr_init(&als_handle->attrs[i].attr);
+		als_handle->attrs[i].attr.name = "als_power";
+		als_handle->attrs[i].attr.mode = S_IRUGO | S_IWUSR;
+		als_handle->attrs[i].show = sony_nc_als_power_show;
+		als_handle->attrs[i].store = sony_nc_als_power_store;
+	}
+
+	if (als_handle->ops->get_kelvin) {
+		int i = als_handle->attrs_num++;
+
+		/* light temperature */
+		sysfs_attr_init(&als_handle->attrs[i].attr);
+		als_handle->attrs[i].attr.name = "als_kelvin";
+		als_handle->attrs[i].attr.mode = S_IRUGO;
+		als_handle->attrs[i].show = sony_nc_als_kelvin_show;
+	}
+
+	/* everything or nothing, otherwise unable to control the ALS */
+	for (; i < als_handle->attrs_num; i++) {
+		if (device_create_file(&pd->dev, &als_handle->attrs[i]))
+			goto attrserror;
+	}
+
+	return 0;
+
+attrserror:
+	for (; i > 0; i--)
+		device_remove_file(&pd->dev, &als_handle->attrs[i]);
+nosensor:
+	kfree(als_handle);
+	als_handle = NULL;
+
+	return -1;
+}
+
+static void sony_nc_als_resume(void)
+{
+	if (als_handle->managed) /* it restores the power state too */
+		sony_nc_als_managed_set(1);
+	else if (als_handle->power)
+		sony_nc_als_power_set(1);
+}
+
+static int sony_nc_als_cleanup(struct platform_device *pd)
+{
+	if (als_handle) {
+		int i;
+
+		for (i = 0; i < als_handle->attrs_num; i++)
+			device_remove_file(&pd->dev, &als_handle->attrs[i]);
+
+		/* disable the events notification */
+		if (als_handle->managed)
+			if (sony_nc_als_managed_set(0))
+				pr_info("ALS notifications disable failed\n");
+
+		if (als_handle->power)
+			if (sony_nc_als_power_set(0))
+				pr_info("ALS power off failed\n");
+
+		if (als_handle->ops->exit)
+			if (als_handle->ops->exit())
+				pr_info("ALS device cleaning failed\n");
+
+		kfree(als_handle);
+		als_handle = NULL;
+	}
+
+	return 0;
+}
+/*	end ALS code	*/
+
  /* Keyboard backlight feature */
  struct kbd_backlight {
  	unsigned int base;
@@ -2899,6 +3902,9 @@ static void sony_nc_snc_setup_handles(st
  		case 0x0143:
  			sony_kbd_handle = handle;
  			ret = sony_nc_kbd_backlight_setup(pd);
+		case 0x012f: /* no keyboard backlight */
+			sony_als_handle = handle;
+			ret = sony_nc_als_setup(pd);
  			break;
  		case 0x0131:
  			ret = sony_nc_highspeed_charging_setup(pd);
@@ -2964,6 +3970,8 @@ static void sony_nc_snc_cleanup_handles(
  		case 0x0137:
  		case 0x0143:
  			sony_nc_kbd_backlight_cleanup(pd);
+		case 0x012f:
+			sony_nc_als_cleanup(pd);
  			break;
  		case 0x0131:
  			sony_nc_highspeed_charging_cleanup(pd);
@@ -3082,6 +4090,8 @@ static int sony_nc_snc_resume(void)
  		case 0x0137: /* kbd + als */
  		case 0x0143:
  			sony_nc_kbd_backlight_resume();
+		case 0x012f: /* als only */
+			sony_nc_als_resume();
  			break;
  		default:
  			continue;
@@ -3146,6 +4156,31 @@ static void sony_nc_notify(struct acpi_d
  			ev = 1;
  			break;

+		case 0x0143:
+			sony_call_snc_handle(sony_als_handle, 0x2000, &result);
+			/* event reasons are reverted */
+			value = (result & 0x03) == 1 ? 2 : 1;
+			dprintk("sony_nc_notify, ALS event received (reason:"
+				       " %s change)\n", value == 1 ? "light" :
+				       "backlight");
+			/* no further actions needed */
+
+			ev = 3;
+			break;
+
+		case 0x012f:
+		case 0x0137:
+			sony_call_snc_handle(sony_als_handle, 0x0800, &result);
+			value = result & 0x03;
+			dprintk("sony_nc_notify, ALS event received (reason:"
+					" %s change)\n", value == 1 ? "light" :
+					"backlight");
+			if (value == 1) /* lighting change reason */
+				sony_nc_als_event_handler();
+
+			ev = 3;
+			break;
+
  		case 0x0124:
  		case 0x0135:
  			sony_call_snc_handle(sony_rfkill_handle, 0x0100,

[PATCH 24/25] sony-laptop: backlight device changes

[Marco Chiappero]

On Vaio models equipped with an ALS device, when the video driver 
backlight device is not used, a similar backlight device (based on the 
_BCM method implementation) is created by the sony-laptop driver, using 
the same backlight levels.


Signed-off-by: Marco Chiappero <marco@absence.it>
---

--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -1038,69 +1038,6 @@ static ssize_t sony_nc_sysfs_store(struc
  	return count;
  }

-
-/*
- * Backlight device
- */
-struct sony_backlight_props {
-	struct backlight_device *dev;
-	int			handle;
-	u8			offset;
-	u8			maxlvl;
-};
-struct sony_backlight_props sony_bl_props;
-
-static int sony_backlight_update_status(struct backlight_device *bd)
-{
-	return acpi_callsetfunc(sony_nc_acpi_handle, "SBRT",
-				bd->props.brightness + 1, NULL);
-}
-
-static int sony_backlight_get_brightness(struct backlight_device *bd)
-{
-	unsigned int value;
-
-	if (acpi_callgetfunc(sony_nc_acpi_handle, "GBRT", &value))
-		return 0;
-	/* brightness levels are 1-based, while backlight ones are 0-based */
-	return value - 1;
-}
-
-static int sony_nc_get_brightness_ng(struct backlight_device *bd)
-{
-	unsigned int result;
-	struct sony_backlight_props *sdev =
-		(struct sony_backlight_props *)bl_get_data(bd);
-
-	sony_call_snc_handle(sdev->handle, 0x0200, &result);
-
-	return (result & 0xff) - sdev->offset;
-}
-
-static int sony_nc_update_status_ng(struct backlight_device *bd)
-{
-	unsigned int value, result;
-	struct sony_backlight_props *sdev =
-		(struct sony_backlight_props *)bl_get_data(bd);
-
-	value = bd->props.brightness + sdev->offset;
-	if (sony_call_snc_handle(sdev->handle, 0x0100 | (value << 16), &result))
-		return -EIO;
-
-	return value;
-}
-
-static const struct backlight_ops sony_backlight_ops = {
-	.options = BL_CORE_SUSPENDRESUME,
-	.update_status = sony_backlight_update_status,
-	.get_brightness = sony_backlight_get_brightness,
-};
-static const struct backlight_ops sony_backlight_ng_ops = {
-	.options = BL_CORE_SUSPENDRESUME,
-	.update_status = sony_nc_update_status_ng,
-	.get_brightness = sony_nc_get_brightness_ng,
-};
-
  /*
   * New SNC-only Vaios event mapping to driver known keys
   */
@@ -2069,6 +2006,44 @@ static int sony_nc_als_managed_set(unsig
  	return ret;
  }

+static unsigned int level;
+static int sony_nc_als_get_brightness(struct backlight_device *bd)
+{
+	if (bd->props.brightness != level)
+		dprintk("bd->props.brightness != level\n");
+
+	return level;
+}
+
+static int sony_nc_als_update_status(struct backlight_device *bd)
+{
+	unsigned int value, result;
+
+	if (als_handle->managed) {
+		if (bd->props.brightness != level) {
+			dprintk("generating ALS event 3 (reason: 2)\n");
+			acpi_bus_generate_proc_event(sony_nc_acpi_device,
+					3, 2);
+			acpi_bus_generate_netlink_event(
+					sony_nc_acpi_device->pnp.device_class,
+					dev_name(&sony_nc_acpi_device->dev),
+					3, 2);
+		}
+	} else {
+		unsigned int cmd;
+
+		value = als_handle->levels[bd->props.brightness];
+		cmd = sony_als_handle == 0x0143 ? 0x3000 : 0x0100;
+		if (sony_call_snc_handle(sony_als_handle,
+					(value << 0x10) | cmd, &result))
+			return -EIO;
+	}
+
+	level = bd->props.brightness;
+
+	return level;
+}
+
  /*	ALS sys interface	*/
  static ssize_t sony_nc_als_power_show(struct device *dev,
  		struct device_attribute *attr, char *buffer)
@@ -2245,7 +2220,6 @@ static ssize_t sony_nc_als_kelvin_show(s
  	return count;
  }

-
  /*	ALS attach/detach functions	*/
  static int sony_nc_als_setup(struct platform_device *pd)
  {
@@ -3742,76 +3716,38 @@ static int sony_nc_odd_cleanup(struct pl
  	return 0;
  }

+/*
+ * Backlight device
+ */
+static struct backlight_device *sony_backlight_device;

-static void sony_nc_backlight_ng_read_limits(int handle,
-		struct sony_backlight_props *props)
+static int sony_backlight_update_status(struct backlight_device *bd)
  {
-	int offset;
-	acpi_status status;
-	u8 brlvl, i;
-	u8 min = 0xff, max = 0x00;
-	struct acpi_object_list params;
-	union acpi_object in_obj;
-	union acpi_object *lvl_enum;
-	struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
-
-	props->handle = handle;
-	props->offset = 0;
-	props->maxlvl = 0xff;
-
-	offset = sony_find_snc_handle(handle);
-	if (offset < 0)
-		return;
-
-	/* try to read the boundaries from ACPI tables, if we fail the above
-	 * defaults should be reasonable
-	 */
-	params.count = 1;
-	params.pointer = &in_obj;
-	in_obj.type = ACPI_TYPE_INTEGER;
-	in_obj.integer.value = offset;
-	status = acpi_evaluate_object(sony_nc_acpi_handle, "SN06", &params,
-			&buffer);
-	if (ACPI_FAILURE(status))
-		return;
-
-	lvl_enum = (union acpi_object *) buffer.pointer;
-	if (!lvl_enum) {
-		pr_err("No SN06 return object.");
-		return;
-	}
-	if (lvl_enum->type != ACPI_TYPE_BUFFER) {
-		pr_err("Invalid SN06 return object 0x%.2x\n",
-		       lvl_enum->type);
-		goto out_invalid;
-	}
-
-	/* the buffer lists brightness levels available, brightness levels are
-	 * from 0 to 8 in the array, other values are used by ALS control.
-	 */
-	for (i = 0; i < 9 && i < lvl_enum->buffer.length; i++) {
-
-		brlvl = *(lvl_enum->buffer.pointer + i);
-		dprintk("Brightness level: %d\n", brlvl);
-
-		if (!brlvl)
-			break;
+	return acpi_callsetfunc(sony_nc_acpi_handle, "SBRT",
+				bd->props.brightness + 1, NULL);
+}

-		if (brlvl > max)
-			max = brlvl;
-		if (brlvl < min)
-			min = brlvl;
-	}
-	props->offset = min;
-	props->maxlvl = max;
-	dprintk("Brightness levels: min=%d max=%d\n", props->offset,
-			props->maxlvl);
+static int sony_backlight_get_brightness(struct backlight_device *bd)
+{
+	unsigned int value;

-out_invalid:
-	kfree(buffer.pointer);
-	return;
+	if (acpi_callgetfunc(sony_nc_acpi_handle, "GBRT", &value))
+		return 0;
+	/* brightness levels are 1-based, while backlight ones are 0-based */
+	return value - 1;
  }

+static const struct backlight_ops sony_backlight_ops = {
+	.options = BL_CORE_SUSPENDRESUME,
+	.update_status = sony_backlight_update_status,
+	.get_brightness = sony_backlight_get_brightness,
+};
+static const struct backlight_ops sony_als_backlight_ops = {
+	.options = BL_CORE_SUSPENDRESUME,
+	.update_status = sony_nc_als_update_status,
+	.get_brightness = sony_nc_als_get_brightness,
+};
+
  static void sony_nc_backlight_setup(void)
  {
  	acpi_handle unused;
@@ -3819,43 +3755,38 @@ static void sony_nc_backlight_setup(void
  	const struct backlight_ops *ops = NULL;
  	struct backlight_properties props;

-	if (sony_find_snc_handle(0x12f) != -1) {
-		ops = &sony_backlight_ng_ops;
-		sony_nc_backlight_ng_read_limits(0x12f, &sony_bl_props);
-		max_brightness = sony_bl_props.maxlvl - sony_bl_props.offset;
-
-	} else if (sony_find_snc_handle(0x137) != -1) {
-		ops = &sony_backlight_ng_ops;
-		sony_nc_backlight_ng_read_limits(0x137, &sony_bl_props);
-		max_brightness = sony_bl_props.maxlvl - sony_bl_props.offset;
-
+	/* do not use SNC GBRT/SBRT controls along with the ALS */
+	if (sony_als_handle != -1) {
+		/* ALS based backlight device */
+		ops = &sony_als_backlight_ops;
+		max_brightness = als_handle->levels_num - 1;
  	} else if (ACPI_SUCCESS(acpi_get_handle(sony_nc_acpi_handle, "GBRT",
  						&unused))) {
  		ops = &sony_backlight_ops;
  		max_brightness = SONY_MAX_BRIGHTNESS - 1;
-
-	} else
+	} else {
  		return;
+	}

  	memset(&props, 0, sizeof(struct backlight_properties));
  	props.type = BACKLIGHT_PLATFORM;
  	props.max_brightness = max_brightness;
-	sony_bl_props.dev = backlight_device_register("sony", NULL,
-						      &sony_bl_props,
-						      ops, &props);
+	sony_backlight_device = backlight_device_register("sony", NULL, NULL,
+								ops, &props);

-	if (IS_ERR(sony_bl_props.dev)) {
+	if (IS_ERR(sony_backlight_device)) {
  		pr_warn("unable to register backlight device\n");
-		sony_bl_props.dev = NULL;
-	} else
-		sony_bl_props.dev->props.brightness =
-			ops->get_brightness(sony_bl_props.dev);
+		sony_backlight_device = NULL;
+	} else {
+		sony_backlight_device->props.brightness =
+			ops->get_brightness(sony_backlight_device);
+	}
  }

  static void sony_nc_backlight_cleanup(void)
  {
-	if (sony_bl_props.dev)
-		backlight_device_unregister(sony_bl_props.dev);
+	if (sony_backlight_device)
+		backlight_device_unregister(sony_backlight_device);
  }

  static void sony_nc_snc_setup_handles(struct platform_device *pd)
@@ -5273,7 +5204,7 @@ static long sonypi_misc_ioctl(struct fil
  	mutex_lock(&spic_dev.lock);
  	switch (cmd) {
  	case SONYPI_IOCGBRT:
-		if (sony_bl_props.dev == NULL) {
+		if (sony_backlight_device == NULL) {
  			ret = -EIO;
  			break;
  		}
@@ -5286,7 +5217,7 @@ static long sonypi_misc_ioctl(struct fil
  				ret = -EFAULT;
  		break;
  	case SONYPI_IOCSBRT:
-		if (sony_bl_props.dev == NULL) {
+		if (sony_backlight_device == NULL) {
  			ret = -EIO;
  			break;
  		}
@@ -5300,8 +5231,8 @@ static long sonypi_misc_ioctl(struct fil
  			break;
  		}
  		/* sync the backlight device status */
-		sony_bl_props.dev->props.brightness =
-		    sony_backlight_get_brightness(sony_bl_props.dev);
+		sony_backlight_device->props.brightness =
+		    sony_backlight_get_brightness(sony_backlight_device);
  		break;
  	case SONYPI_IOCGBAT1CAP:
  		if (ec_read16(SONYPI_BAT1_FULL, &val16)) {

[PATCH 25/25] sony-laptop: update copyright owners

[Marco Chiappero]

Marco Chiappero and Javier Achirica added.


Signed-off-by: Marco Chiappero <marco@absence.it>
---

--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -3,6 +3,8 @@
   *
   * Copyright (C) 2004-2005 Stelian Pop <stelian@popies.net>
   * Copyright (C) 2007-2009 Mattia Dongili <malattia@linux.it>
+ * Copyright (C) 2011 Marco Chiappero <marco@absence.it>
+ * Copyright (C) 2011 Javier Achirica <jachirica@gmail.com>
   *
   * Parts of this driver inspired from asus_acpi.c and ibm_acpi.c
   * which are copyrighted by their respective authors.

Re: [PATCH 19/25] sony-laptop: add touchpad enable/disable control file

[Dmitry Torokhov]

On Friday, June 03, 2011 11:16:52 AM Marco Chiappero wrote:
> Handle 0x0105 allows to change (and store persistently) the touchpad
> state, while notebooks with handle 0x0148 also provides the Fn-F1 combo
> to change the touchpad state, but the key driven change is not handled
> by this patch.

Why do we want to do this? X allows to ignore certain pointing devices 
IIRC.

Thanks.

-- 
Dmitry

Re: [PATCH 19/25] sony-laptop: add touchpad enable/disable control file

[Marco Chiappero]

Il 03/06/2011 22:23, Dmitry Torokhov ha scritto:

> Why do we want to do this? X allows to ignore certain pointing devices
> IIRC.

Because I believe it turns off the device, the power state is also 
stored and preserved across reboots and shutdowns. Telling X to ignore 
the input is, IMHO, a workaround if we have the hardware capability for 
that (and why should we suppose that X will be used always and forever?).

Re: [PATCH 19/25] sony-laptop: add touchpad enable/disable control file

[Dmitry Torokhov]

On Friday, June 03, 2011 01:33:05 PM Marco Chiappero wrote:
> Il 03/06/2011 22:23, Dmitry Torokhov ha scritto:
> > Why do we want to do this? X allows to ignore certain pointing devices
> > IIRC.
> 
> Because I believe it turns off the device, the power state is also
> stored and preserved across reboots and shutdowns. Telling X to ignore
> the input is, IMHO, a workaround if we have the hardware capability for
> that

The issue with that that we are breeding myriad of quirks that nobody
knows about and nobody ever uses. X provides standardized way of
ignoring input devices. It is also more transparent than "I once wrote
something to some sysfs file and I completely forgot about this but
now my touchpad does not work". There were quite a few bugs filed just
because users pressed key that cuts power to touchpad and stores the
state across reboots.

> (and why should we suppose that X will be used always and
> forever?).

We should not but replacement should have at least the same functionality
if not better.

-- 
Dmitry

Re: [PATCH 19/25] sony-laptop: add touchpad enable/disable control file

[Marco Chiappero]

Il 03/06/2011 23:00, Dmitry Torokhov ha scritto:
> The issue with that that we are breeding myriad of quirks

Where is the quirk? If many vendors provide the same feature let's 
create a common interface for that.

> that nobody
> knows  about

This is false, especially for (so many) people using Windows too, where 
the feature is clearly visible by the OEM software.

> and nobody ever uses.

Again, this is false, and I don't think you can speak for everybody.

> X provides standardized way of
> ignoring input devices.

Let's create a standardized solution, instead of using a standardized hack.

> It is also more transparent than "I once wrote
> something to some sysfs file and I completely forgot about this but
> now my touchpad does not work".

The problem does not lie in the sysfs file, lies in the lack of 
userspace software for it (BTW, about this case someone already created 
a Vaio specific GUI for an easy control of these features).

> There were quite a few bugs filed just
> because users pressed key that cuts power to touchpad and stores the
> state across reboots.

It's very much like saying that we should not produce cars because some 
people use them improperly and crash. People doing wrong things will 
always be present, we can improve userspace software to help them 
instead, not just delete features they payed for (and they wanted to 
use, at least once as you say).

>> (and why should we suppose that X will be used always and
>> forever?).
>
> We should not but replacement should have at least the same functionality
> if not better.

I agree, but this doesn't necessarily mean it will use an hack again.

It's a common and widespread feature, let's support it better instead of 
just removing it.

Re: [PATCH 19/25] sony-laptop: add touchpad enable/disable control file

[Dmitry Torokhov]

On Friday, June 03, 2011 02:46:39 PM Marco Chiappero wrote:
> Il 03/06/2011 23:00, Dmitry Torokhov ha scritto:
> > The issue with that that we are breeding myriad of quirks
> 
> Where is the quirk?

The quirk is that for given device there is a sysfs attribute somewhere
that one can write something into to turn the touchpad off. 

> If many vendors provide the same feature let's
> create a common interface for that.
> 
> > that nobody
> > knows  about
> 
> This is false, especially for (so many) people using Windows too, where
> the feature is clearly visible by the OEM software.

Thankfully OEM software either does not exist or is not widespread on
Linux. 

> 
> > and nobody ever uses.
> 
> Again, this is false, and I don't think you can speak for everybody.

No, I indeed can not speak for everybody, but it is my belief that this
feature in the form it is implemented will not be widely used.

> 
> > X provides standardized way of
> > ignoring input devices.
> 
> Let's create a standardized solution, instead of using a standardized
> hack.
> 
> > It is also more transparent than "I once wrote
> > something to some sysfs file and I completely forgot about this but
> > now my touchpad does not work".
> 
> The problem does not lie in the sysfs file, lies in the lack of
> userspace software for it (BTW, about this case someone already created
> a Vaio specific GUI for an easy control of these features).

Gah... Vaio-specific, Dell-specific, HP-specific... I'd rather we do not
go down this road. The kernel needs to abstract away this data and present
unified interface to the userspace. For bonus points... No, scratch that.
The interface should behave consistently for all input devices, including
keyboards, keypads, etc. 

> 
> > There were quite a few bugs filed just
> > because users pressed key that cuts power to touchpad and stores the
> > state across reboots.
> 
> It's very much like saying that we should not produce cars because some
> people use them improperly and crash. People doing wrong things will
> always be present, we can improve userspace software to help them
> instead, not just delete features they payed for (and they wanted to
> use, at least once as you say).

No, it's like saying railroad tracks should be unified instead of every
country inventing their own size. We all know how helpful it was.

> 
> >> (and why should we suppose that X will be used always and
> >> forever?).
> > 
> > We should not but replacement should have at least the same
> > functionality if not better.
> 
> I agree, but this doesn't necessarily mean it will use an hack again.
> 
> It's a common and widespread feature, let's support it better instead of
> just removing it.

What is the feature again? What do users really want to do here?
Do they turn off the touchpad because in interferes when they type?
Do they hate touchpads? Do they believe they will save power if the
touchpad is off?

Thanks.

-- 
Dmitry

Re: [PATCH 19/25] sony-laptop: add touchpad enable/disable control file

[Marco Chiappero]

Il 04/06/2011 00:12, Dmitry Torokhov ha scritto:
> The quirk is that for given device there is a sysfs attribute somewhere
> that one can write something into to turn the touchpad off.

Once again, let's have a single unified interface. Are you saying that 
the GNU world is not able to do that?

>> This is false, especially for (so many) people using Windows too, where
>> the feature is clearly visible by the OEM software.
>
> Thankfully OEM software either does not exist or is not widespread on
> Linux.

But the point is not to clone the OEM software (but we need to do it 
when there is nothing else), we do want to clone the functionality only, 
people just want to make that (well, every) hardware feature available 
under linux. Saying that X offers a workaround is, IMHO, a fail. Once 
again: the feature is known, OEM software has nothing to do with it.

> No, I indeed can not speak for everybody, but it is my belief that this
> feature in the form it is implemented will not be widely used.

That's your belief... sorry, but after paying 1300 Eur for a laptop I 
don't care about your belief, I'd like to see my laptop fully supported, 
since we can do it.

> No, it's like saying railroad tracks should be unified instead of every
> country inventing their own size. We all know how helpful it was.

No, at all, that is what I was saying. Again, let's create a common 
interface.

>> It's a common and widespread feature, let's support it better instead of
>> just removing it.
>
> What is the feature again? What do users really want to do here?

Have their touchpad disabled, and have it disabled when using either 
windows or linux. That's what the user payed for.
Discussing what the user should be interested in, whether a real power 
saving is achievable or not, is a totally wrong starting point, it's not 
your own business.

Re: [PATCH 19/25] sony-laptop: add touchpad enable/disable control file

[Mattia Dongili]

On Sat, Jun 04, 2011 at 03:54:22AM +0200, Marco Chiappero wrote:
> Il 04/06/2011 00:12, Dmitry Torokhov ha scritto:
...
> >What is the feature again? What do users really want to do here?
> 
> Have their touchpad disabled, and have it disabled when using either
> windows or linux. That's what the user payed for.
> Discussing what the user should be interested in, whether a real
> power saving is achievable or not, is a totally wrong starting
> point, it's not your own business.

the point is that disabling the touchpad is already possible via a
common interface already, if there is any additional win in implementing
the switch in sony-laptop then it's worth using this sony-specific
quirks otherwise it's totally pointless.

Something that may be worth considering though is if switching the
touchpad off in Windows survives a hot/cold reboot. We may want to
re-enable it under Linux if that is the case.

For the rest I totally agree with Dmitry and I'd rather not see this
patch applied unless there is an actual advantage in having the feature.
-- 
mattia
:wq!

Re: [PATCH 10/25] sony-laptop: keyboard backlight support extended to newer Vaios

[Mattia Dongili]

On Fri, Jun 03, 2011 at 05:41:01PM +0200, Marco Chiappero wrote:
> Added support for handle 0x0143 (Vaio SA/SB/SC, CA/CB). Minor
> corrections included.
> 
> Signed-off-by: Marco Chiappero <marco@absence.it>
> ---
> 
> --- a/drivers/platform/x86/sony-laptop.c
> +++ b/drivers/platform/x86/sony-laptop.c
> @@ -127,7 +127,7 @@ MODULE_PARM_DESC(minor,
>  		 "default is -1 (automatic)");
>  #endif
> 
> -static int kbd_backlight;	/* = 1 */
> +static int kbd_backlight;	/* = 0 */
>  module_param(kbd_backlight, int, 0444);
>  MODULE_PARM_DESC(kbd_backlight,
>  		 "set this to 0 to disable keyboard backlight, "
> @@ -140,15 +140,6 @@ MODULE_PARM_DESC(kbd_backlight_timeout,
>  		 "1 for 30 seconds, 2 for 60 seconds and 3 to disable timeout "
>  		 "(default: 0)");
> 
> -static void sony_nc_kbd_backlight_resume(void);
> -
> -enum sony_nc_rfkill {
> -	SONY_WIFI,
> -	SONY_BLUETOOTH,
> -	SONY_WWAN,
> -	SONY_WIMAX,
> -	N_SONY_RFKILL,
> -};

removing this enum seems superfluous (it's re-added some patches later)
and breaks compilation at this point.

>  static int sony_rfkill_handle;
>  static struct rfkill *sony_rfkill_devices[N_SONY_RFKILL];
> @@ -1356,38 +1347,33 @@ static int sony_nc_rfkill_setup(struct a
>  }
> 
>  /* Keyboard backlight feature */
> -#define KBDBL_HANDLER	0x137
> -#define KBDBL_PRESENT	0xB00
> -#define	SET_MODE	0xC00
> -#define SET_STATE	0xD00
> -#define SET_TIMEOUT	0xE00
> -
>  struct kbd_backlight {
> -	int mode;
> -	int timeout;
> +	unsigned int base;
> +	unsigned int mode;
> +	unsigned int timeout;
>  	struct device_attribute mode_attr;
>  	struct device_attribute timeout_attr;
>  };
> -
>  static struct kbd_backlight *kbdbl_handle;
> +static int sony_kbd_handle = -1;

there seems to be no real point initializing this to -1. Also, can it be
made part of the struct above?

> -static ssize_t __sony_nc_kbd_backlight_mode_set(u8 value)
> +static int __sony_nc_kbd_backlight_mode_set(u8 value)
>  {
>  	unsigned int result;
> 
>  	if (value > 1)
>  		return -EINVAL;
> 
> -	if (sony_call_snc_handle(KBDBL_HANDLER,
> -				(value << 0x10) | SET_MODE, &result))
> +	if (sony_call_snc_handle(sony_kbd_handle, (value << 0x10) |
> +				(kbdbl_handle->base), &result))
>  		return -EIO;
> 
> -	/* Try to turn the light on/off immediately */
> -	sony_call_snc_handle(KBDBL_HANDLER, (value << 0x10) | SET_STATE,
> -			&result);
> -
>  	kbdbl_handle->mode = value;
> 
> +	/* Try to turn the light on/off immediately */
> +	sony_call_snc_handle(sony_kbd_handle, (value << 0x10) |
> +				(kbdbl_handle->base + 0x100), &result);
> +
>  	return 0;
>  }
> 
> @@ -1415,7 +1401,9 @@ static ssize_t sony_nc_kbd_backlight_mod
>  		struct device_attribute *attr, char *buffer)
>  {
>  	ssize_t count = 0;
> +
>  	count = snprintf(buffer, PAGE_SIZE, "%d\n", kbdbl_handle->mode);
> +
>  	return count;
>  }
> 
> @@ -1426,8 +1414,8 @@ static int __sony_nc_kbd_backlight_timeo
>  	if (value > 3)
>  		return -EINVAL;
> 
> -	if (sony_call_snc_handle(KBDBL_HANDLER,
> -				(value << 0x10) | SET_TIMEOUT, &result))
> +	if (sony_call_snc_handle(sony_kbd_handle, (value << 0x10) |
> +				(kbdbl_handle->base + 0x200), &result))
>  		return -EIO;
> 
>  	kbdbl_handle->timeout = value;
> @@ -1459,18 +1447,36 @@ static ssize_t sony_nc_kbd_backlight_tim
>  		struct device_attribute *attr, char *buffer)
>  {
>  	ssize_t count = 0;
> +
>  	count = snprintf(buffer, PAGE_SIZE, "%d\n", kbdbl_handle->timeout);
> +
>  	return count;
>  }
> 
>  static int sony_nc_kbd_backlight_setup(struct platform_device *pd)
>  {
> -	unsigned int result;
> +	unsigned int result, base_cmd;
> +	bool found = false;
> 
> -	if (sony_call_snc_handle(KBDBL_HANDLER, KBDBL_PRESENT, &result))
> -		return 0;
> -	if (!(result & 0x02))
> +	/* verify the kbd backlight presence, some models do not have it */
> +	if (sony_kbd_handle == 0x0137) {
> +		if (sony_call_snc_handle(sony_kbd_handle, 0x0B00, &result))
> +			return -EIO;
> +
> +		found = !!(result & 0x02);
> +		base_cmd = 0x0C00;
> +	} else {
> +		if (sony_call_snc_handle(sony_kbd_handle, 0x0100, &result))
> +			return -EIO;
> +
> +		found = result & 0x01;
> +		base_cmd = 0x4000;
> +	}
> +
> +	if (!found) {
> +		dprintk("no backlight keyboard found\n");
>  		return 0;
> +	}
> 
>  	kbdbl_handle = kzalloc(sizeof(*kbdbl_handle), GFP_KERNEL);
>  	if (!kbdbl_handle)
> @@ -1494,6 +1500,8 @@ static int sony_nc_kbd_backlight_setup(s
>  	if (device_create_file(&pd->dev, &kbdbl_handle->timeout_attr))
>  		goto outmode;
> 
> +	kbdbl_handle->base = base_cmd;
> +
>  	__sony_nc_kbd_backlight_mode_set(kbd_backlight);
>  	__sony_nc_kbd_backlight_timeout_set(kbd_backlight_timeout);
> 
> @@ -1516,28 +1524,32 @@ static int sony_nc_kbd_backlight_cleanup
>  		device_remove_file(&pd->dev, &kbdbl_handle->timeout_attr);
> 
>  		/* restore the default hw behaviour */
> -		sony_call_snc_handle(KBDBL_HANDLER, 0x1000 | SET_MODE, &result);
> -		sony_call_snc_handle(KBDBL_HANDLER, SET_TIMEOUT, &result);
> +		sony_call_snc_handle(sony_kbd_handle,
> +				kbdbl_handle->base | 0x10000, &result);
> +		sony_call_snc_handle(sony_kbd_handle,
> +				kbdbl_handle->base + 0x200, &result);
> 
>  		kfree(kbdbl_handle);
> +		kbdbl_handle = NULL;
>  	}
>  	return 0;
>  }
> 
>  static void sony_nc_kbd_backlight_resume(void)
>  {
> -	unsigned int ignore = 0;
> +	unsigned int result;
> 
>  	if (!kbdbl_handle)
>  		return;
> 
>  	if (kbdbl_handle->mode == 0)
> -		sony_call_snc_handle(KBDBL_HANDLER, SET_MODE, &ignore);
> +		sony_call_snc_handle(sony_kbd_handle,
> +				kbdbl_handle->base, &result);
> 
>  	if (kbdbl_handle->timeout != 0)
> -		sony_call_snc_handle(KBDBL_HANDLER,
> -				(kbdbl_handle->timeout << 0x10) | SET_TIMEOUT,
> -				&ignore);
> +		sony_call_snc_handle(sony_kbd_handle,
> +				(kbdbl_handle->base + 0x200) |
> +				(kbdbl_handle->timeout << 0x10), &result);
>  }
> 
>  static void sony_nc_backlight_ng_read_limits(int handle,
> @@ -1676,6 +1688,8 @@ static void sony_nc_snc_setup_handles(st
>  			ret = sony_nc_function_setup(handle);
>  			break;
>  		case 0x0137:
> +		case 0x0143:
> +			sony_kbd_handle = handle;
>  			ret = sony_nc_kbd_backlight_setup(pd);
>  			break;
>  		case 0x0124:
> @@ -1710,6 +1724,7 @@ static void sony_nc_snc_cleanup_handles(
> 
>  		switch (handle) {
>  		case 0x0137:
> +		case 0x0143:
>  			sony_nc_kbd_backlight_cleanup(pd);
>  			break;
>  		case 0x0124:
> @@ -1814,6 +1829,7 @@ static int sony_nc_snc_resume(void)
>  			sony_nc_rfkill_update();
>  			break;
>  		case 0x0137: /* kbd + als */
> +		case 0x0143:
>  			sony_nc_kbd_backlight_resume();
>  			break;
>  		default:
-- 
mattia
:wq!

Re: [PATCH 11/25] sony-laptop: rfkill improvements

[Mattia Dongili]

On Fri, Jun 03, 2011 at 05:42:22PM +0200, Marco Chiappero wrote:
> - added sony_nc_get_rfkill_hwblock helper function
> - rfkill type now persistent, using the hardware stored device power state
> - added support for newer WWAN modules
> - handle detection removed because no longer necessary
> - now notifying rfkill events to the acpi bus
> 
> Signed-off-by: Marco Chiappero <marco@absence.it>
> ---
> 
> --- a/drivers/platform/x86/sony-laptop.c
> +++ b/drivers/platform/x86/sony-laptop.c
> @@ -141,10 +141,7 @@ MODULE_PARM_DESC(kbd_backlight_timeout,
>  		 "(default: 0)");
> 
> 
> -static int sony_rfkill_handle;
> -static struct rfkill *sony_rfkill_devices[N_SONY_RFKILL];
> -static int sony_rfkill_address[N_SONY_RFKILL] = {0x300, 0x500,
> 0x700, 0x900};

your mail client is wrapping lines in your patches (it happened to other
patches too), can you please fix it before resending?
Documentation/email-clients.txt has suggestions on how to do it.

> -static void sony_nc_rfkill_update(void);
> +static int sony_rfkill_handle = -1;
> 
>  /*********** Input Devices ***********/
> 
> @@ -1190,6 +1187,26 @@ static int sony_nc_hotkeys_decode(unsign
>  	return ret;
>  }
> 
> +enum sony_nc_rfkill {
> +	SONY_WIFI,
> +	SONY_BLUETOOTH,
> +	SONY_WWAN,
> +	SONY_WIMAX,
> +	N_SONY_RFKILL,
> +};
> +static struct rfkill *sony_rfkill_devices[N_SONY_RFKILL];
> +static int sony_rfkill_address[N_SONY_RFKILL] = {0x300, 0x500,
> 0x700, 0x900};
> +
> +static int sony_nc_get_rfkill_hwblock(void)
> +{
> +	unsigned int result;
> +
> +	if (sony_call_snc_handle(sony_rfkill_handle, 0x200, &result))
> +		return -1;
> +
> +	return result & 0x1;
> +}
> +
>  static void sony_nc_rfkill_cleanup(void)
>  {
>  	int i;
> @@ -1204,9 +1221,14 @@ static void sony_nc_rfkill_cleanup(void)
> 
>  static int sony_nc_rfkill_set(void *data, bool blocked)
>  {
> -	unsigned int result;
> -	unsigned int argument = sony_rfkill_address[(long) data] + 0x100;
> +	unsigned int result, argument = sony_rfkill_address[(long) data];
> 
> +	/* do not force an already set state */
> +	sony_call_snc_handle(sony_rfkill_handle, argument, &result);
> +	if ((result & 0x1) == !blocked)
> +		return 0;
> +
> +	argument += 0x100;
>  	if (!blocked)
>  		argument |= 0xff0000;
> 
> @@ -1225,7 +1247,7 @@ static int sony_nc_setup_rfkill(struct a
>  	enum rfkill_type type;
>  	const char *name;
>  	unsigned int result;
> -	bool hwblock;
> +	bool hwblock, swblock;
> 
>  	switch (nc_type) {
>  	case SONY_WIFI:
> @@ -1255,6 +1277,13 @@ static int sony_nc_setup_rfkill(struct a
> 
>  	sony_call_snc_handle(sony_rfkill_handle, 0x200, &result);
>  	hwblock = !(result & 0x1);
> +
> +	result = 0;
> +	sony_call_snc_handle(sony_rfkill_handle, sony_rfkill_address[nc_type],
> +				&result);
> +	swblock = !(result & 0x2);
> +
> +	rfkill_init_sw_state(rfk, swblock);
>  	rfkill_set_hw_state(rfk, hwblock);
> 
>  	err = rfkill_register(rfk);
> @@ -1281,16 +1310,9 @@ static void sony_nc_rfkill_update(void)
>  		if (!sony_rfkill_devices[i])
>  			continue;
> 
> -		if (hwblock) {
> -			if (rfkill_set_hw_state(sony_rfkill_devices[i], true)) {
> -				/* we already know we're blocked */
> -			}
> -			continue;
> -		}
> -
>  		sony_call_snc_handle(sony_rfkill_handle, argument, &result);
>  		rfkill_set_states(sony_rfkill_devices[i],
> -				  !(result & 0xf), false);
> +				  !(result & 0x2), hwblock);
>  	}
>  }
> 
> @@ -1298,17 +1320,7 @@ static int sony_nc_rfkill_setup(struct a
>  {
>  #define	RFKILL_BUFF_SIZE 8
>  	u8 dev_code, i, buff[RFKILL_BUFF_SIZE] = { 0 };
> -	int offset;
> 
> -	offset = sony_find_snc_handle(0x124);
> -	if (offset == -1) {
> -		offset = sony_find_snc_handle(0x135);
> -		if (offset == -1)
> -			return 0;
> -		else
> -			sony_rfkill_handle = 0x135;
> -	} else
> -		sony_rfkill_handle = 0x124;
>  	dprintk("Found rkfill handle: 0x%.4x\n", sony_rfkill_handle);
> 
>  	/* need to read the whole buffer returned by the acpi call to SN06
> @@ -1327,6 +1339,25 @@ static int sony_nc_rfkill_setup(struct a
>  		if (dev_code == 0xff)
>  			break;
> 
> +		/*
> +		   known codes:
> +
> +		   0x00	WLAN
> +		   0x10 BLUETOOTH
> +		   0x20 WWAN GPRS-EDGE
> +		   0x21 WWAN HSDPA
> +		   0x22 WWAN EV-DO
> +		   0x23 WWAN GPS
> +		   0x25	Gobi WWAN no GPS
> +		   0x26 Gobi WWAN + GPS
> +		   0x28	Gobi WWAN no GPS
> +		   0x29 Gobi WWAN + GPS
> +		   0x50	Gobi WWAN no GPS
> +		   0x51 Gobi WWAN + GPS
> +		   0x30	WIMAX
> +		   0x70 no SIM card slot
> +		   0x71 SIM card slot
> +		*/
>  		dprintk("Radio devices, looking at 0x%.2x\n", dev_code);
> 
>  		if (dev_code == 0 && !sony_rfkill_devices[SONY_WIFI])
> @@ -1335,7 +1366,7 @@ static int sony_nc_rfkill_setup(struct a
>  		if (dev_code == 0x10 && !sony_rfkill_devices[SONY_BLUETOOTH])
>  			sony_nc_setup_rfkill(device, SONY_BLUETOOTH);
> 
> -		if ((0xf0 & dev_code) == 0x20 &&
> +		if (((0xf0 & dev_code) == 0x20 || (0xf0 & dev_code) == 0x50) &&
>  				!sony_rfkill_devices[SONY_WWAN])
>  			sony_nc_setup_rfkill(device, SONY_WWAN);
> 
> @@ -1694,6 +1725,7 @@ static void sony_nc_snc_setup_handles(st
>  			break;
>  		case 0x0124:
>  		case 0x0135:
> +			sony_rfkill_handle = handle;
>  			ret = sony_nc_rfkill_setup(sony_nc_acpi_device);
>  			break;
>  		default:
> @@ -1887,6 +1919,30 @@ static void sony_nc_notify(struct acpi_d
>  			ev = 1;
>  			break;
> 
> +		case 0x0124:
> +		case 0x0135:
> +			sony_call_snc_handle(sony_rfkill_handle, 0x0100,
> +						&result);
> +			result &= 0x03;
> +			dprintk("sony_nc_notify, RFKILL event received "
> +					"(reason: %s)\n", result == 1 ?
> +					"switch state changed" : "battery");
> +
> +			if (result == 1) { /* hw swtich event */
> +				sony_nc_rfkill_update();
> +				sony_laptop_report_input_event(
> +						SONYPI_EVENT_RFKILL_ALL);

the SONYPI_EVENT_RFKILL_ALL constant is defined in the next patch, this
call should be part of the same patch to avoid breaking building of the
module in the middle of the series.
See the comment to the other email about reporting rfkill events through
the input layer though.

> +				value = sony_nc_get_rfkill_hwblock();
> +			} else if (result == 2) { /* battery event */
> +				/*  we should change the WWAN rfkill
> +				    state when the battery state changes
> +				 */
> +				return;
> +			}
> +
> +			ev = 2;
> +			break;
> +
>  		default:
>  			value = event;
>  			dprintk("Unknowk event for handle: 0x%x\n", handle);
> --
> To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
mattia
:wq!

Re: [PATCH 12/25] sony-laptop: input core improvements improvements

[Mattia Dongili]

On Fri, Jun 03, 2011 at 05:43:42PM +0200, Marco Chiappero wrote:
> The code is now forwarding the SW_RFKILL_ALL event; added a couple

I don't think we should do this.
4eeb50220a4efd8c33598a228d03aff203a7ad07 removed the notification for
the SPIC part of the module and I'd rather not add it now for SNC. The
notification has proven to cause race conditions (see the bug referenced
in the commit message).
Moreover it should be left to the rfkill subsystem to notify userspace
for consistency with all the other drivers implementing rfkill switches.

> of Fn combos too.

the additional key codes are fine though.

> Signed-off-by: Marco Chiappero <marco@absence.it>
> ---
> 
> --- a/include/linux/sonypi.h
> +++ b/include/linux/sonypi.h
> @@ -114,6 +114,7 @@
>  #define SONYPI_EVENT_BRIGHTNESS_PRESSED		71
>  #define SONYPI_EVENT_MEDIA_PRESSED		72
>  #define SONYPI_EVENT_VENDOR_PRESSED		73
> +#define SONYPI_EVENT_RFKILL_ALL			74
> 
>  /* get/set brightness */
>  #define SONYPI_IOCGBRT		_IOR('v', 0, __u8)
> --- a/drivers/platform/x86/sony-laptop.c
> +++ b/drivers/platform/x86/sony-laptop.c
> @@ -142,6 +142,7 @@ MODULE_PARM_DESC(kbd_backlight_timeout,
> 
> 
>  static int sony_rfkill_handle = -1;
> +static int sony_nc_get_rfkill_hwblock(void);
> 
>  /*********** Input Devices ***********/
> 
> @@ -241,7 +242,8 @@ static int sony_laptop_input_index[] = {
>  	57,	/* 70 SONYPI_EVENT_VOLUME_DEC_PRESSED */
>  	-1,	/* 71 SONYPI_EVENT_BRIGHTNESS_PRESSED */
>  	58,	/* 72 SONYPI_EVENT_MEDIA_PRESSED */
> -	59,	/* 72 SONYPI_EVENT_VENDOR_PRESSED */
> +	59,	/* 73 SONYPI_EVENT_VENDOR_PRESSED */
> +	-1,	/* 74 SONYPI_EVENT_RFKILL_ALL */
>  };
> 
>  static int sony_laptop_input_keycode_map[] = {
> @@ -335,6 +337,7 @@ static void sony_laptop_report_input_eve
>  	struct input_dev *jog_dev = sony_laptop_input.jog_dev;
>  	struct input_dev *key_dev = sony_laptop_input.key_dev;
>  	struct sony_laptop_keypress kp = { NULL };
> +	int rfk_switch;
> 
>  	if (event == SONYPI_EVENT_FNKEY_RELEASED ||
>  			event == SONYPI_EVENT_ANYBUTTON_RELEASED) {
> @@ -363,6 +366,14 @@ static void sony_laptop_report_input_eve
>  		kp.dev = jog_dev;
>  		break;
> 
> +	case SONYPI_EVENT_RFKILL_ALL:
> +		rfk_switch = sony_nc_get_rfkill_hwblock();
> +		if (!(rfk_switch < 0)) {
> +			input_report_switch(key_dev, SW_RFKILL_ALL, rfk_switch);
> +			input_sync(key_dev);
> +		}
> +		return;
> +
>  	default:
>  		if (event >= ARRAY_SIZE(sony_laptop_input_index)) {
>  			dprintk("sony_laptop_report_input_event, event not known: %d\n",
> event);
> @@ -438,6 +449,14 @@ static int sony_laptop_setup_input(struc
>  		__set_bit(sony_laptop_input_keycode_map[i], key_dev->keybit);
>  	__clear_bit(KEY_RESERVED, key_dev->keybit);
> 
> +	if (sony_rfkill_handle != -1) {
> +		int rfk_switch;
> +
> +		rfk_switch = sony_nc_get_rfkill_hwblock();
> +		input_set_capability(key_dev, EV_SW, SW_RFKILL_ALL);
> +		input_report_switch(key_dev, SW_RFKILL_ALL, rfk_switch);
> +	}
> +
>  	error = input_register_device(key_dev);
>  	if (error)
>  		goto err_free_keydev;
> @@ -1079,10 +1098,6 @@ struct sony_nc_event {
>  };
> 
>  static struct sony_nc_event sony_100_events[] = {
> -	{ 0x90, SONYPI_EVENT_PKEY_P1 },
> -	{ 0x10, SONYPI_EVENT_ANYBUTTON_RELEASED },
> -	{ 0x91, SONYPI_EVENT_PKEY_P2 },
> -	{ 0x11, SONYPI_EVENT_ANYBUTTON_RELEASED },
>  	{ 0x81, SONYPI_EVENT_FNKEY_F1 },
>  	{ 0x01, SONYPI_EVENT_FNKEY_RELEASED },
>  	{ 0x82, SONYPI_EVENT_FNKEY_F2 },
> @@ -1097,12 +1112,20 @@ static struct sony_nc_event sony_100_eve
>  	{ 0x06, SONYPI_EVENT_FNKEY_RELEASED },
>  	{ 0x87, SONYPI_EVENT_FNKEY_F7 },
>  	{ 0x07, SONYPI_EVENT_FNKEY_RELEASED },
> +	{ 0x88, SONYPI_EVENT_FNKEY_F8 },
> +	{ 0x08, SONYPI_EVENT_FNKEY_RELEASED },
>  	{ 0x89, SONYPI_EVENT_FNKEY_F9 },
>  	{ 0x09, SONYPI_EVENT_FNKEY_RELEASED },
>  	{ 0x8A, SONYPI_EVENT_FNKEY_F10 },
>  	{ 0x0A, SONYPI_EVENT_FNKEY_RELEASED },
> +	{ 0x8B, SONYPI_EVENT_FNKEY_F11 },
> +	{ 0x0B, SONYPI_EVENT_FNKEY_RELEASED },
>  	{ 0x8C, SONYPI_EVENT_FNKEY_F12 },
>  	{ 0x0C, SONYPI_EVENT_FNKEY_RELEASED },
> +	{ 0x90, SONYPI_EVENT_PKEY_P1 },
> +	{ 0x10, SONYPI_EVENT_ANYBUTTON_RELEASED },
> +	{ 0x91, SONYPI_EVENT_PKEY_P2 },
> +	{ 0x11, SONYPI_EVENT_ANYBUTTON_RELEASED },
>  	{ 0x9d, SONYPI_EVENT_ZOOM_PRESSED },
>  	{ 0x1d, SONYPI_EVENT_ANYBUTTON_RELEASED },
>  	{ 0x9f, SONYPI_EVENT_CD_EJECT_PRESSED },
-- 
mattia
:wq!

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Mattia Dongili]

On Fri, Jun 03, 2011 at 05:38:08PM +0200, Marco Chiappero wrote:
> sony_nc_notify rewritten (and placed near the other acpi callbacks),
> the hotkey decoding code move to a new function
> sony_nc_hotkeys_decode. Now generating acpi netlink events too.

one thing I'm wondering is if we shouldn't stop sending input
events also via the acpi bus rather than adding new notification
methods. The /proc/acpi/event notification will go away on its own one
day so maybe letting this habit die with it is a reasonable deprecation
plan for /proc/acpi/event users.

Dmitry, Matthew,
any thought about this?

> Signed-off-by: Marco Chiappero <marco@absence.it>
> ---
> 
> --- a/drivers/platform/x86/sony-laptop.c
> +++ b/drivers/platform/x86/sony-laptop.c
> @@ -1151,62 +1151,6 @@ static struct sony_nc_event sony_127_eve
>  /*
>   * ACPI callbacks
>   */
> -static void sony_nc_notify(struct acpi_device *device, u32 event)
> -{
> -	u32 ev = event;
> -
> -	if (ev >= 0x90) {
> -		/* New-style event */
> -		unsigned int result;
> -		int key_handle = 0;
> -		ev -= 0x90;
> -
> -		if (sony_find_snc_handle(0x100) == ev)
> -			key_handle = 0x100;
> -		if (sony_find_snc_handle(0x127) == ev)
> -			key_handle = 0x127;
> -
> -		if (key_handle) {
> -			struct sony_nc_event *key_event;
> -
> -			if (sony_call_snc_handle(key_handle, 0x200, &result)) {
> -				dprintk("sony_nc_notify, unable to decode"
> -					" event 0x%.2x 0x%.2x\n", key_handle,
> -					ev);
> -				/* restore the original event */
> -				ev = event;
> -			} else {
> -				ev = result & 0xFF;
> -
> -				if (key_handle == 0x100)
> -					key_event = sony_100_events;
> -				else
> -					key_event = sony_127_events;
> -
> -				for (; key_event->data; key_event++) {
> -					if (key_event->data == ev) {
> -						ev = key_event->event;
> -						break;
> -					}
> -				}
> -
> -				if (!key_event->data)
> -					pr_info("Unknown event: 0x%x 0x%x\n",
> -						key_handle, ev);
> -				else
> -					sony_laptop_report_input_event(ev);
> -			}
> -		} else if (sony_find_snc_handle(sony_rfkill_handle) == ev) {
> -			sony_nc_rfkill_update();
> -			return;
> -		}
> -	} else
> -		sony_laptop_report_input_event(ev);
> -
> -	dprintk("sony_nc_notify, event: 0x%.2x\n", ev);
> -	acpi_bus_generate_proc_event(sony_nc_acpi_device, 1, ev);
> -}
> -
>  static acpi_status sony_walk_callback(acpi_handle handle, u32 level,
>  				      void *context, void **return_value)
>  {
> @@ -1237,6 +1181,42 @@ static int sony_nc_function_setup(unsign
>  	return 0;
>  }
> 
> +static int sony_nc_hotkeys_decode(unsigned int handle)
> +{
> +	int ret = 0;
> +	unsigned int result = 0;
> +	struct sony_nc_event *key_event;
> +
> +	if (sony_call_snc_handle(handle, 0x200, &result)) {
> +		dprintk("sony_nc_hotkeys_decode,"
> +				" unable to retrieve the hotkey\n");
> +		ret = -1;

when sony_call_snc_handle(handle, 0x200, &result) fails above you will
be reporting -1 via the acpi bus. The old code restored the event and
reported the raw number instead.

> +	} else {
> +		result &= 0xff;
> +
> +		if (handle == 0x100)
> +			key_event = sony_100_events;
> +		else
> +			key_event = sony_127_events;
> +
> +		for (; key_event->data; key_event++) {
> +			if (key_event->data == result) {
> +				ret = key_event->event;
> +				break;
> +			}
> +		}
> +
> +		if (!key_event->data)
> +			pr_info("Unknown hotkey 0x%.2x (handle 0x%.2x)\n",
> +							result, handle);

For not yet mapped keys instead you'll always report 0;
The current behaviour is different, please don't change it without a
good reason.

> +		else
> +			dprintk("sony_nc_hotkeys_decode, hotkey 0x%.2x decoded "
> +					"to event 0x%.2x\n", result, ret);
> +	}
> +
> +	return ret;
> +}
> +
>  static void sony_nc_rfkill_cleanup(void)
>  {
>  	int i;
> @@ -1864,6 +1844,52 @@ static int sony_nc_snc_resume(void)
>  	return 0;
>  }
> 
> +static void sony_nc_notify(struct acpi_device *device, u32 event)
> +{
> +	u8 ev = 0;
> +	int value = 0;
> +
> +	dprintk("sony_nc_notify, event: 0x%.2x\n", event);
> +
> +	/* handles related events */
> +	if (event >= 0x90) {
> +		unsigned int result = 0, handle = 0;
> +
> +		/* the event should corrispond to the offset of the method */
> +		unsigned int offset = event - 0x90;
> +
> +		handle = handles->cap[offset];
> +		switch (handle) {
> +		/* list of handles known for generating events */
> +		case 0x0100:
> +		case 0x0127:
> +			/* hotkey event, a key has been pressed, retrieve it */
> +			value = sony_nc_hotkeys_decode(handle);
> +			if (value > 0) /* known event */
> +				sony_laptop_report_input_event(value);
> +			/* else unknown event or failure, do nothing */
> +			ev = 1;
> +			break;
> +
> +		default:
> +			value = event;
> +			dprintk("Unknowk event for handle: 0x%x\n", handle);
> +			break;
> +		}
> +
> +		/* clear the event (and the event reason when present) */
> +		acpi_callsetfunc(sony_nc_acpi_handle, "SN05", 1 << offset,
> +				&result);
> +	} else {
> +		ev = 1;
> +		sony_laptop_report_input_event(event);
> +	}
> +
> +	acpi_bus_generate_proc_event(device, ev, value);
> +	acpi_bus_generate_netlink_event(device->pnp.device_class,
> +					dev_name(&device->dev), ev, value);

see above about this.

> +}
> +
>  static int sony_nc_add(struct acpi_device *device)
>  {
>  	acpi_status status;
-- 
mattia
:wq!

Re: [PATCH 22/25] sony-laptop: forward Hybrid GFX notifications to userspace

[Mattia Dongili]

On Fri, Jun 03, 2011 at 09:27:00PM +0200, Marco Chiappero wrote:
> Some Vaios come with both integrated and discrete graphics, plus a
> switch for choosing one of the two. When the switch position is
> changed, a notification is generated, now forwarded to userspace for
> example for visual notifications, user scripts, and so on.
> 
> Signed-off-by: Marco Chiappero <marco@absence.it>
> ---
> 
> --- a/drivers/platform/x86/sony-laptop.c
> +++ b/drivers/platform/x86/sony-laptop.c
> @@ -3118,6 +3118,14 @@ static void sony_nc_notify(struct acpi_d
> 
>  	dprintk("sony_nc_notify, event: 0x%.2x\n", event);
> 
> +	/* events codes list
> +	 * 1    Hotkeys
> +	 * 2    RFKILL
> +	 * 3    ALS
> +	 * 4    HDD protection
> +	 * 5	Hybrid GFX
> +	 */

how about some #defines instead of a comment?

>  	/* handles related events */
>  	if (event >= 0x90) {
>  		unsigned int result = 0, handle = 0;
> @@ -3169,6 +3177,23 @@ static void sony_nc_notify(struct acpi_d
>  			/* hdd protection event, notify userspace */
>  			break;
> 
> +		case 0x0128:
> +		case 0x0146:
> +			/* Hybrid GFX switching, 1 */
> +			sony_call_snc_handle(handle, 0x0000, &result);
> +			dprintk("sony_nc_notify, Hybrid GFX event received "
> +					"(reason: %s)\n", (result & 0x01) ?
> +					"switch position change" : "unknown");
> +
> +			/* verify the switch state
> +			   (1: discrete GFX, 0: integrated GFX)*/
> +			result = 0;
> +			sony_call_snc_handle(handle, 0x0100, &result);
> +
> +			ev = 5;
> +			value = result & 0xff;
> +			break;

shouldn't this be reported as an input event rather than just an acpi
one?
also, I am trying to recall how the speed/stamina switch was handled in
older SZ and other models. I think we are already notifying the
switching event as an input key (PROG4? PROG5?)
I didn't see a better option in input.h, maybe time to add one?

>  		default:
>  			value = event;
>  			dprintk("Unknowk event for handle: 0x%x\n", handle);
-- 
mattia
:wq!

Re: [PATCH 0/25] sony-laptop: code improvements and support extension for newer Vaios

[Mattia Dongili]

On Fri, Jun 03, 2011 at 05:22:50PM +0200, Marco Chiappero wrote:
> Hello,
> 
> this set of patches aims to reorganize and clean the driver code
> where necessary [patches 1-9, 13], improve some functionalities
> [patches 10-12] and add some others present on recent Vaios (TT, Y1,
> Z1, F1, S1, SA/SB/SC, CA/SB and possibly others), such as ALS driven
> backlight control, HDD shock protection control and Battery charge
> control.
> 
> During the development of these patches a long list of new handles
> has been found and analyzed (the list can be read here:
> http://absence.it/vaio-acpi/handles_list.txt), many of them are now
> well known and mostly implemented by patches from 14 to 24.

Thanks for this. Note though that some of the clean-up code is
conflicting with other patches I have yet to submit, I'll see if it's
easier to adapt your code to mine or viceversa.

I tried to comment on some of the patchese that you submitted, those I
have yet to comment on I'll get back to later.

Regards,
-- 
mattia
:wq!

Re: [PATCH 10/25] sony-laptop: keyboard backlight support extended to newer Vaios

[Marco Chiappero]

Il 04/06/2011 09:58, Mattia Dongili wrote:

>> -static void sony_nc_kbd_backlight_resume(void);
>> -
>> -enum sony_nc_rfkill {
>> -	SONY_WIFI,
>> -	SONY_BLUETOOTH,
>> -	SONY_WWAN,
>> -	SONY_WIMAX,
>> -	N_SONY_RFKILL,
>> -};
>
> removing this enum seems superfluous (it's re-added some patches later)
> and breaks compilation at this point.

Sorry, I made a mistake, I'm going to fix and resend patches #10 and #11.

>>   static struct kbd_backlight *kbdbl_handle;
>> +static int sony_kbd_handle = -1;
>
> there seems to be no real point initializing this to -1.

Just for safety, since handle 0x0000 is a valid handle [1] it would be 
better to initialize it to an invalid value.

> Also, can it be
> made part of the struct above?

Sure


[1]
sony_laptop: found handle 0x0000 (offset: 0x0d)
sony_laptop: called SN07 with 0x000d (result: 0x0000)

Re: [PATCH 12/25] sony-laptop: input core improvements improvements

[Marco Chiappero]

Il 04/06/2011 10:07, Mattia Dongili ha scritto:
> On Fri, Jun 03, 2011 at 05:43:42PM +0200, Marco Chiappero wrote:
>> The code is now forwarding the SW_RFKILL_ALL event; added a couple
>
> I don't think we should do this.

As far as I know this event should be forwarded and the rfkill-input 
code removed as soon as there is enough userspace support. Another 
platform driver (thinkpad_acpi) is using it.
What is right and what is wrong? Should it be removed from thinkpad_acpi 
too?

Re: [PATCH 19/25] sony-laptop: add touchpad enable/disable control file

[Marco Chiappero]

Il 04/06/2011 09:09, Mattia Dongili ha scritto:
> the point is that disabling the touchpad is already possible via a
> common interface already,

Well, disabling/powering off and ignoring are not synonyms. It would be 
better to have userspace disabling the touchpad when this feature is 
present and ignoring it when not.

> if there is any additional win in implementing
> the switch in sony-laptop then it's worth using this sony-specific
> quirks otherwise it's totally pointless.

I cannot see how such small code and file will harm, people that don't 
care can ignore it.

Re: [PATCH 10/25] sony-laptop: keyboard backlight support extended to newer Vaios

[Mattia Dongili]

On Sat, Jun 04, 2011 at 12:30:44PM +0200, Marco Chiappero wrote:
> Il 04/06/2011 09:58, Mattia Dongili wrote:
...
> >>  static struct kbd_backlight *kbdbl_handle;
> >>+static int sony_kbd_handle = -1;
> >
> >there seems to be no real point initializing this to -1.
> 
> Just for safety, since handle 0x0000 is a valid handle [1] it would
> be better to initialize it to an invalid value.

0x0 is not valid, it's just the lack of a value. For sure it's not a
valid value for the keyboard backlight handle.

...
> [1]
> sony_laptop: found handle 0x0000 (offset: 0x0d)
> sony_laptop: called SN07 with 0x000d (result: 0x0000)

this is only going through the handles buffer and telling you that at
0x0d there is nothing.

-- 
mattia
:wq!

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Marco Chiappero]

Il 04/06/2011 10:43, Mattia Dongili ha scritto:
> when sony_call_snc_handle(handle, 0x200,&result) fails above you will
> be reporting -1 via the acpi bus. The old code restored the event and
> reported the raw number instead.

You are right, does the following sony_nc_notify modification look fine 
to you?

/* hotkey event, a key has been pressed, retrieve it */
value = sony_nc_hotkeys_decode(handle);
if (value > 0) /* known event */
	sony_laptop_report_input_event(value);
else /* restore the original event */
	value = event;

Re: [PATCH 10/25] sony-laptop: keyboard backlight support extended to newer Vaios

[Marco Chiappero]

Il 04/06/2011 13:23, Mattia Dongili ha scritto:
>> Just for safety, since handle 0x0000 is a valid handle [1] it would
>> be better to initialize it to an invalid value.
>
> 0x0 is not valid, it's just the lack of a value.

But you can use it. "Just for safety" we'd better set to an invalid 
value that cannot be used by the acpi methods.

>> [1]
>> sony_laptop: found handle 0x0000 (offset: 0x0d)
>> sony_laptop: called SN07 with 0x000d (result: 0x0000)
>
> this is only going through the handles buffer and telling you that at
> 0x0d there is nothing.

the calling code:

ret = sony_call_snc_handle(0, 0, &result);

it returns 0.

sony_find_snc_handle should return -1 when called with handle == -1, right?

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Matthew Garrett]

On Sat, Jun 04, 2011 at 05:43:39PM +0900, Mattia Dongili wrote:
> On Fri, Jun 03, 2011 at 05:38:08PM +0200, Marco Chiappero wrote:
> > sony_nc_notify rewritten (and placed near the other acpi callbacks),
> > the hotkey decoding code move to a new function
> > sony_nc_hotkeys_decode. Now generating acpi netlink events too.
> 
> one thing I'm wondering is if we shouldn't stop sending input
> events also via the acpi bus rather than adding new notification
> methods. The /proc/acpi/event notification will go away on its own one
> day so maybe letting this habit die with it is a reasonable deprecation
> plan for /proc/acpi/event users.

Yeah, it's about time for this to die.

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

Re: [PATCH 12/25] sony-laptop: input core improvements improvements

[Matthew Garrett]

On Sat, Jun 04, 2011 at 12:42:47PM +0200, Marco Chiappero wrote:

> As far as I know this event should be forwarded and the rfkill-input
> code removed as soon as there is enough userspace support. Another
> platform driver (thinkpad_acpi) is using it.
> What is right and what is wrong? Should it be removed from
> thinkpad_acpi too?

This event should be sent if hitting the switch is a request to 
userspace. If pressing it causes the hardware to perform the change and 
this is merely a notification that the change has been made, it 
shouldn't be sent. Just update the rfkill state and let userspace notice 
the uevents from rfkill.

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

Re: [PATCH 12/25] sony-laptop: input core improvements improvements

[Matthew Garrett]

On Sat, Jun 04, 2011 at 12:42:47PM +0200, Marco Chiappero wrote:

> As far as I know this event should be forwarded and the rfkill-input
> code removed as soon as there is enough userspace support. Another
> platform driver (thinkpad_acpi) is using it.
> What is right and what is wrong? Should it be removed from
> thinkpad_acpi too?

This event should be sent if hitting the switch is a request to 
userspace. If pressing it causes the hardware to perform the change and 
this is merely a notification that the change has been made, it 
shouldn't be sent. Just update the rfkill state and let userspace notice 
the uevents from rfkill.

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

Re: [PATCH 19/25] sony-laptop: add touchpad enable/disable control file

[Matthew Garrett]

On Sat, Jun 04, 2011 at 01:15:32PM +0200, Marco Chiappero wrote:

> I cannot see how such small code and file will harm, people that
> don't care can ignore it.

This feature is present in enough machines that we really need some 
standardised way to present it, rather than it just being yet another 
random sysfs file. The problem is working out a good way to standardise 
it.

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

Re: [PATCH 12/25] sony-laptop: input core improvements improvements

[Marco Chiappero]

Il 04/06/2011 14:44, Matthew Garrett ha scritto:
> This event should be sent if hitting the switch is a request to
> userspace. If pressing it causes the hardware to perform the change and
> this is merely a notification that the change has been made, it
> shouldn't be sent.

Ok, I didn't know about this difference, I'll remove it and update the 
patch.

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Marco Chiappero]

Il 04/06/2011 14:42, Matthew Garrett wrote:
>> one thing I'm wondering is if we shouldn't stop sending input
>> events also via the acpi bus rather than adding new notification
>> methods. The /proc/acpi/event notification will go away on its own one
>> day so maybe letting this habit die with it is a reasonable deprecation
>> plan for /proc/acpi/event users.
>
> Yeah, it's about time for this to die.

Sorry, I don't understand what should be changed and the desired behavior:
1) no acpi notification at all, neither proc nor netlink (but we need 
some new entries in input.h first).
2) no acpi notification for hotkeys events only.
3) no acpi notification to the deprecated /proc/acpi/event only

Re: [PATCH 19/25] sony-laptop: add touchpad enable/disable control file

[Marco Chiappero]

Il 04/06/2011 14:46, Matthew Garrett ha scritto:
> This feature is present in enough machines that we really need some
> standardised way to present it, rather than it just being yet another
>  random sysfs file.

I agree.

> The problem is working out a good way to standardise
> it.

I know this too, and unfortunately I cannot help here. But, from the 
user standpoint, not having a feature that can be implemented (somehow) 
and may be useful is really bad.

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Matthew Garrett]

On Sat, Jun 04, 2011 at 04:22:53PM +0200, Marco Chiappero wrote:
> Il 04/06/2011 14:42, Matthew Garrett wrote:
> >>one thing I'm wondering is if we shouldn't stop sending input
> >>events also via the acpi bus rather than adding new notification
> >>methods. The /proc/acpi/event notification will go away on its own one
> >>day so maybe letting this habit die with it is a reasonable deprecation
> >>plan for /proc/acpi/event users.
> >
> >Yeah, it's about time for this to die.
> 
> Sorry, I don't understand what should be changed and the desired behavior:
> 1) no acpi notification at all, neither proc nor netlink (but we
> need some new entries in input.h first).
> 2) no acpi notification for hotkeys events only.
> 3) no acpi notification to the deprecated /proc/acpi/event only

No acpi notification at all. There's no good way for userspace to make 
use of them without knowing the hardware they're running on, which is 
far from ideal.

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

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Marco Chiappero]

Il 04/06/2011 16:30, Matthew Garrett ha scritto:
> No acpi notification at all. There's no good way for userspace to make
> use of them without knowing the hardware they're running on, which is
> far from ideal.

Ok, fine. So, should we forward any event (als events, shock protection, 
hybrid GFX, etc.) to the input core then?

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Matthew Garrett]

On Sat, Jun 04, 2011 at 04:34:43PM +0200, Marco Chiappero wrote:

> Ok, fine. So, should we forward any event (als events, shock
> protection, hybrid GFX, etc.) to the input core then?

als events and shock protection probably ought to be uevents on the 
appropriate device. Hybrid graphics requests probably ought to be input 
events, but we'll probably want to talk to the graphics people about 
that.

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

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Marco Chiappero]

Il 04/06/2011 16:36, Matthew Garrett ha scritto:
> On Sat, Jun 04, 2011 at 04:34:43PM +0200, Marco Chiappero wrote:
>
>> Ok, fine. So, should we forward any event (als events, shock
>> protection, hybrid GFX, etc.) to the input core then?
>
> als events and shock protection probably ought to be uevents on the
> appropriate device.

More precisely? As far as I know there is no ALS device class; and I 
know nothing about the other.

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Matthew Garrett]

On Sat, Jun 04, 2011 at 04:42:24PM +0200, Marco Chiappero wrote:

> More precisely? As far as I know there is no ALS device class; and I
> know nothing about the other.

Where there's no generic implementation of a hardware class that's 
present in multiple pieces of hardware, the first step is to define a 
generic implementation :)

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

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Corentin Chary]

On Sat, Jun 4, 2011 at 4:45 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Sat, Jun 04, 2011 at 04:42:24PM +0200, Marco Chiappero wrote:
>
>> More precisely? As far as I know there is no ALS device class; and I
>> know nothing about the other.
>
> Where there's no generic implementation of a hardware class that's
> present in multiple pieces of hardware, the first step is to define a
> generic implementation :)

The last ALS device class attempt didn't went so well, what's the
current status for this one ?



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

Re: [PATCH 12/25] sony-laptop: input core improvements improvements

[Marco Chiappero]

Il 04/06/2011 10:07, Mattia Dongili ha scritto:
>> of Fn combos too.
>
> the additional key codes are fine though.

There is one thing (IIRC you already heard of) I'd like to discuss here.
It seems that on recent models the hotkeys layout hasn't changed for 
some time now, and it's likely to stay the same for a long time. However 
it is different from the one mapped in the driver, and some changes are 
required. For example:

- Fn-F1 (Touchpad togle enable) to KEY_TOUCHPAD_TOGGLE instead of KEY_FN_F1
- Fn-F5 (bright. down) to KEY_BRIGHTNESSDOWN instead of KEY_FN_F5
- Fn-F9 (zoom out) to KEY_ZOOMOUT instead of KEY_FN_F9
and so on.

To preserve support for older models we can use udev keymaps or a 
fallback map for any notebook not starting with the "VPC" model prefix 
(since a couple of years this is the starting model string). Is this 
solution acceptable? Having a correct mapping at the source instead of 
remapping for every model is better, is it possible?

Re: [PATCH 12/25] sony-laptop: input core improvements improvements

[Mattia Dongili]

On Sat, Jun 04, 2011 at 05:21:11PM +0200, Marco Chiappero wrote:
> Il 04/06/2011 10:07, Mattia Dongili ha scritto:
> >>of Fn combos too.
> >
> >the additional key codes are fine though.
> 
> There is one thing (IIRC you already heard of) I'd like to discuss here.
> It seems that on recent models the hotkeys layout hasn't changed for
> some time now, and it's likely to stay the same for a long time.
> However it is different from the one mapped in the driver, and some
> changes are required. For example:
> 
> - Fn-F1 (Touchpad togle enable) to KEY_TOUCHPAD_TOGGLE instead of KEY_FN_F1
> - Fn-F5 (bright. down) to KEY_BRIGHTNESSDOWN instead of KEY_FN_F5
> - Fn-F9 (zoom out) to KEY_ZOOMOUT instead of KEY_FN_F9
> and so on.
> 
> To preserve support for older models we can use udev keymaps or a
> fallback map for any notebook not starting with the "VPC" model
> prefix (since a couple of years this is the starting model string).
> Is this solution acceptable? Having a correct mapping at the source
> instead of remapping for every model is better, is it possible?

sure it's possible but it's going to be a source of headache once sony
changes their keyboard layout again (and it will happen).
Using generic key codes and remapping them in userspace where necessary
worked for more than 10 years and is still working fine.

-- 
mattia
:wq!

Re: [PATCH 12/25] sony-laptop: input core improvements improvements

[Mattia Dongili]

On Sat, Jun 04, 2011 at 05:21:11PM +0200, Marco Chiappero wrote:
> Il 04/06/2011 10:07, Mattia Dongili ha scritto:
> >>of Fn combos too.
> >
> >the additional key codes are fine though.
> 
> There is one thing (IIRC you already heard of) I'd like to discuss here.
> It seems that on recent models the hotkeys layout hasn't changed for
> some time now, and it's likely to stay the same for a long time.
> However it is different from the one mapped in the driver, and some
> changes are required. For example:
> 
> - Fn-F1 (Touchpad togle enable) to KEY_TOUCHPAD_TOGGLE instead of KEY_FN_F1
> - Fn-F5 (bright. down) to KEY_BRIGHTNESSDOWN instead of KEY_FN_F5
> - Fn-F9 (zoom out) to KEY_ZOOMOUT instead of KEY_FN_F9
> and so on.
> 
> To preserve support for older models we can use udev keymaps or a
> fallback map for any notebook not starting with the "VPC" model
> prefix (since a couple of years this is the starting model string).
> Is this solution acceptable? Having a correct mapping at the source
> instead of remapping for every model is better, is it possible?

sure it's possible but it's going to be a source of headache once sony
changes their keyboard layout again (and it will happen).
Using generic key codes and remapping them in userspace where necessary
worked for more than 10 years and is still working fine.

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

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Marco Chiappero]

Il 04/06/2011 17:04, Corentin Chary ha scritto:
> The last ALS device class attempt didn't went so well,

In fact I had to expose some sysfs nodes in sony-laptop. I don't know 
how other vendors implemented the ALS stuff (I suppose mostly with an hw 
solution), but the software based solution from Sony is quite complex 
and I don't know if it can fit in a generic interface, but we can try. 
However in the meantime I cloned the (nicely working) Windows software 
behavior, with the help of Javier Achirica: by means of the acpi bus and 
a Vaio specific daemon (using some model specific parameters provided by 
the DSDT code and the same lux-to-backlight formula used by the windows 
software from Sony) we managed to have everything working and every 
model supported. Ok, it not the best design (a better one may be 
introduced later), but it works great and now (please consider that 
older ALS equipped models are now 2 years old, so it would be good to 
support them as soon as possible); many people are already happily using 
this solution.
I think there will be a lot to discuss about patch #23.

Re: [PATCH 12/25] sony-laptop: input core improvements improvements

[Marco Chiappero]

Il 04/06/2011 18:40, Mattia Dongili ha scritto:
> sure it's possible but it's going to be a source of headache once sony
> changes their keyboard layout again (and it will happen).

Well, it depends on when, if it will happen in 2020 that's absolutely 
fine. ;)

> Using generic key codes and remapping them in userspace where necessary
> worked for more than 10 years and is still working fine.

Sure and I consider to be a good alternative, but it looks to me like 
being another workaround, it is fine for particular exceptions that need 
a few remappings, but it should not be the rule, the driver extension. 
That's why I was asking about this change.

Re: [PATCH 12/25] sony-laptop: input core improvements improvements

[Marco Chiappero]

Il 04/06/2011 18:40, Mattia Dongili ha scritto:
> sure it's possible but it's going to be a source of headache once sony
> changes their keyboard layout again (and it will happen).

Well, it depends on when, if it will happen in 2020 that's absolutely 
fine. ;)

> Using generic key codes and remapping them in userspace where necessary
> worked for more than 10 years and is still working fine.

Sure and I consider to be a good alternative, but it looks to me like 
being another workaround, it is fine for particular exceptions that need 
a few remappings, but it should not be the rule, the driver extension. 
That's why I was asking about this change.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Alan Cox]

On Sat, 04 Jun 2011 16:42:24 +0200
Marco Chiappero <marco@absence.it> wrote:

> Il 04/06/2011 16:36, Matthew Garrett ha scritto:
> > On Sat, Jun 04, 2011 at 04:34:43PM +0200, Marco Chiappero wrote:
> >
> >> Ok, fine. So, should we forward any event (als events, shock
> >> protection, hybrid GFX, etc.) to the input core then?
> >
> > als events and shock protection probably ought to be uevents on the
> > appropriate device.
> 
> More precisely? As far as I know there is no ALS device class; and I 
> know nothing about the other.

Start reading around here

http://lkml.org/lkml/2010/3/3/334

(and the earlier threads on the ALS class which Linus rejected)

I'd like to see an ALS class but it seems the head penguin won't accept
one, so we now have a zillion incompatible light sensors mostly out of
tree because nobody can be bothered to have the argument again.

The longer term plan is to stick all kinds of device sensors (as distinct
from input devices) into the IIO layer but that is still in staging and
seems to have no clear plan of date for migration yet. However Jonathan
(the maintainer) also doesn't seem too keen on owning them either

http://lkml.org/lkml/2010/3/3/378

All in all ALS is a bit of a disaster area.

Alan

Re: [PATCH 23/25] sony-laptop: add ALS support

[Mattia Dongili]

On Fri, Jun 03, 2011 at 09:49:20PM +0200, Marco Chiappero wrote:
> Vaio S1, F1, Z1, TT and probably some others are equipped with an
> ambient light sensor and full access to the sensor is provided via
> 0x012F or 0x0137 handle. On newer SA/SB/SC and CA/CB series, only
> the lux reading is provided. This patch provides full support for
> both types, including a driver for TAOS devices used in conjunction
> with handles 0x012F and 0x0137, and a generic layer that exposes
> control files for every handle. Some other model specific parameters
> provided by the hardware, to be used for ALS based backlight
> regulation, are exposed too.

could you document a bit better what managed mode is, the way GPE
notification works (under which conditions) and the general idea behind
your re-implementation of a backlight device and why we would ever want
to have it?

To my understanding, SNC will receive GPEs in two cases under managed
mode:
 1. when the user request a backlight change via the standard acpi_video
 2. when ambient light changes
In both cases your code sends an acpi event to userspace. Let alone the
acpi event discussion that belongs to another thread, why aren't we
just setting the requested brightness?

I'm also under the impression that the whole ALS driver could be split
out of sony-laptop (like meye was).

> This patch has been written by Marco Chiappero and Javier Achirica.
> 
> Signed-off-by: Marco Chiappero <marco@absence.it>
> ---
> 
> --- a/drivers/platform/x86/sony-laptop.c
> +++ b/drivers/platform/x86/sony-laptop.c
> @@ -1412,6 +1412,1009 @@ static int sony_nc_rfkill_setup(struct a
>  	return 0;
>  }
> 
> +/*	ALS controlled backlight feature	*/
> +/* generic ALS data and interface */
> +#define ALS_TABLE_SIZE	25
> +
> +struct als_device_ops {
> +	int (*init)(const u8 defaults[]);
> +	int (*exit)(void);
> +	int (*event_handler)(void);
> +	int (*set_power)(unsigned int);
> +	int (*get_power)(unsigned int *);
> +	int (*get_lux)(unsigned int *, unsigned int *);
> +	int (*get_kelvin)(unsigned int *);
> +};
> +
> +struct als_device {
> +	unsigned int power;
> +	unsigned int managed;
> +
> +	unsigned int levels_num;
> +	u8 *levels;
> +	unsigned int defaults_num;
> +	u8 *defaults;
> +	u8 parameters[ALS_TABLE_SIZE];
> +
> +	/* common device operations */
> +	const struct als_device_ops *ops;
> +
> +	/* basic ALS sys interface */
> +	unsigned int attrs_num;
> +	struct device_attribute attrs[7];
> +};
> +
> +static struct als_device *als_handle;
> +static int sony_als_handle = -1;
> +
> +/*
> +	model specific ALS data and controls
> +	TAOS TSL256x device data
> +*/
> +#define LUX_SHIFT_BITS		16	/* for non-floating point math */
> +/* scale 100000 multiplied fractional coefficients rounding the values */
> +#define SCALE(u)	((((((u64) u) << LUX_SHIFT_BITS) / 10000) + 5) / 10)
> +
> +#define TSL256X_REG_CTRL	0x00
> +#define TSL256X_REG_TIMING	0x01
> +#define TSL256X_REG_TLOW	0x02
> +#define TSL256X_REG_THIGH	0x04
> +#define TSL256X_REG_INT		0x06
> +#define TSL256X_REG_ID		0x0a
> +#define TSL256X_REG_DATA0	0x0c
> +#define TSL256X_REG_DATA1	0x0e
> +
> +#define TSL256X_POWER_ON	0x03
> +#define TSL256X_POWER_OFF	0x00
> +
> +#define TSL256X_POWER_MASK	0x03
> +#define TSL256X_INT_MASK	0x10
> +
> +struct tsl256x_coeff {
> +	u32 ratio;
> +	u32 ch0;
> +	u32 ch1;
> +	u32 ka;
> +	s32 kb;
> +};
> +
> +struct tsl256x_data {
> +	unsigned int gaintime;
> +	unsigned int periods;
> +	u8 *defaults;
> +	struct tsl256x_coeff const *coeff_table;
> +};
> +static struct tsl256x_data *tsl256x_handle;
> +
> +static const struct tsl256x_coeff tsl256x_coeff_fn[] = {
> +	{
> +		.ratio	= SCALE(12500),	/* 0.125 * 2^LUX_SHIFT_BITS  */
> +		.ch0	= SCALE(3040),	/* 0.0304 * 2^LUX_SHIFT_BITS */
> +		.ch1	= SCALE(2720),	/* 0.0272 * 2^LUX_SHIFT_BITS */
> +		.ka	= SCALE(313550000),
> +		.kb	= -10651,
> +	}, {
> +		.ratio	= SCALE(25000),	/* 0.250 * 2^LUX_SHIFT_BITS  */
> +		.ch0	= SCALE(3250),	/* 0.0325 * 2^LUX_SHIFT_BITS */
> +		.ch1	= SCALE(4400),	/* 0.0440 * 2^LUX_SHIFT_BITS */
> +		.ka	= SCALE(203390000),
> +		.kb	= -2341,
> +	}, {
> +		.ratio	= SCALE(37500),	/* 0.375 * 2^LUX_SHIFT_BITS  */
> +		.ch0	= SCALE(3510),	/* 0.0351 * 2^LUX_SHIFT_BITS */
> +		.ch1	= SCALE(5440),	/* 0.0544 * 2^LUX_SHIFT_BITS */
> +		.ka	= SCALE(152180000),
> +		.kb	= 157,
> +	}, {
> +		.ratio	= SCALE(50000),	/* 0.50 * 2^LUX_SHIFT_BITS   */
> +		.ch0	= SCALE(3810),	/* 0.0381 * 2^LUX_SHIFT_BITS */
> +		.ch1	= SCALE(6240),	/* 0.0624 * 2^LUX_SHIFT_BITS */
> +		.ka	= SCALE(163580000),
> +		.kb	= -145,
> +	}, {
> +		.ratio	= SCALE(61000),	/* 0.61 * 2^LUX_SHIFT_BITS   */
> +		.ch0	= SCALE(2240),	/* 0.0224 * 2^LUX_SHIFT_BITS */
> +		.ch1	= SCALE(3100),	/* 0.0310 * 2^LUX_SHIFT_BITS */
> +		.ka	= SCALE(180800000),
> +		.kb	= -495,
> +	}, {
> +		.ratio	= SCALE(80000),	/* 0.80 * 2^LUX_SHIFT_BITS   */
> +		.ch0	= SCALE(1280),	/* 0.0128 * 2^LUX_SHIFT_BITS */
> +		.ch1	= SCALE(1530),	/* 0.0153 * 2^LUX_SHIFT_BITS */
> +		.ka	= SCALE(197340000),
> +		.kb	= -765
> +	}, {
> +		.ratio	= SCALE(130000),/* 1.3 * 2^LUX_SHIFT_BITS     */
> +		.ch0	= SCALE(146),	/* 0.00146 * 2^LUX_SHIFT_BITS */
> +		.ch1	= SCALE(112),	/* 0.00112 * 2^LUX_SHIFT_BITS */
> +		.ka	= SCALE(182900000),
> +		.kb	= -608,
> +	}, {
> +		.ratio	= UINT_MAX,	/* for higher ratios */
> +		.ch0	= 0,
> +		.ch1	= 0,
> +		.ka	= 0,
> +		.kb	= 830,
> +	}
> +};
> +
> +static const struct tsl256x_coeff tsl256x_coeff_cs[] = {
> +	{
> +		.ratio  = SCALE(13000),	/* 0.130 * 2^LUX_SHIFT_BITS  */
> +		.ch0    = SCALE(3150),	/* 0.0315 * 2^LUX_SHIFT_BITS */
> +		.ch1    = SCALE(2620),	/* 0.0262 * 2^LUX_SHIFT_BITS */
> +		.ka	= SCALE(300370000),
> +		.kb	= -9587,
> +	}, {
> +		.ratio  = SCALE(26000),	/* 0.260 * 2^LUX_SHIFT_BITS  */
> +		.ch0    = SCALE(3370),	/* 0.0337 * 2^LUX_SHIFT_BITS */
> +		.ch1    = SCALE(4300),	/* 0.0430 * 2^LUX_SHIFT_BITS */
> +		.ka	= SCALE(194270000),
> +		.kb	= -1824,
> +	}, {
> +		.ratio  = SCALE(39000),	/* 0.390 * 2^LUX_SHIFT_BITS  */
> +		.ch0    = SCALE(3630),	/* 0.0363 * 2^LUX_SHIFT_BITS */
> +		.ch1    = SCALE(5290),	/* 0.0529 * 2^LUX_SHIFT_BITS */
> +		.ka	= SCALE(152520000),
> +		.kb	= 145,
> +	}, {
> +		.ratio  = SCALE(52000),	/* 0.520 * 2^LUX_SHIFT_BITS  */
> +		.ch0    = SCALE(3920),	/* 0.0392 * 2^LUX_SHIFT_BITS */
> +		.ch1    = SCALE(6050),	/* 0.0605 * 2^LUX_SHIFT_BITS */
> +		.ka	= SCALE(165960000),
> +		.kb	= -200,
> +	}, {
> +		.ratio  = SCALE(65000),	/* 0.650 * 2^LUX_SHIFT_BITS  */
> +		.ch0    = SCALE(2290),	/* 0.0229 * 2^LUX_SHIFT_BITS */
> +		.ch1    = SCALE(2910),	/* 0.0291 * 2^LUX_SHIFT_BITS */
> +		.ka	= SCALE(184800000),
> +		.kb	= -566,
> +	}, {
> +		.ratio  = SCALE(80000),	/* 0.800 * 2^LUX_SHIFT_BITS  */
> +		.ch0    = SCALE(1570),	/* 0.0157 * 2^LUX_SHIFT_BITS */
> +		.ch1    = SCALE(1800),	/* 0.0180 * 2^LUX_SHIFT_BITS */
> +		.ka	= SCALE(199220000),
> +		.kb	= -791,
> +	}, {
> +		.ratio  = SCALE(130000),/* 0.130 * 2^LUX_SHIFT_BITS  */
> +		.ch0    = SCALE(338),	/* 0.00338 * 2^LUX_SHIFT_BITS */
> +		.ch1    = SCALE(260),	/* 0.00260 * 2^LUX_SHIFT_BITS */
> +		.ka	= SCALE(182900000),
> +		.kb	= -608,
> +	}, {
> +		.ratio  = UINT_MAX,	/* for higher ratios */
> +		.ch0    = 0,
> +		.ch1    = 0,
> +		.ka	= 0,
> +		.kb	= 830,
> +	}
> +};
> +
> +/*	TAOS helper & control functions		*/
> +static inline int tsl256x_exec_writebyte(unsigned int reg,
> +						unsigned int const *value)
> +{
> +	unsigned int result;
> +
> +	return (sony_call_snc_handle(sony_als_handle, (*value << 0x18) |
> +		(reg << 0x10) | 0x800500, &result) || !(result & 0x01))
> +		? -EIO : 0;
> +}
> +
> +static inline int tsl256x_exec_writeword(unsigned int reg,
> +						unsigned int const *value)
> +{
> +	u8 result[1];
> +	u64 arg = *value;
> +
> +	/* using sony_call_snc_handle_buffer due to possible input overflows */
> +	return ((sony_call_snc_handle_buffer(sony_als_handle, (arg << 0x18) |
> +				(reg << 0x10) | 0xA00700, result, 1) < 0) ||
> +				!(result[0] & 0x01)) ? -EIO : 0;
> +}
> +
> +static inline int tsl256x_exec_readbyte(unsigned int reg, unsigned
> int *result)
> +{
> +	if (sony_call_snc_handle(sony_als_handle, (reg << 0x10)
> +		| 0x800400, result) || !(*result & 0x01))
> +		return -EIO;
> +	*result = (*result >> 0x08) & 0xFF;
> +
> +	return 0;
> +}
> +
> +static inline int tsl256x_exec_readword(unsigned int reg, unsigned
> int *result)
> +{
> +	if (sony_call_snc_handle(sony_als_handle, (reg << 0x10)
> +		| 0xA00600, result) || !(*result & 0x01))
> +		return -EIO;
> +	*result = (*result >> 0x08) & 0xFFFF;
> +
> +	return 0;
> +}
> +
> +static int tsl256x_interrupt_ctrls(unsigned int *interrupt,
> +					unsigned int *periods)
> +{
> +	unsigned int value, result;
> +
> +	/* if no interrupt parameter, retrieve interrupt status */
> +	if (!interrupt) {
> +		if (tsl256x_exec_readbyte(TSL256X_REG_INT, &result))
> +			return -EIO;
> +
> +		value = (result & TSL256X_INT_MASK);
> +	} else {
> +		value = *interrupt << 0x04;
> +	}
> +
> +	/* if no periods provided use the last one set */
> +	value |= (periods ? *periods : tsl256x_handle->periods);
> +
> +	if (tsl256x_exec_writebyte(TSL256X_REG_INT, &value))
> +		return -EIO;
> +
> +	if (periods)
> +		tsl256x_handle->periods = *periods;
> +
> +	return 0;
> +}
> +
> +static int tsl256x_setup(void)
> +{
> +	unsigned int interr = 1, zero = 0;
> +
> +	/*
> +	 *   reset the threshold settings to trigger an event as soon
> +	 *   as the event goes on, forcing a backlight adaptation to
> +	 *   the current lighting conditions
> +	 */
> +	tsl256x_exec_writeword(TSL256X_REG_TLOW, &zero);
> +	tsl256x_exec_writeword(TSL256X_REG_THIGH, &zero);
> +
> +	/* set gain and time */
> +	if (tsl256x_exec_writebyte(TSL256X_REG_TIMING,
> +				&tsl256x_handle->gaintime))
> +		return -EIO;
> +
> +	/* restore persistence value and enable the interrupt generation */
> +	if (tsl256x_interrupt_ctrls(&interr, &tsl256x_handle->periods))
> +		return -EIO;
> +
> +	return 0;
> +}
> +
> +static int tsl256x_set_power(unsigned int status)
> +{
> +	int ret;
> +
> +	if (status) {
> +		ret = tsl256x_setup();
> +		if (ret)
> +			return ret;
> +	}
> +
> +	status = status ? TSL256X_POWER_ON : TSL256X_POWER_OFF;
> +	ret = tsl256x_exec_writebyte(TSL256X_REG_CTRL, &status);
> +
> +	return ret;
> +}
> +
> +static int tsl256x_get_power(unsigned int *status)
> +{
> +	if (tsl256x_exec_readbyte(TSL256X_REG_CTRL, status))
> +		return -EIO;
> +
> +	*status = ((*status & TSL256X_POWER_MASK) == TSL256X_POWER_ON) ? 1 : 0;
> +
> +	return 0;
> +}
> +
> +static int tsl256x_get_raw_data(unsigned int *ch0, unsigned int *ch1)
> +{
> +	if (!ch0)
> +		return -1;
> +
> +	if (tsl256x_exec_readword(TSL256X_REG_DATA0, ch0))
> +		return -EIO;
> +
> +	if (ch1) {
> +		if (tsl256x_exec_readword(TSL256X_REG_DATA1, ch1))
> +			return -EIO;
> +	}
> +
> +	return 0;
> +}
> +
> +static int tsl256x_set_thresholds(const unsigned int *ch0)
> +{
> +	unsigned int tlow, thigh;
> +
> +	tlow = (*ch0 * tsl256x_handle->defaults[0]) / 100;
> +	thigh = ((*ch0 * tsl256x_handle->defaults[1]) / 100) + 1;
> +
> +	if (thigh > 0xffff)
> +		thigh = 0xffff;
> +
> +	if (tsl256x_exec_writeword(TSL256X_REG_TLOW, &tlow) ||
> +		tsl256x_exec_writeword(TSL256X_REG_THIGH, &thigh))
> +		return -EIO;
> +
> +	return 0;
> +}
> +
> +#define MAX_LUX 1500
> +static void tsl256x_calculate_lux(const u32 ch0, const u32 ch1,
> +				unsigned int *integ, unsigned int *fract)
> +{
> +	/* the raw output from the sensor is just a "count" value, as
> +	   it is the result of the integration of the analog sensor
> +	   signal, the counts-to-lux curve (and its approximation can
> +	   be found on the datasheet.
> +	*/
> +	const struct tsl256x_coeff *coeff = tsl256x_handle->coeff_table;
> +	u32 ratio, temp, integer, fractional;
> +
> +	if (ch0 >= 65535 || ch1 >= 65535)
> +		goto saturation;
> +
> +	/* STEP 1: ratio calculation, for ch0 & ch1 coeff selection */
> +
> +	/* protect against division by 0 */
> +	ratio = ch0 ? ((ch1 << (LUX_SHIFT_BITS + 1)) / ch0) : UINT_MAX;
> +	/* round the ratio value */
> +	ratio = (ratio + 1) >> 1;
> +
> +	/* coeff selection rule */
> +	while (coeff->ratio < ratio)
> +		coeff++;
> +
> +	/* STEP 2: lux calculation formula using the right coeffcients */
> +	temp = (ch0 * coeff->ch0) - (ch1 * coeff->ch1);
> +	/* the sensor is placed under a plastic or glass cover which filters
> +	   a certain ammount of light (depending on that particular material).
> +	   To have an accurate reading, we need to compensate for this loss,
> +	   multiplying for compensation parameter, taken from the DSDT.
> +	*/
> +	temp *= tsl256x_handle->defaults[3] / 10;
> +
> +	/* STEP 3: separate integer and fractional part */
> +	/* remove the integer part and multiply for the 10^N, N decimals  */
> +	fractional = (temp % (1 << LUX_SHIFT_BITS)) * 100; /* two decimals */
> +	/* scale down the value */
> +	fractional >>= LUX_SHIFT_BITS;
> +
> +	/* strip off fractional portion to obtain the integer part */
> +	integer = temp >> LUX_SHIFT_BITS;
> +
> +	if (integer > MAX_LUX)
> +		goto saturation;
> +
> +	*integ = integer;
> +	*fract = fractional;
> +
> +	return;
> +
> +saturation:
> +	*integ = MAX_LUX;
> +	*fract = 0;
> +}
> +
> +static void tsl256x_calculate_kelvin(const u32 *ch0, const u32 *ch1,
> +					unsigned int *temperature)
> +{
> +	const struct tsl256x_coeff *coeff = tsl256x_handle->coeff_table;
> +	u32 ratio;
> +
> +	/* protect against division by 0 */
> +	ratio = *ch0 ? ((*ch1 << (LUX_SHIFT_BITS + 1)) / *ch0) : UINT_MAX;
> +	/* round the ratio value */
> +	ratio = (ratio + 1) >> 1;
> +
> +	/* coeff selection rule */
> +	while (coeff->ratio < ratio)
> +		coeff++;
> +
> +	*temperature = ratio ? coeff->ka / ratio + coeff->kb : 0;
> +}
> +
> +static int tsl256x_get_lux(unsigned int *integ, unsigned int *fract)
> +{
> +	int ret = 0;
> +	unsigned int ch0, ch1;
> +
> +	if (!integ || !fract)
> +		return -1;
> +
> +	ret = tsl256x_get_raw_data(&ch0, &ch1);
> +	if (!ret)
> +		tsl256x_calculate_lux(ch0, ch1, integ, fract);
> +
> +	return ret;
> +}
> +
> +static int tsl256x_get_kelvin(unsigned int *temperature)
> +{
> +	int ret = -1;
> +	unsigned int ch0, ch1;
> +
> +	if (!temperature)
> +		return ret;
> +
> +	ret = tsl256x_get_raw_data(&ch0, &ch1);
> +	if (!ret)
> +		tsl256x_calculate_kelvin(&ch0, &ch1, temperature);
> +
> +	return ret;
> +}
> +
> +static int tsl256x_get_id(char *model, unsigned int *id, bool *cs)
> +{
> +	int ret;
> +	unsigned int result;
> +	char *name = NULL;
> +	bool unknown = false;
> +	bool type_cs = false;
> +
> +	ret = tsl256x_exec_readbyte(TSL256X_REG_ID, &result);
> +	if (ret)
> +		return ret;
> +
> +	switch ((result >> 0x04) & 0x0F) {
> +	case 11:
> +		name = "TAOS TSL2569";
> +		break;
> +	case 5:
> +		name = "TAOS TSL2561";
> +		break;
> +	case 3:
> +		name = "TAOS TSL2563";
> +		break;
> +	case 0:
> +		type_cs = true;
> +		name = "TAOS TSL2560CS";
> +		break;
> +	default:
> +		unknown = true;
> +		break;
> +	}
> +
> +	if (id)
> +		*id = result;
> +	if (cs)
> +		*cs = type_cs;
> +	if (model && name)
> +		strcpy(model, name);
> +
> +	return unknown;
> +}
> +
> +static int tsl256x_event_handler(void)
> +{
> +	unsigned int ch0, interr = 1;
> +
> +	/* wait for the EC to clear the interrupt */
> +/*      schedule_timeout_interruptible(msecs_to_jiffies(100));	*/
> +	/* ...or force the interrupt clear immediately */
> +	sony_call_snc_handle(sony_als_handle, 0x04C60500, &interr);
> +
> +	/* read the raw data */
> +	tsl256x_get_raw_data(&ch0, NULL);
> +
> +	/* set the thresholds */
> +	tsl256x_set_thresholds(&ch0);
> +
> +	/* enable interrupt */
> +	tsl256x_interrupt_ctrls(&interr, NULL);
> +
> +	return 0;
> +}
> +
> +static int tsl256x_init(const u8 defaults[])
> +{
> +	unsigned int id;
> +	int ret = 0;
> +	bool cs; /* if CS package choose CS coefficients */
> +	char model[64];
> +
> +	/* detect the device */
> +	ret = tsl256x_get_id(model, &id, &cs);
> +	if (ret < 0)
> +		return ret;
> +	if (ret) {
> +		dprintk("unsupported ALS found (unknown model "
> +			"number %u rev. %u\n", id >> 4, id & 0x0F);
> +		return ret;
> +	} else {
> +		dprintk("found ALS model number %u rev. %u (%s)\n",
> +				id >> 4, id & 0x0F, model);
> +	}
> +
> +	tsl256x_handle = kzalloc(sizeof(struct tsl256x_data), GFP_KERNEL);
> +	if (!tsl256x_handle)
> +		return -ENOMEM;
> +
> +	tsl256x_handle->defaults = kzalloc(sizeof(u8) * 4, GFP_KERNEL);
> +	if (!tsl256x_handle->defaults) {
> +		kfree(tsl256x_handle);
> +		return -ENOMEM;
> +	}
> +
> +	/* populate the device data */
> +	tsl256x_handle->defaults[0] = defaults[3];  /* low threshold % */
> +	tsl256x_handle->defaults[1] = defaults[4];  /* high threshold % */
> +	tsl256x_handle->defaults[2] = defaults[9];  /* sensor interrupt rate */
> +	tsl256x_handle->defaults[3] = defaults[10]; /* light compensat. rate */
> +	tsl256x_handle->gaintime = 0x12;
> +	tsl256x_handle->periods = defaults[9];
> +	tsl256x_handle->coeff_table = cs ? tsl256x_coeff_cs : tsl256x_coeff_fn;
> +
> +	ret = tsl256x_setup();
> +
> +	return ret;
> +}
> +
> +static int tsl256x_exit(void)
> +{
> +	unsigned int interr = 0, periods = tsl256x_handle->defaults[2];
> +
> +	/* disable the interrupt generation, restore defaults */
> +	tsl256x_interrupt_ctrls(&interr, &periods);
> +
> +	tsl256x_handle->coeff_table = NULL;
> +	kfree(tsl256x_handle->defaults);
> +	tsl256x_handle->defaults = NULL;
> +	kfree(tsl256x_handle);
> +
> +	return 0;
> +}
> +
> +/* TAOS TSL256x specific ops */
> +static const struct als_device_ops tsl256x_ops = {
> +	.init = tsl256x_init,
> +	.exit = tsl256x_exit,
> +	.event_handler = tsl256x_event_handler,
> +	.set_power = tsl256x_set_power,
> +	.get_power = tsl256x_get_power,
> +	.get_lux = tsl256x_get_lux,
> +	.get_kelvin = tsl256x_get_kelvin,
> +};
> +
> +/* unknown ALS sensors controlled by the EC present on newer Vaios */
> +static inline int ngals_get_raw_data(unsigned int *data)
> +{
> +	if (sony_call_snc_handle(sony_als_handle, 0x1000, data))
> +		return -EIO;
> +
> +	return 0;
> +}
> +
> +static int ngals_get_lux(unsigned int *integ, unsigned int *fract)
> +{
> +	unsigned int data;
> +
> +	if (sony_call_snc_handle(sony_als_handle, 0x1000, &data))
> +		return -EIO;
> +
> +	/* if we have a valid lux data */
> +	if (!!(data & 0xff0000) == 0x01) {
> +		*integ = 0xffff & data;
> +		*fract = 0;
> +	} else {
> +		return -1;
> +	}
> +
> +	return 0;
> +}
> +
> +static const struct als_device_ops ngals_ops = {
> +	.init = NULL,
> +	.exit = NULL,
> +	.event_handler = NULL,
> +	.set_power = NULL,
> +	.get_power = NULL,
> +	.get_lux = ngals_get_lux,
> +	.get_kelvin = NULL,
> +};
> +
> +/*	ALS common data and functions	*/
> +static int sony_nc_als_event_handler(void)
> +{
> +	/* call the device handler */
> +	if (als_handle->ops->event_handler)
> +		als_handle->ops->event_handler();
> +
> +	return 0;
> +}
> +
> +static int sony_nc_als_power_set(unsigned int status)
> +{
> +	if (!als_handle->ops->set_power)
> +		return -EPERM;
> +
> +	if (als_handle->ops->set_power(status))
> +		return -EIO;
> +
> +	als_handle->power = status;
> +
> +	return 0;
> +}
> +
> +static int sony_nc_als_managed_set(unsigned int status)
> +{
> +	int ret = 0;
> +	unsigned int result, cmd;
> +	static bool was_on;
> +
> +	/*  turn on/off the event notification
> +	 *  (and enable als_backlight writes)
> +	 */
> +	cmd = sony_als_handle == 0x0143 ? 0x2200 : 0x0900;
> +	if (sony_call_snc_handle(sony_als_handle,
> +		(status << 0x10) | cmd, &result))
> +		return -EIO;
> +
> +	als_handle->managed = status;
> +
> +	/* turn on the ALS; this will also enable the interrupt generation */
> +	if (status) /* store the power state else check the previous state */
> +		was_on = als_handle->power;
> +	else if (was_on)
> +		return 0;

I don't quite understand what you want to achieve with the code above.
Also, if als_power and als_managed have to go along together why not
just have one single file that allows 3 values, i.e. 0:off, 1:on,
2:managed ?

> +	ret = sony_nc_als_power_set(status);
> +	if (ret == -EPERM) /* new models do not allow power control */
> +		ret = 0;
> +
> +	return ret;
> +}
> +
> +/*	ALS sys interface	*/
> +static ssize_t sony_nc_als_power_show(struct device *dev,
> +		struct device_attribute *attr, char *buffer)
> +{
> +	ssize_t count = 0;
> +	int status;
> +
> +	if (!als_handle->ops->get_power)
> +		return -EPERM;
> +
> +	if (als_handle->ops->get_power(&status))
> +		return -EIO;
> +
> +	count = snprintf(buffer, PAGE_SIZE, "%d\n", status);
> +
> +	return count;
> +}
> +
> +static ssize_t sony_nc_als_power_store(struct device *dev,
> +		struct device_attribute *attr,
> +		const char *buffer, size_t count)
> +{
> +	int ret;
> +	unsigned long value;
> +
> +	if (count > 31)
> +		return -EINVAL;
> +
> +	if (strict_strtoul(buffer, 10, &value) || value > 1)
> +		return -EINVAL;
> +
> +	/* no action if already set */
> +	if (value == als_handle->power)
> +		return count;
> +
> +	ret = sony_nc_als_power_set(value);
> +	if (ret)
> +		return ret;
> +
> +	return count;
> +}
> +
> +static ssize_t sony_nc_als_managed_show(struct device *dev,
> +		struct device_attribute *attr, char *buffer)
> +{
> +	ssize_t count = 0;
> +	unsigned int status, cmd;
> +
> +	cmd = sony_als_handle == 0x0143 ? 0x2100 : 0x0A00;
> +	if (sony_call_snc_handle(sony_als_handle, cmd, &status))
> +		return -EIO;
> +
> +	count = snprintf(buffer, PAGE_SIZE, "%d\n", status & 0x01);
> +
> +	return count;
> +}
> +
> +static ssize_t sony_nc_als_managed_store(struct device *dev,
> +		struct device_attribute *attr,
> +		const char *buffer, size_t count)
> +{
> +	unsigned long value;
> +
> +	if (count > 31)
> +		return -EINVAL;
> +
> +	if (strict_strtoul(buffer, 10, &value) || value > 1)
> +		return -EINVAL;
> +
> +	if (als_handle->managed != value) {
> +		int ret = sony_nc_als_managed_set(value);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	return count;
> +}
> +
> +static ssize_t sony_nc_als_lux_show(struct device *dev,
> +		struct device_attribute *attr, char *buffer)
> +{
> +	ssize_t count = 0;
> +	unsigned int integ = 0, fract = 0;
> +
> +	if (als_handle->power)
> +		/* als_handle->ops->get_lux is mandatory, no check */
> +		als_handle->ops->get_lux(&integ, &fract);
> +
> +	count = snprintf(buffer, PAGE_SIZE, "%u.%.2u\n", integ, fract);
> +
> +	return count;
> +}
> +
> +static ssize_t sony_nc_als_parameters_show(struct device *dev,
> +		struct device_attribute *attr, char *buffer)
> +{
> +	ssize_t count = 0;
> +	unsigned int i, num;
> +	u8 *list;
> +
> +	if (!strcmp(attr->attr.name, "als_defaults")) {
> +		list = als_handle->defaults;
> +		num = als_handle->defaults_num;
> +	} else { /* als_backlight_levels */
> +		list = als_handle->levels;
> +		num = als_handle->levels_num;
> +	}
> +
> +	for (i = 0; i < num; i++)
> +		count += snprintf(buffer + count, PAGE_SIZE - count,
> +				"0x%.2x ", list[i]);
> +
> +	count += snprintf(buffer + count, PAGE_SIZE - count, "\n");
> +
> +	return count;
> +}
> +
> +static ssize_t sony_nc_als_backlight_show(struct device *dev,
> +		struct device_attribute *attr, char *buffer)
> +{
> +	ssize_t count = 0;
> +	unsigned int result, cmd;
> +
> +	cmd = sony_als_handle == 0x0143 ? 0x3100 : 0x0200;
> +	if (sony_call_snc_handle(sony_als_handle, cmd, &result))
> +		return -EIO;
> +
> +	count = snprintf(buffer, PAGE_SIZE, "%d\n", result & 0xff);
> +
> +	return count;
> +}
> +
> +static ssize_t sony_nc_als_backlight_store(struct device *dev,
> +		struct device_attribute *attr,
> +		const char *buffer, size_t count)
> +{
> +	unsigned long value;
> +	unsigned int result, cmd, max = als_handle->levels_num - 1;
> +
> +	if (count > 31)
> +		return -EINVAL;
> +
> +	if (strict_strtoul(buffer, 10, &value))
> +		return -EINVAL;
> +
> +	if (!als_handle->managed)
> +		return -EPERM;
> +
> +	/* verify that the provided value falls inside the model
> +	   specific backlight range */
> +	if ((value < als_handle->levels[0])
> +			|| (value > als_handle->levels[max]))
> +		return -EINVAL;
> +
> +	cmd = sony_als_handle == 0x0143 ? 0x3000 : 0x0100;
> +	if (sony_call_snc_handle(sony_als_handle, (value << 0x10) | cmd,
> +				&result))
> +		return -EIO;
> +
> +	return count;
> +}
> +
> +static ssize_t sony_nc_als_kelvin_show(struct device *dev,
> +		struct device_attribute *attr, char *buffer)
> +{
> +	ssize_t count = 0;
> +	unsigned int kelvin = 0;
> +
> +	if (als_handle->ops->get_kelvin && als_handle->power)
> +		als_handle->ops->get_kelvin(&kelvin);
> +
> +	count = snprintf(buffer, PAGE_SIZE, "%d\n", kelvin);
> +
> +	return count;
> +}
> +
> +
> +/*	ALS attach/detach functions	*/
> +static int sony_nc_als_setup(struct platform_device *pd)
> +{
> +	int i = 0;
> +
> +	/* check the device presence */
> +	if (sony_als_handle == 0x0137) {
> +		unsigned int result;
> +
> +		if (sony_call_snc_handle(sony_als_handle, 0xB00, &result))
> +			return -EIO;
> +
> +		if (!(result & 0x01)) {
> +			pr_info("no ALS present\n");
> +			return 0;
> +		}
> +	}
> +
> +	als_handle = kzalloc(sizeof(struct als_device), GFP_KERNEL);
> +	if (!als_handle)
> +		return -ENOMEM;
> +
> +	/* set model specific data */
> +	/* if handle 0x012f or 0x0137 use tsl256x_ops, else new als controls */
> +	if (sony_als_handle == 0x0143) {
> +		als_handle->ops = &ngals_ops;
> +		als_handle->levels_num = 16;
> +		als_handle->defaults_num = 9;
> +	} else {
> +		als_handle->ops = &tsl256x_ops;
> +		als_handle->levels_num = 9;
> +		als_handle->defaults_num = 13;
> +	}
> +	/* backlight levels are the first levels_num values, the remaining
> +	   defaults_num values are default settings for als regulation
> +	*/
> +	als_handle->levels = als_handle->parameters;
> +	als_handle->defaults = als_handle->parameters + als_handle->levels_num;
> +
> +	/* get power state */
> +	if (als_handle->ops->get_power) {
> +		if (als_handle->ops->get_power(&als_handle->power))
> +			pr_warn("unable to retrieve the power status\n");
> +	}
> +
> +	/* set managed to 0, userspace daemon should enable it */
> +	sony_nc_als_managed_set(0);
> +
> +	/* get ALS parameters */
> +	if (sony_call_snc_handle_buffer(sony_als_handle, 0x0000,
> +		als_handle->parameters, ALS_TABLE_SIZE) < 0)
> +		goto nosensor;
> +
> +	/* initial device configuration */
> +	if (als_handle->ops->init)
> +		if (als_handle->ops->init(als_handle->defaults)) {
> +			pr_warn("ALS setup failed\n");
> +			goto nosensor;
> +		}
> +
> +	/* set up the sys interface */
> +
> +	/* notifications and backlight enable control file */
> +	sysfs_attr_init(&als_handle->attrs[0].attr);
> +	als_handle->attrs[0].attr.name = "als_managed";
> +	als_handle->attrs[0].attr.mode = S_IRUGO | S_IWUSR;
> +	als_handle->attrs[0].show = sony_nc_als_managed_show;
> +	als_handle->attrs[0].store = sony_nc_als_managed_store;
> +	/* lux equivalent value */
> +	sysfs_attr_init(&als_handle->attrs[1].attr);
> +	als_handle->attrs[1].attr.name = "als_lux";
> +	als_handle->attrs[1].attr.mode = S_IRUGO;
> +	als_handle->attrs[1].show = sony_nc_als_lux_show;
> +	/* ALS default parameters */
> +	sysfs_attr_init(&als_handle->attrs[2].attr);
> +	als_handle->attrs[2].attr.name = "als_defaults";
> +	als_handle->attrs[2].attr.mode = S_IRUGO;
> +	als_handle->attrs[2].show = sony_nc_als_parameters_show;
> +	/* ALS default backlight levels */
> +	sysfs_attr_init(&als_handle->attrs[3].attr);
> +	als_handle->attrs[3].attr.name = "als_backlight_levels";
> +	als_handle->attrs[3].attr.mode = S_IRUGO;
> +	als_handle->attrs[3].show = sony_nc_als_parameters_show;
> +	/* als backlight control */
> +	sysfs_attr_init(&als_handle->attrs[4].attr);
> +	als_handle->attrs[4].attr.name = "als_backlight";
> +	als_handle->attrs[4].attr.mode = S_IRUGO | S_IWUSR;
> +	als_handle->attrs[4].show = sony_nc_als_backlight_show;
> +	als_handle->attrs[4].store = sony_nc_als_backlight_store;
> +
> +	als_handle->attrs_num = 5;
> +	/* end mandatory sys interface */
> +
> +	if (als_handle->ops->get_power || als_handle->ops->set_power) {
> +		int i = als_handle->attrs_num++;
> +
> +		/* als power control */
> +		sysfs_attr_init(&als_handle->attrs[i].attr);
> +		als_handle->attrs[i].attr.name = "als_power";
> +		als_handle->attrs[i].attr.mode = S_IRUGO | S_IWUSR;
> +		als_handle->attrs[i].show = sony_nc_als_power_show;
> +		als_handle->attrs[i].store = sony_nc_als_power_store;
> +	}
> +
> +	if (als_handle->ops->get_kelvin) {
> +		int i = als_handle->attrs_num++;
> +
> +		/* light temperature */
> +		sysfs_attr_init(&als_handle->attrs[i].attr);
> +		als_handle->attrs[i].attr.name = "als_kelvin";
> +		als_handle->attrs[i].attr.mode = S_IRUGO;
> +		als_handle->attrs[i].show = sony_nc_als_kelvin_show;
> +	}
> +
> +	/* everything or nothing, otherwise unable to control the ALS */
> +	for (; i < als_handle->attrs_num; i++) {
> +		if (device_create_file(&pd->dev, &als_handle->attrs[i]))
> +			goto attrserror;
> +	}
> +
> +	return 0;
> +
> +attrserror:
> +	for (; i > 0; i--)
> +		device_remove_file(&pd->dev, &als_handle->attrs[i]);
> +nosensor:
> +	kfree(als_handle);
> +	als_handle = NULL;
> +
> +	return -1;
> +}
> +
> +static void sony_nc_als_resume(void)
> +{
> +	if (als_handle->managed) /* it restores the power state too */
> +		sony_nc_als_managed_set(1);
> +	else if (als_handle->power)
> +		sony_nc_als_power_set(1);
> +}
> +
> +static int sony_nc_als_cleanup(struct platform_device *pd)
> +{
> +	if (als_handle) {
> +		int i;
> +
> +		for (i = 0; i < als_handle->attrs_num; i++)
> +			device_remove_file(&pd->dev, &als_handle->attrs[i]);
> +
> +		/* disable the events notification */
> +		if (als_handle->managed)
> +			if (sony_nc_als_managed_set(0))
> +				pr_info("ALS notifications disable failed\n");
> +
> +		if (als_handle->power)
> +			if (sony_nc_als_power_set(0))
> +				pr_info("ALS power off failed\n");
> +
> +		if (als_handle->ops->exit)
> +			if (als_handle->ops->exit())
> +				pr_info("ALS device cleaning failed\n");
> +
> +		kfree(als_handle);
> +		als_handle = NULL;
> +	}
> +
> +	return 0;
> +}
> +/*	end ALS code	*/
> +
>  /* Keyboard backlight feature */
>  struct kbd_backlight {
>  	unsigned int base;
> @@ -2899,6 +3902,9 @@ static void sony_nc_snc_setup_handles(st
>  		case 0x0143:
>  			sony_kbd_handle = handle;
>  			ret = sony_nc_kbd_backlight_setup(pd);
> +		case 0x012f: /* no keyboard backlight */
> +			sony_als_handle = handle;
> +			ret = sony_nc_als_setup(pd);
>  			break;
>  		case 0x0131:
>  			ret = sony_nc_highspeed_charging_setup(pd);
> @@ -2964,6 +3970,8 @@ static void sony_nc_snc_cleanup_handles(
>  		case 0x0137:
>  		case 0x0143:
>  			sony_nc_kbd_backlight_cleanup(pd);
> +		case 0x012f:
> +			sony_nc_als_cleanup(pd);
>  			break;
>  		case 0x0131:
>  			sony_nc_highspeed_charging_cleanup(pd);
> @@ -3082,6 +4090,8 @@ static int sony_nc_snc_resume(void)
>  		case 0x0137: /* kbd + als */
>  		case 0x0143:
>  			sony_nc_kbd_backlight_resume();
> +		case 0x012f: /* als only */
> +			sony_nc_als_resume();
>  			break;
>  		default:
>  			continue;
> @@ -3146,6 +4156,31 @@ static void sony_nc_notify(struct acpi_d
>  			ev = 1;
>  			break;
> 
> +		case 0x0143:
> +			sony_call_snc_handle(sony_als_handle, 0x2000, &result);
> +			/* event reasons are reverted */

inverted with respect to?

> +			value = (result & 0x03) == 1 ? 2 : 1;
> +			dprintk("sony_nc_notify, ALS event received (reason:"
> +				       " %s change)\n", value == 1 ? "light" :
> +				       "backlight");
> +			/* no further actions needed */
> +
> +			ev = 3;
> +			break;
> +
> +		case 0x012f:
> +		case 0x0137:
> +			sony_call_snc_handle(sony_als_handle, 0x0800, &result);
> +			value = result & 0x03;
> +			dprintk("sony_nc_notify, ALS event received (reason:"
> +					" %s change)\n", value == 1 ? "light" :
> +					"backlight");
> +			if (value == 1) /* lighting change reason */
> +				sony_nc_als_event_handler();
> +
> +			ev = 3;
> +			break;
> +
>  		case 0x0124:
>  		case 0x0135:
>  			sony_call_snc_handle(sony_rfkill_handle, 0x0100,
> --
> To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
mattia
:wq!

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Marco Chiappero]

Il 04/06/2011 22:22, Alan Cox ha scritto:

> The longer term plan is to stick all kinds of device sensors (as distinct
> from input devices) into the IIO layer but that is still in staging and
> seems to have no clear plan of date for migration yet. However Jonathan
> (the maintainer) also doesn't seem too keen on owning them either
>
> http://lkml.org/lkml/2010/3/3/378
>
> All in all ALS is a bit of a disaster area.

So, what to do now? I'm not sure that the IIO layer is always fine when 
dealing with notbooks. For example, on every ALS equipped Vaio notebook, 
setting the notebook to generate ALS events will also result in _BCM no 
longer applying any further backlight change, it will instead generate 
another ACPI event when calling (this allows to have, in userspace, a 
single piece of software mixing and applying coherently both ALS driven 
and user driven backlight corrections).
On newer Vaios, the ALS sensor is totally controlled by the EC, so we 
just have the illuminance reading and talking about "device driver" 
don't make much sense (we'd better have an ALS device class). I don't 
know how other vendors introduced this functionality, but I can imagine 
that many different implementation are present across different models 
or brands. We need a solution, now, because there are lots of notebooks 
with these tiny but useful sensors, and people do want to use them.

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Alan Cox]

> that many different implementation are present across different models 
> or brands. We need a solution, now,

We needed a solution last year nothing has changed there other than there
are now a bazillion more out of tree drivers.

I don't have a solution I just wanted to make sure you understood the
problem space. Personally I think the right solution is for someone who
has infinite time to point out the mess and cluebat Linus, I don't have
time for that.

Alan

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Marco Chiappero]

Il 05/06/2011 21:14, Alan Cox ha scritto:
>> that many different implementation are present across different models
>> or brands. We need a solution, now,
>
> We needed a solution last year nothing has changed there other than there
> are now a bazillion more out of tree drivers.
>
> I don't have a solution I just wanted to make sure you understood the
> problem space.

Sure, I was rather expecting a reply from Matthew about what to do now, 
since there is no "rule" to follow regarding the ALS support and it's a 
pity not to support hardware we can make 100% working. But at this point 
perhaps we'd better discuss only on the platform driver mailing list.

Marco

Re: [PATCH 23/25] sony-laptop: add ALS support

[Marco Chiappero]

Il 05/06/2011 07:31, Mattia Dongili ha scritto:
> To my understanding, SNC will receive GPEs in two cases under managed
> mode:
>   1. when the user request a backlight change via the standard acpi_video
>   2. when ambient light changes

Right, more in detail:

When managed mode is set to 1, automatic backlight is desired by the 
user and a userspace tool is supposed to take control of every backlight 
change, to be applied via als_backlight node (which offers a fine grain 
backlight control for smooth transitions). It will receive two different 
types of ALS events, depending on the source of the event, as you said: 
1 - ambient light change 2 - backlight change request via backlight 
device (in linux, the standard acpi_video backlight device). When either 
of the two events occurs, this software will calculate a new backlight 
level (using a model specific formula) and set it by writing in the 
als_backlight file mentioned earlier. (NOTE: this is how the hardware 
has been designed and it supposed to work even though workarounds are 
possible).

When managed mode is set to 0, no automatic backlight control is 
requested by the user and no userspace software is doing any backlight 
regulation based on the ALS readings. This implies that no ALS events 
are generated (regardless the source) and the standard ACPI  backlight 
methods (used by the acpi_video backlight device) will work properly as 
usual.

> In both cases your code sends an acpi event to userspace. Let alone the
> acpi event discussion that belongs to another thread, why aren't we
> just setting the requested brightness?

Simply because any calculation can be done in userspace, but if we can 
include the calculation stuff inside the driver, then we can get rid of 
the daemon, everything will be easier and we can avoid the als_backlight 
file too. Is it possible? The formulas are a bit complex but just a few 
lines of code, while the keyboard backlight based on the ambient light 
is just a matter of a threshold check.

Re: [PATCH 12/25] sony-laptop: input core improvements improvements

[Mattia Dongili]

On Sat, Jun 04, 2011 at 06:58:53PM +0200, Marco Chiappero wrote:
> Il 04/06/2011 18:40, Mattia Dongili ha scritto:
...
> >Using generic key codes and remapping them in userspace where necessary
> >worked for more than 10 years and is still working fine.
> 
> Sure and I consider to be a good alternative, but it looks to me
> like being another workaround, it is fine for particular exceptions
> that need a few remappings, but it should not be the rule, the
> driver extension. That's why I was asking about this change.

what is a better solution? having keymaps for every different layout
that Sony implemented throught the years and adding more when things
change? This already exists in userspace, it makes not much sense to
have it in the kernel as well.

-- 
mattia
:wq!

Re: [PATCH 10/25] sony-laptop: keyboard backlight support extended to newer Vaios

[Mattia Dongili]

On Sat, Jun 04, 2011 at 01:41:35PM +0200, Marco Chiappero wrote:
> Il 04/06/2011 13:23, Mattia Dongili ha scritto:
> >>Just for safety, since handle 0x0000 is a valid handle [1] it would
> >>be better to initialize it to an invalid value.
> >
> >0x0 is not valid, it's just the lack of a value.
> 
> But you can use it. "Just for safety" we'd better set to an invalid
> value that cannot be used by the acpi methods.
> 
> >>[1]
> >>sony_laptop: found handle 0x0000 (offset: 0x0d)
> >>sony_laptop: called SN07 with 0x000d (result: 0x0000)
> >
> >this is only going through the handles buffer and telling you that at
> >0x0d there is nothing.
> 
> the calling code:
> 
> ret = sony_call_snc_handle(0, 0, &result);
> 
> it returns 0.

this is easily fixed and should be fixed since 0x0 is not a valid
handle.

> sony_find_snc_handle should return -1 when called with handle == -1, right?
-- 
mattia
:wq!

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Mattia Dongili]

On Sat, Jun 04, 2011 at 01:26:28PM +0200, Marco Chiappero wrote:
> Il 04/06/2011 10:43, Mattia Dongili ha scritto:
> >when sony_call_snc_handle(handle, 0x200,&result) fails above you will
> >be reporting -1 via the acpi bus. The old code restored the event and
> >reported the raw number instead.
> 
> You are right, does the following sony_nc_notify modification look
> fine to you?
> 
> /* hotkey event, a key has been pressed, retrieve it */
> value = sony_nc_hotkeys_decode(handle);
> if (value > 0) /* known event */
> 	sony_laptop_report_input_event(value);
> else /* restore the original event */
> 	value = event;

it's a bit out of context but I guess it should work. It would be good
to have sony_nc_hotkeys_decode also report the "not decoded" case
consistently back to callers though.
-- 
mattia
:wq!

Re: [PATCH 23/25] sony-laptop: add ALS support

[Javier Achirica]

On Mon, Jun 6, 2011 at 12:21 AM, Marco Chiappero <marco@absence.it> wrote:
> Il 05/06/2011 07:31, Mattia Dongili ha scritto:
>>
>> To my understanding, SNC will receive GPEs in two cases under managed
>> mode:
>>  1. when the user request a backlight change via the standard acpi_video
>>  2. when ambient light changes
>
> Right, more in detail:
>
> When managed mode is set to 1, automatic backlight is desired by the user
> and a userspace tool is supposed to take control of every backlight change,
> to be applied via als_backlight node (which offers a fine grain backlight
> control for smooth transitions). It will receive two different types of ALS
> events, depending on the source of the event, as you said: 1 - ambient light
> change 2 - backlight change request via backlight device (in linux, the
> standard acpi_video backlight device). When either of the two events occurs,
> this software will calculate a new backlight level (using a model specific
> formula) and set it by writing in the als_backlight file mentioned earlier.
> (NOTE: this is how the hardware has been designed and it supposed to work
> even though workarounds are possible).
>
> When managed mode is set to 0, no automatic backlight control is requested
> by the user and no userspace software is doing any backlight regulation
> based on the ALS readings. This implies that no ALS events are generated
> (regardless the source) and the standard ACPI  backlight methods (used by
> the acpi_video backlight device) will work properly as usual.
>
>> In both cases your code sends an acpi event to userspace. Let alone the
>> acpi event discussion that belongs to another thread, why aren't we
>> just setting the requested brightness?
>
> Simply because any calculation can be done in userspace, but if we can
> include the calculation stuff inside the driver, then we can get rid of the
> daemon, everything will be easier and we can avoid the als_backlight file
> too. Is it possible? The formulas are a bit complex but just a few lines of
> code, while the keyboard backlight based on the ambient light is just a
> matter of a threshold check.

It bothers me a bit that due to the fact that Sony implemented complex
formulas using floating point arithmetic, that would require us to use
floating point within the kernel. In fact in Sony Windows drivers
everything is done in user-space. Hiding the calculation of the lux
values and handling interrupt set-up in the kernel seems like a good
thing, but moving all management there, not.

From what I'm researching, in newer models, brightness and backlight
calculation are also related to power status and other aspects, so
putting that into a driver will generate lots of dependencies.

Javier

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Marco Chiappero]

Il 06/06/2011 00:38, Mattia Dongili ha scritto:
> it's a bit out of context but I guess it should work. It would be good
> to have sony_nc_hotkeys_decode also report the "not decoded" case
> consistently back to callers though.

Do you mean a negative value instead of 0? If so, let's return -EIO (or 
-2) on error and -1 for the unknown mapping case, else the translated 
key value (> 0).

Re: [PATCH 10/25] sony-laptop: keyboard backlight support extended to newer Vaios

[Marco Chiappero]

Il 06/06/2011 00:33, Mattia Dongili ha scritto:

>>> this is only going through the handles buffer and telling you that at
>>> 0x0d there is nothing.
>>
>> the calling code:
>>
>> ret = sony_call_snc_handle(0, 0,&result);
>>
>> it returns 0.
>
> this is easily fixed and should be fixed since 0x0 is not a valid
> handle.

I agree, but I'll wait for the fix to be posted before changing the patch.

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Mattia Dongili]

On Mon, Jun 06, 2011 at 02:23:34PM +0200, Marco Chiappero wrote:
> Il 06/06/2011 00:38, Mattia Dongili ha scritto:
> >it's a bit out of context but I guess it should work. It would be good
> >to have sony_nc_hotkeys_decode also report the "not decoded" case
> >consistently back to callers though.
> 
> Do you mean a negative value instead of 0? If so, let's return -EIO
> (or -2) on error and -1 for the unknown mapping case, else the
> translated key value (> 0).

I was more thinking of -EINVAL for all cases.

-- 
mattia
:wq!

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Marco Chiappero]

Il 06/06/2011 14:42, Mattia Dongili ha scritto:
> On Mon, Jun 06, 2011 at 02:23:34PM +0200, Marco Chiappero wrote:
>> Il 06/06/2011 00:38, Mattia Dongili ha scritto:
>>> it's a bit out of context but I guess it should work. It would be good
>>> to have sony_nc_hotkeys_decode also report the "not decoded" case
>>> consistently back to callers though.
>>
>> Do you mean a negative value instead of 0? If so, let's return -EIO
>> (or -2) on error and -1 for the unknown mapping case, else the
>> translated key value (>  0).
>
> I was more thinking of -EINVAL for all cases.

Ok, added to my changelist. As soon as there are no more comments I'll 
repost the modified patches.

Re: [PATCH 23/25] sony-laptop: add ALS support

[Mattia Dongili]

Marco,
Could you split the actual ALS driver and the modifications to the rest
in 2 separate patches?

On Mon, Jun 06, 2011 at 09:41:24AM +0200, Javier Achirica wrote:
> On Mon, Jun 6, 2011 at 12:21 AM, Marco Chiappero <marco@absence.it> wrote:
> > Il 05/06/2011 07:31, Mattia Dongili ha scritto:
> >>
> >> To my understanding, SNC will receive GPEs in two cases under managed
> >> mode:
> >>  1. when the user request a backlight change via the standard acpi_video
> >>  2. when ambient light changes
> >
> > Right, more in detail:
> >
> > When managed mode is set to 1, automatic backlight is desired by the user
> > and a userspace tool is supposed to take control of every backlight change,
> > to be applied via als_backlight node (which offers a fine grain backlight
> > control for smooth transitions). It will receive two different types of ALS
> > events, depending on the source of the event, as you said: 1 - ambient light
> > change 2 - backlight change request via backlight device (in linux, the
> > standard acpi_video backlight device). When either of the two events occurs,
> > this software will calculate a new backlight level (using a model specific
> > formula) and set it by writing in the als_backlight file mentioned earlier.
> > (NOTE: this is how the hardware has been designed and it supposed to work
> > even though workarounds are possible).

I don't think this is a feasible solution. sony-laptop already exposes
the fine grained backlight control and there is nothing preventing
userspace from doing the appropriate backlight calculation beforehand
without this back and forth with the kernel.
i.e. would it work if you always enable managed mode to receive the
ambient light events and just let userpace react for automatic dimming?
Also, userspace will intercept key-presses and scale the user
requested brightness change to an appropriate value using the current
lux values.

At this point you could have a generic software (modulo the not yet
standardized als interface) handling any laptop that has these simpler
features.

> > When managed mode is set to 0, no automatic backlight control is requested
> > by the user and no userspace software is doing any backlight regulation
> > based on the ALS readings. This implies that no ALS events are generated
> > (regardless the source) and the standard ACPI  backlight methods (used by
> > the acpi_video backlight device) will work properly as usual.
> >
> >> In both cases your code sends an acpi event to userspace. Let alone the
> >> acpi event discussion that belongs to another thread, why aren't we
> >> just setting the requested brightness?
> >
> > Simply because any calculation can be done in userspace, but if we can

the question was why sending a "user requested to change
brightness"-event instead of setting the brightness. The calculation
should be done in userspace but for what we know the user input could
already take ALS parameters into consideration so we should just set
that value.

> > include the calculation stuff inside the driver, then we can get rid of the
> > daemon, everything will be easier and we can avoid the als_backlight file
> > too. Is it possible? The formulas are a bit complex but just a few lines of
> > code, while the keyboard backlight based on the ambient light is just a
> > matter of a threshold check.
> 
> It bothers me a bit that due to the fact that Sony implemented complex
> formulas using floating point arithmetic, that would require us to use
> floating point within the kernel. In fact in Sony Windows drivers
> everything is done in user-space. Hiding the calculation of the lux
> values and handling interrupt set-up in the kernel seems like a good
> thing, but moving all management there, not.

agreed, one such policy handling has little to do with the kernel.

-- 
mattia
:wq!

Re: [PATCH 12/25] sony-laptop: input core improvements improvements

[Marco Chiappero]

Il 06/06/2011 00:24, Mattia Dongili ha scritto:
>> Sure and I consider to be a good alternative, but it looks to me
>> like being another workaround, it is fine for particular exceptions
>> that need a few remappings, but it should not be the rule, the
>> driver extension. That's why I was asking about this change.
>
> what is a better solution? having keymaps for every different layout
> that Sony implemented throught the years

This is a wrong assumption: the layout never really changed "recently" 
(I mean, at least 4-5 years, or even more), is still the same since a 
long time (and it's very likely to stay the same), Sony is just adding 
keys. For example, there are models with the Zoom In key (Fn-F10), but 
no Zoom Out (Fn-F9), but on those models Fn-F9 do not generate 
"scancodes". The same goes, for example, for newer models where the 
Fn-F1 key (Touchpad toggle) is now present. The hotkeys layout is now 
stable enough to be used as the default one for every model, causing no 
problems at all (very old models will continue to work through the udev 
keymaps already in place - well, just one, because module-sony would no 
longer be necessary -).
To answer your question: to me, it looks much better having a single 
real input driver mapping the right keys for everybody instead of having 
a fake layout plus a userspace keymap (because just a single keymap is 
needed).

Re: [PATCH 23/25] sony-laptop: add ALS support

[Marco Chiappero]

Il 06/06/2011 15:08, Mattia Dongili ha scritto:
> i.e. would it work if you always enable managed mode to receive the
> ambient light events and just let userpace react for automatic dimming?
> Also, userspace will intercept key-presses and scale the user
> requested brightness change to an appropriate value using the current
> lux values.

sony-acpid is already doing this without listening for key events (we 
can do that but we miss any other different backlight correction otherwise).

> At this point you could have a generic software (modulo the not yet
> standardized als interface) handling any laptop that has these simpler
> features.

The small big issue is that not every notebook use the same LCD panel, 
so, in theory, different calculations are required (and this also the 
reason why a model specific parameter list is also provided by every 
Vaio notebook too). A single suboptimal formula for everybody is not 
likely to provide satisfactory results.

> the question was why sending a "user requested to change
> brightness"-event instead of setting the brightness. The calculation
> should be done in userspace

...taking into account both the current user/power_saving_sofware/etc. 
backlight correction level and the ambient light level. We need to 
forward both informations to userspace otherwise no calculation is possible.

Re: [PATCH 23/25] sony-laptop: add ALS support

[Mattia Dongili]

On Mon, Jun 06, 2011 at 03:51:46PM +0200, Marco Chiappero wrote:
> Il 06/06/2011 15:08, Mattia Dongili ha scritto:
> >i.e. would it work if you always enable managed mode to receive the
> >ambient light events and just let userpace react for automatic dimming?
> >Also, userspace will intercept key-presses and scale the user
> >requested brightness change to an appropriate value using the current
> >lux values.
> 
> sony-acpid is already doing this without listening for key events
> (we can do that but we miss any other different backlight correction
> otherwise).

how many sources of backlight changes do you have? A system should have
only one application trying to control the backlight, having more than
one is asking for trouble in the first place.
Also, if I echo a number to /sys/... directly I would expect that to be
applied no matter what and without any magic correction going on.

> >At this point you could have a generic software (modulo the not yet
> >standardized als interface) handling any laptop that has these simpler
> >features.
> 
> The small big issue is that not every notebook use the same LCD
> panel, so, in theory, different calculations are required (and this
> also the reason why a model specific parameter list is also provided
> by every Vaio notebook too). A single suboptimal formula for
> everybody is not likely to provide satisfactory results.

this is something else that should be thought of presenting in a unified
way to userspace. The entire idea of platform drivers is to enable and
unify how platform specific features are handled. Having each one of
them diverge to its own custom interface defeats the whole purpose.

> >the question was why sending a "user requested to change
> >brightness"-event instead of setting the brightness. The calculation
> >should be done in userspace
> 
> ...taking into account both the current
> user/power_saving_sofware/etc. backlight correction level and the
> ambient light level. We need to forward both informations to
> userspace otherwise no calculation is possible.

the backlight change request is initiated in userspace already, why do
you need to tell userspace that it generated a backlight change request?

So again, can you split the patch in two so that we have the driver in
one patch and the interaction/integration part in another?

Thanks
-- 
mattia
:wq!

Re: [PATCH 23/25] sony-laptop: add ALS support

[Marco Chiappero]

Il 07/06/2011 00:24, Mattia Dongili ha scritto:
>> sony-acpid is already doing this without listening for key events
>> (we can do that but we miss any other different backlight correction
>> otherwise).
>
> how many sources of backlight changes do you have?

Potentially many, user keys, power saving options, proximity sensors, 
als, etc. and any other user defined (eg. low backlight setting when 
compiling software).

> A system should have
> only one application trying to control the backlight, having more than
> one is asking for trouble in the first place.

But it is not when using sony-acpid.

> Also, if I echo a number to /sys/... directly I would expect that to be
> applied no matter what and without any magic correction going on.

Again another wrong assumption, IMO: if the user enables the autodimming 
feature everything should follow this rule. You are saying is that if 
you echo to sysfs, you really want to mess things up... really hard to 
believe.

>> The small big issue is that not every notebook use the same LCD
>> panel, so, in theory, different calculations are required (and this
>> also the reason why a model specific parameter list is also provided
>> by every Vaio notebook too). A single suboptimal formula for
>> everybody is not likely to provide satisfactory results.
>
> this is something else that should be thought of presenting in a unified
> way to userspace.

Frankly, I cannot see how, especially right now... We have some hardware 
designed in a certain way that allows to be used only in that way, small 
changes are possible, but I really doubt that what you are asking for is 
possible.

> The entire idea of platform drivers is to enable and
> unify how platform specific features are handled.

Sure, whenever possible.

> Having each one of
> them diverge to its own custom interface defeats the whole purpose.

I know, it depends on whether the "hardware support" purpose come first 
or not. If it doesn't, the patch have to be rejected, but I think that a 
poor hardware support will take users away from linux on these devices.

> the backlight change request is initiated in userspace already,

Right, but how can you be sure when you have a backlight device that can 
be accessed by anything?

> So again, can you split the patch in two so that we have the driver in
> one patch and the interaction/integration part in another?

Please specify "interaction/integration part". There is almost nothing 
to be removed if you want code that makes sense and something working, 
if you specify a particular function I'll try to remove it, if it is 
feasible, otherwise be more specific, please.

Re: [PATCH 12/25] sony-laptop: input core improvements improvements

[Mattia Dongili]

On Mon, Jun 06, 2011 at 03:26:42PM +0200, Marco Chiappero wrote:
> Il 06/06/2011 00:24, Mattia Dongili ha scritto:
> >>Sure and I consider to be a good alternative, but it looks to me
> >>like being another workaround, it is fine for particular exceptions
> >>that need a few remappings, but it should not be the rule, the
> >>driver extension. That's why I was asking about this change.
> >
> >what is a better solution? having keymaps for every different layout
> >that Sony implemented throught the years
> 
> This is a wrong assumption: the layout never really changed
> "recently" (I mean, at least 4-5 years, or even more), is still the
> same since a long time (and it's very likely to stay the same), Sony

hmmm this is true only in part, mainly for SNC hotkeys.
All the S1/S2, speed/stamina and friends keys vary from model to model
and sometimes send the same event for different keys.
SPIC hotkeys are a lot more messy and there still are a number of (not
so) old models using SPIC to send hotkey events.

...
> models where the Fn-F1 key (Touchpad toggle) is now present. The
> hotkeys layout is now stable enough to be used as the default one
> for every model, causing no problems at all (very old models will

lovely, does it make any difference if udev maps those keys and the
driver instead just sends FN_F* making old and new models send the same
keycodes and scancodes?

> continue to work through the udev keymaps already in place - well,
> just one, because module-sony would no longer be necessary -).
> To answer your question: to me, it looks much better having a single
> real input driver mapping the right keys for everybody instead of
> having a fake layout plus a userspace keymap (because just a single
> keymap is needed).

you're a bit too optimistic here but well...
-- 
mattia
:wq!

Re: [PATCH 12/25] sony-laptop: input core improvements improvements

[Marco Chiappero]

Il 07/06/2011 16:23, Mattia Dongili ha scritto:
>> This is a wrong assumption: the layout never really changed
>> "recently" (I mean, at least 4-5 years, or even more), is still the
>> same since a long time (and it's very likely to stay the same), Sony
>
> hmmm this is true only in part, mainly for SNC hotkeys.

I was indeed referring to recent models ("the layout never really 
changed "recently"") using the SNC device for the hotkeys.

> All the S1/S2, speed/stamina and friends keys vary from model to model
> and sometimes send the same event for different keys.

So why are those keys are already fine in sony_100_events and never 
remapped by udev? I'm just talking about keys from SONYPI_EVENT_FNKEY_F1 
to SONYPI_EVENT_FNKEY_F12 though.

> lovely, does it make any difference if udev maps those keys and the
> driver instead just sends FN_F* making old and new models send the same
> keycodes and scancodes?

Models equipped with the SNC device are already using the same 
scancodes, there is no need to translate them twice.

 > you're a bit too optimistic here but well...

Maybe, but I don't think that Sony wants to deal with model specific 
layouts under Windows as well (in fact it seems to me that is shipping 
the same base software on every model).

Re: [PATCH 23/25] sony-laptop: add ALS support

[Mattia Dongili]

On Tue, Jun 07, 2011 at 01:26:06AM +0200, Marco Chiappero wrote:
> Il 07/06/2011 00:24, Mattia Dongili ha scritto:
> >>sony-acpid is already doing this without listening for key events
> >>(we can do that but we miss any other different backlight correction
> >>otherwise).
> >
> >how many sources of backlight changes do you have?
> 
> Potentially many, user keys, power saving options, proximity
> sensors, als, etc. and any other user defined (eg. low backlight
> setting when compiling software).
> 
> >A system should have
> >only one application trying to control the backlight, having more than
> >one is asking for trouble in the first place.
> 
> But it is not when using sony-acpid.

How do you coordinate different policies, one trying to increase and one
trying to decrease brightness?
Or even, say you have two sony-acpid-like applications working with
different policies, how do you solve that? Create another backlight
sysfs file that overrules the other two?
Do you see where I'm going? I think you're trying to slove a problem at
the bottom of the stack when it should be solved at the top.

> >Also, if I echo a number to /sys/... directly I would expect that to be
> >applied no matter what and without any magic correction going on.
> 
> Again another wrong assumption, IMO: if the user enables the
> autodimming feature everything should follow this rule. You are
> saying is that if you echo to sysfs, you really want to mess things
> up... really hard to believe.

possibly, I guess I just can't make my mind up about the fact that you
could set a backlight value via /sys/class/backlight/ that is not what
is going to applied.

> >>The small big issue is that not every notebook use the same LCD
> >>panel, so, in theory, different calculations are required (and this
> >>also the reason why a model specific parameter list is also provided
> >>by every Vaio notebook too). A single suboptimal formula for
> >>everybody is not likely to provide satisfactory results.
> >
> >this is something else that should be thought of presenting in a unified
> >way to userspace.
> 
> Frankly, I cannot see how, especially right now... We have some
> hardware designed in a certain way that allows to be used only in
> that way, small changes are possible, but I really doubt that what
> you are asking for is possible.

I don't see how presenting illumination data and correction factors and
giving a way to change lid backlight is such an unreasonable request.
Why do you think is not possible with als chips you find on vaios?

...
> >the backlight change request is initiated in userspace already,
> 
> Right, but how can you be sure when you have a backlight device that
> can be accessed by anything?

I'm not following you here. Sure about what? Also, is als_backlight only
accessible to a few privileged ones?

> >So again, can you split the patch in two so that we have the driver in
> >one patch and the interaction/integration part in another?
> 
> Please specify "interaction/integration part". There is almost
> nothing to be removed if you want code that makes sense and
> something working, if you specify a particular function I'll try to
> remove it, if it is feasible, otherwise be more specific, please.

I'd just like to see just the ALS driver in one patch, all the
managed/backlight stuff in another.

PS: to tell you the truth, I think the way Sony implemented all this
autodimming idea is just a clever workaround with limitations and
constraints they find in Windows where I guess they couldn't strip off
some of the standard acpi components. It has nothing to do with
hardware.
-- 
mattia
:wq!

Re: [PATCH 12/25] sony-laptop: input core improvements improvements

[Mattia Dongili]

On Tue, Jun 07, 2011 at 05:15:32PM +0200, Marco Chiappero wrote:
> Il 07/06/2011 16:23, Mattia Dongili ha scritto:
...
> >lovely, does it make any difference if udev maps those keys and the
> >driver instead just sends FN_F* making old and new models send the same
> >keycodes and scancodes?
> 
> Models equipped with the SNC device are already using the same
> scancodes, there is no need to translate them twice.

having the translation layer makes them consistent with all the other
hotkeys on all vaios.

> > you're a bit too optimistic here but well...
> 
> Maybe, but I don't think that Sony wants to deal with model specific
> layouts under Windows as well (in fact it seems to me that is
> shipping the same base software on every model).

one would hope so.

-- 
mattia
:wq!

Re: [PATCH 23/25] sony-laptop: add ALS support

[Marco Chiappero]

Il 07/06/2011 18:07, Mattia Dongili ha scritto:
> How do you coordinate different policies, one trying to increase and one
> trying to decrease brightness?

It depends on the purpose, if I just want to lower the brightness when 
I'm not in front of the notebook, I just do it, it doesn't conflict with 
the power saving options or the ambient light level. If I just want to 
write a shortcut that rises a bit the backlight level before calling my 
favorite video player I can do it, nothing is broken.

> Or even, say you have two sony-acpid-like applications working with
> different policies,

This makes no sense at all.

> Do you see where I'm going?

To a perfect design it's not there, with other side effects, that is 
likely to behave worse and arrive too late? I comprehend that the 
"unification" purpose is totally broken here and so on, but if you don't 
like this design, just drop this patch. I have nothing to say against 
better designs that works as good as this solution (yes, it works very 
good), but everything else is lacking and I doubt it to be possible, at 
least with certain models... maybe with some other models in the future, 
especially if an ACPI compliant sensor will be exposed. When everything 
will be ready and any issue solved...

>> Again another wrong assumption, IMO: if the user enables the
>> autodimming feature everything should follow this rule. You are
>> saying is that if you echo to sysfs, you really want to mess things
>> up... really hard to believe.
>
> possibly,

No way. Just an example: you set the backlight level to the minimum, 
then 2 seconds later there is an ambient light change and your setting 
is overwritten. It makes no sense to write directly to the "raw" 
backlight device when a potentially continuous regulation is present, 
you'll never want. You'd disable the autodimming feature, instead.

>>>> The small big issue is that not every notebook use the same LCD
>>>> panel, so, in theory, different calculations are required (and this
>>>> also the reason why a model specific parameter list is also provided
>>>> by every Vaio notebook too). A single suboptimal formula for
>>>> everybody is not likely to provide satisfactory results.
>>>
>>> this is something else that should be thought of presenting in a unified
>>> way to userspace.
>>
>> Frankly, I cannot see how, especially right now... We have some
>> hardware designed in a certain way that allows to be used only in
>> that way, small changes are possible, but I really doubt that what
>> you are asking for is possible.
>
> I don't see how presenting illumination data and correction factors and
> giving a way to change lid backlight is such an unreasonable request.

This is not an unreasonable request, and sony-acpid is exactly doing that.
Your request is to clone sony-acpid and merge it into every available DE 
(which still means that the "unification" or "interface" purpose is 
broken, because userspace have to know hardware/model specific details).

>> Right, but how can you be sure when you have a backlight device that
>> can be accessed by anything?
>
> I'm not following you here. Sure about what? Also, is als_backlight only
> accessible to a few privileged ones?

No, but what is supposed to use it?

>> Please specify "interaction/integration part". There is almost
>> nothing to be removed if you want code that makes sense and
>> something working, if you specify a particular function I'll try to
>> remove it, if it is feasible, otherwise be more specific, please.
>
> I'd just like to see just the ALS driver in one patch, all the
> managed/backlight stuff in another.

Conceptually there are two drivers... that said, do you mean any 
attribute with "all" and "stuff"? Splitting the patch will require a 
certain amount of work and will result in a broken patch. I'll try to do 
it, but I don't have much free time at the moment and I prefer to work 
on patches that have a chance to be included soon.

> PS: to tell you the truth, I think the way Sony implemented all this
> autodimming idea is just a clever workaround with limitations and
> constraints they find in Windows where I guess they couldn't strip off
> some of the standard acpi components.

To tell you the truth, I already thought of that... it might be true, 
but it's not that relevant since we cannot change the DSDT code.

> It has nothing to do with
> hardware.

Well, I do consider both a physical connection between the ALS and the 
EC and the BIOS code part of the hardware. I've never said that 
different hardware designs are not possible, I just said that "We have 
some hardware designed in a certain way that allows to be used only in 
that way".

Re: [PATCH 12/25] sony-laptop: input core improvements improvements

[Marco Chiappero]

Il 07/06/2011 18:24, Mattia Dongili ha scritto:
> On Tue, Jun 07, 2011 at 05:15:32PM +0200, Marco Chiappero wrote:
>> Il 07/06/2011 16:23, Mattia Dongili ha scritto:
> ...
>>> lovely, does it make any difference if udev maps those keys and the
>>> driver instead just sends FN_F* making old and new models send the same
>>> keycodes and scancodes?
>>
>> Models equipped with the SNC device are already using the same
>> scancodes, there is no need to translate them twice.
>
> having the translation layer makes them consistent with all the other
> hotkeys on all vaios.

In this case I can't see how consistency is relevant (especially if we 
think that it's a nonexistent layout!). Moreover every SNC equipped 
notebooks use the same map while SPIC related code is going to be 
deprecated.

Re: [PATCH 23/25] sony-laptop: add ALS support

[Mattia Dongili]

On Tue, Jun 07, 2011 at 07:50:35PM +0200, Marco Chiappero wrote:
> Il 07/06/2011 18:07, Mattia Dongili ha scritto:
> >How do you coordinate different policies, one trying to increase and one
> >trying to decrease brightness?
> 
> It depends on the purpose, if I just want to lower the brightness
> when I'm not in front of the notebook, I just do it, it doesn't
> conflict with the power saving options or the ambient light level.
> If I just want to write a shortcut that rises a bit the backlight
> level before calling my favorite video player I can do it, nothing
> is broken.
> 
> >Or even, say you have two sony-acpid-like applications working with
> >different policies,
> 
> This makes no sense at all.
> 
> >Do you see where I'm going?
> 
> To a perfect design it's not there, with other side effects, that is

not really. You're stripping my mails a lot...
I'm trying to demonstrate that the way you solved the multiple
brightness writers problem would not work or at least that your solution
as the same problem as the original issue.
Making the acpi_video sysfs nodes ineffective and creating an alternate
custom backlight regulation entry makes no sense and is a workaround
that is not needed.

[reshuffling the discussion a bit to bring pieces together]
> >>Right, but how can you be sure when you have a backlight device that
> >>can be accessed by anything?
> >
> >I'm not following you here. Sure about what? Also, is als_backlight only
> >accessible to a few privileged ones?
> 
> No, but what is supposed to use it?

anything can use it. The fact that for now there is only your deamon
using it doesn't mean that nothing else can use it. It's exactly the
same situation you have with the standard acpi video backlight
regulation where you say above you cannot be sure.

> >I don't see how presenting illumination data and correction factors and
> >giving a way to change lid backlight is such an unreasonable request.
> 
> This is not an unreasonable request, and sony-acpid is exactly doing that.
> Your request is to clone sony-acpid and merge it into every
> available DE (which still means that the "unification" or
> "interface" purpose is broken, because userspace have to know
> hardware/model specific details).

like what? if correction factors are provided what else is missing?
Do you also really think that DEs would not try to integrate the
function that sony-acpid is providing in their own framework?

...
> >>Please specify "interaction/integration part". There is almost
> >>nothing to be removed if you want code that makes sense and
> >>something working, if you specify a particular function I'll try to
> >>remove it, if it is feasible, otherwise be more specific, please.
> >
> >I'd just like to see just the ALS driver in one patch, all the
> >managed/backlight stuff in another.
> 
> Conceptually there are two drivers... that said, do you mean any
> attribute with "all" and "stuff"? Splitting the patch will require a
> certain amount of work and will result in a broken patch. I'll try
> to do it, but I don't have much free time at the moment and I prefer
> to work on patches that have a chance to be included soon.

actually having the two separate would make merging at least some of the
patch easier. I'm fine with the ALS driver (i.e. all the als_device_ops
and als_lux/power/kelvin) part. The whole als_backlight/managed mode I
wouldn't want to see merged as is. As I said before, I think we should
always set managed mode and intercept the GPE notifications sending an
(u?)event to userspace backlight changes and just chainging the
backlight when the user writes to
/sys/class/backlight/acpi_video/brightness.
A fine grained control is already provided with acpi_backlight=vendor,
potentially we could ask the acpi people to not take the device for
specific models or anyway a way to force the vendor driver to take over
backlight regulation without the need for a kernel parameter.

-- 
mattia
:wq!

Re: [PATCH 12/25] sony-laptop: input core improvements improvements

[Joey Lee]

於 六，2011-06-04 於 12:42 +0200，Marco Chiappero 提到：
> Il 04/06/2011 10:07, Mattia Dongili ha scritto:
> > On Fri, Jun 03, 2011 at 05:43:42PM +0200, Marco Chiappero wrote:
> >> The code is now forwarding the SW_RFKILL_ALL event; added a couple
> >
> > I don't think we should do this.
> 
> As far as I know this event should be forwarded and the rfkill-input 
> code removed as soon as there is enough userspace support. Another 

There already have a urfkill daemon on userland has good support
killswitch:
http://www.freedesktop.org/wiki/Software/urfkill

But, 
rfkill-input will not removed:
http://www.spinics.net/lists/linux-acpi/msg32465.html

The above information for you reference.


Thank's a lot!
Joey Lee

Re: [PATCH 12/25] sony-laptop: input core improvements improvements

[Joey Lee]

於 六，2011-06-04 於 12:42 +0200，Marco Chiappero 提到：
> Il 04/06/2011 10:07, Mattia Dongili ha scritto:
> > On Fri, Jun 03, 2011 at 05:43:42PM +0200, Marco Chiappero wrote:
> >> The code is now forwarding the SW_RFKILL_ALL event; added a couple
> >
> > I don't think we should do this.
> 
> As far as I know this event should be forwarded and the rfkill-input 
> code removed as soon as there is enough userspace support. Another 

There already have a urfkill daemon on userland has good support
killswitch:
http://www.freedesktop.org/wiki/Software/urfkill

But, 
rfkill-input will not removed:
http://www.spinics.net/lists/linux-acpi/msg32465.html

The above information for you reference.


Thank's a lot!
Joey Lee

Re: [PATCH 23/25] sony-laptop: add ALS support

[Marco Chiappero]

Il 08/06/2011 00:39, Mattia Dongili ha scritto:
>>> Do you see where I'm going?
>>
>> To a perfect design it's not there, with other side effects, that is
>
> not really.

Yeah, because it's not perfect at all...

> You're stripping my mails a lot...

Because there is no need to have tons of useless words in every mail. 
But if it's important for you, because you're unable to tell exactly 
where what's working and what's not, just cut and paste the "relevant" 
parts.

> I'm trying to demonstrate

absolutely nothing, apart being annoying.

> that the way you solved the multiple
> brightness writers problem would not work or at least that your solution
> as the same problem as the original issue.

I have my notebook here demonstrating that you are wrong, so, please, 
stop insisting. Once again, if you don't like the patch (for whatever 
reason), drop it and everything will be just fine. But stop insisting 
with wrong argumentations.

> Making the acpi_video sysfs nodes ineffective and creating an alternate
> custom backlight regulation entry makes no sense and is a workaround
> that is not needed.

Not quite right: those nodes will be always working while the 
autodimming feature is disabled, while when the feature is enabled they 
will work with the help of the daemon (they will always be effective).
That said, it makes a lot of sense (if you can't understand it, I'm 
sorry for you), I agree that it would be better not to have it (but it's 
the only downside and it's not that bad - but this doesn't seem to be 
relevant to you -), but has a lot of sense, and will make everything 
working in a much cleaner way than the one you're proposing, which comes 
with other drawbacks.

> [reshuffling the discussion a bit to bring pieces together]
>>>> Right, but how can you be sure when you have a backlight device that
>>>> can be accessed by anything?
>>>
>>> I'm not following you here. Sure about what? Also, is als_backlight only
>>> accessible to a few privileged ones?
>>
>> No, but what is supposed to use it?
>
> anything can use it. The fact that for now there is only your deamon
> using it doesn't mean that nothing else can use it. It's exactly the
> same situation you have with the standard acpi video backlight
> regulation where you say above you cannot be sure.

Not at all, because a backlight device is a standar interface known to 
everybody, while als_backlight is not (yes, it is relevant). Please, 
tell me, does, for example, gnome-power-manager use 
/sys/class/backlight/ or /sys/devices/platform/sony-laptop? No. So, 
again, please stop insisting with your pointless objections. The only 
thing you're demonstrating is that you had a different idea (that would 
be fine on different hardware, but not this one), no matter if it has 
downsides, no matter if this requires everything else to change, you had 
that idea and you refuse any other idea because it's not your idea. And 
you can't accept that someone else does not agree with your idea, 
otherwise you would not continue to try to demonstrate absolutely 
nothing, to tell that I don't see the problem and other pointless stuff 
about the top and the bottom. Nonetheless, it is fine, just say you 
don't like the patch and reject it. Stop.
I won't reply anymore about this, I've already explained a lot, I have 
no time to waste.

>>> I don't see how presenting illumination data and correction factors and
>>> giving a way to change lid backlight is such an unreasonable request.
>>
>> This is not an unreasonable request, and sony-acpid is exactly doing that.
>> Your request is to clone sony-acpid and merge it into every
>> available DE (which still means that the "unification" or
>> "interface" purpose is broken, because userspace have to know
>> hardware/model specific details).
>
> like what? if correction factors are provided what else is missing?
> Do you also really think that DEs would not try to integrate the
> function that sony-acpid is providing in their own framework?

DEs don't even have generic als support and are model agnostic, why 
should they all add and maintain (very) model specific code [1] in their 
programs? Are you sure they will? It makes no sense, we can have this 
code in a single place, with a really small daemon that will make the 
autodimming working even with no DE at all, and that will be installed 
only on machines that really need it. Far better than your "solution".

>>>> Please specify "interaction/integration part". There is almost
>>>> nothing to be removed if you want code that makes sense and
>>>> something working, if you specify a particular function I'll try to
>>>> remove it, if it is feasible, otherwise be more specific, please.
>>>
>>> I'd just like to see just the ALS driver in one patch, all the
>>> managed/backlight stuff in another.
>>
>> Conceptually there are two drivers... that said, do you mean any
>> attribute with "all" and "stuff"? Splitting the patch will require a
>> certain amount of work and will result in a broken patch. I'll try
>> to do it, but I don't have much free time at the moment and I prefer
>> to work on patches that have a chance to be included soon.
>
> actually having the two separate would make merging at least some of the
> patch easier.

As you like, but it makes no sense to merge something that will be useless.

> I'm fine with the ALS driver (i.e. all the als_device_ops
> and als_lux/power/kelvin) part. The whole als_backlight/managed mode I
> wouldn't want to see merged as is. As I said before, I think we should
> always set managed mode and intercept the GPE notifications sending an
> (u?)event to userspace backlight changes and just chainging the
> backlight when the user writes to
> /sys/class/backlight/acpi_video/brightness.
> A fine grained control is already provided with acpi_backlight=vendor,
> potentially we could ask the acpi people to not take the device for
> specific models or anyway a way to force the vendor driver to take over
> backlight regulation without the need for a kernel parameter.

To sum up your idea: quirks everywhere. Quirks for the backlight device 
(with a long list of models to be specified, that is likely to grow over 
the time), quirks everywhere in userspace with duplicated and hard to 
maintain code, ALS events always generated (I guess ignored when the 
user do not want the autodimming feature, which is very clean...). No, 
it does seem no way better to me. Everything else should change 
(worsening) just to let you have your design realized and make 
sony-laptop look good. We have a much smaller, cleaner and less invasive 
solution, that only partially affects sony-laptop and sony-laptop only. 
And we can have it now while now (we will see in the future if changes 
are possible) there is no other better solution.
In the end, take your decision, there is nothing more to say.


[1] they should detect the model type and use a specific parameter set 
with a specific formula.

Re: [PATCH 10/25] sony-laptop: keyboard backlight support extended to newer Vaios

[Marco Chiappero]

Il 04/06/2011 09:58, Mattia Dongili ha scritto:

>>   struct kbd_backlight {
>> -	int mode;
>> -	int timeout;
>> +	unsigned int base;
>> +	unsigned int mode;
>> +	unsigned int timeout;
>>   	struct device_attribute mode_attr;
>>   	struct device_attribute timeout_attr;
>>   };
>> -
>>   static struct kbd_backlight *kbdbl_handle;
>> +static int sony_kbd_handle = -1;
>
> there seems to be no real point initializing this to -1. Also, can it be
> made part of the struct above?

I'm including these two changes in every patch that provides a new 
capability using different handles.
I need some more time to prepare the new patches, but before resending 
I'd like to hear some more feedbacks: removing any acpi notification in 
patch #8, do patches from 1 to 9 look fine? Is it possible to merge 
them, as they are, as soon as I repost them? If some changes are 
required please let me know. I've also posted a patch fixing the "0x0" 
handle issue ("fix potential improper handle usage"), I suppose it to be 
okay, can I include it in my original source file before creating the 
patches? Or should I include that patch in the patchset instead?

Thanks

Re: [PATCH 2/25] sony-laptop: simple_strtoul replaced by strict_strtoul

[Mattia Dongili]

On Fri, Jun 03, 2011 at 05:28:08PM +0200, Marco Chiappero wrote:
> Any occurrence of simple_strtoul has been replaced with the better
> strict_strtoul.

you should probably say why it's better.

> Signed-off-by: Marco Chiappero <marco@absence.it>
> ---
> 
> --- a/drivers/platform/x86/sony-laptop.c
> +++ b/drivers/platform/x86/sony-laptop.c
> @@ -919,7 +919,8 @@ static ssize_t sony_nc_sysfs_store(struc
>  	if (count > 31)
>  		return -EINVAL;
> 
> -	value = simple_strtoul(buffer, NULL, 10);
> +	if (strict_strtoul(buffer, 10, &value))
> +		return -EINVAL;
> 
>  	if (item->validate)
>  		value = item->validate(SNC_VALIDATE_IN, value);
> @@ -2437,7 +2438,9 @@ static ssize_t sony_pic_wwanpower_store(
>  	if (count > 31)
>  		return -EINVAL;
> 
> -	value = simple_strtoul(buffer, NULL, 10);
> +	if (strict_strtoul(buffer, 10, &value))
> +		return -EINVAL;
> +
>  	mutex_lock(&spic_dev.lock);
>  	__sony_pic_set_wwanpower(value);
>  	mutex_unlock(&spic_dev.lock);
> @@ -2474,7 +2477,9 @@ static ssize_t sony_pic_bluetoothpower_s
>  	if (count > 31)
>  		return -EINVAL;
> 
> -	value = simple_strtoul(buffer, NULL, 10);
> +	if (strict_strtoul(buffer, 10, &value))
> +		return -EINVAL;
> +
>  	mutex_lock(&spic_dev.lock);
>  	__sony_pic_set_bluetoothpower(value);
>  	mutex_unlock(&spic_dev.lock);
> @@ -2513,7 +2518,9 @@ static ssize_t sony_pic_fanspeed_store(s
>  	if (count > 31)
>  		return -EINVAL;
> 
> -	value = simple_strtoul(buffer, NULL, 10);
> +	if (strict_strtoul(buffer, 10, &value))
> +		return -EINVAL;
> +
>  	if (sony_pic_set_fanspeed(value))
>  		return -EIO;
> --
> To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
mattia
:wq!

Re: [PATCH 4/25] sony-laptop: new SNC setup and cleanup functions

[Mattia Dongili]

On Fri, Jun 03, 2011 at 05:32:11PM +0200, Marco Chiappero wrote:
> New SNC setup and cleanup functions, sony_nc_snc_setup and
> sony_nc_snc_cleanup, to avoid eccessive tainting of sony_nc_add and
> sony_nc_remove, with cleaner and easier to read code, better event
> initialization and better error handling.
> 
> Signed-off-by: Marco Chiappero <marco@absence.it>
> ---
> 
> --- a/drivers/platform/x86/sony-laptop.c
> +++ b/drivers/platform/x86/sony-laptop.c
> @@ -1736,6 +1736,66 @@ static void sony_nc_backlight_cleanup(vo
>  		backlight_device_unregister(sony_bl_props.dev);
>  }
> 
> +static int sony_nc_snc_setup(struct platform_device *pd)

To be honest these sony_nc_snc_* functions are a bit poorly named.
sony_nc_ was already supposed to be a partial expansion of SNC so this
whole thing is a bit redundant now. what about
sony_nc_setup/sony_nc_cleanup?

> +{
> +	unsigned int i, string[4], bitmask, result;
> +
> +	for (i = 0; i < 4; i++) {
> +		if (acpi_callsetfunc(sony_nc_acpi_handle,
> +				"SN00", i, &string[i]))
> +			return -EIO;
> +	}
> +	if (strncmp("SncSupported", (char *) string, 0x10)) {
> +		pr_info("SNC device present but not supported by hardware");
> +		return -1;
> +	}

oh lord. For the record, this is:
	 Store (0x53636E53, Index (CFGI, Zero))
	 Store (0x6F707075, Index (CFGI, One))
	 Store (0x64657472, Index (CFGI, 0x02))

But does it ever happen that it's not supported? Also, not all models
seem to have those fields with exactly that string. I'd rather not have
this check here.

> +
> +	if (!acpi_callsetfunc(sony_nc_acpi_handle, "SN00", 0x04, &result)) {
> +		unsigned int model, i;
> +		for (model = 0, i = 0; i < 4; i++)
> +			model |= ((result >> (i * 8)) & 0xff) << ((3 - i) * 8);
> +		pr_info("found Vaio model ID: %u\n", model);
> +	}
> +
> +	/* retrieve the implemented offsets mask */
> +	if (acpi_callsetfunc(sony_nc_acpi_handle, "SN00", 0x10, &bitmask))
> +		return -EIO;

not all models seem to have this bitmask either, default to 0xffff as is
today if the call to SN00(0x10) returns an error please.

> +	/* retrieve the available handles, otherwise return */
> +	if (sony_nc_handles_setup(pd))
> +		return -2;

can't we just return the value from the function call instead of
-ENOENT?

> +
> +	/* setup found handles here */
> +	sony_nc_kbd_backlight_setup(pd);
> +	sony_nc_function_setup(sony_nc_acpi_device);
> +	sony_nc_rfkill_setup(sony_nc_acpi_device);
> +
> +	/* Enable all events for the found handles, otherwise return */
> +	if (acpi_callsetfunc(sony_nc_acpi_handle, "SN02", bitmask, &result))
> +		return -EIO;
> +
> +	return 0;
> +}
> +
> +static int sony_nc_snc_cleanup(struct platform_device *pd)
> +{
> +	unsigned int result, bitmask;
> +
> +	/* retrieve the event enabled handles */
> +	acpi_callgetfunc(sony_nc_acpi_handle, "SN01", &bitmask);
> +
> +	/* disable the event generation	for every handle */
> +	acpi_callsetfunc(sony_nc_acpi_handle, "SN03", bitmask, &result);
> +
> +	/* cleanup handles here */
> +	sony_nc_kbd_backlight_cleanup(pd);
> +	sony_nc_rfkill_cleanup();
> +
> +	sony_nc_handles_cleanup(pd);
> +
> +	return 0;
> +}
> +
>  static int sony_nc_add(struct acpi_device *device)
>  {
>  	acpi_status status;
> @@ -1783,21 +1843,16 @@ static int sony_nc_add(struct acpi_devic
>  	if (ACPI_SUCCESS(acpi_get_handle(sony_nc_acpi_handle, "SN00",
>  					 &handle))) {
>  		dprintk("Doing SNC setup\n");
> -		result = sony_nc_handles_setup(sony_pf_device);
> -		if (result)
> -			goto outpresent;
> -		result = sony_nc_kbd_backlight_setup(sony_pf_device);
> -		if (result)
> +
> +		if (sony_nc_snc_setup(sony_pf_device))
>  			goto outsnc;
> -		sony_nc_function_setup(device);
> -		sony_nc_rfkill_setup(device);
>  	}
> 
>  	/* setup input devices and helper fifo */
>  	result = sony_laptop_setup_input(device);
>  	if (result) {
>  		pr_err("Unable to create input devices\n");
> -		goto outkbdbacklight;
> +		goto outsnc;
>  	}
> 
>  	if (acpi_video_backlight_support()) {
> @@ -1855,17 +1910,13 @@ static int sony_nc_add(struct acpi_devic
> 
>  	sony_laptop_remove_input();
> 
> -      outkbdbacklight:
> -	sony_nc_kbd_backlight_cleanup(sony_pf_device);
> -
>        outsnc:
> -	sony_nc_handles_cleanup(sony_pf_device);
> +	sony_nc_snc_cleanup(sony_pf_device);
> 
>        outpresent:
>  	sony_pf_remove();
> 
>        outwalk:
> -	sony_nc_rfkill_cleanup();
>  	return result;
>  }
> 
> @@ -1881,11 +1932,9 @@ static int sony_nc_remove(struct acpi_de
>  		device_remove_file(&sony_pf_device->dev, &item->devattr);
>  	}
> 
> -	sony_nc_kbd_backlight_cleanup(sony_pf_device);
> -	sony_nc_handles_cleanup(sony_pf_device);
> +	sony_nc_snc_cleanup(sony_pf_device);
>  	sony_pf_remove();
>  	sony_laptop_remove_input();
> -	sony_nc_rfkill_cleanup();
>  	dprintk(SONY_NC_DRIVER_NAME " removed.\n");
> 
>  	return 0;
> --
> To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
mattia
:wq!

Re: [PATCH 10/25] sony-laptop: keyboard backlight support extended to newer Vaios

[Mattia Dongili]

On Fri, Jun 10, 2011 at 02:31:50PM +0200, Marco Chiappero wrote:
> Il 04/06/2011 09:58, Mattia Dongili ha scritto:
> 
> >>  struct kbd_backlight {
> >>-	int mode;
> >>-	int timeout;
> >>+	unsigned int base;
> >>+	unsigned int mode;
> >>+	unsigned int timeout;
> >>  	struct device_attribute mode_attr;
> >>  	struct device_attribute timeout_attr;
> >>  };
> >>-
> >>  static struct kbd_backlight *kbdbl_handle;
> >>+static int sony_kbd_handle = -1;
> >
> >there seems to be no real point initializing this to -1. Also, can it be
> >made part of the struct above?
> 
> I'm including these two changes in every patch that provides a new
> capability using different handles.
> I need some more time to prepare the new patches, but before
> resending I'd like to hear some more feedbacks: removing any acpi
> notification in patch #8, do patches from 1 to 9 look fine? Is it
> possible to merge them, as they are, as soon as I repost them? If

potentially, if they seem safe yes. I'd rather review what you have than
a stale version that you're already changing so please send the patches
over and then we'll see.

> some changes are required please let me know. I've also posted a
> patch fixing the "0x0" handle issue ("fix potential improper handle
> usage"), I suppose it to be okay, can I include it in my original
> source file before creating the patches? Or should I include that
> patch in the patchset instead?

either way, that patch is not compulsory for any of the functionalities
you posted.

-- 
mattia
:wq!

Re: [PATCH 4/25] sony-laptop: new SNC setup and cleanup functions

[Marco Chiappero]

Il 13/06/2011 00:21, Mattia Dongili ha scritto:
>> +static int sony_nc_snc_setup(struct platform_device *pd)
>
> To be honest these sony_nc_snc_* functions are a bit poorly named.
> sony_nc_ was already supposed to be a partial expansion of SNC so this
> whole thing is a bit redundant now. what about
> sony_nc_setup/sony_nc_cleanup?

Yes I know but in the hurry I forgot to think about that, I will use 
this new naming schema.

>> +{
>> +	unsigned int i, string[4], bitmask, result;
>> +
>> +	for (i = 0; i<  4; i++) {
>> +		if (acpi_callsetfunc(sony_nc_acpi_handle,
>> +				"SN00", i,&string[i]))
>> +			return -EIO;
>> +	}
>> +	if (strncmp("SncSupported", (char *) string, 0x10)) {
>> +		pr_info("SNC device present but not supported by hardware");
>> +		return -1;
>> +	}
>
> oh lord.

Could you please avoid pointless comments like the one above?

> For the record, this is:
> 	 Store (0x53636E53, Index (CFGI, Zero))
> 	 Store (0x6F707075, Index (CFGI, One))
> 	 Store (0x64657472, Index (CFGI, 0x02))

and Store (0x0100, Index (CFGI, 0x03))
It's a 16 bytes string.

> But does it ever happen that it's not supported?

Well, who knows, but I think it's there for a reason. I suppose that in 
the future the SNC can be removed or improved (eg. using more SN methods 
or more offsets), it might happen to see strings like "SncDeprecated" or 
"SncRevision2". Probably the error string I wrote is misleading.

> Also, not all models
> seem to have those fields with exactly that string.

For example? Let's find out their meaning (maybe "sncsupported" instead 
of "SncSupported"?) and have a better understanding, instead.

> I'd rather not have
> this check here.

Avoiding this check here seems a logical error to me: it's basically the 
entry point (and the first thing to look at when calling the setup 
method SN00), maybe revealing info about the device and the action to be 
taken about this device, I can't see why we'd better skip this step, 
that doesn't hurt, just because at the moment almost every notebook 
won't fail.

Re: [PATCH 4/25] sony-laptop: new SNC setup and cleanup functions

[Mattia Dongili]

On Mon, June 13, 2011 2:01 am, Marco Chiappero wrote:
> Il 13/06/2011 00:21, Mattia Dongili ha scritto:
...
>>> +{
>>> +	unsigned int i, string[4], bitmask, result;
>>> +
>>> +	for (i = 0; i<  4; i++) {
>>> +		if (acpi_callsetfunc(sony_nc_acpi_handle,
>>> +				"SN00", i,&string[i]))
>>> +			return -EIO;
>>> +	}
>>> +	if (strncmp("SncSupported", (char *) string, 0x10)) {
>>> +		pr_info("SNC device present but not supported by hardware");
>>> +		return -1;
>>> +	}
>>
>> oh lord.
>
> Could you please avoid pointless comments like the one above?

no. But you're lucky, you are free to ignore what you think is pointless.
And just because you seem to take things a bit too personally, the
exclamation
was aimed at whoever wrote that SncSupported string into the ACPI tables.

>> For the record, this is:
>> 	 Store (0x53636E53, Index (CFGI, Zero))
>> 	 Store (0x6F707075, Index (CFGI, One))
>> 	 Store (0x64657472, Index (CFGI, 0x02))
>
> and Store (0x0100, Index (CFGI, 0x03))
> It's a 16 bytes string.
>
>> But does it ever happen that it's not supported?
>
> Well, who knows, but I think it's there for a reason. I suppose that in
> the future the SNC can be removed or improved (eg. using more SN methods
> or more offsets), it might happen to see strings like "SncDeprecated" or
> "SncRevision2". Probably the error string I wrote is misleading.
>
>> Also, not all models
>> seem to have those fields with exactly that string.
>
> For example? Let's find out their meaning (maybe "sncsupported" instead
> of "SncSupported"?) and have a better understanding, instead.

I did a quick grep for 0x53636E53 and SN00 on the DSDTs I have at hand and
the
count didn't match. I can check more carefully later.

>> I'd rather not have
>> this check here.
>
> Avoiding this check here seems a logical error to me: it's basically the
> entry point (and the first thing to look at when calling the setup
> method SN00), maybe revealing info about the device and the action to be
> taken about this device, I can't see why we'd better skip this step,
> that doesn't hurt, just because at the moment almost every notebook
> won't fail.

the string never changes and there seems to be no logic associated to it
in the DSDT.
If the string is changed in some bios revision or gets removed you have to
change the driver.
We know what handles do and for now their behaviour is consistent
regardless of a meaningless string stored in the acpi tables. It's good to
know
the meaning of that part of the buffer but I see no reason why the driver
should
not initialize if the string is not there or doesn't match.

-- 
mattia
:wq!

Re: [PATCH 4/25] sony-laptop: new SNC setup and cleanup functions

[Marco Chiappero]

Il 13/06/2011 03:28, Mattia Dongili ha scritto:
> On Mon, June 13, 2011 2:01 am, Marco Chiappero wrote:
>> Il 13/06/2011 00:21, Mattia Dongili ha scritto:
> ...
>>>> +{
>>>> +	unsigned int i, string[4], bitmask, result;
>>>> +
>>>> +	for (i = 0; i<   4; i++) {
>>>> +		if (acpi_callsetfunc(sony_nc_acpi_handle,
>>>> +				"SN00", i,&string[i]))
>>>> +			return -EIO;
>>>> +	}
>>>> +	if (strncmp("SncSupported", (char *) string, 0x10)) {
>>>> +		pr_info("SNC device present but not supported by hardware");
>>>> +		return -1;
>>>> +	}
>>>
>>> oh lord.
>>
>> Could you please avoid pointless comments like the one above?
>
> no. But you're lucky, you are free to ignore what you think is pointless.
> And just because you seem to take things a bit too personally, the
> exclamation
> was aimed at whoever wrote that SncSupported string into the ACPI tables.

This way of writing is for me annoying, I don't care who you think is 
stupid here (or whatever that would mean), it's just not relevant, so 
avoid it. And no, I can't ignore it if I have to read the mail, you can 
instead avoid writing, it is not necessary for you to write everything 
you think.

>>> I'd rather not have
>>> this check here.
>>
>> Avoiding this check here seems a logical error to me: it's basically the
>> entry point (and the first thing to look at when calling the setup
>> method SN00), maybe revealing info about the device and the action to be
>> taken about this device, I can't see why we'd better skip this step,
>> that doesn't hurt, just because at the moment almost every notebook
>> won't fail.
>
> the string never changes and there seems to be no logic associated to it
> in the DSDT.

Well, maybe. Or maybe not. Every year lots of new models are launched, 
and every model comes with it... why should they bring a useless 
information? The fact that at the moment we have basically only one 
string it doesn't assure that there is no logic.

> If the string is changed in some bios revision or gets removed you have to
> change the driver.

Yes, it's surely the right thing to do:
- if it removed and nothing changes, well, we have the proof that this 
string is not relevant for Sony too, so it's likely to be useless (at 
least, today, maybe it was the past). As far as I can say every model 
I've seen do have this string, so it doesn't seem the case.
- if it changes we will immediately have the chance to find out if 
something else has changed too. But again, this change is likely to have 
a meaning that we should try to discover.

It is instead much less relevant the Vaio model information, that we 
should show only in debug mode, because it's currently used by the 
software for windows, but that allow us to look for a DSDT file just 
looking at that number.

Re: [PATCH 4/25] sony-laptop: new SNC setup and cleanup functions

[Mattia Dongili]

On Mon, Jun 13, 2011 at 11:39:09AM +0200, Marco Chiappero wrote:
> Il 13/06/2011 03:28, Mattia Dongili ha scritto:
> >On Mon, June 13, 2011 2:01 am, Marco Chiappero wrote:
> >>Il 13/06/2011 00:21, Mattia Dongili ha scritto:
...
> This way of writing is for me annoying, I don't care who you think

Let's try to lower the tone of emails. Maybe I missed a couple of
smilies here and there but hostility doesn't help anyone. :)

...
> >>>I'd rather not have
> >>>this check here.
> >>
> >>Avoiding this check here seems a logical error to me: it's basically the
> >>entry point (and the first thing to look at when calling the setup
> >>method SN00), maybe revealing info about the device and the action to be
> >>taken about this device, I can't see why we'd better skip this step,
> >>that doesn't hurt, just because at the moment almost every notebook
> >>won't fail.
> >
> >the string never changes and there seems to be no logic associated to it
> >in the DSDT.
> 
> Well, maybe. Or maybe not. Every year lots of new models are
> launched, and every model comes with it... why should they bring a

Apparently not. Vaio Y doesn't have that string hardcoded in the DSDT.

Again, not initializing the driver because a string doesn't match
SncSupported seems wrong. Especially given that if the string is there
or not makes no difference to us.
On the other hand I have nothing against fetching the string value
and printing some debug statement if really we can't just ignore it.

> useless information? The fact that at the moment we have basically
> only one string it doesn't assure that there is no logic.
> 
> >If the string is changed in some bios revision or gets removed you have to
> >change the driver.
> 
> Yes, it's surely the right thing to do:
> - if it removed and nothing changes, well, we have the proof that
> this string is not relevant for Sony too, so it's likely to be
> useless (at least, today, maybe it was the past). As far as I can
> say every model I've seen do have this string, so it doesn't seem
> the case.
> - if it changes we will immediately have the chance to find out if
> something else has changed too. But again, this change is likely to
> have a meaning that we should try to discover.

The net result is that a large part of the SNC driver doesn't
initialize, how is that the right thing to do?
Again, we know how to discover and use handles, that's enough for now as
far as we know.
-- 
mattia
:wq!

Re: [PATCH 4/25] sony-laptop: new SNC setup and cleanup functions

[Marco Chiappero]

Il 13/06/2011 15:42, Mattia Dongili ha scritto:

>>>>> I'd rather not have
>>>>> this check here.
>>>>
>>>> Avoiding this check here seems a logical error to me: it's basically the
>>>> entry point (and the first thing to look at when calling the setup
>>>> method SN00), maybe revealing info about the device and the action to be
>>>> taken about this device, I can't see why we'd better skip this step,
>>>> that doesn't hurt, just because at the moment almost every notebook
>>>> won't fail.
>>>
>>> the string never changes and there seems to be no logic associated to it
>>> in the DSDT.
>>
>> Well, maybe. Or maybe not. Every year lots of new models are
>> launched, and every model comes with it... why should they bring a
>
> Apparently not. Vaio Y doesn't have that string hardcoded in the DSDT.

Interesting, may I see such DSDT file?
It seem to fall into the case "if it removed and nothing changes, well, 
we have the proof that this string is not relevant for Sony too". 
However I'm still doubtful: why to remove it on just a single model if 
it's no longer necessary? Have you ever seen other models without that 
string?

> Again, not initializing the driver because a string doesn't match
> SncSupported seems wrong. Especially given that if the string is there
> or not makes no difference to us.

This is the point that I was trying to explain: are we sure? How can we 
be sure? If we are not sure, IMHO, we should add a check, just for 
safety, but I'd investigate before deciding (I have just a few DSDTs 
though). BTW, is the sole 0x53636E53 "substring" changing among 
different models? is it 0x73636E73 ("sncs" instead of "SncS")?

> On the other hand I have nothing against fetching the string value
> and printing some debug statement if really we can't just ignore it.

Ok ok... well, it wouldn't matter anymore even though it might mostly 
act as SNC "documentation" (we know what it means but we don't need it).

Re: [PATCH 10/25] sony-laptop: keyboard backlight support extended to newer Vaios

[Marco Chiappero]

Il 13/06/2011 00:24, Mattia Dongili ha scritto:
> On Fri, Jun 10, 2011 at 02:31:50PM +0200, Marco Chiappero wrote:
>> Il 04/06/2011 09:58, Mattia Dongili ha scritto:
>>
>>>>   struct kbd_backlight {
>>>> -	int mode;
>>>> -	int timeout;
>>>> +	unsigned int base;
>>>> +	unsigned int mode;
>>>> +	unsigned int timeout;
>>>>   	struct device_attribute mode_attr;
>>>>   	struct device_attribute timeout_attr;
>>>>   };
>>>> -
>>>>   static struct kbd_backlight *kbdbl_handle;
>>>> +static int sony_kbd_handle = -1;
>>>
>>> there seems to be no real point initializing this to -1. Also, can it be
>>> made part of the struct above?
>>
>> I'm including these two changes in every patch that provides a new
>> capability using different handles.
>> I need some more time to prepare the new patches, but before
>> resending I'd like to hear some more feedbacks: removing any acpi
>> notification in patch #8, do patches from 1 to 9 look fine? Is it
>> possible to merge them, as they are, as soon as I repost them? If
>
> potentially, if they seem safe yes. I'd rather review what you have than
> a stale version that you're already changing so please send the patches
> over and then we'll see.

Ok, to avoid multiple resends, does this new naming schema look fine to you?

/* Keyboard backlight feature */
static struct sony_kbdbl_data {
	unsigned int handle;
	unsigned int base;
	unsigned int mode;
	unsigned int timeout;
	struct device_attribute mode_attr;
	struct device_attribute timeout_attr;
} *sony_kbdbl;


Another example:

static struct sony_battcare_data {
	unsigned int handle;
	struct device_attribute attrs[2];
} *sony_battcare;


I think that we might use the sony_FEATURE_device namining when we have 
multiple data regarding a physical device rather than just a collection 
of data related to a feature, so sony_kbdbl_data could be named 
sony_kbdbl_device. If you don't like the "sony" prefix, which is not 
much informative, we can change to "snc", which specifies that it's a 
SNC related feature, even though it's already clear enough.
Sorry but I don't really like the current naming schema (using 
kbdbl_handle->handle or kbdbl_handle->snc_handle names doesn't look good 
to me); I'd like to hear comments on this, please.

Re: [PATCH 10/25] sony-laptop: keyboard backlight support extended to newer Vaios

[Mattia Dongili]

On Mon, Jun 13, 2011 at 04:28:15PM +0200, Marco Chiappero wrote:
> Il 13/06/2011 00:24, Mattia Dongili ha scritto:
> >On Fri, Jun 10, 2011 at 02:31:50PM +0200, Marco Chiappero wrote:
> >>Il 04/06/2011 09:58, Mattia Dongili ha scritto:
> >>
> >>>>  struct kbd_backlight {
> >>>>-	int mode;
> >>>>-	int timeout;
> >>>>+	unsigned int base;
> >>>>+	unsigned int mode;
> >>>>+	unsigned int timeout;
> >>>>  	struct device_attribute mode_attr;
> >>>>  	struct device_attribute timeout_attr;
> >>>>  };
> >>>>-
> >>>>  static struct kbd_backlight *kbdbl_handle;
> >>>>+static int sony_kbd_handle = -1;
> >>>
> >>>there seems to be no real point initializing this to -1. Also, can it be
> >>>made part of the struct above?
> >>
> >>I'm including these two changes in every patch that provides a new
> >>capability using different handles.
> >>I need some more time to prepare the new patches, but before
> >>resending I'd like to hear some more feedbacks: removing any acpi
> >>notification in patch #8, do patches from 1 to 9 look fine? Is it
> >>possible to merge them, as they are, as soon as I repost them? If
> >
> >potentially, if they seem safe yes. I'd rather review what you have than
> >a stale version that you're already changing so please send the patches
> >over and then we'll see.
> 
> Ok, to avoid multiple resends, does this new naming schema look fine to you?

I'd recommend sending what you have when you think it is reviewable. I
have the time I have to review all this and having some finished work is
easier to review.

> /* Keyboard backlight feature */
> static struct sony_kbdbl_data {
> 	unsigned int handle;
> 	unsigned int base;
> 	unsigned int mode;
> 	unsigned int timeout;
> 	struct device_attribute mode_attr;
> 	struct device_attribute timeout_attr;
> } *sony_kbdbl;
> 
> 
> Another example:
> 
> static struct sony_battcare_data {
> 	unsigned int handle;
> 	struct device_attribute attrs[2];
> } *sony_battcare;
> 
> 
> I think that we might use the sony_FEATURE_device namining when we
> have multiple data regarding a physical device rather than just a
> collection of data related to a feature, so sony_kbdbl_data could be
> named sony_kbdbl_device. If you don't like the "sony" prefix, which
> is not much informative, we can change to "snc", which specifies
> that it's a SNC related feature, even though it's already clear
> enough.

I'd prefer the snc prefix to distinguish it from the spic related
features.

Thanks
-- 
mattia
:wq!

Re: [PATCH 4/25] sony-laptop: new SNC setup and cleanup functions

[Marco Chiappero]

Il 13/06/2011 16:10, Marco Chiappero ha scritto:
> Il 13/06/2011 15:42, Mattia Dongili ha scritto:
>
>>>>>> I'd rather not have
>>>>>> this check here.
>>>>>
>>>>> Avoiding this check here seems a logical error to me: it's
>>>>> basically the
>>>>> entry point (and the first thing to look at when calling the setup
>>>>> method SN00), maybe revealing info about the device and the action
>>>>> to be
>>>>> taken about this device, I can't see why we'd better skip this step,
>>>>> that doesn't hurt, just because at the moment almost every notebook
>>>>> won't fail.
>>>>
>>>> the string never changes and there seems to be no logic associated
>>>> to it
>>>> in the DSDT.
>>>
>>> Well, maybe. Or maybe not. Every year lots of new models are
>>> launched, and every model comes with it... why should they bring a
>>
>> Apparently not. Vaio Y doesn't have that string hardcoded in the DSDT.
>
> Interesting, may I see such DSDT file?

I've seen the DSDT file, and I can say that almost surely (well, I'd say 
surely) this model comes with the same string, even though it's 
hardcoded in some hw register instead (the first bytes of CIM more 
precisely). My idea hasn't changed, I strongly suggest to maintain this 
check, if the string changes we will have the chance to immediately 
determine what changed, otherwise it won't harm.

Re: [PATCH 4/25] sony-laptop: new SNC setup and cleanup functions

[Marco Chiappero]

Il 13/06/2011 02:01, Marco Chiappero ha scritto:
> Il 13/06/2011 00:21, Mattia Dongili ha scritto:
>>> +static int sony_nc_snc_setup(struct platform_device *pd)
>>
>> To be honest these sony_nc_snc_* functions are a bit poorly named.
>> sony_nc_ was already supposed to be a partial expansion of SNC so this
>> whole thing is a bit redundant now. what about
>> sony_nc_setup/sony_nc_cleanup?
>
> Yes I know but in the hurry I forgot to think about that, I will use
> this new naming schema.

I've been rethinking about this, I was rather unhappy with the 
sony_nc_snc_setup_handles and sony_nc_handles_setup names. I think that 
the best solution is:
- to rename sony_nc_handles_setup to sony_nc_handles_list_setup
- to include the sony_nc_setup_handles code back to sony_nc_snc_setup 
and to rename this last one sony_nc_handles_setup, that should now deal 
with the sole handles (and handles events) setup. The same goes for the 
sony_nc_snc_resume and sony_nc_snc_cleanup functions.

Re: [PATCH 4/25] sony-laptop: new SNC setup and cleanup functions

[Marco Chiappero]

Il 13/06/2011 00:21, Mattia Dongili ha scritto:
> On Fri, Jun 03, 2011 at 05:32:11PM +0200, Marco Chiappero wrote:
>> +
>> +	/* retrieve the implemented offsets mask */
>> +	if (acpi_callsetfunc(sony_nc_acpi_handle, "SN00", 0x10,&bitmask))
>> +		return -EIO;
>
> not all models seem to have this bitmask either, default to 0xffff as is
> today if the call to SN00(0x10) returns an error please.

Are you sure about this? Not being present inside the DSDT doesn't 
necessarily mean that the this mask is not provided by the HW. I'm 
almost sure that the SN00 method has been designed at a certain point in 
time (the very beginning) and that is the same everywhere, for this reason.

Re: [PATCH 12/25] sony-laptop: input core improvements improvements

[Marco Chiappero]

Il 07/06/2011 19:59, Marco Chiappero ha scritto:
> Il 07/06/2011 18:24, Mattia Dongili ha scritto:
>> On Tue, Jun 07, 2011 at 05:15:32PM +0200, Marco Chiappero wrote:
>>> Il 07/06/2011 16:23, Mattia Dongili ha scritto:
>> ...
>>>> lovely, does it make any difference if udev maps those keys and the
>>>> driver instead just sends FN_F* making old and new models send the same
>>>> keycodes and scancodes?
>>>
>>> Models equipped with the SNC device are already using the same
>>> scancodes, there is no need to translate them twice.
>>
>> having the translation layer makes them consistent with all the other
>> hotkeys on all vaios.
>
> In this case I can't see how consistency is relevant (especially if we
> think that it's a nonexistent layout!). Moreover every SNC equipped
> notebooks use the same map while SPIC related code is going to be
> deprecated.

Mattia, what is your final decision about this topic? Would you like to 
maintain the KEY_FN_F* mapping?

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Marco Chiappero]

Il 06/06/2011 00:38, Mattia Dongili ha scritto:
> On Sat, Jun 04, 2011 at 01:26:28PM +0200, Marco Chiappero wrote:
>> Il 04/06/2011 10:43, Mattia Dongili ha scritto:
>>> when sony_call_snc_handle(handle, 0x200,&result) fails above you will
>>> be reporting -1 via the acpi bus. The old code restored the event and
>>> reported the raw number instead.
>>
>> You are right, does the following sony_nc_notify modification look
>> fine to you?
>>
>> /* hotkey event, a key has been pressed, retrieve it */
>> value = sony_nc_hotkeys_decode(handle);
>> if (value>  0) /* known event */
>> 	sony_laptop_report_input_event(value);
>> else /* restore the original event */
>> 	value = event;
>
> it's a bit out of context but I guess it should work.

Two things I'd like to ask:
1) can I remove any acpi bus notification from this patch?
2) if so, do you prefer sony_nc_hotkeys_decode to forward decoded keys 
to the input core directly instead of returning the decoded value back 
to sony_nc_notify?
I'm not sure about what you meant with "out of context", is the above 
point #2?

Re: [PATCH 22/25] sony-laptop: forward Hybrid GFX notifications to userspace

[Marco Chiappero]

Il 04/06/2011 10:48, Mattia Dongili ha scritto:
> On Fri, Jun 03, 2011 at 09:27:00PM +0200, Marco Chiappero wrote:
>> Some Vaios come with both integrated and discrete graphics, plus a
>> switch for choosing one of the two. When the switch position is
>> changed, a notification is generated, now forwarded to userspace for
>> example for visual notifications, user scripts, and so on.

[...]

>> +		case 0x0128:
>> +		case 0x0146:
>> +			/* Hybrid GFX switching, 1 */
>> +			sony_call_snc_handle(handle, 0x0000,&result);
>> +			dprintk("sony_nc_notify, Hybrid GFX event received "
>> +					"(reason: %s)\n", (result&  0x01) ?
>> +					"switch position change" : "unknown");
>> +
>> +			/* verify the switch state
>> +			   (1: discrete GFX, 0: integrated GFX)*/
>> +			result = 0;
>> +			sony_call_snc_handle(handle, 0x0100,&result);
>> +
>> +			ev = 5;
>> +			value = result&  0xff;
>> +			break;
>
> shouldn't this be reported as an input event rather than just an acpi
> one?

If so, please someone let me know which keys to use.

Re: [PATCH 4/25] sony-laptop: new SNC setup and cleanup functions

[Mattia Dongili]

Marco Chiappero <marco@absence.it> wrote:

>Il 13/06/2011 02:01, Marco Chiappero ha scritto:
>> Il 13/06/2011 00:21, Mattia Dongili ha scritto:
>>>> +static int sony_nc_snc_setup(struct platform_device *pd)
>>>
>>> To be honest these sony_nc_snc_* functions are a bit poorly named.
>>> sony_nc_ was already supposed to be a partial expansion of SNC so
>this
>>> whole thing is a bit redundant now. what about
>>> sony_nc_setup/sony_nc_cleanup?
>>
>> Yes I know but in the hurry I forgot to think about that, I will use
>> this new naming schema.
>
>I've been rethinking about this, I was rather unhappy with the 
>sony_nc_snc_setup_handles and sony_nc_handles_setup names. I think that
>
>the best solution is:
>- to rename sony_nc_handles_setup to sony_nc_handles_list_setup

This:
>- to include the sony_nc_setup_handles code back to sony_nc_snc_setup 

should be enough to disambiguate without gratuitously renaming all the other functions.

Again ị can only access my mail via a mobile phone for now so I hope I remember correctly what the whole discussion was about.

>and to rename this last one sony_nc_handles_setup, that should now deal
>
>with the sole handles (and handles events) setup. The same goes for the
>
>sony_nc_snc_resume and sony_nc_snc_cleanup functions.

-- 
Mattia

Re: [PATCH 4/25] sony-laptop: new SNC setup and cleanup functions

[Marco Chiappero]

Il 28/06/2011 11:27, Mattia Dongili ha scritto:
>
>
> Marco Chiappero<marco@absence.it>  wrote:
>
>> Il 13/06/2011 02:01, Marco Chiappero ha scritto:
>>> Il 13/06/2011 00:21, Mattia Dongili ha scritto:
>>>>> +static int sony_nc_snc_setup(struct platform_device *pd)
>>>>
>>>> To be honest these sony_nc_snc_* functions are a bit poorly named.
>>>> sony_nc_ was already supposed to be a partial expansion of SNC so
>> this
>>>> whole thing is a bit redundant now. what about
>>>> sony_nc_setup/sony_nc_cleanup?
>>>
>>> Yes I know but in the hurry I forgot to think about that, I will use
>>> this new naming schema.
>>
>> I've been rethinking about this, I was rather unhappy with the
>> sony_nc_snc_setup_handles and sony_nc_handles_setup names. I think that
>>
>> the best solution is:
>> - to rename sony_nc_handles_setup to sony_nc_handles_list_setup
>
> This:
>> - to include the sony_nc_setup_handles code back to sony_nc_snc_setup
>
> should be enough to disambiguate without gratuitously renaming all the other functions.

Yeah, but there are two issues:
1) sony_nc_add/resume/remove/notify are the ACPI callbacks that deal 
with the whole SNC stuff, while the sony_nc_setup/cleanup functions deal 
with the sole handles init and cleanup stuff. IMHO, this adds confusion.
2) we need an handles resume function but sony_nc_resume is already present.

Moreover the sony_nc_handles_list_* schema is much better and meaningful 
since those functions are related to the handles list.

so:
1) sony_nc_handles_* to sony_nc_handles_list_* --> handles list stuff
2) sony_nc_handles_* --> functions dealing with the handles 
setup/cleanup/resume stuff called from sony_nc_add/remove/resume (ACPI 
callbacks)

To get a better idea, have a look at this modified source, using the 
naming schema I'm proposing: 
http://www.absence.it/vaio-acpi/source/sony-laptop_dev_28062011.c
Hope this helps.

Re: [PATCH 4/25] sony-laptop: new SNC setup and cleanup functions

[Marco Chiappero]

Il 28/06/2011 12:04, Marco Chiappero ha scritto:
> To get a better idea, have a look at this modified source, using the
> naming schema I'm proposing:
> http://www.absence.it/vaio-acpi/source/sony-laptop_dev_28062011.c

I recently uploaded the first part (new features excluded) of my v2 
patches at http://www.absence.it/vaio-acpi/source/patches/patchset-v2/ 
to help you and receive new feedbacks. There is no description but the 
patches should be self explanatory to you. I'm still waiting for a few 
clarifications before sending them to the mailing list, so if something 
doesn't look good let me know.

Re: [PATCH 12/25] sony-laptop: input core improvements improvements

[Marco Chiappero]

Il 20/06/2011 15:53, Marco Chiappero ha scritto:

>> In this case I can't see how consistency is relevant (especially if we
>> think that it's a nonexistent layout!). Moreover every SNC equipped
>> notebooks use the same map while SPIC related code is going to be
>> deprecated.
>
> Mattia, what is your final decision about this topic? Would you like to
> maintain the KEY_FN_F* mapping?

About the hotkeys, there is one more thing to deal with: the touchpad 
enable Fn-F1 combo. Now, the easy solution (I don't like) is to let 
acpid run some script that writes to the touchpad attribute to 
enable/disable the touchpad when the combo is pressed. Of course this 
requires acpid and the acpi bus notifications we are about to remove. I 
think that the driver should perform this change, when that combo is 
pressed and handle 0x0148 is present. Any thoughts on this? I think we 
can't avoid providing this feature.

Re: [PATCH 12/25] sony-laptop: input core improvements improvements

[Matthew Garrett]

On Fri, Jul 01, 2011 at 01:12:03PM +0200, Marco Chiappero wrote:
> Il 20/06/2011 15:53, Marco Chiappero ha scritto:
> 
> >>In this case I can't see how consistency is relevant (especially if we
> >>think that it's a nonexistent layout!). Moreover every SNC equipped
> >>notebooks use the same map while SPIC related code is going to be
> >>deprecated.
> >
> >Mattia, what is your final decision about this topic? Would you like to
> >maintain the KEY_FN_F* mapping?
> 
> About the hotkeys, there is one more thing to deal with: the
> touchpad enable Fn-F1 combo. Now, the easy solution (I don't like)
> is to let acpid run some script that writes to the touchpad
> attribute to enable/disable the touchpad when the combo is pressed.
> Of course this requires acpid and the acpi bus notifications we are
> about to remove. I think that the driver should perform this change,
> when that combo is pressed and handle 0x0148 is present. Any
> thoughts on this? I think we can't avoid providing this feature.

We've standardised on doing this via the input layer.

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

Re: [PATCH 12/25] sony-laptop: input core improvements improvements

[Marco Chiappero]

Il 01/07/2011 14:50, Matthew Garrett ha scritto:
> On Fri, Jul 01, 2011 at 01:12:03PM +0200, Marco Chiappero wrote:
>> About the hotkeys, there is one more thing to deal with: the
>> touchpad enable Fn-F1 combo. Now, the easy solution (I don't like)
>> is to let acpid run some script that writes to the touchpad
>> attribute to enable/disable the touchpad when the combo is pressed.
>> Of course this requires acpid and the acpi bus notifications we are
>> about to remove. I think that the driver should perform this change,
>> when that combo is pressed and handle 0x0148 is present. Any
>> thoughts on this? I think we can't avoid providing this feature.
>
> We've standardised on doing this via the input layer.

Are you referring to 
KEY_TOUCHPAD_TOGGLE/KEY_TOUCHPAD_ON/KEY_TOUCHPAD_OFF? If so, we end up 
having two different unrelated controls.

Re: [PATCH 12/25] sony-laptop: input core improvements improvements

[Matthew Garrett]

On Fri, Jul 01, 2011 at 04:03:26PM +0200, Marco Chiappero wrote:
> Il 01/07/2011 14:50, Matthew Garrett ha scritto:
> >We've standardised on doing this via the input layer.
> 
> Are you referring to
> KEY_TOUCHPAD_TOGGLE/KEY_TOUCHPAD_ON/KEY_TOUCHPAD_OFF? If so, we end
> up having two different unrelated controls.

That's what I'm referring to, yes. I don't understand what you mean by 
unrelated controls.

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

Re: [PATCH 12/25] sony-laptop: input core improvements improvements

[Marco Chiappero]

Il 01/07/2011 16:09, Matthew Garrett ha scritto:
> On Fri, Jul 01, 2011 at 04:03:26PM +0200, Marco Chiappero wrote:
>> Il 01/07/2011 14:50, Matthew Garrett ha scritto:
>>> We've standardised on doing this via the input layer.
>>
>> Are you referring to
>> KEY_TOUCHPAD_TOGGLE/KEY_TOUCHPAD_ON/KEY_TOUCHPAD_OFF? If so, we end
>> up having two different unrelated controls.
>
> That's what I'm referring to, yes. I don't understand what you mean by
> unrelated controls.

The hardware stored setting touchpad on/off. The KEY_TOUCHPAD_TOGGLE 
input key can be used by userspace but how can userspace act on the 
hardware setting? And if the touchpad is disabled via hardware, pressing 
the combo will have no effect.

Re: [PATCH 12/25] sony-laptop: input core improvements improvements

[Matthew Garrett]

On Fri, Jul 01, 2011 at 04:20:06PM +0200, Marco Chiappero wrote:
> Il 01/07/2011 16:09, Matthew Garrett ha scritto:
> >That's what I'm referring to, yes. I don't understand what you mean by
> >unrelated controls.
> 
> The hardware stored setting touchpad on/off. The KEY_TOUCHPAD_TOGGLE
> input key can be used by userspace but how can userspace act on the
> hardware setting? And if the touchpad is disabled via hardware,
> pressing the combo will have no effect.

That's why the touchpad power needs to be exported in a standardised way 
so the synaptics driver can use it.

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

Re: [PATCH 12/25] sony-laptop: input core improvements improvements

[Marco Chiappero]

Il 01/07/2011 17:06, Matthew Garrett ha scritto:
> On Fri, Jul 01, 2011 at 04:20:06PM +0200, Marco Chiappero wrote:
>> The hardware stored setting touchpad on/off. The KEY_TOUCHPAD_TOGGLE
>> input key can be used by userspace but how can userspace act on the
>> hardware setting? And if the touchpad is disabled via hardware,
>> pressing the combo will have no effect.
>
> That's why the touchpad power needs to be exported in a standardised way
> so the synaptics driver can use it.

I just wanted to point out this issue until everything is in place.

Re: [PATCH 12/25] sony-laptop: input core improvements improvements

[Matthew Garrett]

On Fri, Jul 01, 2011 at 05:11:46PM +0200, Marco Chiappero wrote:
> Il 01/07/2011 17:06, Matthew Garrett ha scritto:
> >That's why the touchpad power needs to be exported in a standardised way
> >so the synaptics driver can use it.
> 
> I just wanted to point out this issue until everything is in place.

I'm not going to add any new acpi notifications. If you're ok with that 
then there's no problem - I just want it to be clear that we need a 
mechanism for doing this in a standardised way.

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

Re: [PATCH 12/25] sony-laptop: input core improvements improvements

[Marco Chiappero]

Il 01/07/2011 17:53, Matthew Garrett ha scritto:
> On Fri, Jul 01, 2011 at 05:11:46PM +0200, Marco Chiappero wrote:
>> Il 01/07/2011 17:06, Matthew Garrett ha scritto:
>>> That's why the touchpad power needs to be exported in a standardised way
>>> so the synaptics driver can use it.
>>
>> I just wanted to point out this issue until everything is in place.
>
> I'm not going to add any new acpi notifications. If you're ok with that
> then there's no problem - I just want it to be clear that we need a
> mechanism for doing this in a standardised way.

No doubt, don't get me wrong, I totally agree. I'm just saying I don't 
know how long it takes to have it implemented and I suppose that a user 
with the blue touchpad icon on the F1 key expects it to be working (more 
than owners of older models where there is no "hw" shortcut but only a 
software control), so I was just asking what to do in the meantime. Of 
course one possible way is to use acpid, not a good one though. So, we 
can change the hw state inside the driver when the combo is recognized 
and eventually move to a better solution later on. Or no support at all 
until we have that standard interface. The decision, of course, is up to 
you, I'm just posing the existence of this issue.

Re: [PATCH 4/25] sony-laptop: new SNC setup and cleanup functions

[Marco Chiappero]

Il 01/07/2011 12:54, Marco Chiappero ha scritto:
> Il 28/06/2011 12:04, Marco Chiappero ha scritto:
>> To get a better idea, have a look at this modified source, using the
>> naming schema I'm proposing:
>> http://www.absence.it/vaio-acpi/source/sony-laptop_dev_28062011.c
>
> I recently uploaded the first part (new features excluded) of my v2
> patches at http://www.absence.it/vaio-acpi/source/patches/patchset-v2/
> to help you and receive new feedbacks.

Still no feedbacks...

Re: [PATCH 4/25] sony-laptop: new SNC setup and cleanup functions

[Mattia Dongili]

On Thu, Jul 14, 2011 at 12:19:09AM +0200, Marco Chiappero wrote:
> Il 01/07/2011 12:54, Marco Chiappero ha scritto:
> >Il 28/06/2011 12:04, Marco Chiappero ha scritto:
> >>To get a better idea, have a look at this modified source, using the
> >>naming schema I'm proposing:
> >>http://www.absence.it/vaio-acpi/source/sony-laptop_dev_28062011.c
> >
> >I recently uploaded the first part (new features excluded) of my v2
> >patches at http://www.absence.it/vaio-acpi/source/patches/patchset-v2/
> >to help you and receive new feedbacks.
> 
> Still no feedbacks...

still not much time. what I noticed so far:
- patches are 14 instead of 25, any reason?
- still stopping handlers evaluation if the magi SncSupported string is
  not present
- the function naming in patch 5 looks ok.

Once again, post the patches here with proper description, it's easier
for everyone to review and comment the changes.
-- 
mattia
:wq!

Re: [PATCH 4/25] sony-laptop: new SNC setup and cleanup functions

[Marco Chiappero]

Il 15/07/2011 00:05, Mattia Dongili ha scritto:

>>> I recently uploaded the first part (new features excluded) of my v2
>>> patches at http://www.absence.it/vaio-acpi/source/patches/patchset-v2/
>>> to help you and receive new feedbacks.
>>
>> Still no feedbacks...
>
> still not much time. what I noticed so far:
> - patches are 14 instead of 25, any reason?

Because writing patches is time consuming. The first 14 patches include 
code cleaning/reorganization and improvements that can be merged 
immediately (if they look fine now), while the new features are a bit 
more problematic. Please, just review these 14 patches at the moment.

> - still stopping handlers evaluation if the magi SncSupported string is
>    not present

I do believe it's a good thing to have it. Do you prefer to drop the 
while patch #14 or just to change that check?

> - the function naming in patch 5 looks ok.

Do you wish to include the change from

	struct sony_nc_handles {
		u16 cap[0x10];
		struct device_attribute devattr;
	};

	static struct sony_nc_handles *handles;

to

	struct sony_nc_handles_list {
		u16 cap[0x10];
		struct device_attribute devattr;
	};

	static struct sony_nc_handles_list *handles;

as well?

> Once again, post the patches here with proper description, it's easier
> for everyone to review and comment the changes.

I'm still waiting for a few replies [1], I'd rather avoid spending time 
to send the patches twice. As soon as everything look fine (we are 
close) I will send the patches again.


[1]
http://www.spinics.net/lists/platform-driver-x86/msg02214.html
http://www.spinics.net/lists/platform-driver-x86/msg02213.html
(and possibly 
http://www.spinics.net/lists/platform-driver-x86/msg02216.html)

Re: [PATCH 12/25] sony-laptop: input core improvements improvements

[Mattia Dongili]

On Mon, Jun 20, 2011 at 03:53:31PM +0200, Marco Chiappero wrote:
> Il 07/06/2011 19:59, Marco Chiappero ha scritto:
> >Il 07/06/2011 18:24, Mattia Dongili ha scritto:
> >>On Tue, Jun 07, 2011 at 05:15:32PM +0200, Marco Chiappero wrote:
> >>>Il 07/06/2011 16:23, Mattia Dongili ha scritto:
> >>...
> >>>>lovely, does it make any difference if udev maps those keys and the
> >>>>driver instead just sends FN_F* making old and new models send the same
> >>>>keycodes and scancodes?
> >>>
> >>>Models equipped with the SNC device are already using the same
> >>>scancodes, there is no need to translate them twice.
> >>
> >>having the translation layer makes them consistent with all the other
> >>hotkeys on all vaios.
> >
> >In this case I can't see how consistency is relevant (especially if we
> >think that it's a nonexistent layout!). Moreover every SNC equipped
> >notebooks use the same map while SPIC related code is going to be
> >deprecated.
> 
> Mattia, what is your final decision about this topic? Would you like
> to maintain the KEY_FN_F* mapping?

yes, there is no need to change them now.
-- 
mattia
:wq!

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Mattia Dongili]

On Mon, Jun 20, 2011 at 04:00:16PM +0200, Marco Chiappero wrote:
> Il 06/06/2011 00:38, Mattia Dongili ha scritto:
> >On Sat, Jun 04, 2011 at 01:26:28PM +0200, Marco Chiappero wrote:
> >>Il 04/06/2011 10:43, Mattia Dongili ha scritto:
> >>>when sony_call_snc_handle(handle, 0x200,&result) fails above you will
> >>>be reporting -1 via the acpi bus. The old code restored the event and
> >>>reported the raw number instead.
> >>
> >>You are right, does the following sony_nc_notify modification look
> >>fine to you?
> >>
> >>/* hotkey event, a key has been pressed, retrieve it */
> >>value = sony_nc_hotkeys_decode(handle);
> >>if (value>  0) /* known event */
> >>	sony_laptop_report_input_event(value);
> >>else /* restore the original event */
> >>	value = event;
> >
> >it's a bit out of context but I guess it should work.
> 
> Two things I'd like to ask:
> 1) can I remove any acpi bus notification from this patch?

no. Just leave the current ones and don't add any new one.

> 2) if so, do you prefer sony_nc_hotkeys_decode to forward decoded
> keys to the input core directly instead of returning the decoded
> value back to sony_nc_notify?

feel free to propose your solution.

-- 
mattia
:wq!

Re: [PATCH 22/25] sony-laptop: forward Hybrid GFX notifications to userspace

[Mattia Dongili]

On Mon, Jun 20, 2011 at 11:12:50PM +0200, Marco Chiappero wrote:
> Il 04/06/2011 10:48, Mattia Dongili ha scritto:
> >On Fri, Jun 03, 2011 at 09:27:00PM +0200, Marco Chiappero wrote:
> >>Some Vaios come with both integrated and discrete graphics, plus a
> >>switch for choosing one of the two. When the switch position is
> >>changed, a notification is generated, now forwarded to userspace for
> >>example for visual notifications, user scripts, and so on.
> 
> [...]
> 
> >>+		case 0x0128:
> >>+		case 0x0146:
> >>+			/* Hybrid GFX switching, 1 */
> >>+			sony_call_snc_handle(handle, 0x0000,&result);
> >>+			dprintk("sony_nc_notify, Hybrid GFX event received "
> >>+					"(reason: %s)\n", (result&  0x01) ?
> >>+					"switch position change" : "unknown");
> >>+
> >>+			/* verify the switch state
> >>+			   (1: discrete GFX, 0: integrated GFX)*/
> >>+			result = 0;
> >>+			sony_call_snc_handle(handle, 0x0100,&result);
> >>+
> >>+			ev = 5;
> >>+			value = result&  0xff;
> >>+			break;
> >
> >shouldn't this be reported as an input event rather than just an acpi
> >one?
> 
> If so, please someone let me know which keys to use.

the speed/stamina switch is not very useful at the moment as we can't do
anything with it anyway. There is probably no need to send the event to
userspace at all for now. Else a new switch event should be defined for
this.

-- 
mattia
:wq!

Re: [PATCH 4/25] sony-laptop: new SNC setup and cleanup functions

[Mattia Dongili]

On Mon, Jul 18, 2011 at 04:49:08PM +0200, Marco Chiappero wrote:
> Il 15/07/2011 00:05, Mattia Dongili ha scritto:
> 
> >>>I recently uploaded the first part (new features excluded) of my v2
> >>>patches at http://www.absence.it/vaio-acpi/source/patches/patchset-v2/
> >>>to help you and receive new feedbacks.
> >>
> >>Still no feedbacks...
> >
> >still not much time. what I noticed so far:
> >- patches are 14 instead of 25, any reason?
> 
> Because writing patches is time consuming. The first 14 patches
> include code cleaning/reorganization and improvements that can be
> merged immediately (if they look fine now), while the new features
> are a bit more problematic. Please, just review these 14 patches at
> the moment.

send the patches to the mailing list please. There are more eyes
watching, they are archived and they can be quoted in emails.

> >- still stopping handlers evaluation if the magi SncSupported string is
> >   not present
> 
> I do believe it's a good thing to have it. Do you prefer to drop the
> while patch #14 or just to change that check?

I thought I made it clear already. Stopping evaluation of handlers will
break things and make the driver less maintainable. If you want to print
a debug message about SncSupported is up to you. I don't mind.

> >- the function naming in patch 5 looks ok.
> 
> Do you wish to include the change from
> 
> 	struct sony_nc_handles {
> 		u16 cap[0x10];
> 		struct device_attribute devattr;
> 	};
> 
> 	static struct sony_nc_handles *handles;
> 
> to
> 
> 	struct sony_nc_handles_list {
> 		u16 cap[0x10];
> 		struct device_attribute devattr;
> 	};
> 
> 	static struct sony_nc_handles_list *handles;
> 
> as well?
> 
> >Once again, post the patches here with proper description, it's easier
> >for everyone to review and comment the changes.
> 
> I'm still waiting for a few replies [1], I'd rather avoid spending

You've got your replies now, for the rest propose your solutions.
-- 
mattia
:wq!