* [GIT PULL] ibm-acpi changes acpi-test/2.6.22
@ 2007-03-12 0:20 Henrique de Moraes Holschuh
2007-03-12 0:20 ` [PATCH 1/6] ACPI: ibm-acpi: kill trailing whitespace Henrique de Moraes Holschuh
2007-03-12 0:54 ` [GIT PULL] ibm-acpi changes acpi-test/2.6.22 Len Brown
0 siblings, 2 replies; 60+ messages in thread
From: Henrique de Moraes Holschuh @ 2007-03-12 0:20 UTC (permalink / raw)
To: lenb-DgEjT+Ai2ygdnm+yROfE0A
Cc: linux-acpi-u79uwXL29TY76Z2rM5mHXA,
ibm-acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Len,
Please pull from:
git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
branch for-upstream/acpi-test
to receive the following patches:
ACPI: ibm-acpi: kill trailing whitespace
ACPI: ibm-acpi: rename some identifiers
ACPI: ibm-acpi: add header file
ACPI: ibm-acpi: organize code
ACPI: ibm-acpi: update copyright notice
ACPI: ibm-acpi: update documentation
Please merge them into acpi-test, targetting 2.6.22.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
^ permalink raw reply [flat|nested] 60+ messages in thread* [PATCH 1/6] ACPI: ibm-acpi: kill trailing whitespace 2007-03-12 0:20 [GIT PULL] ibm-acpi changes acpi-test/2.6.22 Henrique de Moraes Holschuh @ 2007-03-12 0:20 ` Henrique de Moraes Holschuh [not found] ` <11736588493322-git-send-email-hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org> 2007-03-12 0:54 ` [GIT PULL] ibm-acpi changes acpi-test/2.6.22 Len Brown 1 sibling, 1 reply; 60+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-12 0:20 UTC (permalink / raw) To: lenb; +Cc: linux-acpi, ibm-acpi-devel, Henrique de Moraes Holschuh I shall protect the ibm-acpi city against the invasion of the barbarian blanks! To the unforgiving jaws of sed s/[[:blank:]]\+$// they go! Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> --- Documentation/ibm-acpi.txt | 6 +++--- drivers/acpi/ibm_acpi.c | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/ibm-acpi.txt b/Documentation/ibm-acpi.txt index 0132d36..cdcef01 100644 --- a/Documentation/ibm-acpi.txt +++ b/Documentation/ibm-acpi.txt @@ -21,7 +21,7 @@ detailed description): - Fn key combinations - Bluetooth enable and disable - - video output switching, expansion control + - video output switching, expansion control - ThinkLight on and off - limited docking and undocking - UltraBay eject @@ -472,7 +472,7 @@ This feature dumps the values of 256 embedded controller registers. Values which have changed since the last time the registers were dumped are marked with a star: -[root@x40 ibm-acpi]# cat /proc/acpi/ibm/ecdump +[root@x40 ibm-acpi]# cat /proc/acpi/ibm/ecdump EC +00 +01 +02 +03 +04 +05 +06 +07 +08 +09 +0a +0b +0c +0d +0e +0f EC 0x00: a7 47 87 01 fe 96 00 08 01 00 cb 00 00 00 40 00 EC 0x10: 00 00 ff ff f4 3c 87 09 01 ff 42 01 ff ff 0d 00 @@ -503,7 +503,7 @@ vary. The second ensures that the fan-related values do vary, since the fan speed fluctuates a bit. The third will (hopefully) mark the fan register with a star: -[root@x40 ibm-acpi]# cat /proc/acpi/ibm/ecdump +[root@x40 ibm-acpi]# cat /proc/acpi/ibm/ecdump EC +00 +01 +02 +03 +04 +05 +06 +07 +08 +09 +0a +0b +0c +0d +0e +0f EC 0x00: a7 47 87 01 fe 96 00 08 01 00 cb 00 00 00 40 00 EC 0x10: 00 00 ff ff f4 3c 87 09 01 ff 42 01 ff ff 0d 00 diff --git a/drivers/acpi/ibm_acpi.c b/drivers/acpi/ibm_acpi.c index 3690136..a889dc5 100644 --- a/drivers/acpi/ibm_acpi.c +++ b/drivers/acpi/ibm_acpi.c @@ -28,7 +28,7 @@ * 2006-11-22 0.13 new maintainer * changelog now lives in git commit history, and will * not be updated further in-file. - * + * * 2005-08-17 0.12 fix compilation on 2.6.13-rc kernels * 2005-03-17 0.11 support for 600e, 770x * thanks to Jamie Lentin <lentinj@dial.pipex.com> @@ -38,7 +38,7 @@ * experimental brightness control * experimental volume control * experimental fan enable/disable - * 2005-01-16 0.10 fix module loading on R30, R31 + * 2005-01-16 0.10 fix module loading on R30, R31 * 2005-01-16 0.9 support for 570, R30, R31 * ultrabay support on A22p, A3x * limit arg for cmos, led, beep, drop experimental status @@ -161,7 +161,7 @@ IBM_HANDLE(dock, root, "\\_SB.GDCK", /* X30, X31, X40 */ #ifdef CONFIG_ACPI_IBM_BAY IBM_HANDLE(bay, root, "\\_SB.PCI.IDE.SECN.MAST", /* 570 */ "\\_SB.PCI0.IDE0.IDES.IDSM", /* 600e/x, 770e, 770x */ - "\\_SB.PCI0.SATA.SCND.MSTR", /* T60, X60, Z60 */ + "\\_SB.PCI0.SATA.SCND.MSTR", /* T60, X60, Z60 */ "\\_SB.PCI0.IDE0.SCND.MSTR", /* all others */ ); /* A21e, R30, R31 */ -- 1.5.0.3 ^ permalink raw reply related [flat|nested] 60+ messages in thread
[parent not found: <11736588493322-git-send-email-hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>]
* [PATCH 2/6] ACPI: ibm-acpi: rename some identifiers [not found] ` <11736588493322-git-send-email-hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org> @ 2007-03-12 0:20 ` Henrique de Moraes Holschuh [not found] ` <11736588491476-git-send-email-hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org> 0 siblings, 1 reply; 60+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-12 0:20 UTC (permalink / raw) To: lenb-DgEjT+Ai2ygdnm+yROfE0A Cc: linux-acpi-u79uwXL29TY76Z2rM5mHXA, Henrique de Moraes Holschuh, ibm-acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Rename some identifiers so that they are more in tune with the rest of the driver code, or less generic. Signed-off-by: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org> --- drivers/acpi/ibm_acpi.c | 43 ++++++++++++++++++++++++------------------- 1 files changed, 24 insertions(+), 19 deletions(-) diff --git a/drivers/acpi/ibm_acpi.c b/drivers/acpi/ibm_acpi.c index a889dc5..3363eda 100644 --- a/drivers/acpi/ibm_acpi.c +++ b/drivers/acpi/ibm_acpi.c @@ -506,7 +506,7 @@ static int ibm_acpi_driver_init(void) return 0; } -static int driver_read(char *p) +static int ibm_acpi_driver_read(char *p) { int len = 0; @@ -1310,9 +1310,9 @@ static const int led_exp_hlbl[] = { 0, 0, 1 }; /* led# * */ static const int led_exp_hlcl[] = { 0, 1, 1 }; /* led# * */ static const int led_led_arg1[] = { 0, 0x80, 0xc0 }; -#define EC_HLCL 0x0c -#define EC_HLBL 0x0d -#define EC_HLMS 0x0e +#define IBMACPI_LED_EC_HLCL 0x0c +#define IBMACPI_LED_EC_HLBL 0x0d +#define IBMACPI_LED_EC_HLMS 0x0e static int led_write(char *buf) { @@ -1344,13 +1344,15 @@ static int led_write(char *buf) } else if (led_supported == IBMACPI_LED_OLD) { /* 600e/x, 770e, 770x, A21e, A2xm/p, T20-22, X20 */ led = 1 << led; - ret = ec_write(EC_HLMS, led); + ret = ec_write(IBMACPI_LED_EC_HLMS, led); if (ret >= 0) ret = - ec_write(EC_HLBL, led * led_exp_hlbl[ind]); + ec_write(IBMACPI_LED_EC_HLBL, + led * led_exp_hlbl[ind]); if (ret >= 0) ret = - ec_write(EC_HLCL, led * led_exp_hlcl[ind]); + ec_write(IBMACPI_LED_EC_HLCL, + led * led_exp_hlcl[ind]); if (ret < 0) return ret; } else { @@ -1657,8 +1659,8 @@ static int brightness_read(char *p) return len; } -#define BRIGHTNESS_UP 4 -#define BRIGHTNESS_DOWN 5 +#define TP_CMOS_BRIGHTNESS_UP 4 +#define TP_CMOS_BRIGHTNESS_DOWN 5 static int brightness_set(int value) { @@ -1667,7 +1669,8 @@ static int brightness_set(int value) value &= 7; - cmos_cmd = value > current_value ? BRIGHTNESS_UP : BRIGHTNESS_DOWN; + cmos_cmd = value > current_value ? + TP_CMOS_BRIGHTNESS_UP : TP_CMOS_BRIGHTNESS_DOWN; inc = value > current_value ? 1 : -1; for (i = current_value; i != value; i += inc) { if (!cmos_eval(cmos_cmd)) @@ -1769,9 +1772,9 @@ static int volume_read(char *p) return len; } -#define VOLUME_DOWN 0 -#define VOLUME_UP 1 -#define VOLUME_MUTE 2 +#define TP_CMOS_VOLUME_DOWN 0 +#define TP_CMOS_VOLUME_UP 1 +#define TP_CMOS_VOLUME_MUTE 2 static int volume_write(char *buf) { @@ -1805,7 +1808,8 @@ static int volume_write(char *buf) return -EINVAL; if (new_level != level) { /* mute doesn't change */ - cmos_cmd = new_level > level ? VOLUME_UP : VOLUME_DOWN; + cmos_cmd = new_level > level ? + TP_CMOS_VOLUME_UP : TP_CMOS_VOLUME_DOWN; inc = new_level > level ? 1 : -1; if (mute && (!cmos_eval(cmos_cmd) || @@ -1817,14 +1821,15 @@ static int volume_write(char *buf) !acpi_ec_write(volume_offset, i + inc)) return -EIO; - if (mute && (!cmos_eval(VOLUME_MUTE) || + if (mute && (!cmos_eval(TP_CMOS_VOLUME_MUTE) || !acpi_ec_write(volume_offset, new_level + mute))) return -EIO; } if (new_mute != mute) { /* level doesn't change */ - cmos_cmd = new_mute ? VOLUME_MUTE : VOLUME_UP; + cmos_cmd = new_mute ? + TP_CMOS_VOLUME_MUTE : TP_CMOS_VOLUME_UP; if (!cmos_eval(cmos_cmd) || !acpi_ec_write(volume_offset, level + new_mute)) @@ -2315,7 +2320,7 @@ static struct ibm_struct ibms[] = { { .name = "driver", .init = ibm_acpi_driver_init, - .read = driver_read, + .read = ibm_acpi_driver_read, }, { .name = "hotkey", @@ -2529,7 +2534,7 @@ static int __init ibm_device_add(struct acpi_device *device) return 0; } -static int __init register_driver(struct ibm_struct *ibm) +static int __init register_ibmacpi_subdriver(struct ibm_struct *ibm) { int ret; @@ -2562,7 +2567,7 @@ static int __init ibm_init(struct ibm_struct *ibm) return 0; if (ibm->hid) { - ret = register_driver(ibm); + ret = register_ibmacpi_subdriver(ibm); if (ret < 0) return ret; ibm->driver_registered = 1; -- 1.5.0.3 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ^ permalink raw reply related [flat|nested] 60+ messages in thread
[parent not found: <11736588491476-git-send-email-hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>]
* [PATCH 3/6] ACPI: ibm-acpi: add header file [not found] ` <11736588491476-git-send-email-hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org> @ 2007-03-12 0:20 ` Henrique de Moraes Holschuh [not found] ` <11736588493502-git-send-email-hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org> 0 siblings, 1 reply; 60+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-12 0:20 UTC (permalink / raw) To: lenb-DgEjT+Ai2ygdnm+yROfE0A Cc: linux-acpi-u79uwXL29TY76Z2rM5mHXA, Henrique de Moraes Holschuh, ibm-acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Add a (private) header file for ibm-acpi, and move type definitions and ThinkPad driver constants to the new header file. This patch has no functional changes. Signed-off-by: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org> --- drivers/acpi/ibm_acpi.c | 137 +--------------- drivers/acpi/ibm_acpi.h | 437 +++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 438 insertions(+), 136 deletions(-) create mode 100644 drivers/acpi/ibm_acpi.h diff --git a/drivers/acpi/ibm_acpi.c b/drivers/acpi/ibm_acpi.c index 3363eda..59cbafc 100644 --- a/drivers/acpi/ibm_acpi.c +++ b/drivers/acpi/ibm_acpi.c @@ -78,44 +78,13 @@ * 2004-08-09 0.1 initial release, support for X series */ -#include <linux/kernel.h> -#include <linux/module.h> -#include <linux/init.h> -#include <linux/types.h> -#include <linux/string.h> - -#include <linux/proc_fs.h> -#include <linux/backlight.h> -#include <linux/fb.h> -#include <asm/uaccess.h> - -#include <linux/dmi.h> -#include <linux/jiffies.h> -#include <linux/workqueue.h> - -#include <acpi/acpi_drivers.h> -#include <acpi/acnamesp.h> - -#define IBM_NAME "ibm" -#define IBM_DESC "IBM ThinkPad ACPI Extras" -#define IBM_FILE "ibm_acpi" -#define IBM_URL "http://ibm-acpi.sf.net/" +#include "ibm_acpi.h" MODULE_AUTHOR("Borislav Deianov, Henrique de Moraes Holschuh"); MODULE_DESCRIPTION(IBM_DESC); MODULE_VERSION(IBM_VERSION); MODULE_LICENSE("GPL"); -#define IBM_DIR IBM_NAME - -#define IBM_LOG IBM_FILE ": " -#define IBM_ERR KERN_ERR IBM_LOG -#define IBM_NOTICE KERN_NOTICE IBM_LOG -#define IBM_INFO KERN_INFO IBM_LOG -#define IBM_DEBUG KERN_DEBUG IBM_LOG - -#define IBM_MAX_ACPI_ARGS 3 - #define __unused __attribute__ ((unused)) static int experimental; @@ -207,22 +176,6 @@ IBM_HANDLE(sfan, ec, "SFAN", /* 570 */ "JFNS", /* 770x-JL */ ); /* all others */ -#define IBM_HKEY_HID "IBM0068" -#define IBM_PCI_HID "PNP0A03" - -enum thermal_access_mode { - IBMACPI_THERMAL_NONE = 0, /* No thermal support */ - IBMACPI_THERMAL_ACPI_TMP07, /* Use ACPI TMP0-7 */ - IBMACPI_THERMAL_ACPI_UPDT, /* Use ACPI TMP0-7 with UPDT */ - IBMACPI_THERMAL_TPEC_8, /* Use ACPI EC regs, 8 sensors */ - IBMACPI_THERMAL_TPEC_16, /* Use ACPI EC regs, 16 sensors */ -}; - -#define IBMACPI_MAX_THERMAL_SENSORS 16 /* Max thermal sensors supported */ -struct ibm_thermal_sensors_struct { - s32 temp[IBMACPI_MAX_THERMAL_SENSORS]; -}; - /* * FAN ACCESS MODES * @@ -323,72 +276,12 @@ struct ibm_thermal_sensors_struct { * but the ACPI tables just mention level 7. */ -enum fan_status_access_mode { - IBMACPI_FAN_NONE = 0, /* No fan status or control */ - IBMACPI_FAN_RD_ACPI_GFAN, /* Use ACPI GFAN */ - IBMACPI_FAN_RD_TPEC, /* Use ACPI EC regs 0x2f, 0x84-0x85 */ -}; - -enum fan_control_access_mode { - IBMACPI_FAN_WR_NONE = 0, /* No fan control */ - IBMACPI_FAN_WR_ACPI_SFAN, /* Use ACPI SFAN */ - IBMACPI_FAN_WR_TPEC, /* Use ACPI EC reg 0x2f */ - IBMACPI_FAN_WR_ACPI_FANS, /* Use ACPI FANS and EC reg 0x2f */ -}; - -enum fan_control_commands { - IBMACPI_FAN_CMD_SPEED = 0x0001, /* speed command */ - IBMACPI_FAN_CMD_LEVEL = 0x0002, /* level command */ - IBMACPI_FAN_CMD_ENABLE = 0x0004, /* enable/disable cmd, - * and also watchdog cmd */ -}; - -enum { /* Fan control constants */ - fan_status_offset = 0x2f, /* EC register 0x2f */ - fan_rpm_offset = 0x84, /* EC register 0x84: LSB, 0x85 MSB (RPM) - * 0x84 must be read before 0x85 */ - - IBMACPI_FAN_EC_DISENGAGED = 0x40, /* EC mode: tachometer - * disengaged */ - IBMACPI_FAN_EC_AUTO = 0x80, /* EC mode: auto fan - * control */ -}; - static char *ibm_thinkpad_ec_found = NULL; -struct ibm_struct { - char *name; - char param[32]; - - char *hid; - struct acpi_driver *driver; - - int (*init) (void); - int (*read) (char *); - int (*write) (char *); - void (*exit) (void); - - void (*notify) (struct ibm_struct *, u32); - acpi_handle *handle; - int type; - struct acpi_device *device; - - int driver_registered; - int proc_created; - int init_called; - int notify_installed; - - int experimental; -}; - static struct proc_dir_entry *proc_dir = NULL; static struct backlight_device *ibm_backlight_device = NULL; -#define onoff(status,bit) ((status) & (1 << (bit)) ? "on" : "off") -#define enabled(status,bit) ((status) & (1 << (bit)) ? "enabled" : "disabled") -#define strlencmp(a,b) (strncmp((a), (b), strlen(b))) - static int acpi_evalf(acpi_handle handle, void *res, char *method, char *fmt, ...) { @@ -775,13 +668,6 @@ static int wan_write(char *buf) return 0; } -enum video_access_mode { - IBMACPI_VIDEO_NONE = 0, - IBMACPI_VIDEO_570, /* 570 */ - IBMACPI_VIDEO_770, /* 600e/x, 770e, 770x */ - IBMACPI_VIDEO_NEW, /* all others */ -}; - static enum video_access_mode video_supported; static int video_orig_autosw; @@ -1248,12 +1134,6 @@ static int cmos_write(char *buf) return 0; } -enum led_access_mode { - IBMACPI_LED_NONE = 0, - IBMACPI_LED_570, /* 570 */ - IBMACPI_LED_OLD, /* 600e/x, 770e, 770x, A21e, A2xm/p, T20-22, X20-21 */ - IBMACPI_LED_NEW, /* all others */ -}; static enum led_access_mode led_supported; static int led_init(void) @@ -1310,10 +1190,6 @@ static const int led_exp_hlbl[] = { 0, 0, 1 }; /* led# * */ static const int led_exp_hlcl[] = { 0, 1, 1 }; /* led# * */ static const int led_led_arg1[] = { 0, 0x80, 0xc0 }; -#define IBMACPI_LED_EC_HLCL 0x0c -#define IBMACPI_LED_EC_HLBL 0x0d -#define IBMACPI_LED_EC_HLMS 0x0e - static int led_write(char *buf) { char *cmd; @@ -1629,8 +1505,6 @@ static int ecdump_write(char *buf) return 0; } -static int brightness_offset = 0x31; - static int brightness_get(struct backlight_device *bd) { u8 level; @@ -1659,9 +1533,6 @@ static int brightness_read(char *p) return len; } -#define TP_CMOS_BRIGHTNESS_UP 4 -#define TP_CMOS_BRIGHTNESS_DOWN 5 - static int brightness_set(int value) { int cmos_cmd, inc, i; @@ -1752,8 +1623,6 @@ static void brightness_exit(void) } } -static int volume_offset = 0x30; - static int volume_read(char *p) { int len = 0; @@ -1772,10 +1641,6 @@ static int volume_read(char *p) return len; } -#define TP_CMOS_VOLUME_DOWN 0 -#define TP_CMOS_VOLUME_UP 1 -#define TP_CMOS_VOLUME_MUTE 2 - static int volume_write(char *buf) { int cmos_cmd, inc, i; diff --git a/drivers/acpi/ibm_acpi.h b/drivers/acpi/ibm_acpi.h new file mode 100644 index 0000000..7ebaaa4 --- /dev/null +++ b/drivers/acpi/ibm_acpi.h @@ -0,0 +1,437 @@ +/* + * ibm_acpi.h - IBM ThinkPad ACPI Extras + * + * + * Copyright (C) 2004-2005 Borislav Deianov <borislav-iA+eEnwkJgzk1uMJSBkQmQ@public.gmane.org> + * Copyright (C) 2006-2007 Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA + * 02110-1301, USA. + */ + +#ifndef __IBM_ACPI_H__ +#define __IBM_ACPI_H__ + +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/init.h> +#include <linux/types.h> +#include <linux/string.h> + +#include <linux/proc_fs.h> +#include <linux/backlight.h> +#include <linux/fb.h> +#include <asm/uaccess.h> + +#include <linux/dmi.h> +#include <linux/jiffies.h> +#include <linux/workqueue.h> + +#include <acpi/acpi_drivers.h> +#include <acpi/acnamesp.h> + + +/**************************************************************************** + * Main driver + */ + +#define IBM_NAME "ibm" +#define IBM_DESC "IBM ThinkPad ACPI Extras" +#define IBM_FILE "ibm_acpi" +#define IBM_URL "http://ibm-acpi.sf.net/" + +#define IBM_DIR IBM_NAME + +#define IBM_LOG IBM_FILE ": " +#define IBM_ERR KERN_ERR IBM_LOG +#define IBM_NOTICE KERN_NOTICE IBM_LOG +#define IBM_INFO KERN_INFO IBM_LOG +#define IBM_DEBUG KERN_DEBUG IBM_LOG + +#define IBM_MAX_ACPI_ARGS 3 + +/* ThinkPad CMOS commands */ +#define TP_CMOS_VOLUME_DOWN 0 +#define TP_CMOS_VOLUME_UP 1 +#define TP_CMOS_VOLUME_MUTE 2 +#define TP_CMOS_BRIGHTNESS_UP 4 +#define TP_CMOS_BRIGHTNESS_DOWN 5 + +#define onoff(status,bit) ((status) & (1 << (bit)) ? "on" : "off") +#define enabled(status,bit) ((status) & (1 << (bit)) ? "enabled" : "disabled") +#define strlencmp(a,b) (strncmp((a), (b), strlen(b))) + +/* ACPI HIDs */ +#define IBM_HKEY_HID "IBM0068" +#define IBM_PCI_HID "PNP0A03" + +/* ACPI helpers */ +static int acpi_evalf(acpi_handle handle, + void *res, char *method, char *fmt, ...); +static int acpi_ec_read(int i, u8 * p); +static int acpi_ec_write(int i, u8 v); +static int _sta(acpi_handle handle); + +/* ACPI handles */ +static acpi_handle root_handle; /* root namespace */ +static acpi_handle ec_handle; /* EC */ +static acpi_handle ecrd_handle, ecwr_handle; /* 570 EC access */ +static acpi_handle cmos_handle, hkey_handle; /* basic thinkpad handles */ + +static void ibm_handle_init(char *name, + acpi_handle * handle, acpi_handle parent, + char **paths, int num_paths, char **path); +#define IBM_HANDLE_INIT(object) \ + ibm_handle_init(#object, &object##_handle, *object##_parent, \ + object##_paths, ARRAY_SIZE(object##_paths), &object##_path) + +/* procfs support */ +static struct proc_dir_entry *proc_dir; +static int ibm_acpi_driver_init(void); +static int ibm_acpi_driver_read(char *p); + +/* procfs helpers */ +static int dispatch_read(char *page, char **start, off_t off, int count, + int *eof, void *data); +static int dispatch_write(struct file *file, const char __user * userbuf, + unsigned long count, void *data); +static char *next_cmd(char **cmds); + +/* Module */ +static int experimental; +static char *ibm_thinkpad_ec_found; + +static char* check_dmi_for_ec(void); +static int acpi_ibm_init(void); +static void acpi_ibm_exit(void); + + +/**************************************************************************** + * Subdrivers + */ + +struct ibm_struct { + char *name; + char param[32]; + + char *hid; + struct acpi_driver *driver; + + int (*init) (void); + int (*read) (char *); + int (*write) (char *); + void (*exit) (void); + + void (*notify) (struct ibm_struct *, u32); + acpi_handle *handle; + int type; + struct acpi_device *device; + + int driver_registered; + int proc_created; + int init_called; + int notify_installed; + + int experimental; +}; + +static struct ibm_struct ibms[]; +static int set_ibm_param(const char *val, struct kernel_param *kp); +static int ibm_init(struct ibm_struct *ibm); +static void ibm_exit(struct ibm_struct *ibm); + +/* ACPI devices */ +static void dispatch_notify(acpi_handle handle, u32 event, void *data); +static int setup_notify(struct ibm_struct *ibm); +static int ibm_device_add(struct acpi_device *device); +static int register_ibmacpi_subdriver(struct ibm_struct *ibm); + + +/* + * Bay subdriver + */ + +#ifdef CONFIG_ACPI_IBM_BAY +static int bay_status_supported, bay_eject_supported; +static int bay_status2_supported, bay_eject2_supported; + +static acpi_handle bay_handle, bay_ej_handle; +static acpi_handle bay2_handle, bay2_ej_handle; + +static int bay_init(void); +static void bay_notify(struct ibm_struct *ibm, u32 event); +static int bay_read(char *p); +static int bay_write(char *buf); +#endif /* CONFIG_ACPI_IBM_BAY */ + + +/* + * Beep subdriver + */ + +static acpi_handle beep_handle; + +static int beep_read(char *p); +static int beep_write(char *buf); + + +/* + * Bluetooth subdriver + */ + +static int bluetooth_supported; + +static int bluetooth_init(void); +static int bluetooth_status(void); +static int bluetooth_read(char *p); +static int bluetooth_write(char *buf); + + +/* + * Brightness (backlight) subdriver + */ + +static struct backlight_device *ibm_backlight_device; +static int brightness_offset = 0x31; + +static int brightness_init(void); +static void brightness_exit(void); +static int brightness_get(struct backlight_device *bd); +static int brightness_set(int value); +static int brightness_update_status(struct backlight_device *bd); +static int brightness_read(char *p); +static int brightness_write(char *buf); + + +/* + * CMOS subdriver + */ + +static int cmos_eval(int cmos_cmd); +static int cmos_read(char *p); +static int cmos_write(char *buf); + + +/* + * Dock subdriver + */ + +static acpi_handle pci_handle; +#ifdef CONFIG_ACPI_IBM_DOCK +static acpi_handle dock_handle; + +static void dock_notify(struct ibm_struct *ibm, u32 event); +static int dock_read(char *p); +static int dock_write(char *buf); +#endif /* CONFIG_ACPI_IBM_DOCK */ + + +/* + * EC dump subdriver + */ + +static int ecdump_read(char *p) ; +static int ecdump_write(char *buf); + + +/* + * Fan subdriver + */ + +enum { /* Fan control constants */ + fan_status_offset = 0x2f, /* EC register 0x2f */ + fan_rpm_offset = 0x84, /* EC register 0x84: LSB, 0x85 MSB (RPM) + * 0x84 must be read before 0x85 */ + + IBMACPI_FAN_EC_DISENGAGED = 0x40, /* EC mode: tachometer + * disengaged */ + IBMACPI_FAN_EC_AUTO = 0x80, /* EC mode: auto fan + * control */ +}; + +enum fan_status_access_mode { + IBMACPI_FAN_NONE = 0, /* No fan status or control */ + IBMACPI_FAN_RD_ACPI_GFAN, /* Use ACPI GFAN */ + IBMACPI_FAN_RD_TPEC, /* Use ACPI EC regs 0x2f, 0x84-0x85 */ +}; + +enum fan_control_access_mode { + IBMACPI_FAN_WR_NONE = 0, /* No fan control */ + IBMACPI_FAN_WR_ACPI_SFAN, /* Use ACPI SFAN */ + IBMACPI_FAN_WR_TPEC, /* Use ACPI EC reg 0x2f */ + IBMACPI_FAN_WR_ACPI_FANS, /* Use ACPI FANS and EC reg 0x2f */ +}; + +enum fan_control_commands { + IBMACPI_FAN_CMD_SPEED = 0x0001, /* speed command */ + IBMACPI_FAN_CMD_LEVEL = 0x0002, /* level command */ + IBMACPI_FAN_CMD_ENABLE = 0x0004, /* enable/disable cmd, + * and also watchdog cmd */ +}; + +static enum fan_status_access_mode fan_status_access_mode; +static enum fan_control_access_mode fan_control_access_mode; +static enum fan_control_commands fan_control_commands; +static int fan_control_status_known; +static u8 fan_control_initial_status; +static int fan_watchdog_maxinterval; + +static acpi_handle fans_handle, gfan_handle, sfan_handle; + +static int fan_init(void); +static void fan_exit(void); +static int fan_get_status(u8 *status); +static int fan_get_speed(unsigned int *speed); +static void fan_watchdog_fire(struct work_struct *ignored); +static void fan_watchdog_reset(void); +static int fan_set_level(int level); +static int fan_set_enable(void); +static int fan_set_disable(void); +static int fan_set_speed(int speed); +static int fan_read(char *p); +static int fan_write(char *buf); +static int fan_write_cmd_level(const char *cmd, int *rc); +static int fan_write_cmd_enable(const char *cmd, int *rc); +static int fan_write_cmd_disable(const char *cmd, int *rc); +static int fan_write_cmd_speed(const char *cmd, int *rc); +static int fan_write_cmd_watchdog(const char *cmd, int *rc); + + +/* + * Hotkey subdriver + */ + +static int hotkey_supported; +static int hotkey_mask_supported; +static int hotkey_orig_status; +static int hotkey_orig_mask; + +static int hotkey_init(void); +static void hotkey_exit(void); +static int hotkey_get(int *status, int *mask); +static int hotkey_set(int status, int mask); +static void hotkey_notify(struct ibm_struct *ibm, u32 event); +static int hotkey_read(char *p); +static int hotkey_write(char *buf); + + +/* + * LED subdriver + */ + +enum led_access_mode { + IBMACPI_LED_NONE = 0, + IBMACPI_LED_570, /* 570 */ + IBMACPI_LED_OLD, /* 600e/x, 770e, 770x, A21e, A2xm/p, T20-22, X20-21 */ + IBMACPI_LED_NEW, /* all others */ +}; + +enum { /* For IBMACPI_LED_OLD */ + IBMACPI_LED_EC_HLCL = 0x0c, /* EC reg to get led to power on */ + IBMACPI_LED_EC_HLBL = 0x0d, /* EC reg to blink a lit led */ + IBMACPI_LED_EC_HLMS = 0x0e, /* EC reg to select led to command */ +}; + +static enum led_access_mode led_supported; +static acpi_handle led_handle; + +static int led_init(void); +static int led_read(char *p); +static int led_write(char *buf); + +/* + * Light (thinklight) subdriver + */ + +static int light_supported; +static int light_status_supported; +static acpi_handle lght_handle, ledb_handle; + +static int light_init(void); +static int light_read(char *p); +static int light_write(char *buf); + + +/* + * Thermal subdriver + */ + +enum thermal_access_mode { + IBMACPI_THERMAL_NONE = 0, /* No thermal support */ + IBMACPI_THERMAL_ACPI_TMP07, /* Use ACPI TMP0-7 */ + IBMACPI_THERMAL_ACPI_UPDT, /* Use ACPI TMP0-7 with UPDT */ + IBMACPI_THERMAL_TPEC_8, /* Use ACPI EC regs, 8 sensors */ + IBMACPI_THERMAL_TPEC_16, /* Use ACPI EC regs, 16 sensors */ +}; + +#define IBMACPI_MAX_THERMAL_SENSORS 16 /* Max thermal sensors supported */ +struct ibm_thermal_sensors_struct { + s32 temp[IBMACPI_MAX_THERMAL_SENSORS]; +}; + +static int thermal_init(void); +static int thermal_get_sensors(struct ibm_thermal_sensors_struct *s); +static int thermal_read(char *p); + + +/* + * Video subdriver + */ + +enum video_access_mode { + IBMACPI_VIDEO_NONE = 0, + IBMACPI_VIDEO_570, /* 570 */ + IBMACPI_VIDEO_770, /* 600e/x, 770e, 770x */ + IBMACPI_VIDEO_NEW, /* all others */ +}; + +static enum video_access_mode video_supported; +static int video_orig_autosw; +static acpi_handle vid_handle, vid2_handle; + +static int video_init(void); +static void video_exit(void); +static int video_status(void); +static int video_autosw(void); +static int video_switch(void); +static int video_switch2(int status); +static int video_expand(void); +static int video_read(char *p); +static int video_write(char *buf); + + +/* + * Volume subdriver + */ + +static int volume_offset = 0x30; + +static int volume_read(char *p); +static int volume_write(char *buf); + + +/* + * Wan subdriver + */ + +static int wan_supported; + +static int wan_init(void); +static int wan_status(void); +static int wan_read(char *p); +static int wan_write(char *buf); + + +#endif /* __IBM_ACPI_H */ -- 1.5.0.3 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ^ permalink raw reply related [flat|nested] 60+ messages in thread
[parent not found: <11736588493502-git-send-email-hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>]
* [PATCH 4/6] ACPI: ibm-acpi: organize code [not found] ` <11736588493502-git-send-email-hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org> @ 2007-03-12 0:20 ` Henrique de Moraes Holschuh 2007-03-12 0:20 ` [PATCH 5/6] ACPI: ibm-acpi: update copyright notice Henrique de Moraes Holschuh 0 siblings, 1 reply; 60+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-12 0:20 UTC (permalink / raw) To: lenb-DgEjT+Ai2ygdnm+yROfE0A Cc: linux-acpi-u79uwXL29TY76Z2rM5mHXA, Henrique de Moraes Holschuh, ibm-acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Shuffle code around to better organize the driver code inside the ibm-acpi.c file. This patch adds no functional changes. It is pure fluff that will make me a bit more productive. Signed-off-by: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org> --- drivers/acpi/ibm_acpi.c | 1388 +++++++++++++++++++++++++---------------------- 1 files changed, 752 insertions(+), 636 deletions(-) diff --git a/drivers/acpi/ibm_acpi.c b/drivers/acpi/ibm_acpi.c index 59cbafc..7cd2888 100644 --- a/drivers/acpi/ibm_acpi.c +++ b/drivers/acpi/ibm_acpi.c @@ -87,8 +87,17 @@ MODULE_LICENSE("GPL"); #define __unused __attribute__ ((unused)) -static int experimental; -module_param(experimental, int, 0); +/**************************************************************************** + **************************************************************************** + * + * ACPI Helpers and device model + * + **************************************************************************** + ****************************************************************************/ + +/************************************************************************* + * ACPI basic handles + */ static acpi_handle root_handle = NULL; @@ -105,183 +114,31 @@ IBM_HANDLE(ec, root, "\\_SB.PCI0.ISA.EC0", /* 240, 240x */ "\\_SB.PCI0.AD4S.EC0", /* i1400, R30 */ "\\_SB.PCI0.ICH3.EC0", /* R31 */ "\\_SB.PCI0.LPC.EC", /* all others */ - ); + ); -IBM_HANDLE(vid, root, "\\_SB.PCI.AGP.VGA", /* 570 */ - "\\_SB.PCI0.AGP0.VID0", /* 600e/x, 770x */ - "\\_SB.PCI0.VID0", /* 770e */ - "\\_SB.PCI0.VID", /* A21e, G4x, R50e, X30, X40 */ - "\\_SB.PCI0.AGP.VID", /* all others */ - ); /* R30, R31 */ +IBM_HANDLE(ecrd, ec, "ECRD"); /* 570 */ +IBM_HANDLE(ecwr, ec, "ECWR"); /* 570 */ -IBM_HANDLE(vid2, root, "\\_SB.PCI0.AGPB.VID"); /* G41 */ + +/************************************************************************* + * Misc ACPI handles + */ IBM_HANDLE(cmos, root, "\\UCMS", /* R50, R50e, R50p, R51, T4x, X31, X40 */ "\\CMOS", /* A3x, G4x, R32, T23, T30, X22-24, X30 */ "\\CMS", /* R40, R40e */ - ); /* all others */ -#ifdef CONFIG_ACPI_IBM_DOCK -IBM_HANDLE(dock, root, "\\_SB.GDCK", /* X30, X31, X40 */ - "\\_SB.PCI0.DOCK", /* 600e/x,770e,770x,A2xm/p,T20-22,X20-21 */ - "\\_SB.PCI0.PCI1.DOCK", /* all others */ - "\\_SB.PCI.ISA.SLCE", /* 570 */ - ); /* A21e,G4x,R30,R31,R32,R40,R40e,R50e */ -#endif -#ifdef CONFIG_ACPI_IBM_BAY -IBM_HANDLE(bay, root, "\\_SB.PCI.IDE.SECN.MAST", /* 570 */ - "\\_SB.PCI0.IDE0.IDES.IDSM", /* 600e/x, 770e, 770x */ - "\\_SB.PCI0.SATA.SCND.MSTR", /* T60, X60, Z60 */ - "\\_SB.PCI0.IDE0.SCND.MSTR", /* all others */ - ); /* A21e, R30, R31 */ - -IBM_HANDLE(bay_ej, bay, "_EJ3", /* 600e/x, A2xm/p, A3x */ - "_EJ0", /* all others */ - ); /* 570,A21e,G4x,R30,R31,R32,R40e,R50e */ - -IBM_HANDLE(bay2, root, "\\_SB.PCI0.IDE0.PRIM.SLAV", /* A3x, R32 */ - "\\_SB.PCI0.IDE0.IDEP.IDPS", /* 600e/x, 770e, 770x */ - ); /* all others */ - -IBM_HANDLE(bay2_ej, bay2, "_EJ3", /* 600e/x, 770e, A3x */ - "_EJ0", /* 770x */ - ); /* all others */ -#endif /* CONFIG_ACPI_IBM_BAY */ - -/* don't list other alternatives as we install a notify handler on the 570 */ -IBM_HANDLE(pci, root, "\\_SB.PCI"); /* 570 */ + ); /* all others */ IBM_HANDLE(hkey, ec, "\\_SB.HKEY", /* 600e/x, 770e, 770x */ "^HKEY", /* R30, R31 */ "HKEY", /* all others */ - ); /* 570 */ + ); /* 570 */ -IBM_HANDLE(lght, root, "\\LGHT"); /* A21e, A2xm/p, T20-22, X20-21 */ -IBM_HANDLE(ledb, ec, "LEDB"); /* G4x */ -IBM_HANDLE(led, ec, "SLED", /* 570 */ - "SYSL", /* 600e/x, 770e, 770x, A21e, A2xm/p, T20-22, X20-21 */ - "LED", /* all others */ - ); /* R30, R31 */ - -IBM_HANDLE(beep, ec, "BEEP"); /* all except R30, R31 */ -IBM_HANDLE(ecrd, ec, "ECRD"); /* 570 */ -IBM_HANDLE(ecwr, ec, "ECWR"); /* 570 */ -IBM_HANDLE(fans, ec, "FANS"); /* X31, X40, X41 */ - -IBM_HANDLE(gfan, ec, "GFAN", /* 570 */ - "\\FSPD", /* 600e/x, 770e, 770x */ - ); /* all others */ - -IBM_HANDLE(sfan, ec, "SFAN", /* 570 */ - "JFNS", /* 770x-JL */ - ); /* all others */ - -/* - * FAN ACCESS MODES - * - * IBMACPI_FAN_RD_ACPI_GFAN: - * ACPI GFAN method: returns fan level - * - * see IBMACPI_FAN_WR_ACPI_SFAN - * EC 0x2f not available if GFAN exists - * - * IBMACPI_FAN_WR_ACPI_SFAN: - * ACPI SFAN method: sets fan level, 0 (stop) to 7 (max) - * - * EC 0x2f might be available *for reading*, but never for writing. - * - * IBMACPI_FAN_WR_TPEC: - * ThinkPad EC register 0x2f (HFSP): fan control loop mode Supported - * on almost all ThinkPads - * - * Fan speed changes of any sort (including those caused by the - * disengaged mode) are usually done slowly by the firmware as the - * maximum ammount of fan duty cycle change per second seems to be - * limited. - * - * Reading is not available if GFAN exists. - * Writing is not available if SFAN exists. - * - * Bits - * 7 automatic mode engaged; - * (default operation mode of the ThinkPad) - * fan level is ignored in this mode. - * 6 disengage mode (takes precedence over bit 7); - * not available on all thinkpads. May disable - * the tachometer, and speeds up fan to 100% duty-cycle, - * which speeds it up far above the standard RPM - * levels. It is not impossible that it could cause - * hardware damage. - * 5-3 unused in some models. Extra bits for fan level - * in others, but still useless as all values above - * 7 map to the same speed as level 7 in these models. - * 2-0 fan level (0..7 usually) - * 0x00 = stop - * 0x07 = max (set when temperatures critical) - * Some ThinkPads may have other levels, see - * IBMACPI_FAN_WR_ACPI_FANS (X31/X40/X41) - * - * FIRMWARE BUG: on some models, EC 0x2f might not be initialized at - * boot. Apparently the EC does not intialize it, so unless ACPI DSDT - * does so, its initial value is meaningless (0x07). - * - * For firmware bugs, refer to: - * http://thinkwiki.org/wiki/Embedded_Controller_Firmware#Firmware_Issues - * - * ---- - * - * ThinkPad EC register 0x84 (LSB), 0x85 (MSB): - * Main fan tachometer reading (in RPM) - * - * This register is present on all ThinkPads with a new-style EC, and - * it is known not to be present on the A21m/e, and T22, as there is - * something else in offset 0x84 according to the ACPI DSDT. Other - * ThinkPads from this same time period (and earlier) probably lack the - * tachometer as well. - * - * Unfortunately a lot of ThinkPads with new-style ECs but whose firwmare - * was never fixed by IBM to report the EC firmware version string - * probably support the tachometer (like the early X models), so - * detecting it is quite hard. We need more data to know for sure. - * - * FIRMWARE BUG: always read 0x84 first, otherwise incorrect readings - * might result. - * - * FIRMWARE BUG: when EC 0x2f bit 6 is set (disengaged mode), this - * register is not invalidated in ThinkPads that disable tachometer - * readings. Thus, the tachometer readings go stale. - * - * For firmware bugs, refer to: - * http://thinkwiki.org/wiki/Embedded_Controller_Firmware#Firmware_Issues - * - * IBMACPI_FAN_WR_ACPI_FANS: - * ThinkPad X31, X40, X41. Not available in the X60. - * - * FANS ACPI handle: takes three arguments: low speed, medium speed, - * high speed. ACPI DSDT seems to map these three speeds to levels - * as follows: STOP LOW LOW MED MED HIGH HIGH HIGH HIGH - * (this map is stored on FAN0..FAN8 as "0,1,1,2,2,3,3,3,3") - * - * The speeds are stored on handles - * (FANA:FAN9), (FANC:FANB), (FANE:FAND). - * - * There are three default speed sets, acessible as handles: - * FS1L,FS1M,FS1H; FS2L,FS2M,FS2H; FS3L,FS3M,FS3H - * - * ACPI DSDT switches which set is in use depending on various - * factors. - * - * IBMACPI_FAN_WR_TPEC is also available and should be used to - * command the fan. The X31/X40/X41 seems to have 8 fan levels, - * but the ACPI tables just mention level 7. +/************************************************************************* + * ACPI helpers */ -static char *ibm_thinkpad_ec_found = NULL; - -static struct proc_dir_entry *proc_dir = NULL; - -static struct backlight_device *ibm_backlight_device = NULL; - static int acpi_evalf(acpi_handle handle, void *res, char *method, char *fmt, ...) { @@ -371,6 +228,198 @@ static void __unused acpi_print_int(acpi_handle handle, char *method) printk(IBM_ERR "error calling %s\n", method); } +static int acpi_ec_read(int i, u8 * p) +{ + int v; + + if (ecrd_handle) { + if (!acpi_evalf(ecrd_handle, &v, NULL, "dd", i)) + return 0; + *p = v; + } else { + if (ec_read(i, p) < 0) + return 0; + } + + return 1; +} + +static int acpi_ec_write(int i, u8 v) +{ + if (ecwr_handle) { + if (!acpi_evalf(ecwr_handle, NULL, NULL, "vdd", i, v)) + return 0; + } else { + if (ec_write(i, v) < 0) + return 0; + } + + return 1; +} + +static int _sta(acpi_handle handle) +{ + int status; + + if (!handle || !acpi_evalf(handle, &status, "_STA", "d")) + status = 0; + + return status; +} + +/************************************************************************* + * ACPI device model + */ + +static void __init ibm_handle_init(char *name, + acpi_handle * handle, acpi_handle parent, + char **paths, int num_paths, char **path) +{ + int i; + acpi_status status; + + for (i = 0; i < num_paths; i++) { + status = acpi_get_handle(parent, paths[i], handle); + if (ACPI_SUCCESS(status)) { + *path = paths[i]; + return; + } + } + + *handle = NULL; +} + +static void dispatch_notify(acpi_handle handle, u32 event, void *data) +{ + struct ibm_struct *ibm = data; + + if (!ibm || !ibm->notify) + return; + + ibm->notify(ibm, event); +} + +static int __init setup_notify(struct ibm_struct *ibm) +{ + acpi_status status; + int ret; + + if (!*ibm->handle) + return 0; + + ret = acpi_bus_get_device(*ibm->handle, &ibm->device); + if (ret < 0) { + printk(IBM_ERR "%s device not present\n", ibm->name); + return 0; + } + + acpi_driver_data(ibm->device) = ibm; + sprintf(acpi_device_class(ibm->device), "%s/%s", IBM_NAME, ibm->name); + + status = acpi_install_notify_handler(*ibm->handle, ibm->type, + dispatch_notify, ibm); + if (ACPI_FAILURE(status)) { + printk(IBM_ERR "acpi_install_notify_handler(%s) failed: %d\n", + ibm->name, status); + return -ENODEV; + } + ibm->notify_installed = 1; + return 0; +} + +static int __init ibm_device_add(struct acpi_device *device) +{ + return 0; +} + +static int __init register_ibmacpi_subdriver(struct ibm_struct *ibm) +{ + int ret; + + ibm->driver = kzalloc(sizeof(struct acpi_driver), GFP_KERNEL); + if (!ibm->driver) { + printk(IBM_ERR "kmalloc(ibm->driver) failed\n"); + return -1; + } + + sprintf(ibm->driver->name, "%s_%s", IBM_NAME, ibm->name); + ibm->driver->ids = ibm->hid; + ibm->driver->ops.add = &ibm_device_add; + + ret = acpi_bus_register_driver(ibm->driver); + if (ret < 0) { + printk(IBM_ERR "acpi_bus_register_driver(%s) failed: %d\n", + ibm->hid, ret); + kfree(ibm->driver); + } + + return ret; +} + + +/**************************************************************************** + **************************************************************************** + * + * Procfs Helpers + * + **************************************************************************** + ****************************************************************************/ + +static int dispatch_read(char *page, char **start, off_t off, int count, + int *eof, void *data) +{ + struct ibm_struct *ibm = data; + int len; + + if (!ibm || !ibm->read) + return -EINVAL; + + len = ibm->read(page); + if (len < 0) + return len; + + if (len <= off + count) + *eof = 1; + *start = page + off; + len -= off; + if (len > count) + len = count; + if (len < 0) + len = 0; + + return len; +} + +static int dispatch_write(struct file *file, const char __user * userbuf, + unsigned long count, void *data) +{ + struct ibm_struct *ibm = data; + char *kernbuf; + int ret; + + if (!ibm || !ibm->write) + return -EINVAL; + + kernbuf = kmalloc(count + 2, GFP_KERNEL); + if (!kernbuf) + return -ENOMEM; + + if (copy_from_user(kernbuf, userbuf, count)) { + kfree(kernbuf); + return -EFAULT; + } + + kernbuf[count] = 0; + strcat(kernbuf, ","); + ret = ibm->write(kernbuf); + if (ret == 0) + ret = count; + + kfree(kernbuf); + + return ret; +} + static char *next_cmd(char **cmds) { char *start = *cmds; @@ -387,6 +436,19 @@ static char *next_cmd(char **cmds) return start; } + +/**************************************************************************** + **************************************************************************** + * + * Subdrivers + * + **************************************************************************** + ****************************************************************************/ + +/************************************************************************* + * ibm-acpi init subdriver + */ + static int ibm_acpi_driver_init(void) { printk(IBM_INFO "%s v%s\n", IBM_DESC, IBM_VERSION); @@ -409,11 +471,51 @@ static int ibm_acpi_driver_read(char *p) return len; } +/************************************************************************* + * Hotkey subdriver + */ + static int hotkey_supported; static int hotkey_mask_supported; static int hotkey_orig_status; static int hotkey_orig_mask; +static int hotkey_init(void) +{ + /* hotkey not supported on 570 */ + hotkey_supported = hkey_handle != NULL; + + if (hotkey_supported) { + /* mask not supported on 570, 600e/x, 770e, 770x, A21e, A2xm/p, + A30, R30, R31, T20-22, X20-21, X22-24 */ + hotkey_mask_supported = + acpi_evalf(hkey_handle, NULL, "DHKN", "qv"); + + if (!hotkey_get(&hotkey_orig_status, &hotkey_orig_mask)) + return -ENODEV; + } + + return 0; +} + +static void hotkey_exit(void) +{ + if (hotkey_supported) + hotkey_set(hotkey_orig_status, hotkey_orig_mask); +} + +static void hotkey_notify(struct ibm_struct *ibm, u32 event) +{ + int hkey; + + if (acpi_evalf(hkey_handle, &hkey, "MHKP", "d")) + acpi_bus_generate_event(ibm->device, event, hkey); + else { + printk(IBM_ERR "unknown hotkey event %d\n", event); + acpi_bus_generate_event(ibm->device, event, 0); + } +} + static int hotkey_get(int *status, int *mask) { if (!acpi_evalf(hkey_handle, status, "DHKC", "d")) @@ -444,24 +546,6 @@ static int hotkey_set(int status, int mask) return 1; } -static int hotkey_init(void) -{ - /* hotkey not supported on 570 */ - hotkey_supported = hkey_handle != NULL; - - if (hotkey_supported) { - /* mask not supported on 570, 600e/x, 770e, 770x, A21e, A2xm/p, - A30, R30, R31, T20-22, X20-21, X22-24 */ - hotkey_mask_supported = - acpi_evalf(hkey_handle, NULL, "DHKN", "qv"); - - if (!hotkey_get(&hotkey_orig_status, &hotkey_orig_mask)) - return -ENODEV; - } - - return 0; -} - static int hotkey_read(char *p) { int status, mask; @@ -523,23 +607,9 @@ static int hotkey_write(char *buf) return 0; } -static void hotkey_exit(void) -{ - if (hotkey_supported) - hotkey_set(hotkey_orig_status, hotkey_orig_mask); -} - -static void hotkey_notify(struct ibm_struct *ibm, u32 event) -{ - int hkey; - - if (acpi_evalf(hkey_handle, &hkey, "MHKP", "d")) - acpi_bus_generate_event(ibm->device, event, hkey); - else { - printk(IBM_ERR "unknown hotkey event %d\n", event); - acpi_bus_generate_event(ibm->device, event, 0); - } -} +/************************************************************************* + * Bluetooth subdriver + */ static int bluetooth_supported; @@ -606,6 +676,10 @@ static int bluetooth_write(char *buf) return 0; } +/************************************************************************* + * Wan subdriver + */ + static int wan_supported; static int wan_init(void) @@ -668,9 +742,22 @@ static int wan_write(char *buf) return 0; } +/************************************************************************* + * Video subdriver + */ + static enum video_access_mode video_supported; static int video_orig_autosw; +IBM_HANDLE(vid, root, "\\_SB.PCI.AGP.VGA", /* 570 */ + "\\_SB.PCI0.AGP0.VID0", /* 600e/x, 770x */ + "\\_SB.PCI0.VID0", /* 770e */ + "\\_SB.PCI0.VID", /* A21e, G4x, R50e, X30, X40 */ + "\\_SB.PCI0.AGP.VID", /* all others */ + ); /* R30, R31 */ + +IBM_HANDLE(vid2, root, "\\_SB.PCI0.AGPB.VID"); /* G41 */ + static int video_init(void) { int ivga; @@ -695,6 +782,11 @@ static int video_init(void) return 0; } +static void video_exit(void) +{ + acpi_evalf(vid_handle, NULL, "_DOS", "vd", video_orig_autosw); +} + static int video_status(void) { int status = 0; @@ -736,33 +828,6 @@ static int video_autosw(void) return autosw & 1; } -static int video_read(char *p) -{ - int status = video_status(); - int autosw = video_autosw(); - int len = 0; - - if (!video_supported) { - len += sprintf(p + len, "status:\t\tnot supported\n"); - return len; - } - - len += sprintf(p + len, "status:\t\tsupported\n"); - len += sprintf(p + len, "lcd:\t\t%s\n", enabled(status, 0)); - len += sprintf(p + len, "crt:\t\t%s\n", enabled(status, 1)); - if (video_supported == IBMACPI_VIDEO_NEW) - len += sprintf(p + len, "dvi:\t\t%s\n", enabled(status, 3)); - len += sprintf(p + len, "auto:\t\t%s\n", enabled(autosw, 0)); - len += sprintf(p + len, "commands:\tlcd_enable, lcd_disable\n"); - len += sprintf(p + len, "commands:\tcrt_enable, crt_disable\n"); - if (video_supported == IBMACPI_VIDEO_NEW) - len += sprintf(p + len, "commands:\tdvi_enable, dvi_disable\n"); - len += sprintf(p + len, "commands:\tauto_enable, auto_disable\n"); - len += sprintf(p + len, "commands:\tvideo_switch, expand_toggle\n"); - - return len; -} - static int video_switch(void) { int autosw = video_autosw(); @@ -812,6 +877,33 @@ static int video_switch2(int status) return ret; } +static int video_read(char *p) +{ + int status = video_status(); + int autosw = video_autosw(); + int len = 0; + + if (!video_supported) { + len += sprintf(p + len, "status:\t\tnot supported\n"); + return len; + } + + len += sprintf(p + len, "status:\t\tsupported\n"); + len += sprintf(p + len, "lcd:\t\t%s\n", enabled(status, 0)); + len += sprintf(p + len, "crt:\t\t%s\n", enabled(status, 1)); + if (video_supported == IBMACPI_VIDEO_NEW) + len += sprintf(p + len, "dvi:\t\t%s\n", enabled(status, 3)); + len += sprintf(p + len, "auto:\t\t%s\n", enabled(autosw, 0)); + len += sprintf(p + len, "commands:\tlcd_enable, lcd_disable\n"); + len += sprintf(p + len, "commands:\tcrt_enable, crt_disable\n"); + if (video_supported == IBMACPI_VIDEO_NEW) + len += sprintf(p + len, "commands:\tdvi_enable, dvi_disable\n"); + len += sprintf(p + len, "commands:\tauto_enable, auto_disable\n"); + len += sprintf(p + len, "commands:\tvideo_switch, expand_toggle\n"); + + return len; +} + static int video_write(char *buf) { char *cmd; @@ -862,14 +954,16 @@ static int video_write(char *buf) return 0; } -static void video_exit(void) -{ - acpi_evalf(vid_handle, NULL, "_DOS", "vd", video_orig_autosw); -} +/************************************************************************* + * Light (thinklight) subdriver + */ static int light_supported; static int light_status_supported; +IBM_HANDLE(lght, root, "\\LGHT"); /* A21e, A2xm/p, T20-22, X20-21 */ +IBM_HANDLE(ledb, ec, "LEDB"); /* G4x */ + static int light_init(void) { /* light not supported on 570, 600e/x, 770e, 770x, G4x, R30, R31 */ @@ -933,21 +1027,45 @@ static int light_write(char *buf) return 0; } -#if defined(CONFIG_ACPI_IBM_DOCK) || defined(CONFIG_ACPI_IBM_BAY) -static int _sta(acpi_handle handle) -{ - int status; - - if (!handle || !acpi_evalf(handle, &status, "_STA", "d")) - status = 0; +/************************************************************************* + * Dock subdriver + */ - return status; -} -#endif +/* don't list other alternatives as we install a notify handler on the 570 */ +IBM_HANDLE(pci, root, "\\_SB.PCI"); /* 570 */ #ifdef CONFIG_ACPI_IBM_DOCK + +IBM_HANDLE(dock, root, "\\_SB.GDCK", /* X30, X31, X40 */ + "\\_SB.PCI0.DOCK", /* 600e/x,770e,770x,A2xm/p,T20-22,X20-21 */ + "\\_SB.PCI0.PCI1.DOCK", /* all others */ + "\\_SB.PCI.ISA.SLCE", /* 570 */ + ); /* A21e,G4x,R30,R31,R32,R40,R40e,R50e */ + #define dock_docked() (_sta(dock_handle) & 1) +static void dock_notify(struct ibm_struct *ibm, u32 event) +{ + int docked = dock_docked(); + int pci = ibm->hid && strstr(ibm->hid, IBM_PCI_HID); + + if (event == 1 && !pci) /* 570 */ + acpi_bus_generate_event(ibm->device, event, 1); /* button */ + else if (event == 1 && pci) /* 570 */ + acpi_bus_generate_event(ibm->device, event, 3); /* dock */ + else if (event == 3 && docked) + acpi_bus_generate_event(ibm->device, event, 1); /* button */ + else if (event == 3 && !docked) + acpi_bus_generate_event(ibm->device, event, 2); /* undock */ + else if (event == 0 && docked) + acpi_bus_generate_event(ibm->device, event, 3); /* dock */ + else { + printk(IBM_ERR "unknown dock event %d, status %d\n", + event, _sta(dock_handle)); + acpi_bus_generate_event(ibm->device, event, 0); /* unknown */ + } +} + static int dock_read(char *p) { int len = 0; @@ -987,28 +1105,11 @@ static int dock_write(char *buf) return 0; } -static void dock_notify(struct ibm_struct *ibm, u32 event) -{ - int docked = dock_docked(); - int pci = ibm->hid && strstr(ibm->hid, IBM_PCI_HID); +#endif /* CONFIG_ACPI_IBM_DOCK */ - if (event == 1 && !pci) /* 570 */ - acpi_bus_generate_event(ibm->device, event, 1); /* button */ - else if (event == 1 && pci) /* 570 */ - acpi_bus_generate_event(ibm->device, event, 3); /* dock */ - else if (event == 3 && docked) - acpi_bus_generate_event(ibm->device, event, 1); /* button */ - else if (event == 3 && !docked) - acpi_bus_generate_event(ibm->device, event, 2); /* undock */ - else if (event == 0 && docked) - acpi_bus_generate_event(ibm->device, event, 3); /* dock */ - else { - printk(IBM_ERR "unknown dock event %d, status %d\n", - event, _sta(dock_handle)); - acpi_bus_generate_event(ibm->device, event, 0); /* unknown */ - } -} -#endif +/************************************************************************* + * Bay subdriver + */ #ifdef CONFIG_ACPI_IBM_BAY static int bay_status_supported; @@ -1016,6 +1117,21 @@ static int bay_status2_supported; static int bay_eject_supported; static int bay_eject2_supported; +IBM_HANDLE(bay, root, "\\_SB.PCI.IDE.SECN.MAST", /* 570 */ + "\\_SB.PCI0.IDE0.IDES.IDSM", /* 600e/x, 770e, 770x */ + "\\_SB.PCI0.SATA.SCND.MSTR", /* T60, X60, Z60 */ + "\\_SB.PCI0.IDE0.SCND.MSTR", /* all others */ + ); /* A21e, R30, R31 */ +IBM_HANDLE(bay_ej, bay, "_EJ3", /* 600e/x, A2xm/p, A3x */ + "_EJ0", /* all others */ + ); /* 570,A21e,G4x,R30,R31,R32,R40e,R50e */ +IBM_HANDLE(bay2, root, "\\_SB.PCI0.IDE0.PRIM.SLAV", /* A3x, R32 */ + "\\_SB.PCI0.IDE0.IDEP.IDPS", /* 600e/x, 770e, 770x */ + ); /* all others */ +IBM_HANDLE(bay2_ej, bay2, "_EJ3", /* 600e/x, 770e, A3x */ + "_EJ0", /* 770x */ + ); /* all others */ + static int bay_init(void) { bay_status_supported = bay_handle && @@ -1031,6 +1147,11 @@ static int bay_init(void) return 0; } +static void bay_notify(struct ibm_struct *ibm, u32 event) +{ + acpi_bus_generate_event(ibm->device, event, 0); +} + #define bay_occupied(b) (_sta(b##_handle) & 1) static int bay_read(char *p) @@ -1081,12 +1202,19 @@ static int bay_write(char *buf) return 0; } +#endif /* CONFIG_ACPI_IBM_BAY */ -static void bay_notify(struct ibm_struct *ibm, u32 event) +/************************************************************************* + * CMOS subdriver + */ + +static int cmos_eval(int cmos_cmd) { - acpi_bus_generate_event(ibm->device, event, 0); + if (cmos_handle) + return acpi_evalf(cmos_handle, NULL, NULL, "vd", cmos_cmd); + else + return 1; } -#endif /* CONFIG_ACPI_IBM_BAY */ static int cmos_read(char *p) { @@ -1104,14 +1232,6 @@ static int cmos_read(char *p) return len; } -static int cmos_eval(int cmos_cmd) -{ - if (cmos_handle) - return acpi_evalf(cmos_handle, NULL, NULL, "vd", cmos_cmd); - else - return 1; -} - static int cmos_write(char *buf) { char *cmd; @@ -1134,8 +1254,18 @@ static int cmos_write(char *buf) return 0; } + +/************************************************************************* + * LED subdriver + */ + static enum led_access_mode led_supported; +IBM_HANDLE(led, ec, "SLED", /* 570 */ + "SYSL", /* 600e/x, 770e, 770x, A21e, A2xm/p, T20-22, X20-21 */ + "LED", /* all others */ + ); /* R30, R31 */ + static int led_init(void) { if (!led_handle) @@ -1242,6 +1372,12 @@ static int led_write(char *buf) return 0; } +/************************************************************************* + * Beep subdriver + */ + +IBM_HANDLE(beep, ec, "BEEP"); /* all except R30, R31 */ + static int beep_read(char *p) { int len = 0; @@ -1277,34 +1413,9 @@ static int beep_write(char *buf) return 0; } -static int acpi_ec_read(int i, u8 * p) -{ - int v; - - if (ecrd_handle) { - if (!acpi_evalf(ecrd_handle, &v, NULL, "dd", i)) - return 0; - *p = v; - } else { - if (ec_read(i, p) < 0) - return 0; - } - - return 1; -} - -static int acpi_ec_write(int i, u8 v) -{ - if (ecwr_handle) { - if (!acpi_evalf(ecwr_handle, NULL, NULL, "vdd", i, v)) - return 0; - } else { - if (ec_write(i, v) < 0) - return 0; - } - - return 1; -} +/************************************************************************* + * Thermal subdriver + */ static enum thermal_access_mode thermal_read_mode; @@ -1446,6 +1557,10 @@ static int thermal_read(char *p) return len; } +/************************************************************************* + * EC Dump subdriver + */ + static u8 ecdump_regs[256]; static int ecdump_read(char *p) @@ -1505,6 +1620,55 @@ static int ecdump_write(char *buf) return 0; } +/************************************************************************* + * Backlight/brightness subdriver + */ + +static struct backlight_device *ibm_backlight_device = NULL; + +static struct backlight_ops ibm_backlight_data = { + .get_brightness = brightness_get, + .update_status = brightness_update_status, +}; + +static int brightness_init(void) +{ + int b; + + b = brightness_get(NULL); + if (b < 0) + return b; + + ibm_backlight_device = backlight_device_register("ibm", NULL, NULL, + &ibm_backlight_data); + if (IS_ERR(ibm_backlight_device)) { + printk(IBM_ERR "Could not register backlight device\n"); + return PTR_ERR(ibm_backlight_device); + } + + ibm_backlight_device->props.max_brightness = 7; + ibm_backlight_device->props.brightness = b; + backlight_update_status(ibm_backlight_device); + + return 0; +} + +static void brightness_exit(void) +{ + if (ibm_backlight_device) { + backlight_device_unregister(ibm_backlight_device); + ibm_backlight_device = NULL; + } +} + +static int brightness_update_status(struct backlight_device *bd) +{ + return brightness_set( + (bd->props.fb_blank == FB_BLANK_UNBLANK && + bd->props.power == FB_BLANK_UNBLANK) ? + bd->props.brightness : 0); +} + static int brightness_get(struct backlight_device *bd) { u8 level; @@ -1516,23 +1680,6 @@ static int brightness_get(struct backlight_device *bd) return level; } -static int brightness_read(char *p) -{ - int len = 0; - int level; - - if ((level = brightness_get(NULL)) < 0) { - len += sprintf(p + len, "level:\t\tunreadable\n"); - } else { - len += sprintf(p + len, "level:\t\t%d\n", level & 0x7); - len += sprintf(p + len, "commands:\tup, down\n"); - len += sprintf(p + len, "commands:\tlevel <level>" - " (<level> is 0-7)\n"); - } - - return len; -} - static int brightness_set(int value) { int cmos_cmd, inc, i; @@ -1540,8 +1687,7 @@ static int brightness_set(int value) value &= 7; - cmos_cmd = value > current_value ? - TP_CMOS_BRIGHTNESS_UP : TP_CMOS_BRIGHTNESS_DOWN; + cmos_cmd = value > current_value ? TP_CMOS_BRIGHTNESS_UP : TP_CMOS_BRIGHTNESS_DOWN; inc = value > current_value ? 1 : -1; for (i = current_value; i != value; i += inc) { if (!cmos_eval(cmos_cmd)) @@ -1553,6 +1699,23 @@ static int brightness_set(int value) return 0; } +static int brightness_read(char *p) +{ + int len = 0; + int level; + + if ((level = brightness_get(NULL)) < 0) { + len += sprintf(p + len, "level:\t\tunreadable\n"); + } else { + len += sprintf(p + len, "level:\t\t%d\n", level & 0x7); + len += sprintf(p + len, "commands:\tup, down\n"); + len += sprintf(p + len, "commands:\tlevel <level>" + " (<level> is 0-7)\n"); + } + + return len; +} + static int brightness_write(char *buf) { int level; @@ -1580,48 +1743,9 @@ static int brightness_write(char *buf) return 0; } -static int brightness_update_status(struct backlight_device *bd) -{ - return brightness_set( - (bd->props.fb_blank == FB_BLANK_UNBLANK && - bd->props.power == FB_BLANK_UNBLANK) ? - bd->props.brightness : 0); -} - -static struct backlight_ops ibm_backlight_data = { - .get_brightness = brightness_get, - .update_status = brightness_update_status, -}; - -static int brightness_init(void) -{ - int b; - - b = brightness_get(NULL); - if (b < 0) - return b; - - ibm_backlight_device = backlight_device_register("ibm", NULL, NULL, - &ibm_backlight_data); - if (IS_ERR(ibm_backlight_device)) { - printk(IBM_ERR "Could not register backlight device\n"); - return PTR_ERR(ibm_backlight_device); - } - - ibm_backlight_device->props.max_brightness = 7; - ibm_backlight_device->props.brightness = b; - backlight_update_status(ibm_backlight_device); - - return 0; -} - -static void brightness_exit(void) -{ - if (ibm_backlight_device) { - backlight_device_unregister(ibm_backlight_device); - ibm_backlight_device = NULL; - } -} +/************************************************************************* + * Volume subdriver + */ static int volume_read(char *p) { @@ -1673,8 +1797,7 @@ static int volume_write(char *buf) return -EINVAL; if (new_level != level) { /* mute doesn't change */ - cmos_cmd = new_level > level ? - TP_CMOS_VOLUME_UP : TP_CMOS_VOLUME_DOWN; + cmos_cmd = new_level > level ? TP_CMOS_VOLUME_UP : TP_CMOS_VOLUME_DOWN; inc = new_level > level ? 1 : -1; if (mute && (!cmos_eval(cmos_cmd) || @@ -1693,8 +1816,7 @@ static int volume_write(char *buf) } if (new_mute != mute) { /* level doesn't change */ - cmos_cmd = new_mute ? - TP_CMOS_VOLUME_MUTE : TP_CMOS_VOLUME_UP; + cmos_cmd = new_mute ? TP_CMOS_VOLUME_MUTE : TP_CMOS_VOLUME_UP; if (!cmos_eval(cmos_cmd) || !acpi_ec_write(volume_offset, level + new_mute)) @@ -1705,6 +1827,111 @@ static int volume_write(char *buf) return 0; } + +/************************************************************************* + * Fan subdriver + */ + +/* + * FAN ACCESS MODES + * + * IBMACPI_FAN_RD_ACPI_GFAN: + * ACPI GFAN method: returns fan level + * + * see IBMACPI_FAN_WR_ACPI_SFAN + * EC 0x2f not available if GFAN exists + * + * IBMACPI_FAN_WR_ACPI_SFAN: + * ACPI SFAN method: sets fan level, 0 (stop) to 7 (max) + * + * EC 0x2f might be available *for reading*, but never for writing. + * + * IBMACPI_FAN_WR_TPEC: + * ThinkPad EC register 0x2f (HFSP): fan control loop mode Supported + * on almost all ThinkPads + * + * Fan speed changes of any sort (including those caused by the + * disengaged mode) are usually done slowly by the firmware as the + * maximum ammount of fan duty cycle change per second seems to be + * limited. + * + * Reading is not available if GFAN exists. + * Writing is not available if SFAN exists. + * + * Bits + * 7 automatic mode engaged; + * (default operation mode of the ThinkPad) + * fan level is ignored in this mode. + * 6 disengage mode (takes precedence over bit 7); + * not available on all thinkpads. May disable + * the tachometer, and speeds up fan to 100% duty-cycle, + * which speeds it up far above the standard RPM + * levels. It is not impossible that it could cause + * hardware damage. + * 5-3 unused in some models. Extra bits for fan level + * in others, but still useless as all values above + * 7 map to the same speed as level 7 in these models. + * 2-0 fan level (0..7 usually) + * 0x00 = stop + * 0x07 = max (set when temperatures critical) + * Some ThinkPads may have other levels, see + * IBMACPI_FAN_WR_ACPI_FANS (X31/X40/X41) + * + * FIRMWARE BUG: on some models, EC 0x2f might not be initialized at + * boot. Apparently the EC does not intialize it, so unless ACPI DSDT + * does so, its initial value is meaningless (0x07). + * + * For firmware bugs, refer to: + * http://thinkwiki.org/wiki/Embedded_Controller_Firmware#Firmware_Issues + * + * ---- + * + * ThinkPad EC register 0x84 (LSB), 0x85 (MSB): + * Main fan tachometer reading (in RPM) + * + * This register is present on all ThinkPads with a new-style EC, and + * it is known not to be present on the A21m/e, and T22, as there is + * something else in offset 0x84 according to the ACPI DSDT. Other + * ThinkPads from this same time period (and earlier) probably lack the + * tachometer as well. + * + * Unfortunately a lot of ThinkPads with new-style ECs but whose firwmare + * was never fixed by IBM to report the EC firmware version string + * probably support the tachometer (like the early X models), so + * detecting it is quite hard. We need more data to know for sure. + * + * FIRMWARE BUG: always read 0x84 first, otherwise incorrect readings + * might result. + * + * FIRMWARE BUG: when EC 0x2f bit 6 is set (disengaged mode), this + * register is not invalidated in ThinkPads that disable tachometer + * readings. Thus, the tachometer readings go stale. + * + * For firmware bugs, refer to: + * http://thinkwiki.org/wiki/Embedded_Controller_Firmware#Firmware_Issues + * + * IBMACPI_FAN_WR_ACPI_FANS: + * ThinkPad X31, X40, X41. Not available in the X60. + * + * FANS ACPI handle: takes three arguments: low speed, medium speed, + * high speed. ACPI DSDT seems to map these three speeds to levels + * as follows: STOP LOW LOW MED MED HIGH HIGH HIGH HIGH + * (this map is stored on FAN0..FAN8 as "0,1,1,2,2,3,3,3,3") + * + * The speeds are stored on handles + * (FANA:FAN9), (FANC:FANB), (FANE:FAND). + * + * There are three default speed sets, acessible as handles: + * FS1L,FS1M,FS1H; FS2L,FS2M,FS2H; FS3L,FS3M,FS3H + * + * ACPI DSDT switches which set is in use depending on various + * factors. + * + * IBMACPI_FAN_WR_TPEC is also available and should be used to + * command the fan. The X31/X40/X41 seems to have 8 fan levels, + * but the ACPI tables just mention level 7. + */ + static enum fan_status_access_mode fan_status_access_mode; static enum fan_control_access_mode fan_control_access_mode; static enum fan_control_commands fan_control_commands; @@ -1716,6 +1943,14 @@ static void fan_watchdog_fire(struct work_struct *ignored); static int fan_watchdog_maxinterval; static DECLARE_DELAYED_WORK(fan_watchdog_task, fan_watchdog_fire); +IBM_HANDLE(fans, ec, "FANS"); /* X31, X40, X41 */ +IBM_HANDLE(gfan, ec, "GFAN", /* 570 */ + "\\FSPD", /* 600e/x, 770e, 770x */ + ); /* all others */ +IBM_HANDLE(sfan, ec, "SFAN", /* 570 */ + "JFNS", /* 770x-JL */ + ); /* all others */ + static int fan_init(void) { fan_status_access_mode = IBMACPI_FAN_NONE; @@ -1831,6 +2066,12 @@ static int fan_get_status(u8 *status) return 0; } +static void fan_exit(void) +{ + cancel_delayed_work(&fan_watchdog_task); + flush_scheduled_work(); +} + static int fan_get_speed(unsigned int *speed) { u8 hi, lo; @@ -1854,10 +2095,14 @@ static int fan_get_speed(unsigned int *speed) return 0; } -static void fan_exit(void) +static void fan_watchdog_fire(struct work_struct *ignored) { - cancel_delayed_work(&fan_watchdog_task); - flush_scheduled_work(); + printk(IBM_NOTICE "fan watchdog: enabling fan\n"); + if (fan_set_enable()) { + printk(IBM_ERR "fan watchdog: error while enabling fan\n"); + /* reschedule for later */ + fan_watchdog_reset(); + } } static void fan_watchdog_reset(void) @@ -1879,90 +2124,6 @@ static void fan_watchdog_reset(void) fan_watchdog_active = 0; } -static int fan_read(char *p) -{ - int len = 0; - int rc; - u8 status; - unsigned int speed = 0; - - switch (fan_status_access_mode) { - case IBMACPI_FAN_RD_ACPI_GFAN: - /* 570, 600e/x, 770e, 770x */ - if ((rc = fan_get_status(&status)) < 0) - return rc; - - len += sprintf(p + len, "status:\t\t%s\n" - "level:\t\t%d\n", - (status != 0) ? "enabled" : "disabled", status); - break; - - case IBMACPI_FAN_RD_TPEC: - /* all except 570, 600e/x, 770e, 770x */ - if ((rc = fan_get_status(&status)) < 0) - return rc; - - if (unlikely(!fan_control_status_known)) { - if (status != fan_control_initial_status) - fan_control_status_known = 1; - else - /* Return most likely status. In fact, it - * might be the only possible status */ - status = IBMACPI_FAN_EC_AUTO; - } - - len += sprintf(p + len, "status:\t\t%s\n", - (status != 0) ? "enabled" : "disabled"); - - /* No ThinkPad boots on disengaged mode, we can safely - * assume the tachometer is online if fan control status - * was unknown */ - if ((rc = fan_get_speed(&speed)) < 0) - return rc; - - len += sprintf(p + len, "speed:\t\t%d\n", speed); - - if (status & IBMACPI_FAN_EC_DISENGAGED) - /* Disengaged mode takes precedence */ - len += sprintf(p + len, "level:\t\tdisengaged\n"); - else if (status & IBMACPI_FAN_EC_AUTO) - len += sprintf(p + len, "level:\t\tauto\n"); - else - len += sprintf(p + len, "level:\t\t%d\n", status); - break; - - case IBMACPI_FAN_NONE: - default: - len += sprintf(p + len, "status:\t\tnot supported\n"); - } - - if (fan_control_commands & IBMACPI_FAN_CMD_LEVEL) { - len += sprintf(p + len, "commands:\tlevel <level>"); - - switch (fan_control_access_mode) { - case IBMACPI_FAN_WR_ACPI_SFAN: - len += sprintf(p + len, " (<level> is 0-7)\n"); - break; - - default: - len += sprintf(p + len, " (<level> is 0-7, " - "auto, disengaged)\n"); - break; - } - } - - if (fan_control_commands & IBMACPI_FAN_CMD_ENABLE) - len += sprintf(p + len, "commands:\tenable, disable\n" - "commands:\twatchdog <timeout> (<timeout> is 0 (off), " - "1-120 (seconds))\n"); - - if (fan_control_commands & IBMACPI_FAN_CMD_SPEED) - len += sprintf(p + len, "commands:\tspeed <speed>" - " (<speed> is 0-65535)\n"); - - return len; -} - static int fan_set_level(int level) { switch (fan_control_access_mode) { @@ -2074,6 +2235,90 @@ static int fan_set_speed(int speed) return 0; } +static int fan_read(char *p) +{ + int len = 0; + int rc; + u8 status; + unsigned int speed = 0; + + switch (fan_status_access_mode) { + case IBMACPI_FAN_RD_ACPI_GFAN: + /* 570, 600e/x, 770e, 770x */ + if ((rc = fan_get_status(&status)) < 0) + return rc; + + len += sprintf(p + len, "status:\t\t%s\n" + "level:\t\t%d\n", + (status != 0) ? "enabled" : "disabled", status); + break; + + case IBMACPI_FAN_RD_TPEC: + /* all except 570, 600e/x, 770e, 770x */ + if ((rc = fan_get_status(&status)) < 0) + return rc; + + if (unlikely(!fan_control_status_known)) { + if (status != fan_control_initial_status) + fan_control_status_known = 1; + else + /* Return most likely status. In fact, it + * might be the only possible status */ + status = IBMACPI_FAN_EC_AUTO; + } + + len += sprintf(p + len, "status:\t\t%s\n", + (status != 0) ? "enabled" : "disabled"); + + /* No ThinkPad boots on disengaged mode, we can safely + * assume the tachometer is online if fan control status + * was unknown */ + if ((rc = fan_get_speed(&speed)) < 0) + return rc; + + len += sprintf(p + len, "speed:\t\t%d\n", speed); + + if (status & IBMACPI_FAN_EC_DISENGAGED) + /* Disengaged mode takes precedence */ + len += sprintf(p + len, "level:\t\tdisengaged\n"); + else if (status & IBMACPI_FAN_EC_AUTO) + len += sprintf(p + len, "level:\t\tauto\n"); + else + len += sprintf(p + len, "level:\t\t%d\n", status); + break; + + case IBMACPI_FAN_NONE: + default: + len += sprintf(p + len, "status:\t\tnot supported\n"); + } + + if (fan_control_commands & IBMACPI_FAN_CMD_LEVEL) { + len += sprintf(p + len, "commands:\tlevel <level>"); + + switch (fan_control_access_mode) { + case IBMACPI_FAN_WR_ACPI_SFAN: + len += sprintf(p + len, " (<level> is 0-7)\n"); + break; + + default: + len += sprintf(p + len, " (<level> is 0-7, " + "auto, disengaged)\n"); + break; + } + } + + if (fan_control_commands & IBMACPI_FAN_CMD_ENABLE) + len += sprintf(p + len, "commands:\tenable, disable\n" + "commands:\twatchdog <timeout> (<timeout> is 0 (off), " + "1-120 (seconds))\n"); + + if (fan_control_commands & IBMACPI_FAN_CMD_SPEED) + len += sprintf(p + len, "commands:\tspeed <speed>" + " (<speed> is 0-65535)\n"); + + return len; +} + static int fan_write_cmd_level(const char *cmd, int *rc) { int level; @@ -2171,16 +2416,18 @@ static int fan_write(char *buf) return rc; } -static void fan_watchdog_fire(struct work_struct *ignored) -{ - printk(IBM_NOTICE "fan watchdog: enabling fan\n"); - if (fan_set_enable()) { - printk(IBM_ERR "fan watchdog: error while enabling fan\n"); - /* reschedule for later */ - fan_watchdog_reset(); - } -} +/**************************************************************************** + **************************************************************************** + * + * Infrastructure + * + **************************************************************************** + ****************************************************************************/ +/* /proc support */ +static struct proc_dir_entry *proc_dir = NULL; + +/* Subdriver registry */ static struct ibm_struct ibms[] = { { .name = "driver", @@ -2301,127 +2548,9 @@ static struct ibm_struct ibms[] = { }, }; -static int dispatch_read(char *page, char **start, off_t off, int count, - int *eof, void *data) -{ - struct ibm_struct *ibm = data; - int len; - - if (!ibm || !ibm->read) - return -EINVAL; - - len = ibm->read(page); - if (len < 0) - return len; - - if (len <= off + count) - *eof = 1; - *start = page + off; - len -= off; - if (len > count) - len = count; - if (len < 0) - len = 0; - - return len; -} - -static int dispatch_write(struct file *file, const char __user * userbuf, - unsigned long count, void *data) -{ - struct ibm_struct *ibm = data; - char *kernbuf; - int ret; - - if (!ibm || !ibm->write) - return -EINVAL; - - kernbuf = kmalloc(count + 2, GFP_KERNEL); - if (!kernbuf) - return -ENOMEM; - - if (copy_from_user(kernbuf, userbuf, count)) { - kfree(kernbuf); - return -EFAULT; - } - - kernbuf[count] = 0; - strcat(kernbuf, ","); - ret = ibm->write(kernbuf); - if (ret == 0) - ret = count; - - kfree(kernbuf); - - return ret; -} - -static void dispatch_notify(acpi_handle handle, u32 event, void *data) -{ - struct ibm_struct *ibm = data; - - if (!ibm || !ibm->notify) - return; - - ibm->notify(ibm, event); -} - -static int __init setup_notify(struct ibm_struct *ibm) -{ - acpi_status status; - int ret; - - if (!*ibm->handle) - return 0; - - ret = acpi_bus_get_device(*ibm->handle, &ibm->device); - if (ret < 0) { - printk(IBM_ERR "%s device not present\n", ibm->name); - return 0; - } - - acpi_driver_data(ibm->device) = ibm; - sprintf(acpi_device_class(ibm->device), "%s/%s", IBM_NAME, ibm->name); - - status = acpi_install_notify_handler(*ibm->handle, ibm->type, - dispatch_notify, ibm); - if (ACPI_FAILURE(status)) { - printk(IBM_ERR "acpi_install_notify_handler(%s) failed: %d\n", - ibm->name, status); - return -ENODEV; - } - ibm->notify_installed = 1; - return 0; -} - -static int __init ibm_device_add(struct acpi_device *device) -{ - return 0; -} - -static int __init register_ibmacpi_subdriver(struct ibm_struct *ibm) -{ - int ret; - - ibm->driver = kzalloc(sizeof(struct acpi_driver), GFP_KERNEL); - if (!ibm->driver) { - printk(IBM_ERR "kmalloc(ibm->driver) failed\n"); - return -1; - } - - sprintf(ibm->driver->name, "%s_%s", IBM_NAME, ibm->name); - ibm->driver->ids = ibm->hid; - ibm->driver->ops.add = &ibm_device_add; - - ret = acpi_bus_register_driver(ibm->driver); - if (ret < 0) { - printk(IBM_ERR "acpi_bus_register_driver(%s) failed: %d\n", - ibm->hid, ret); - kfree(ibm->driver); - } - - return ret; -} +/* + * Module and infrastructure proble, init and exit handling + */ static int __init ibm_init(struct ibm_struct *ibm) { @@ -2489,27 +2618,35 @@ static void ibm_exit(struct ibm_struct *ibm) } } -static void __init ibm_handle_init(char *name, - acpi_handle * handle, acpi_handle parent, - char **paths, int num_paths, char **path) +/* Probing */ + +static char *ibm_thinkpad_ec_found = NULL; + +static char* __init check_dmi_for_ec(void) { - int i; - acpi_status status; + struct dmi_device *dev = NULL; + char ec_fw_string[18]; - for (i = 0; i < num_paths; i++) { - status = acpi_get_handle(parent, paths[i], handle); - if (ACPI_SUCCESS(status)) { - *path = paths[i]; - return; + /* + * ThinkPad T23 or newer, A31 or newer, R50e or newer, + * X32 or newer, all Z series; Some models must have an + * up-to-date BIOS or they will not be detected. + * + * See http://thinkwiki.org/wiki/List_of_DMI_IDs + */ + while ((dev = dmi_find_device(DMI_DEV_TYPE_OEM_STRING, NULL, dev))) { + if (sscanf(dev->name, + "IBM ThinkPad Embedded Controller -[%17c", + ec_fw_string) == 1) { + ec_fw_string[sizeof(ec_fw_string) - 1] = 0; + ec_fw_string[strcspn(ec_fw_string, " ]")] = 0; + return kstrdup(ec_fw_string, GFP_KERNEL); } } - - *handle = NULL; + return NULL; } -#define IBM_HANDLE_INIT(object) \ - ibm_handle_init(#object, &object##_handle, *object##_parent, \ - object##_paths, ARRAY_SIZE(object##_paths), &object##_path) +/* Module init, exit, parameters */ static int __init set_ibm_param(const char *val, struct kernel_param *kp) { @@ -2527,6 +2664,9 @@ static int __init set_ibm_param(const char *val, struct kernel_param *kp) return -EINVAL; } +static int experimental; +module_param(experimental, int, 0); + #define IBM_PARAM(feature) \ module_param_call(feature, set_ibm_param, NULL, NULL, 0) @@ -2548,44 +2688,6 @@ IBM_PARAM(brightness); IBM_PARAM(volume); IBM_PARAM(fan); -static void acpi_ibm_exit(void) -{ - int i; - - for (i = ARRAY_SIZE(ibms) - 1; i >= 0; i--) - ibm_exit(&ibms[i]); - - if (proc_dir) - remove_proc_entry(IBM_DIR, acpi_root_dir); - - if (ibm_thinkpad_ec_found) - kfree(ibm_thinkpad_ec_found); -} - -static char* __init check_dmi_for_ec(void) -{ - struct dmi_device *dev = NULL; - char ec_fw_string[18]; - - /* - * ThinkPad T23 or newer, A31 or newer, R50e or newer, - * X32 or newer, all Z series; Some models must have an - * up-to-date BIOS or they will not be detected. - * - * See http://thinkwiki.org/wiki/List_of_DMI_IDs - */ - while ((dev = dmi_find_device(DMI_DEV_TYPE_OEM_STRING, NULL, dev))) { - if (sscanf(dev->name, - "IBM ThinkPad Embedded Controller -[%17c", - ec_fw_string) == 1) { - ec_fw_string[sizeof(ec_fw_string) - 1] = 0; - ec_fw_string[strcspn(ec_fw_string, " ]")] = 0; - return kstrdup(ec_fw_string, GFP_KERNEL); - } - } - return NULL; -} - static int __init acpi_ibm_init(void) { int ret, i; @@ -2651,5 +2753,19 @@ static int __init acpi_ibm_init(void) return 0; } +static void acpi_ibm_exit(void) +{ + int i; + + for (i = ARRAY_SIZE(ibms) - 1; i >= 0; i--) + ibm_exit(&ibms[i]); + + if (proc_dir) + remove_proc_entry(IBM_DIR, acpi_root_dir); + + if (ibm_thinkpad_ec_found) + kfree(ibm_thinkpad_ec_found); +} + module_init(acpi_ibm_init); module_exit(acpi_ibm_exit); -- 1.5.0.3 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH 5/6] ACPI: ibm-acpi: update copyright notice 2007-03-12 0:20 ` [PATCH 4/6] ACPI: ibm-acpi: organize code Henrique de Moraes Holschuh @ 2007-03-12 0:20 ` Henrique de Moraes Holschuh 2007-03-12 0:20 ` [PATCH 6/6] ACPI: ibm-acpi: update documentation Henrique de Moraes Holschuh 0 siblings, 1 reply; 60+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-12 0:20 UTC (permalink / raw) To: lenb; +Cc: linux-acpi, ibm-acpi-devel, Henrique de Moraes Holschuh Update copyright and license info on the source code comments. No functional changes. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> --- drivers/acpi/ibm_acpi.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/acpi/ibm_acpi.c b/drivers/acpi/ibm_acpi.c index 7cd2888..85116c2 100644 --- a/drivers/acpi/ibm_acpi.c +++ b/drivers/acpi/ibm_acpi.c @@ -3,7 +3,7 @@ * * * Copyright (C) 2004-2005 Borislav Deianov <borislav@users.sf.net> - * Copyright (C) 2006 Henrique de Moraes Holschuh <hmh@hmh.eng.br> + * Copyright (C) 2006-2007 Henrique de Moraes Holschuh <hmh@hmh.eng.br> * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -17,7 +17,8 @@ * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA + * 02110-1301, USA. */ #define IBM_VERSION "0.13" -- 1.5.0.3 ^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH 6/6] ACPI: ibm-acpi: update documentation 2007-03-12 0:20 ` [PATCH 5/6] ACPI: ibm-acpi: update copyright notice Henrique de Moraes Holschuh @ 2007-03-12 0:20 ` Henrique de Moraes Holschuh 0 siblings, 0 replies; 60+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-12 0:20 UTC (permalink / raw) To: lenb; +Cc: linux-acpi, ibm-acpi-devel, Henrique de Moraes Holschuh Update documentation header, and relocate a hunk of text that was missplaced. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> --- Documentation/ibm-acpi.txt | 85 +++++++++++++------------------------------- 1 files changed, 25 insertions(+), 60 deletions(-) diff --git a/Documentation/ibm-acpi.txt b/Documentation/ibm-acpi.txt index cdcef01..f409f4b 100644 --- a/Documentation/ibm-acpi.txt +++ b/Documentation/ibm-acpi.txt @@ -1,16 +1,17 @@ IBM ThinkPad ACPI Extras Driver - Version 0.12 - 17 August 2005 + Version 0.13 + 31 December 2006 Borislav Deianov <borislav@users.sf.net> + Henrique de Moraes Holschuh <hmh@hmh.eng.br> http://ibm-acpi.sf.net/ This is a Linux ACPI driver for the IBM ThinkPad laptops. It supports various features of these laptops which are accessible through the -ACPI framework but not otherwise supported by the generic Linux ACPI -drivers. +ACPI framework but not otherwise fully supported by the generic Linux +ACPI drivers. Status @@ -638,6 +639,26 @@ The ThinkPad's ACPI DSDT code will reprogram the fan on its own when certain conditions are met. It will override any fan programming done through ibm-acpi. +The ibm-acpi kernel driver can be programmed to revert the fan level +to a safe setting if userspace does not issue one of the fan commands: +"enable", "disable", "level" or "watchdog" within a configurable +ammount of time. To do this, use the "watchdog" command. + + echo 'watchdog <interval>' > /proc/acpi/ibm/fan + +Interval is the ammount of time in seconds to wait for one of the +above mentioned fan commands before reseting the fan level to a safe +one. If set to zero, the watchdog is disabled (default). When the +watchdog timer runs out, it does the exact equivalent of the "enable" +fan command. + +Note that the watchdog timer stops after it enables the fan. It will +be rearmed again automatically (using the same interval) when one of +the above mentioned fan commands is received. The fan watchdog is, +therefore, not suitable to protect against fan mode changes made +through means other than the "enable", "disable", and "level" fan +commands. + EXPERIMENTAL: WAN -- /proc/acpi/ibm/wan --------------------------------------- @@ -670,59 +691,3 @@ example: modprobe ibm_acpi hotkey=enable,0xffff video=auto_disable -The ibm-acpi kernel driver can be programmed to revert the fan level -to a safe setting if userspace does not issue one of the fan commands: -"enable", "disable", "level" or "watchdog" within a configurable -ammount of time. To do this, use the "watchdog" command. - - echo 'watchdog <interval>' > /proc/acpi/ibm/fan - -Interval is the ammount of time in seconds to wait for one of the -above mentioned fan commands before reseting the fan level to a safe -one. If set to zero, the watchdog is disabled (default). When the -watchdog timer runs out, it does the exact equivalent of the "enable" -fan command. - -Note that the watchdog timer stops after it enables the fan. It will -be rearmed again automatically (using the same interval) when one of -the above mentioned fan commands is received. The fan watchdog is, -therefore, not suitable to protect against fan mode changes made -through means other than the "enable", "disable", and "level" fan -commands. - - -Example Configuration ---------------------- - -The ACPI support in the kernel is intended to be used in conjunction -with a user-space daemon, acpid. The configuration files for this -daemon control what actions are taken in response to various ACPI -events. An example set of configuration files are included in the -config/ directory of the tarball package available on the web -site. Note that these are provided for illustration purposes only and -may need to be adapted to your particular setup. - -The following utility scripts are used by the example action -scripts (included with ibm-acpi for completeness): - - /usr/local/sbin/idectl -- from the hdparm source distribution, - see http://www.ibiblio.org/pub/Linux/system/hardware - /usr/local/sbin/laptop_mode -- from the Linux kernel source - distribution, see Documentation/laptop-mode.txt - /sbin/service -- comes with Redhat/Fedora distributions - /usr/sbin/hibernate -- from the Software Suspend 2 distribution, - see http://softwaresuspend.berlios.de/ - -Toan T Nguyen <ntt@physics.ucla.edu> notes that Suse uses the -powersave program to suspend ('powersave --suspend-to-ram') or -hibernate ('powersave --suspend-to-disk'). This means that the -hibernate script is not needed on that distribution. - -Henrik Brix Andersen <brix@gentoo.org> has written a Gentoo ACPI event -handler script for the X31. You can get the latest version from -http://dev.gentoo.org/~brix/files/x31.sh - -David Schweikert <dws@ee.eth.ch> has written an alternative blank.sh -script which works on Debian systems. This scripts has now been -extended to also work on Fedora systems and included as the default -blank.sh in the distribution. -- 1.5.0.3 ^ permalink raw reply related [flat|nested] 60+ messages in thread
* Re: [GIT PULL] ibm-acpi changes acpi-test/2.6.22 2007-03-12 0:20 [GIT PULL] ibm-acpi changes acpi-test/2.6.22 Henrique de Moraes Holschuh 2007-03-12 0:20 ` [PATCH 1/6] ACPI: ibm-acpi: kill trailing whitespace Henrique de Moraes Holschuh @ 2007-03-12 0:54 ` Len Brown 2007-03-12 1:27 ` Henrique de Moraes Holschuh 1 sibling, 1 reply; 60+ messages in thread From: Len Brown @ 2007-03-12 0:54 UTC (permalink / raw) To: Henrique de Moraes Holschuh; +Cc: linux-acpi, ibm-acpi-devel On Sunday 11 March 2007 20:20, Henrique de Moraes Holschuh wrote: > Len, > > Please pull from: > git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git > branch for-upstream/acpi-test > > to receive the following patches: > ACPI: ibm-acpi: kill trailing whitespace > ACPI: ibm-acpi: rename some identifiers > ACPI: ibm-acpi: add header file > ACPI: ibm-acpi: organize code > ACPI: ibm-acpi: update copyright notice > ACPI: ibm-acpi: update documentation > > Please merge them into acpi-test, targetting 2.6.22. series applied to acpi-test. BTW. do you have a plan for moving this driver to drivers/misc? thanks, -Len ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [GIT PULL] ibm-acpi changes acpi-test/2.6.22 2007-03-12 0:54 ` [GIT PULL] ibm-acpi changes acpi-test/2.6.22 Len Brown @ 2007-03-12 1:27 ` Henrique de Moraes Holschuh 2007-03-15 3:10 ` [GIT PULL] ibm-acpi move to drivers/misc Henrique de Moraes Holschuh 0 siblings, 1 reply; 60+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-12 1:27 UTC (permalink / raw) To: Len Brown; +Cc: linux-acpi, ibm-acpi-devel On Sun, 11 Mar 2007, Len Brown wrote: > > Please merge them into acpi-test, targetting 2.6.22. > > series applied to acpi-test. Thanks. > BTW. do you have a plan for moving this driver to drivers/misc? Whenever you want to. Would you like me to prepare patches for acpi-test, targetting 2.6.22 ? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ^ permalink raw reply [flat|nested] 60+ messages in thread
* [GIT PULL] ibm-acpi move to drivers/misc 2007-03-12 1:27 ` Henrique de Moraes Holschuh @ 2007-03-15 3:10 ` Henrique de Moraes Holschuh 2007-03-15 3:12 ` [PATCH] ACPI: ibm-acpi: move driver to drivers/misc hierarchy Henrique de Moraes Holschuh 0 siblings, 1 reply; 60+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-15 3:10 UTC (permalink / raw) To: Len Brown; +Cc: linux-acpi, ibm-acpi-devel Len, Please pull from: git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git branch for-upstream/acpi-test to receive the following patch, targetted at 2.6.22: ACPI: ibm-acpi: move driver to drivers/misc hierarchy Note: the branch I am asking you to pull from is the same branch I asked you to pull for acpi-test before, rebased to your current linus branch. So, it contains the other patches you have already accepted, whitespace-stripped by git rebase. I hope this doesn't cause you trouble for the pull, if it does, please tell me how you'd rather I prepare such branches in the future, when it is impossible to have them against Linus' tree. The patch follows this message in email format, using git format-patch -M to reduce the noise tremendously. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ^ permalink raw reply [flat|nested] 60+ messages in thread
* [PATCH] ACPI: ibm-acpi: move driver to drivers/misc hierarchy 2007-03-15 3:10 ` [GIT PULL] ibm-acpi move to drivers/misc Henrique de Moraes Holschuh @ 2007-03-15 3:12 ` Henrique de Moraes Holschuh 2007-03-15 6:06 ` CONFIG_IBM_BAY Len Brown 0 siblings, 1 reply; 60+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-15 3:12 UTC (permalink / raw) To: Len Brown; +Cc: linux-acpi, ibm-acpi-devel ibm-acpi is not an ACPICA driver, so move it to drivers/misc as per Len Brown's request. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> --- drivers/acpi/Kconfig | 37 ------------------------------------- drivers/acpi/Makefile | 1 - drivers/misc/Kconfig | 37 +++++++++++++++++++++++++++++++++++++ drivers/misc/Makefile | 1 + drivers/{acpi => misc}/ibm_acpi.c | 0 drivers/{acpi => misc}/ibm_acpi.h | 0 6 files changed, 38 insertions(+), 38 deletions(-) rename drivers/{acpi => misc}/ibm_acpi.c (100%) rename drivers/{acpi => misc}/ibm_acpi.h (100%) diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index e2ce4a9..45c4315 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -218,43 +218,6 @@ config ACPI_ASUS NOTE: This driver is deprecated and will probably be removed soon, use asus-laptop instead. -config ACPI_IBM - tristate "IBM ThinkPad Laptop Extras" - depends on X86 - select BACKLIGHT_CLASS_DEVICE - ---help--- - This is a Linux ACPI driver for the IBM ThinkPad laptops. It adds - support for Fn-Fx key combinations, Bluetooth control, video - output switching, ThinkLight control, UltraBay eject and more. - For more information about this driver see <file:Documentation/ibm-acpi.txt> - and <http://ibm-acpi.sf.net/> . - - If you have an IBM ThinkPad laptop, say Y or M here. - -config ACPI_IBM_DOCK - bool "Legacy Docking Station Support" - depends on ACPI_IBM - depends on ACPI_DOCK=n - default n - ---help--- - Allows the ibm_acpi driver to handle docking station events. - This support is obsoleted by CONFIG_HOTPLUG_PCI_ACPI. It will - allow locking and removing the laptop from the docking station, - but will not properly connect PCI devices. - - If you are not sure, say N here. - -config ACPI_IBM_BAY - bool "Legacy Removable Bay Support" - depends on ACPI_IBM - default y - ---help--- - Allows the ibm_acpi driver to handle removable bays. It will allow - disabling the device in the bay, and also generate notifications when - the bay lever is ejected or inserted. - - If you are not sure, say Y here. - config ACPI_TOSHIBA tristate "Toshiba Laptop Extras" depends on X86 diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile index 5956e9f..92642ab 100644 --- a/drivers/acpi/Makefile +++ b/drivers/acpi/Makefile @@ -55,7 +55,6 @@ obj-$(CONFIG_ACPI_SYSTEM) += system.o event.o obj-$(CONFIG_ACPI_DEBUG) += debug.o obj-$(CONFIG_ACPI_NUMA) += numa.o obj-$(CONFIG_ACPI_ASUS) += asus_acpi.o -obj-$(CONFIG_ACPI_IBM) += ibm_acpi.o obj-$(CONFIG_ACPI_TOSHIBA) += toshiba_acpi.o obj-$(CONFIG_ACPI_HOTPLUG_MEMORY) += acpi_memhotplug.o obj-y += cm_sbs.o diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 80b199f..5d2bcbf 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -122,4 +122,41 @@ config SONY_LAPTOP Read <file:Documentation/sony-laptop.txt> for more information. +config ACPI_IBM + tristate "IBM ThinkPad Laptop Extras" + depends on X86 && ACPI + select BACKLIGHT_CLASS_DEVICE + ---help--- + This is a Linux ACPI driver for the IBM ThinkPad laptops. It adds + support for Fn-Fx key combinations, Bluetooth control, video + output switching, ThinkLight control, UltraBay eject and more. + For more information about this driver see <file:Documentation/ibm-acpi.txt> + and <http://ibm-acpi.sf.net/> . + + If you have an IBM ThinkPad laptop, say Y or M here. + +config ACPI_IBM_DOCK + bool "Legacy Docking Station Support" + depends on ACPI_IBM + depends on ACPI_DOCK=n + default n + ---help--- + Allows the ibm_acpi driver to handle docking station events. + This support is obsoleted by CONFIG_HOTPLUG_PCI_ACPI. It will + allow locking and removing the laptop from the docking station, + but will not properly connect PCI devices. + + If you are not sure, say N here. + +config ACPI_IBM_BAY + bool "Legacy Removable Bay Support" + depends on ACPI_IBM + default y + ---help--- + Allows the ibm_acpi driver to handle removable bays. It will allow + disabling the device in the bay, and also generate notifications when + the bay lever is ejected or inserted. + + If you are not sure, say Y here. + endmenu diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index 7793ccd..848b398 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -12,3 +12,4 @@ obj-$(CONFIG_TIFM_CORE) += tifm_core.o obj-$(CONFIG_TIFM_7XX1) += tifm_7xx1.o obj-$(CONFIG_SGI_IOC4) += ioc4.o obj-$(CONFIG_SONY_LAPTOP) += sony-laptop.o +obj-$(CONFIG_ACPI_IBM) += ibm_acpi.o diff --git a/drivers/acpi/ibm_acpi.c b/drivers/misc/ibm_acpi.c similarity index 100% rename from drivers/acpi/ibm_acpi.c rename to drivers/misc/ibm_acpi.c diff --git a/drivers/acpi/ibm_acpi.h b/drivers/misc/ibm_acpi.h similarity index 100% rename from drivers/acpi/ibm_acpi.h rename to drivers/misc/ibm_acpi.h -- 1.5.0.3 -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ^ permalink raw reply related [flat|nested] 60+ messages in thread
* CONFIG_IBM_BAY 2007-03-15 3:12 ` [PATCH] ACPI: ibm-acpi: move driver to drivers/misc hierarchy Henrique de Moraes Holschuh @ 2007-03-15 6:06 ` Len Brown 2007-03-15 13:39 ` CONFIG_IBM_BAY Henrique de Moraes Holschuh 0 siblings, 1 reply; 60+ messages in thread From: Len Brown @ 2007-03-15 6:06 UTC (permalink / raw) To: Henrique de Moraes Holschuh, Kristen Carlson Accardi Cc: linux-acpi, ibm-acpi-devel > +config ACPI_IBM_BAY Should this depend on ACPI_BAY=n? > + bool "Legacy Removable Bay Support" > + depends on ACPI_IBM > + default y > + ---help--- > + Allows the ibm_acpi driver to handle removable bays. It will allow > + disabling the device in the bay, and also generate notifications when > + the bay lever is ejected or inserted. > + > + If you are not sure, say Y here. > ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: CONFIG_IBM_BAY 2007-03-15 6:06 ` CONFIG_IBM_BAY Len Brown @ 2007-03-15 13:39 ` Henrique de Moraes Holschuh 2007-03-15 15:06 ` CONFIG_IBM_BAY Kristen Carlson Accardi 0 siblings, 1 reply; 60+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-15 13:39 UTC (permalink / raw) To: Len Brown; +Cc: Kristen Carlson Accardi, linux-acpi, ibm-acpi-devel On Thu, 15 Mar 2007, Len Brown wrote: > > +config ACPI_IBM_BAY > > Should this depend on ACPI_BAY=n? It should allow both as modules, so that the user can choose which one to run. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: CONFIG_IBM_BAY 2007-03-15 13:39 ` CONFIG_IBM_BAY Henrique de Moraes Holschuh @ 2007-03-15 15:06 ` Kristen Carlson Accardi 2007-03-15 17:55 ` CONFIG_IBM_BAY Henrique de Moraes Holschuh 0 siblings, 1 reply; 60+ messages in thread From: Kristen Carlson Accardi @ 2007-03-15 15:06 UTC (permalink / raw) To: Henrique de Moraes Holschuh; +Cc: Len Brown, linux-acpi, ibm-acpi-devel On Thu, 15 Mar 2007 10:39:00 -0300 Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote: > On Thu, 15 Mar 2007, Len Brown wrote: > > > +config ACPI_IBM_BAY > > > > Should this depend on ACPI_BAY=n? > > It should allow both as modules, so that the user can choose which one to > run. Doesn't this option enable support for controlling the bay device via ibm_acpi? If so - if you compile this one, then the user who chooses to use bay.ko instead to control the bay can not use ibm_acpi at all to control the remaining functionality. I feel this should be dependent on ACPI_BAY=n. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: CONFIG_IBM_BAY 2007-03-15 15:06 ` CONFIG_IBM_BAY Kristen Carlson Accardi @ 2007-03-15 17:55 ` Henrique de Moraes Holschuh 2007-03-15 18:01 ` CONFIG_IBM_BAY Kristen Carlson Accardi 2007-03-15 18:22 ` CONFIG_IBM_BAY Kristen Carlson Accardi 0 siblings, 2 replies; 60+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-15 17:55 UTC (permalink / raw) To: Kristen Carlson Accardi; +Cc: Len Brown, linux-acpi, ibm-acpi-devel On Thu, 15 Mar 2007, Kristen Carlson Accardi wrote: > Doesn't this option enable support for controlling the bay device via ibm_acpi? Yes, but the problem is that ACPI_BAY is not nearly good enough in ThinkPads... yet. > If so - if you compile this one, then the user who chooses to use bay.ko instead > to control the bay can not use ibm_acpi at all to control the remaining > functionality. I feel this should be dependent on ACPI_BAY=n. Please look at the patch I just sent. It allows ibm-acpi to load if ACPI_BAY is loaded. It will, of course, cause ACPI_BAY to refuse to load if ibm-acpi is already loaded, but that's probably fine as ACPI_BAY has just a single function. Note that these are all just stop-gap measures. We either need to have ACPI_BAY do everything needed in ThinkPads (like handling bay batteries), or to make both drivers work together, or I'll just pull all the ACPI_BAY functionality into ibm-acpi (and then I will definately conflict with ACPI_BAY). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: CONFIG_IBM_BAY 2007-03-15 17:55 ` CONFIG_IBM_BAY Henrique de Moraes Holschuh @ 2007-03-15 18:01 ` Kristen Carlson Accardi [not found] ` <20070315110156.09e80b99.kristen.c.accardi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 2007-03-15 18:22 ` CONFIG_IBM_BAY Kristen Carlson Accardi 1 sibling, 1 reply; 60+ messages in thread From: Kristen Carlson Accardi @ 2007-03-15 18:01 UTC (permalink / raw) To: Henrique de Moraes Holschuh; +Cc: Len Brown, linux-acpi, ibm-acpi-devel On Thu, 15 Mar 2007 14:55:06 -0300 Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote: > Note that these are all just stop-gap measures. We either need to have > ACPI_BAY do everything needed in ThinkPads (like handling bay batteries), or > to make both drivers work together, or I'll just pull all the ACPI_BAY > functionality into ibm-acpi (and then I will definately conflict with > ACPI_BAY). I think we should focus our efforts on a generic (non platform specific) solution that can work across many laptops (i.e. ACPI_BAY). Let's make the bay driver do what it should - I've got a stack of modules for Dell module bays we can check against too - and I believe that Dell also supports charging the battery in the module bay. I am happy to take patches to the bay driver, and am also happy to help develop them. I don't have handling content of bay changes on my radar at the moment, so if you do have time to work on this, that would be great. I am happy to test on the set of laptops I've got. Thanks, Kristen ^ permalink raw reply [flat|nested] 60+ messages in thread
[parent not found: <20070315110156.09e80b99.kristen.c.accardi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]
* Re: CONFIG_IBM_BAY [not found] ` <20070315110156.09e80b99.kristen.c.accardi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> @ 2007-03-15 19:31 ` Henrique de Moraes Holschuh 2007-03-15 19:50 ` CONFIG_IBM_BAY Kristen Carlson Accardi ` (2 more replies) 0 siblings, 3 replies; 60+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-15 19:31 UTC (permalink / raw) To: Kristen Carlson Accardi Cc: linux-acpi-u79uwXL29TY76Z2rM5mHXA, ibm-acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Len Brown On Thu, 15 Mar 2007, Kristen Carlson Accardi wrote: > I think we should focus our efforts on a generic (non platform specific) > solution that can work across many laptops (i.e. ACPI_BAY). Let's make Agreed, as long as that doesn't mean we have to pollute ACPI_BAY with a truckload of crap required to deal with vendor/model-specific idioticities. I hope ThinkPads are not like that, but I am not sure, and I'd feel bad about adding a lot of quirks to ACPI_BAY because of ThinkPad weirdness :p Otherwise, it would be best to allow model-specific modules to provide extra functionality for ACPI_BAY, that way we have generic code, and we can contain the braindamage to where it belongs (e.g. in ibm-acpi). > so if you do have time to work on this, that would be great. I am happy > to test on the set of laptops I've got. I will see what I can do. My "first approach" at a requirements list for a proper bay module are as follows: 1. It will handle all device types (ATAPI, PATA, SATA, batteries); 2. It will do the right thing on plug and unplug. This means telling the rest of the kernel to disable the device in the bay, for example. Right now we shutdown one end of the PATA/SATA link on ThinkPads eletrically, and leave libata to scream blood murder until it disables its end due to too many retries, for example; 3. It will allow model-specific drivers (like ibm-acpi) to be notified of bay events (callbacks or a notifier chain, since ACPICA doesn't allow for more than one driver notifier per handle) and to request an immediate attempt of ejection or hotplug/bay device change verification. Some thinkpads benefit from an eject before S3 sleep -- as long as what is inside is not a battery... I don't see why the generic driver could not do all of the above. But it will take a while to get there :-) And no, ibm-acpi can't do much more than (1). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: CONFIG_IBM_BAY 2007-03-15 19:31 ` CONFIG_IBM_BAY Henrique de Moraes Holschuh @ 2007-03-15 19:50 ` Kristen Carlson Accardi 2007-03-18 5:38 ` CONFIG_IBM_BAY Tejun Heo 2007-03-15 20:31 ` [ibm-acpi-devel] CONFIG_IBM_BAY Shem Multinymous 2007-03-19 12:04 ` Theodore Tso 2 siblings, 1 reply; 60+ messages in thread From: Kristen Carlson Accardi @ 2007-03-15 19:50 UTC (permalink / raw) To: Henrique de Moraes Holschuh Cc: Len Brown, linux-acpi, ibm-acpi-devel, linux-ide On Thu, 15 Mar 2007 16:31:24 -0300 Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote: > On Thu, 15 Mar 2007, Kristen Carlson Accardi wrote: > > I think we should focus our efforts on a generic (non platform specific) > > solution that can work across many laptops (i.e. ACPI_BAY). Let's make > > Agreed, as long as that doesn't mean we have to pollute ACPI_BAY with a > truckload of crap required to deal with vendor/model-specific idioticities. > I hope ThinkPads are not like that, but I am not sure, and I'd feel bad > about adding a lot of quirks to ACPI_BAY because of ThinkPad weirdness :p So for the dock driver I supplied an interface to allow interested subsystems to register handlers to be called by the dock driver during dock events. This allowed me to let individual subsystems do whatever unique things they needed to do when the dock was either inserted or removed. For the bay driver, we could actually provide a mechanism to allow platform specific drivers to take advantage of the generic stuff, but then have the bay driver call a registered handler to do some weird specific thing - this way at least we are sharing the bulk of our code and weird stuff can be contained somewhere else. > > Otherwise, it would be best to allow model-specific modules to provide extra > functionality for ACPI_BAY, that way we have generic code, and we can > contain the braindamage to where it belongs (e.g. in ibm-acpi). > > > so if you do have time to work on this, that would be great. I am happy > > to test on the set of laptops I've got. > > I will see what I can do. My "first approach" at a requirements list for a > proper bay module are as follows: > > 1. It will handle all device types (ATAPI, PATA, SATA, batteries); > > 2. It will do the right thing on plug and unplug. This means telling the > rest of the kernel to disable the device in the bay, for example. Right now > we shutdown one end of the PATA/SATA link on ThinkPads eletrically, and > leave libata to scream blood murder until it disables its end due to too > many retries, for example; Personally - I think tighter integration to libata here would be beneficial. Once libata acpi support is straightened out, if we can store acpi handles associated with libata devices, we can perhaps have a mechanism of obtaining ata_device structs so that we can have a nice way of telling libata to delete devices etc. I am hoping libata-acpi will be straightened out for 2.6.22. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: CONFIG_IBM_BAY 2007-03-15 19:50 ` CONFIG_IBM_BAY Kristen Carlson Accardi @ 2007-03-18 5:38 ` Tejun Heo 2007-03-18 8:27 ` CONFIG_IBM_BAY Holger Macht [not found] ` <45FCD062.3050001-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 0 siblings, 2 replies; 60+ messages in thread From: Tejun Heo @ 2007-03-18 5:38 UTC (permalink / raw) To: Kristen Carlson Accardi Cc: Henrique de Moraes Holschuh, Len Brown, linux-acpi, ibm-acpi-devel, linux-ide Hello, Kristen Carlson Accardi wrote: >> 1. It will handle all device types (ATAPI, PATA, SATA, batteries); >> >> 2. It will do the right thing on plug and unplug. This means telling the >> rest of the kernel to disable the device in the bay, for example. Right now >> we shutdown one end of the PATA/SATA link on ThinkPads eletrically, and >> leave libata to scream blood murder until it disables its end due to too >> many retries, for example; :-) > Personally - I think tighter integration to libata here would be beneficial. > Once libata acpi support is straightened out, if we can store acpi handles > associated with libata devices, we can perhaps have a mechanism of obtaining > ata_device structs so that we can have a nice way of telling libata to > delete devices etc. I am hoping libata-acpi will be straightened out for > 2.6.22. I dunno what the thread is really about but can't this be dealt within acpid? Finding out the correct scsi host node can be tricky but I think it can be done reliably by jumping through some sysfs whoops. Once you're there, telling libata to kill or probe is really easy. http://www.thinkwiki.org/wiki/How_to_hotswap_UltraBay_devices Thanks. -- tejun ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: CONFIG_IBM_BAY 2007-03-18 5:38 ` CONFIG_IBM_BAY Tejun Heo @ 2007-03-18 8:27 ` Holger Macht 2007-03-18 18:36 ` CONFIG_IBM_BAY Henrique de Moraes Holschuh 2007-03-19 13:22 ` CONFIG_IBM_BAY Matthew Garrett [not found] ` <45FCD062.3050001-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 1 sibling, 2 replies; 60+ messages in thread From: Holger Macht @ 2007-03-18 8:27 UTC (permalink / raw) To: Tejun Heo Cc: Kristen Carlson Accardi, Henrique de Moraes Holschuh, Len Brown, linux-acpi, ibm-acpi-devel, linux-ide On Sun 18. Mar - 14:38:42, Tejun Heo wrote: > Hello, > > Kristen Carlson Accardi wrote: > >> 1. It will handle all device types (ATAPI, PATA, SATA, batteries); > >> > >> 2. It will do the right thing on plug and unplug. This means telling the > >> rest of the kernel to disable the device in the bay, for example. Right now > >> we shutdown one end of the PATA/SATA link on ThinkPads eletrically, and > >> leave libata to scream blood murder until it disables its end due to too > >> many retries, for example; > > :-) > > > Personally - I think tighter integration to libata here would be beneficial. > > Once libata acpi support is straightened out, if we can store acpi handles > > associated with libata devices, we can perhaps have a mechanism of obtaining > > ata_device structs so that we can have a nice way of telling libata to > > delete devices etc. I am hoping libata-acpi will be straightened out for > > 2.6.22. > > I dunno what the thread is really about but can't this be dealt within > acpid? Finding out the correct scsi host node can be tricky but I think > it can be done reliably by jumping through some sysfs whoops. Once > you're there, telling libata to kill or probe is really easy. That's actually what I've created dockutils [1] for. What it basically does is 'echo 1 > /sys/devices/.../delete' on undock, and 'echo "- - -" > /sys/class/scsi_host/*/scan' on dock to get the bay device back to life on those ThinkPads where it is needed. Afterwards it does the corresponding dock/undock request on ibm_acpi. And this works reliably good what I can see from the feedback I already got. But for this to work, userspace would actually need an event on docking and preferably would need to do the ACPI undock itself. Both things are not possible with the generic dock driver currently. And I don't think it matters much if libata's hotplug capabilities are improved in this case, userspace just needs some time to interact with the user in case there is more to do like unmounting filesystems inside the bay etc... I don't prefer any solution, whether doing it inside the kernel, or doing it in userspace. What would be good would be to know what's the 'right' way to go, or at least what both kernel people and userspace people can agree on so that we can find a solution across distributions, whatever. I'm currently just looking how to integrate the generic dock and bay driver into the openSUSE distribution, and this seems to be quite hard, especially because of the above mentioned already working solution ;-) Just my 2 cents, Holger [1] http://en.opensuse.org/Dockutils ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: CONFIG_IBM_BAY 2007-03-18 8:27 ` CONFIG_IBM_BAY Holger Macht @ 2007-03-18 18:36 ` Henrique de Moraes Holschuh 2007-03-18 18:55 ` CONFIG_IBM_BAY Holger Macht 2007-03-19 18:17 ` CONFIG_IBM_BAY Kristen Carlson Accardi 2007-03-19 13:22 ` CONFIG_IBM_BAY Matthew Garrett 1 sibling, 2 replies; 60+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-18 18:36 UTC (permalink / raw) To: Kristen Carlson Accardi, Len Brown, linux-acpi-u79uwXL29TY76Z2rM5mHXA, ibm-acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, linux-ide-u79uwXL29TY76Z2rM5mHXA On Sun, 18 Mar 2007, Holger Macht wrote: > those ThinkPads where it is needed. Afterwards it does the corresponding > dock/undock request on ibm_acpi. And this works reliably good what I can > see from the feedback I already got. But for this to work, userspace would It should work with the generic bay device too, but I have no ideas about dock. But you'll need to deal with udev with the new bay device, something I am not too happy about. These things are ACPI events, they should remain so unless all other ACPI events are going to become uevents. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: CONFIG_IBM_BAY 2007-03-18 18:36 ` CONFIG_IBM_BAY Henrique de Moraes Holschuh @ 2007-03-18 18:55 ` Holger Macht 2007-03-18 19:00 ` CONFIG_IBM_BAY Henrique de Moraes Holschuh 2007-03-19 18:04 ` CONFIG_IBM_BAY Kristen Carlson Accardi 2007-03-19 18:17 ` CONFIG_IBM_BAY Kristen Carlson Accardi 1 sibling, 2 replies; 60+ messages in thread From: Holger Macht @ 2007-03-18 18:55 UTC (permalink / raw) To: Henrique de Moraes Holschuh Cc: Kristen Carlson Accardi, Len Brown, linux-acpi, ibm-acpi-devel, linux-ide On Sun 18. Mar - 15:36:52, Henrique de Moraes Holschuh wrote: > On Sun, 18 Mar 2007, Holger Macht wrote: > > those ThinkPads where it is needed. Afterwards it does the corresponding > > dock/undock request on ibm_acpi. And this works reliably good what I can > > see from the feedback I already got. But for this to work, userspace would > > It should work with the generic bay device too, but I have no ideas about > dock. But you'll need to deal with udev with the new bay device, something > I am not too happy about. These things are ACPI events, they should remain > so unless all other ACPI events are going to become uevents. It doesn't work, I've already tried. The bay driver only emits an event if you really try to remove the bay, but not on docking/undocking. Regards, Holger ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: CONFIG_IBM_BAY 2007-03-18 18:55 ` CONFIG_IBM_BAY Holger Macht @ 2007-03-18 19:00 ` Henrique de Moraes Holschuh 2007-03-19 18:04 ` CONFIG_IBM_BAY Kristen Carlson Accardi 1 sibling, 0 replies; 60+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-18 19:00 UTC (permalink / raw) To: Kristen Carlson Accardi, Len Brown, linux-acpi, ibm-acpi-devel, linux-ide On Sun, 18 Mar 2007, Holger Macht wrote: > It doesn't work, I've already tried. The bay driver only emits an event if > you really try to remove the bay, but not on docking/undocking. Ah, now I understand what you mean. Looks like we really need the dock driver to sort of like act as a bus. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: CONFIG_IBM_BAY 2007-03-18 18:55 ` CONFIG_IBM_BAY Holger Macht 2007-03-18 19:00 ` CONFIG_IBM_BAY Henrique de Moraes Holschuh @ 2007-03-19 18:04 ` Kristen Carlson Accardi 2007-03-20 15:53 ` CONFIG_IBM_BAY Holger Macht 1 sibling, 1 reply; 60+ messages in thread From: Kristen Carlson Accardi @ 2007-03-19 18:04 UTC (permalink / raw) To: Holger Macht Cc: Henrique de Moraes Holschuh, Len Brown, linux-acpi, ibm-acpi-devel, linux-ide On Sun, 18 Mar 2007 19:55:30 +0100 Holger Macht <hmacht@suse.de> wrote: > On Sun 18. Mar - 15:36:52, Henrique de Moraes Holschuh wrote: > > On Sun, 18 Mar 2007, Holger Macht wrote: > > > those ThinkPads where it is needed. Afterwards it does the corresponding > > > dock/undock request on ibm_acpi. And this works reliably good what I can > > > see from the feedback I already got. But for this to work, userspace would > > > > It should work with the generic bay device too, but I have no ideas about > > dock. But you'll need to deal with udev with the new bay device, something > > I am not too happy about. These things are ACPI events, they should remain > > so unless all other ACPI events are going to become uevents. > > It doesn't work, I've already tried. The bay driver only emits an event if > you really try to remove the bay, but not on docking/undocking. > > Regards, > Holger > this *should* work. The Bay driver registers with the dock driver to get dock events: /* if we are on a dock station, we should register for dock * notifications. */ if (bay_is_dock_device(handle)) { bay_dprintk(handle, "Is dependent on dock\n"); register_hotplug_dock_device(handle, bay_notify, new_bay); } then, on undock the dock driver calls the bay_notify function and passes it the EJECT request event. This causes the bay driver to emit an event to userspace. case ACPI_NOTIFY_EJECT_REQUEST: kobject_uevent(&dev->kobj, KOBJ_CHANGE); break; default: an event to userspace. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: CONFIG_IBM_BAY 2007-03-19 18:04 ` CONFIG_IBM_BAY Kristen Carlson Accardi @ 2007-03-20 15:53 ` Holger Macht 2007-03-20 16:19 ` CONFIG_IBM_BAY Kristen Carlson Accardi 0 siblings, 1 reply; 60+ messages in thread From: Holger Macht @ 2007-03-20 15:53 UTC (permalink / raw) To: Kristen Carlson Accardi Cc: Henrique de Moraes Holschuh, Len Brown, linux-acpi, ibm-acpi-devel, linux-ide On Mon 19. Mar - 11:04:12, Kristen Carlson Accardi wrote: > On Sun, 18 Mar 2007 19:55:30 +0100 > Holger Macht <hmacht@suse.de> wrote: > > > On Sun 18. Mar - 15:36:52, Henrique de Moraes Holschuh wrote: > > > On Sun, 18 Mar 2007, Holger Macht wrote: > > > > those ThinkPads where it is needed. Afterwards it does the corresponding > > > > dock/undock request on ibm_acpi. And this works reliably good what I can > > > > see from the feedback I already got. But for this to work, userspace would > > > > > > It should work with the generic bay device too, but I have no ideas about > > > dock. But you'll need to deal with udev with the new bay device, something > > > I am not too happy about. These things are ACPI events, they should remain > > > so unless all other ACPI events are going to become uevents. > > > > It doesn't work, I've already tried. The bay driver only emits an event if > > you really try to remove the bay, but not on docking/undocking. > > > > Regards, > > Holger > > > > this *should* work. The Bay driver registers with the dock driver to get > dock events: > > /* if we are on a dock station, we should register for dock > * notifications. > */ > if (bay_is_dock_device(handle)) { > bay_dprintk(handle, "Is dependent on dock\n"); > register_hotplug_dock_device(handle, bay_notify, new_bay); > } > But is_dock_device(...) for both the bay and for the parent handle return false. I'm using an X60 here, so bay_notify is never registered. I couldn't find the reason in the short time I was looking at it, though. Regards, Holger ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: CONFIG_IBM_BAY 2007-03-20 15:53 ` CONFIG_IBM_BAY Holger Macht @ 2007-03-20 16:19 ` Kristen Carlson Accardi [not found] ` <20070320091932.f61bbdcc.kristen.c.accardi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 0 siblings, 1 reply; 60+ messages in thread From: Kristen Carlson Accardi @ 2007-03-20 16:19 UTC (permalink / raw) To: Holger Macht Cc: Henrique de Moraes Holschuh, Len Brown, linux-acpi, ibm-acpi-devel, linux-ide On Tue, 20 Mar 2007 16:53:21 +0100 Holger Macht <hmacht@suse.de> wrote: > On Mon 19. Mar - 11:04:12, Kristen Carlson Accardi wrote: > > On Sun, 18 Mar 2007 19:55:30 +0100 > > Holger Macht <hmacht@suse.de> wrote: > > > > > On Sun 18. Mar - 15:36:52, Henrique de Moraes Holschuh wrote: > > > > On Sun, 18 Mar 2007, Holger Macht wrote: > > > > > those ThinkPads where it is needed. Afterwards it does the corresponding > > > > > dock/undock request on ibm_acpi. And this works reliably good what I can > > > > > see from the feedback I already got. But for this to work, userspace would > > > > > > > > It should work with the generic bay device too, but I have no ideas about > > > > dock. But you'll need to deal with udev with the new bay device, something > > > > I am not too happy about. These things are ACPI events, they should remain > > > > so unless all other ACPI events are going to become uevents. > > > > > > It doesn't work, I've already tried. The bay driver only emits an event if > > > you really try to remove the bay, but not on docking/undocking. > > > > > > Regards, > > > Holger > > > > > > > this *should* work. The Bay driver registers with the dock driver to get > > dock events: > > > > /* if we are on a dock station, we should register for dock > > * notifications. > > */ > > if (bay_is_dock_device(handle)) { > > bay_dprintk(handle, "Is dependent on dock\n"); > > register_hotplug_dock_device(handle, bay_notify, new_bay); > > } > > > > But is_dock_device(...) for both the bay and for the parent handle return > false. I'm using an X60 here, so bay_notify is never registered. I > couldn't find the reason in the short time I was looking at it, though. > > Regards, > Holger > Works for me on my X60 - have you tested on the latest rc kernel? Also, let me know what your BIOS sets your SATA controller to. I can try to duplicate your issue and get it to work. ^ permalink raw reply [flat|nested] 60+ messages in thread
[parent not found: <20070320091932.f61bbdcc.kristen.c.accardi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]
* Re: CONFIG_IBM_BAY [not found] ` <20070320091932.f61bbdcc.kristen.c.accardi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> @ 2007-03-20 16:34 ` Holger Macht 0 siblings, 0 replies; 60+ messages in thread From: Holger Macht @ 2007-03-20 16:34 UTC (permalink / raw) To: Kristen Carlson Accardi Cc: linux-ide-u79uwXL29TY76Z2rM5mHXA, linux-acpi-u79uwXL29TY76Z2rM5mHXA, ibm-acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Henrique de Moraes Holschuh, Len Brown On Tue 20. Mar - 09:19:32, Kristen Carlson Accardi wrote: > On Tue, 20 Mar 2007 16:53:21 +0100 > Holger Macht <hmacht-l3A5Bk7waGM@public.gmane.org> wrote: > > > On Mon 19. Mar - 11:04:12, Kristen Carlson Accardi wrote: > > > On Sun, 18 Mar 2007 19:55:30 +0100 > > > Holger Macht <hmacht-l3A5Bk7waGM@public.gmane.org> wrote: > > > > > > > On Sun 18. Mar - 15:36:52, Henrique de Moraes Holschuh wrote: > > > > > On Sun, 18 Mar 2007, Holger Macht wrote: > > > > > > those ThinkPads where it is needed. Afterwards it does the corresponding > > > > > > dock/undock request on ibm_acpi. And this works reliably good what I can > > > > > > see from the feedback I already got. But for this to work, userspace would > > > > > > > > > > It should work with the generic bay device too, but I have no ideas about > > > > > dock. But you'll need to deal with udev with the new bay device, something > > > > > I am not too happy about. These things are ACPI events, they should remain > > > > > so unless all other ACPI events are going to become uevents. > > > > > > > > It doesn't work, I've already tried. The bay driver only emits an event if > > > > you really try to remove the bay, but not on docking/undocking. > > > > > > > > Regards, > > > > Holger > > > > > > > > > > this *should* work. The Bay driver registers with the dock driver to get > > > dock events: > > > > > > /* if we are on a dock station, we should register for dock > > > * notifications. > > > */ > > > if (bay_is_dock_device(handle)) { > > > bay_dprintk(handle, "Is dependent on dock\n"); > > > register_hotplug_dock_device(handle, bay_notify, new_bay); > > > } > > > > > > > But is_dock_device(...) for both the bay and for the parent handle return > > false. I'm using an X60 here, so bay_notify is never registered. I > > couldn't find the reason in the short time I was looking at it, though. > > > > Regards, > > Holger > > > > Works for me on my X60 - have you tested on the latest rc kernel? Also, > let me know what your BIOS sets your SATA controller to. I can try to > duplicate your issue and get it to work. Tried with Linus' git tree from today. SATA is set to AHCI if that's the information you're asking for. Thanks, Holger ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: CONFIG_IBM_BAY 2007-03-18 18:36 ` CONFIG_IBM_BAY Henrique de Moraes Holschuh 2007-03-18 18:55 ` CONFIG_IBM_BAY Holger Macht @ 2007-03-19 18:17 ` Kristen Carlson Accardi 2007-03-20 0:07 ` CONFIG_IBM_BAY Henrique de Moraes Holschuh 1 sibling, 1 reply; 60+ messages in thread From: Kristen Carlson Accardi @ 2007-03-19 18:17 UTC (permalink / raw) To: Henrique de Moraes Holschuh Cc: Len Brown, linux-acpi, ibm-acpi-devel, linux-ide On Sun, 18 Mar 2007 15:36:52 -0300 Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote: > On Sun, 18 Mar 2007, Holger Macht wrote: > > those ThinkPads where it is needed. Afterwards it does the corresponding > > dock/undock request on ibm_acpi. And this works reliably good what I can > > see from the feedback I already got. But for this to work, userspace would > > It should work with the generic bay device too, but I have no ideas about > dock. But you'll need to deal with udev with the new bay device, something > I am not too happy about. These things are ACPI events, they should remain > so unless all other ACPI events are going to become uevents. So ACPI is just a mechanism - an implementation detail in the kernel. I don't think we should have special ACPI events to deal with bay/dock activity. If for whatever reason we ever dock something without using ACPI, we can make this transparent to userspace. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: CONFIG_IBM_BAY 2007-03-19 18:17 ` CONFIG_IBM_BAY Kristen Carlson Accardi @ 2007-03-20 0:07 ` Henrique de Moraes Holschuh [not found] ` <20070320000706.GE5932-ZGHd14iZgfaRjzvQDGKj+xxZW9W5cXbT@public.gmane.org> 0 siblings, 1 reply; 60+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-20 0:07 UTC (permalink / raw) To: Kristen Carlson Accardi; +Cc: Len Brown, linux-acpi, ibm-acpi-devel On Mon, 19 Mar 2007, Kristen Carlson Accardi wrote: > > It should work with the generic bay device too, but I have no ideas about > > dock. But you'll need to deal with udev with the new bay device, something > > I am not too happy about. These things are ACPI events, they should remain > > so unless all other ACPI events are going to become uevents. > > So ACPI is just a mechanism - an implementation detail in the kernel. I > don't think we should have special ACPI events to deal with bay/dock activity. Well, that's how the userspace power management structure operates right now. We can walk away from that, of course, but if we are going to, then let's do it for the entire set of ACPI events sent to userspace. In the meanwhile, I would really appreciate a way to hook ibm-acpi into bay so that I can provide the ACPI events ibm-acpi used to generate... we can deprecate them and remove them in one year's time, or when the /proc/acpi/events (and its sysfs counterpart) interface gets removed, whichever happens first. > If for whatever reason we ever dock something without using ACPI, we can > make this transparent to userspace. Yes. But this is also true for battery, thermal notifications, suspend/resume, and pretty much every ACPI event :-) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ^ permalink raw reply [flat|nested] 60+ messages in thread
[parent not found: <20070320000706.GE5932-ZGHd14iZgfaRjzvQDGKj+xxZW9W5cXbT@public.gmane.org>]
* Re: CONFIG_IBM_BAY [not found] ` <20070320000706.GE5932-ZGHd14iZgfaRjzvQDGKj+xxZW9W5cXbT@public.gmane.org> @ 2007-03-20 16:14 ` Kristen Carlson Accardi 0 siblings, 0 replies; 60+ messages in thread From: Kristen Carlson Accardi @ 2007-03-20 16:14 UTC (permalink / raw) To: Henrique de Moraes Holschuh Cc: linux-acpi-u79uwXL29TY76Z2rM5mHXA, ibm-acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Len Brown On Mon, 19 Mar 2007 21:07:06 -0300 Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org> wrote: > In the meanwhile, I would really appreciate a way to hook ibm-acpi into bay > so that I can provide the ACPI events ibm-acpi used to generate... we can > deprecate them and remove them in one year's time, or when the > /proc/acpi/events (and its sysfs counterpart) interface gets removed, > whichever happens first. Ok - I'll design an interface for the bay driver which will allow platform specific drivers to have a way to do whatever special things they want to do. Hopefully will get something for review next week. Kristen ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: CONFIG_IBM_BAY 2007-03-18 8:27 ` CONFIG_IBM_BAY Holger Macht 2007-03-18 18:36 ` CONFIG_IBM_BAY Henrique de Moraes Holschuh @ 2007-03-19 13:22 ` Matthew Garrett [not found] ` <20070319132243.GA2869-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org> 2007-03-19 18:00 ` CONFIG_IBM_BAY Kristen Carlson Accardi 1 sibling, 2 replies; 60+ messages in thread From: Matthew Garrett @ 2007-03-19 13:22 UTC (permalink / raw) To: Tejun Heo, Kristen Carlson Accardi, Henrique de Moraes Holschuh, Len Brown, linux-acpi, ibm-acpi-devel, linux-ide On Sun, Mar 18, 2007 at 09:27:51AM +0100, Holger Macht wrote: > I don't prefer any solution, whether doing it inside the kernel, or doing > it in userspace. What would be good would be to know what's the 'right' > way to go, or at least what both kernel people and userspace people can > agree on so that we can find a solution across distributions, whatever. > I'm currently just looking how to integrate the generic dock and bay > driver into the openSUSE distribution, and this seems to be quite hard, > especially because of the above mentioned already working solution ;-) If the kernel knows that a bay device has just been added or removed, it makes sense for the device removal to take place in the kernel rather than bouncing it out to userspace and then back into the kernel. Pulling out a cardbus card doesn't require us to run a userspace helper to detach the hardware. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 60+ messages in thread
[parent not found: <20070319132243.GA2869-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>]
* Re: CONFIG_IBM_BAY [not found] ` <20070319132243.GA2869-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org> @ 2007-03-19 13:48 ` Holger Macht 2007-03-19 14:04 ` CONFIG_IBM_BAY Matthew Garrett 0 siblings, 1 reply; 60+ messages in thread From: Holger Macht @ 2007-03-19 13:48 UTC (permalink / raw) To: Matthew Garrett Cc: linux-ide-u79uwXL29TY76Z2rM5mHXA, Tejun Heo, ibm-acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, linux-acpi-u79uwXL29TY76Z2rM5mHXA, Henrique de Moraes Holschuh, Kristen Carlson Accardi, Len Brown On Mon 19. Mar - 13:22:43, Matthew Garrett wrote: > On Sun, Mar 18, 2007 at 09:27:51AM +0100, Holger Macht wrote: > > > I don't prefer any solution, whether doing it inside the kernel, or doing > > it in userspace. What would be good would be to know what's the 'right' > > way to go, or at least what both kernel people and userspace people can > > agree on so that we can find a solution across distributions, whatever. > > I'm currently just looking how to integrate the generic dock and bay > > driver into the openSUSE distribution, and this seems to be quite hard, > > especially because of the above mentioned already working solution ;-) > > If the kernel knows that a bay device has just been added or removed, it > makes sense for the device removal to take place in the kernel rather > than bouncing it out to userspace and then back into the kernel. Pulling > out a cardbus card doesn't require us to run a userspace helper to > detach the hardware. Yes, makes sense to me. So if this is the way to go, we would need two things: 1. libata integration into the bay driver 2. The dock station driver has to inform the bay driver that an undock event took place, right? But you still have to deal with mounted filesystems, no matter if it a cardbus or a cdrom. Wouldn't we need something like 'save removal' triggered from userspace like you maybe know from 'the other' operating system? Regards, Holger ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: CONFIG_IBM_BAY 2007-03-19 13:48 ` CONFIG_IBM_BAY Holger Macht @ 2007-03-19 14:04 ` Matthew Garrett 2007-03-19 14:37 ` CONFIG_IBM_BAY Holger Macht [not found] ` <20070319140403.GA3697-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org> 0 siblings, 2 replies; 60+ messages in thread From: Matthew Garrett @ 2007-03-19 14:04 UTC (permalink / raw) To: Tejun Heo, Kristen Carlson Accardi, Henrique de Moraes Holschuh, Len Brown, linux-acpi, ibm-acpi-devel, linux-ide On Mon, Mar 19, 2007 at 02:48:22PM +0100, Holger Macht wrote: > 1. libata integration into the bay driver It actually makes sense to tie all PATA/SATA devices to their ACPI handles where appropriate - there's already code to do that in libata-acpi.c, but it would be nicer if it was integrated in the same way that PCI devices are. > 2. The dock station driver has to inform the bay driver that an undock > event took place, right? Yeah. > But you still have to deal with mounted filesystems, no matter if it a > cardbus or a cdrom. Wouldn't we need something like 'save removal' > triggered from userspace like you maybe know from 'the other' operating > system? Yes, there's a need for a mechanism to deal with all of this safely, but the same is true of any storage device that can be hotplugged (USB, firewire, anything in a hotplug bay...) -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: CONFIG_IBM_BAY 2007-03-19 14:04 ` CONFIG_IBM_BAY Matthew Garrett @ 2007-03-19 14:37 ` Holger Macht [not found] ` <20070319143746.GC4885-tB0uoaAy/Z1bpigZmTR7Iw@public.gmane.org> [not found] ` <20070319140403.GA3697-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org> 1 sibling, 1 reply; 60+ messages in thread From: Holger Macht @ 2007-03-19 14:37 UTC (permalink / raw) To: Matthew Garrett Cc: Tejun Heo, Kristen Carlson Accardi, Henrique de Moraes Holschuh, Len Brown, linux-acpi, ibm-acpi-devel, linux-ide On Mon 19. Mar - 14:04:03, Matthew Garrett wrote: > On Mon, Mar 19, 2007 at 02:48:22PM +0100, Holger Macht wrote: > > > 1. libata integration into the bay driver > > It actually makes sense to tie all PATA/SATA devices to their ACPI > handles where appropriate - there's already code to do that in > libata-acpi.c, but it would be nicer if it was integrated in the same > way that PCI devices are. > > > 2. The dock station driver has to inform the bay driver that an undock > > event took place, right? > > Yeah. > > > But you still have to deal with mounted filesystems, no matter if it a > > cardbus or a cdrom. Wouldn't we need something like 'save removal' > > triggered from userspace like you maybe know from 'the other' operating > > system? > > Yes, there's a need for a mechanism to deal with all of this safely, but > the same is true of any storage device that can be hotplugged (USB, > firewire, anything in a hotplug bay...) Sure. What actually bothers me is that in its current state, the dock station driver signals 'green' on the dock station as soon as the user presses the hardware undock button, but regardlessly of anything else. I think it would be ok to let the ACPI undock event up to userspace because in many situations it knows best when it is save to undock. Regards, Holger ^ permalink raw reply [flat|nested] 60+ messages in thread
[parent not found: <20070319143746.GC4885-tB0uoaAy/Z1bpigZmTR7Iw@public.gmane.org>]
* Re: CONFIG_IBM_BAY [not found] ` <20070319143746.GC4885-tB0uoaAy/Z1bpigZmTR7Iw@public.gmane.org> @ 2007-03-19 18:11 ` Kristen Carlson Accardi 2007-03-19 23:11 ` [ibm-acpi-devel] CONFIG_IBM_BAY Henrique de Moraes Holschuh 2007-03-20 16:07 ` CONFIG_IBM_BAY Holger Macht 0 siblings, 2 replies; 60+ messages in thread From: Kristen Carlson Accardi @ 2007-03-19 18:11 UTC (permalink / raw) To: Holger Macht Cc: linux-ide-u79uwXL29TY76Z2rM5mHXA, Matthew Garrett, Tejun Heo, linux-acpi-u79uwXL29TY76Z2rM5mHXA, ibm-acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Henrique de Moraes Holschuh, Len Brown On Mon, 19 Mar 2007 15:37:46 +0100 Holger Macht <hmacht-l3A5Bk7waGM@public.gmane.org> wrote: > Sure. What actually bothers me is that in its current state, the dock > station driver signals 'green' on the dock station as soon as the user > presses the hardware undock button, but regardlessly of anything else. I > think it would be ok to let the ACPI undock event up to userspace because > in many situations it knows best when it is save to undock. I disagree - as I mentioned, not all laptops actually let you (userspace) control the undock process because they don't lock. The dock driver does notify user space of an undock, before it actually undocks: /* * here we need to generate the undock * event prior to actually doing the undock * so that the device struct still exists. */ dock_event(ds, event, UNDOCK_EVENT); hotplug_dock_devices(ds, ACPI_NOTIFY_EJECT_REQUEST); undock(ds); eject_dock(ds); We even notify other subsystems of our intent to undock prior to actually doing it. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [ibm-acpi-devel] CONFIG_IBM_BAY 2007-03-19 18:11 ` CONFIG_IBM_BAY Kristen Carlson Accardi @ 2007-03-19 23:11 ` Henrique de Moraes Holschuh 2007-03-19 23:56 ` Kristen Carlson Accardi 2007-03-20 16:07 ` CONFIG_IBM_BAY Holger Macht 1 sibling, 1 reply; 60+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-19 23:11 UTC (permalink / raw) To: Kristen Carlson Accardi Cc: Holger Macht, Matthew Garrett, linux-acpi, ibm-acpi-devel, Len Brown On Mon, 19 Mar 2007, Kristen Carlson Accardi wrote: > On Mon, 19 Mar 2007 15:37:46 +0100 > Holger Macht <hmacht@suse.de> wrote: > > Sure. What actually bothers me is that in its current state, the dock > > station driver signals 'green' on the dock station as soon as the user > > presses the hardware undock button, but regardlessly of anything else. I > > think it would be ok to let the ACPI undock event up to userspace because > > in many situations it knows best when it is save to undock. > > I disagree - as I mentioned, not all laptops actually let you (userspace) > control the undock process because they don't lock. The dock driver > does notify user space of an undock, before it actually undocks: > > /* > * here we need to generate the undock > * event prior to actually doing the undock > * so that the device struct still exists. > */ > dock_event(ds, event, UNDOCK_EVENT); > hotplug_dock_devices(ds, ACPI_NOTIFY_EJECT_REQUEST); > undock(ds); > eject_dock(ds); > > > We even notify other subsystems of our intent to undock prior to actually > doing it. The above does not support two-stage-capable (i.e. non-braindamaged) hardware docks properly. While a two-stage (notify always, but undock only if userspace (or another kernel module) tells you to) can support both two-stage and broken-as-designed single-stage docks. You can either let a machine-specific module (e.g. ibm-acpi) generate the "undock immediately" functionality if the machine has a single-stage dock, or let userspace do it, or even use black/whitelists on the dock module if you want... but please give us the two-stage undock support. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [ibm-acpi-devel] CONFIG_IBM_BAY 2007-03-19 23:11 ` [ibm-acpi-devel] CONFIG_IBM_BAY Henrique de Moraes Holschuh @ 2007-03-19 23:56 ` Kristen Carlson Accardi 2007-03-20 0:12 ` Henrique de Moraes Holschuh 0 siblings, 1 reply; 60+ messages in thread From: Kristen Carlson Accardi @ 2007-03-19 23:56 UTC (permalink / raw) To: Henrique de Moraes Holschuh Cc: Holger Macht, Matthew Garrett, linux-acpi, ibm-acpi-devel, Len Brown On Mon, 19 Mar 2007 20:11:19 -0300 Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote: > On Mon, 19 Mar 2007, Kristen Carlson Accardi wrote: > > On Mon, 19 Mar 2007 15:37:46 +0100 > > Holger Macht <hmacht@suse.de> wrote: > > > Sure. What actually bothers me is that in its current state, the dock > > > station driver signals 'green' on the dock station as soon as the user > > > presses the hardware undock button, but regardlessly of anything else. I > > > think it would be ok to let the ACPI undock event up to userspace because > > > in many situations it knows best when it is save to undock. > > > > I disagree - as I mentioned, not all laptops actually let you (userspace) > > control the undock process because they don't lock. The dock driver > > does notify user space of an undock, before it actually undocks: > > > > /* > > * here we need to generate the undock > > * event prior to actually doing the undock > > * so that the device struct still exists. > > */ > > dock_event(ds, event, UNDOCK_EVENT); > > hotplug_dock_devices(ds, ACPI_NOTIFY_EJECT_REQUEST); > > undock(ds); > > eject_dock(ds); > > > > > > We even notify other subsystems of our intent to undock prior to actually > > doing it. > > The above does not support two-stage-capable (i.e. non-braindamaged) > hardware docks properly. While a two-stage (notify always, but undock only > if userspace (or another kernel module) tells you to) can support both > two-stage and broken-as-designed single-stage docks. > > You can either let a machine-specific module (e.g. ibm-acpi) generate the > "undock immediately" functionality if the machine has a single-stage dock, > or let userspace do it, or even use black/whitelists on the dock module if > you want... but please give us the two-stage undock support. > > -- Is this what you had in mind? (Warning - I didn't test this). Allow the driver to be loaded with an option that will allow userspace to control whether the laptop is ejected immediately when the user presses the button, or only when the syfs undock file is written. if immediate_undock == 1, then when the user presses the undock button, the laptop will send an event to userspace to notify userspace of the undock, but then immediately undock without waiting for userspace. This is the current behavior, and I set this to be the default. if immediate_undock == 0, then when the user presses the undock button, the laptop will send an event to userspace and do nothing. User space can query the "flags" sysfs entry to determine if an undock request has been made by the user (if bit 1 is set). User space will then need to write the undock sysfs entry to complete the undocking process. Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com> Index: 2.6-git/drivers/acpi/dock.c =================================================================== --- 2.6-git.orig/drivers/acpi/dock.c +++ 2.6-git/drivers/acpi/dock.c @@ -39,6 +39,9 @@ MODULE_AUTHOR("Kristen Carlson Accardi") MODULE_DESCRIPTION(ACPI_DOCK_DRIVER_DESCRIPTION); MODULE_LICENSE("GPL"); +static int immediate_undock; +module_param(immediate_undock, int, 1); + static struct atomic_notifier_head dock_notifier_list; static struct platform_device dock_device; static char dock_device_name[] = "dock"; @@ -62,6 +65,7 @@ struct dock_dependent_device { }; #define DOCK_DOCKING 0x00000001 +#define DOCK_UNDOCKING 0x00000002 #define DOCK_EVENT 3 #define UNDOCK_EVENT 2 @@ -419,6 +423,16 @@ static inline void complete_dock(struct ds->last_dock_time = jiffies; } +static inline void begin_undock(struct dock_station *ds) +{ + ds->flags |= DOCK_UNDOCKING; +} + +static inline void complete_undock(struct dock_station *ds) +{ + ds->flags &= ~(DOCK_UNDOCKING); +} + /** * dock_in_progress - see if we are in the middle of handling a dock event * @ds: the dock station @@ -549,7 +563,7 @@ static int handle_eject_request(struct d printk(KERN_ERR PREFIX "Unable to undock!\n"); return -EBUSY; } - + complete_undock(ds); return 0; } @@ -593,7 +607,11 @@ static void dock_notify(acpi_handle hand * to the driver who wish to hotplug. */ case ACPI_NOTIFY_EJECT_REQUEST: - handle_eject_request(ds, event); + begin_undock(ds); + if (immediate_undock) + handle_eject_request(ds, event); + else + dock_event(ds, event, UNDOCK_EVENT); break; default: printk(KERN_ERR PREFIX "Unknown dock event %d\n", event); @@ -652,6 +670,17 @@ static ssize_t show_docked(struct device DEVICE_ATTR(docked, S_IRUGO, show_docked, NULL); /* + * show_flags - read method for flags file in sysfs + */ +static ssize_t show_flags(struct device *dev, + struct device_attribute *attr, char *buf) +{ + return snprintf(buf, PAGE_SIZE, "%d\n", dock_station->flags); + +} +DEVICE_ATTR(flags, S_IRUGO, show_flags, NULL); + +/* * write_undock - write method for "undock" file in sysfs */ static ssize_t write_undock(struct device *dev, struct device_attribute *attr, @@ -667,6 +696,7 @@ static ssize_t write_undock(struct devic } DEVICE_ATTR(undock, S_IWUSR, NULL, write_undock); + /** * dock_add - add a new dock station * @handle: the dock station handle @@ -715,6 +745,15 @@ static int dock_add(acpi_handle handle) kfree(dock_station); return ret; } + ret = device_create_file(&dock_device.dev, &dev_attr_flags); + if (ret) { + printk("Error %d adding sysfs file\n", ret); + device_remove_file(&dock_device.dev, &dev_attr_docked); + device_remove_file(&dock_device.dev, &dev_attr_undock); + platform_device_unregister(&dock_device); + kfree(dock_station); + return ret; + } /* Find dependent devices */ acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, @@ -750,6 +789,7 @@ dock_add_err: dock_add_err_unregister: device_remove_file(&dock_device.dev, &dev_attr_docked); device_remove_file(&dock_device.dev, &dev_attr_undock); + device_remove_file(&dock_device.dev, &dev_attr_flags); platform_device_unregister(&dock_device); kfree(dock_station); return ret; @@ -781,6 +821,7 @@ static int dock_remove(void) /* cleanup sysfs */ device_remove_file(&dock_device.dev, &dev_attr_docked); device_remove_file(&dock_device.dev, &dev_attr_undock); + device_remove_file(&dock_device.dev, &dev_attr_flags); platform_device_unregister(&dock_device); /* free dock station memory */ ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [ibm-acpi-devel] CONFIG_IBM_BAY 2007-03-19 23:56 ` Kristen Carlson Accardi @ 2007-03-20 0:12 ` Henrique de Moraes Holschuh 2007-03-20 16:11 ` Kristen Carlson Accardi 0 siblings, 1 reply; 60+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-20 0:12 UTC (permalink / raw) To: Kristen Carlson Accardi Cc: Holger Macht, Matthew Garrett, linux-acpi, ibm-acpi-devel, Len Brown On Mon, 19 Mar 2007, Kristen Carlson Accardi wrote: > Is this what you had in mind? (Warning - I didn't test this). > > > Allow the driver to be loaded with an option that will allow userspace to > control whether the laptop is ejected immediately when the user presses the > button, or only when the syfs undock file is written. > > if immediate_undock == 1, then when the user presses the undock button, the > laptop will send an event to userspace to notify userspace of the undock, but > then immediately undock without waiting for userspace. This is the current > behavior, and I set this to be the default. > > if immediate_undock == 0, then when the user presses the undock button, the > laptop will send an event to userspace and do nothing. User space can query > the "flags" sysfs entry to determine if an undock request has been made by > the user (if bit 1 is set). User space will then need to write the undock > sysfs entry to complete the undocking process. Yes, that's it exactly. I didn't try to test it, as I don't have a dock, but the above describes what I wanted, indeed. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [ibm-acpi-devel] CONFIG_IBM_BAY 2007-03-20 0:12 ` Henrique de Moraes Holschuh @ 2007-03-20 16:11 ` Kristen Carlson Accardi 0 siblings, 0 replies; 60+ messages in thread From: Kristen Carlson Accardi @ 2007-03-20 16:11 UTC (permalink / raw) To: Henrique de Moraes Holschuh Cc: Holger Macht, Matthew Garrett, linux-acpi, ibm-acpi-devel, Len Brown On Mon, 19 Mar 2007 21:12:40 -0300 Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote: > On Mon, 19 Mar 2007, Kristen Carlson Accardi wrote: > > Is this what you had in mind? (Warning - I didn't test this). > > > > > > Allow the driver to be loaded with an option that will allow userspace to > > control whether the laptop is ejected immediately when the user presses the > > button, or only when the syfs undock file is written. > > > > if immediate_undock == 1, then when the user presses the undock button, the > > laptop will send an event to userspace to notify userspace of the undock, but > > then immediately undock without waiting for userspace. This is the current > > behavior, and I set this to be the default. > > > > if immediate_undock == 0, then when the user presses the undock button, the > > laptop will send an event to userspace and do nothing. User space can query > > the "flags" sysfs entry to determine if an undock request has been made by > > the user (if bit 1 is set). User space will then need to write the undock > > sysfs entry to complete the undocking process. > > Yes, that's it exactly. I didn't try to test it, as I don't have a dock, > but the above describes what I wanted, indeed. > Ok - I will implement this for real later this week and try to get something that is somewhat tested by friday. I won't have access to my test laptops till later in the week. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: CONFIG_IBM_BAY 2007-03-19 18:11 ` CONFIG_IBM_BAY Kristen Carlson Accardi 2007-03-19 23:11 ` [ibm-acpi-devel] CONFIG_IBM_BAY Henrique de Moraes Holschuh @ 2007-03-20 16:07 ` Holger Macht [not found] ` <20070320160707.GB6079-tB0uoaAy/Z1bpigZmTR7Iw@public.gmane.org> 1 sibling, 1 reply; 60+ messages in thread From: Holger Macht @ 2007-03-20 16:07 UTC (permalink / raw) To: Kristen Carlson Accardi Cc: Matthew Garrett, Tejun Heo, Henrique de Moraes Holschuh, Len Brown, linux-acpi, ibm-acpi-devel, linux-ide On Mon 19. Mar - 11:11:09, Kristen Carlson Accardi wrote: > On Mon, 19 Mar 2007 15:37:46 +0100 > Holger Macht <hmacht@suse.de> wrote: > > > Sure. What actually bothers me is that in its current state, the dock > > station driver signals 'green' on the dock station as soon as the user > > presses the hardware undock button, but regardlessly of anything else. I > > think it would be ok to let the ACPI undock event up to userspace because > > in many situations it knows best when it is save to undock. > > I disagree - as I mentioned, not all laptops actually let you (userspace) > control the undock process because they don't lock. The dock driver > does notify user space of an undock, before it actually undocks: Yes, I know that, but userspace won't have enough time to interact with the user in this case. I just imagine having an external disk connected to the usb port of the docking station. In the moment the user undocks, his unsynced or unwritten data is lost because the usb port gets disconnected. The user needs the knowledge to actually "save remove" the external disk before he undocks. You are right, this won't help in case the dock station has no indication when it is "safe" to undock. > > /* > * here we need to generate the undock > * event prior to actually doing the undock > * so that the device struct still exists. > */ > dock_event(ds, event, UNDOCK_EVENT); > hotplug_dock_devices(ds, ACPI_NOTIFY_EJECT_REQUEST); > undock(ds); > eject_dock(ds); > > > We even notify other subsystems of our intent to undock prior to actually > doing it. ^ permalink raw reply [flat|nested] 60+ messages in thread
[parent not found: <20070320160707.GB6079-tB0uoaAy/Z1bpigZmTR7Iw@public.gmane.org>]
* Re: CONFIG_IBM_BAY [not found] ` <20070320160707.GB6079-tB0uoaAy/Z1bpigZmTR7Iw@public.gmane.org> @ 2007-03-20 16:16 ` Holger Macht 0 siblings, 0 replies; 60+ messages in thread From: Holger Macht @ 2007-03-20 16:16 UTC (permalink / raw) To: Kristen Carlson Accardi, Matthew Garrett, Tejun Heo, Henrique de Moraes Holschuh, Len Brown, linux-acpi-u79uwXL29TY76Z2rM5mHXA, ibm-acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, linux-ide-u79uwXL29TY76Z2rM5mHXA On Tue 20. Mar - 17:07:07, Holger Macht wrote: > On Mon 19. Mar - 11:11:09, Kristen Carlson Accardi wrote: > > On Mon, 19 Mar 2007 15:37:46 +0100 > > Holger Macht <hmacht-l3A5Bk7waGM@public.gmane.org> wrote: > > > > > Sure. What actually bothers me is that in its current state, the dock > > > station driver signals 'green' on the dock station as soon as the user > > > presses the hardware undock button, but regardlessly of anything else. I > > > think it would be ok to let the ACPI undock event up to userspace because > > > in many situations it knows best when it is save to undock. > > > > I disagree - as I mentioned, not all laptops actually let you (userspace) > > control the undock process because they don't lock. The dock driver > > does notify user space of an undock, before it actually undocks: > > Yes, I know that, but userspace won't have enough time to interact with > the user in this case. I just imagine having an external disk connected to > the usb port of the docking station. In the moment the user undocks, his > unsynced or unwritten data is lost because the usb port gets > disconnected. The user needs the knowledge to actually "save remove" the > external disk before he undocks. You are right, this won't help in case > the dock station has no indication when it is "safe" to undock. This mail was accidentially sent a little bit too early ;-) What I wanted to add is just that with letting it up to userspace, it would also work in all cases, with or without lock, it would just give userspace more possibilities and might be more convenient for those systems where the dock station locks the machine. But I clearly see the advantage of not needing a userspace helper and for getting this docking thing to work in 99% of all cases ;-) Regards, Holger ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ^ permalink raw reply [flat|nested] 60+ messages in thread
[parent not found: <20070319140403.GA3697-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>]
* Re: CONFIG_IBM_BAY [not found] ` <20070319140403.GA3697-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org> @ 2007-03-19 15:36 ` Henrique de Moraes Holschuh 2007-03-19 15:47 ` CONFIG_IBM_BAY Holger Macht [not found] ` <20070319153659.GB15942-ZGHd14iZgfaRjzvQDGKj+xxZW9W5cXbT@public.gmane.org> 0 siblings, 2 replies; 60+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-19 15:36 UTC (permalink / raw) To: Matthew Garrett Cc: Tejun Heo, linux-acpi-u79uwXL29TY76Z2rM5mHXA, linux-ide-u79uwXL29TY76Z2rM5mHXA, ibm-acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Kristen Carlson Accardi, Len Brown On Mon, 19 Mar 2007, Matthew Garrett wrote: > > But you still have to deal with mounted filesystems, no matter if it a > > cardbus or a cdrom. Wouldn't we need something like 'save removal' > > triggered from userspace like you maybe know from 'the other' operating > > system? > > Yes, there's a need for a mechanism to deal with all of this safely, but > the same is true of any storage device that can be hotplugged (USB, > firewire, anything in a hotplug bay...) True. The best available procedure to do this for ACPI bay/dock currently is, AFAIK: 1. Send event when bay/dock "please release" button/lever is pressed. Do *nothing* else. I know bay does this right, maybe dock doesn't. 2. Wait for something to echo 1 >eject or to call the appropriate routine directly, or (if this exists) for an notification from firmware that the user IS disconnecting the device for real. 3. delete the device. This means force-umount, force-close, etc. 4. Tell the hardware to eject. Note that currently (2) and (3) are swapped, as (3) is being done by userspace request, instead of by the kernel. This is something I *don't* like. IMO should do as PCMCIA and hotplug PCI does, and do that in kernel space. The time window where one can ask the user something or notify it is not a good idea to eject is between (1) and (2). If the eject command is issued, delete devices (includes sync, of course) and eject. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: CONFIG_IBM_BAY 2007-03-19 15:36 ` CONFIG_IBM_BAY Henrique de Moraes Holschuh @ 2007-03-19 15:47 ` Holger Macht [not found] ` <20070319153659.GB15942-ZGHd14iZgfaRjzvQDGKj+xxZW9W5cXbT@public.gmane.org> 1 sibling, 0 replies; 60+ messages in thread From: Holger Macht @ 2007-03-19 15:47 UTC (permalink / raw) To: Henrique de Moraes Holschuh Cc: Matthew Garrett, Tejun Heo, Kristen Carlson Accardi, Len Brown, linux-acpi, ibm-acpi-devel, linux-ide On Mon 19. Mar - 12:36:59, Henrique de Moraes Holschuh wrote: > On Mon, 19 Mar 2007, Matthew Garrett wrote: > > > But you still have to deal with mounted filesystems, no matter if it a > > > cardbus or a cdrom. Wouldn't we need something like 'save removal' > > > triggered from userspace like you maybe know from 'the other' operating > > > system? > > > > Yes, there's a need for a mechanism to deal with all of this safely, but > > the same is true of any storage device that can be hotplugged (USB, > > firewire, anything in a hotplug bay...) > > True. The best available procedure to do this for ACPI bay/dock currently > is, AFAIK: > > 1. Send event when bay/dock "please release" button/lever is pressed. Do > *nothing* else. I know bay does this right, maybe dock doesn't. Yes, the dock driver just does the undock, without any event. As you know, the "please release" mechanism is how it works with ibm_acpi. ACPI event comes through proc and userspace does echo undock > ....That would also be my favourite because it already works quite well. Just without generic docking. > 2. Wait for something to echo 1 >eject or to call the appropriate routine > directly, or (if this exists) for an notification from firmware that the > user IS disconnecting the device for real. > > 3. delete the device. This means force-umount, force-close, etc. > > 4. Tell the hardware to eject. > > > Note that currently (2) and (3) are swapped, as (3) is being done by > userspace request, instead of by the kernel. This is something I *don't* > like. IMO should do as PCMCIA and hotplug PCI does, and do that in kernel > space. Right. > The time window where one can ask the user something or notify it is not a > good idea to eject is between (1) and (2). If the eject command is issued, > delete devices (includes sync, of course) and eject. Yes, at this point in time, userspace is required to have finished the tasks it is responsible for. Regards, Holger ^ permalink raw reply [flat|nested] 60+ messages in thread
[parent not found: <20070319153659.GB15942-ZGHd14iZgfaRjzvQDGKj+xxZW9W5cXbT@public.gmane.org>]
* Re: CONFIG_IBM_BAY [not found] ` <20070319153659.GB15942-ZGHd14iZgfaRjzvQDGKj+xxZW9W5cXbT@public.gmane.org> @ 2007-03-19 16:41 ` Shem Multinymous [not found] ` <41840b750703190941p77fc4a64k49361b678dd6aa90-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 60+ messages in thread From: Shem Multinymous @ 2007-03-19 16:41 UTC (permalink / raw) To: Henrique de Moraes Holschuh Cc: Matthew Garrett, Tejun Heo, linux-acpi-u79uwXL29TY76Z2rM5mHXA, ibm-acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, linux-ide-u79uwXL29TY76Z2rM5mHXA, Kristen Carlson Accardi, Len Brown On 3/19/07, Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org> wrote: > True. The best available procedure to do this for ACPI bay/dock currently > is, AFAIK: > > 1. Send event when bay/dock "please release" button/lever is pressed. Do > *nothing* else. I know bay does this right, maybe dock doesn't. > > 2. Wait for something to echo 1 >eject or to call the appropriate routine > directly, or (if this exists) for an notification from firmware that the > user IS disconnecting the device for real. > > 3. delete the device. This means force-umount, force-close, etc. > > 4. Tell the hardware to eject. > > > Note that currently (2) and (3) are swapped, as (3) is being done by > userspace request, instead of by the kernel. This is something I *don't* > like. Userspace wants to (non-force-)-unmount by itself after (1), so it can stop the eject process if the filesystems cannot be cleanly unmounted. So the force-unmount at (3) ends up being a redundant safety measure at best. Shem ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ^ permalink raw reply [flat|nested] 60+ messages in thread
[parent not found: <41840b750703190941p77fc4a64k49361b678dd6aa90-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: CONFIG_IBM_BAY [not found] ` <41840b750703190941p77fc4a64k49361b678dd6aa90-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2007-03-19 23:04 ` Henrique de Moraes Holschuh 2007-03-20 14:18 ` [ibm-acpi-devel] CONFIG_IBM_BAY Shem Multinymous 0 siblings, 1 reply; 60+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-19 23:04 UTC (permalink / raw) To: Shem Multinymous Cc: Matthew Garrett, Tejun Heo, linux-acpi-u79uwXL29TY76Z2rM5mHXA, ibm-acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, linux-ide-u79uwXL29TY76Z2rM5mHXA, Kristen Carlson Accardi, Len Brown On Mon, 19 Mar 2007, Shem Multinymous wrote: > Userspace wants to (non-force-)-unmount by itself after (1), so it can > stop the eject process if the filesystems cannot be cleanly > unmounted. So the force-unmount at (3) ends up being a redundant > safety measure at best. More like it is a "make sure we can actually eject, as we have been told to". We might return an error instead, but if we do, we need a way to force-eject (e.g. echo 2 >eject). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [ibm-acpi-devel] CONFIG_IBM_BAY 2007-03-19 23:04 ` CONFIG_IBM_BAY Henrique de Moraes Holschuh @ 2007-03-20 14:18 ` Shem Multinymous 2007-03-20 15:12 ` Henrique de Moraes Holschuh 0 siblings, 1 reply; 60+ messages in thread From: Shem Multinymous @ 2007-03-20 14:18 UTC (permalink / raw) To: Henrique de Moraes Holschuh Cc: Matthew Garrett, Tejun Heo, linux-acpi, ibm-acpi-devel, linux-ide, Kristen Carlson Accardi, Len Brown On 3/19/07, Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote: > On Mon, 19 Mar 2007, Shem Multinymous wrote: > > Userspace wants to (non-force-)-unmount by itself after (1), so it can > > stop the eject process if the filesystems cannot be cleanly > > unmounted. So the force-unmount at (3) ends up being a redundant > > safety measure at best. > > More like it is a "make sure we can actually eject, as we have been told > to". We might return an error instead, but if we do, we need a way to > force-eject (e.g. echo 2 >eject). Which stage are you referring to? Note that the only way to check if you can unmount is to actually do so. Otherwise, you're very likely to run into race conditions with someone accessing the filesystem between the check and the actual unmount. Shem ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [ibm-acpi-devel] CONFIG_IBM_BAY 2007-03-20 14:18 ` [ibm-acpi-devel] CONFIG_IBM_BAY Shem Multinymous @ 2007-03-20 15:12 ` Henrique de Moraes Holschuh 0 siblings, 0 replies; 60+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-20 15:12 UTC (permalink / raw) To: Shem Multinymous Cc: Matthew Garrett, Tejun Heo, linux-acpi, ibm-acpi-devel, linux-ide, Kristen Carlson Accardi, Len Brown On Tue, 20 Mar 2007, Shem Multinymous wrote: > >More like it is a "make sure we can actually eject, as we have been told > >to". We might return an error instead, but if we do, we need a way to > >force-eject (e.g. echo 2 >eject). > > Which stage are you referring to? Stage 2, of course. It is useful to have a force_eject functionality that **will** eject and not error out because of anything other than the eject command itself failing. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: CONFIG_IBM_BAY 2007-03-19 13:22 ` CONFIG_IBM_BAY Matthew Garrett [not found] ` <20070319132243.GA2869-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org> @ 2007-03-19 18:00 ` Kristen Carlson Accardi 1 sibling, 0 replies; 60+ messages in thread From: Kristen Carlson Accardi @ 2007-03-19 18:00 UTC (permalink / raw) To: Matthew Garrett Cc: Tejun Heo, Henrique de Moraes Holschuh, Len Brown, linux-acpi, ibm-acpi-devel, linux-ide On Mon, 19 Mar 2007 13:22:43 +0000 Matthew Garrett <mjg59@srcf.ucam.org> wrote: > On Sun, Mar 18, 2007 at 09:27:51AM +0100, Holger Macht wrote: > > > I don't prefer any solution, whether doing it inside the kernel, or doing > > it in userspace. What would be good would be to know what's the 'right' > > way to go, or at least what both kernel people and userspace people can > > agree on so that we can find a solution across distributions, whatever. > > I'm currently just looking how to integrate the generic dock and bay > > driver into the openSUSE distribution, and this seems to be quite hard, > > especially because of the above mentioned already working solution ;-) > > If the kernel knows that a bay device has just been added or removed, it > makes sense for the device removal to take place in the kernel rather > than bouncing it out to userspace and then back into the kernel. Pulling > out a cardbus card doesn't require us to run a userspace helper to > detach the hardware. > > -- > Matthew Garrett | mjg59@srcf.ucam.org > Not to mention, with dock stations some laptops don't actually lock the laptop into the dock station, so when the user decides to press the button and undock, it just does it instantly. And same with some bay devices - they don't actually give you an event until the bay is physically removed. Because of this, I think we should handle things in kernel space. ^ permalink raw reply [flat|nested] 60+ messages in thread
[parent not found: <45FCD062.3050001-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: CONFIG_IBM_BAY [not found] ` <45FCD062.3050001-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> @ 2007-03-18 18:26 ` Henrique de Moraes Holschuh 0 siblings, 0 replies; 60+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-18 18:26 UTC (permalink / raw) To: Tejun Heo Cc: linux-ide-u79uwXL29TY76Z2rM5mHXA, linux-acpi-u79uwXL29TY76Z2rM5mHXA, ibm-acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Kristen Carlson Accardi, Len Brown On Sun, 18 Mar 2007, Tejun Heo wrote: > Kristen Carlson Accardi wrote: > >> 1. It will handle all device types (ATAPI, PATA, SATA, batteries); > >> > >> 2. It will do the right thing on plug and unplug. This means telling the > >> rest of the kernel to disable the device in the bay, for example. Right now > >> we shutdown one end of the PATA/SATA link on ThinkPads eletrically, and > >> leave libata to scream blood murder until it disables its end due to too > >> many retries, for example; > > :-) Yeah :) Try it with old ide, and the results are not... pretty. libata new EH *rules*. > > Personally - I think tighter integration to libata here would be beneficial. > > Once libata acpi support is straightened out, if we can store acpi handles > > associated with libata devices, we can perhaps have a mechanism of obtaining > > ata_device structs so that we can have a nice way of telling libata to > > delete devices etc. I am hoping libata-acpi will be straightened out for > > 2.6.22. > > I dunno what the thread is really about but can't this be dealt within > acpid? Finding out the correct scsi host node can be tricky but I think It could, yes. But to me the kernel looks like the proper place for this one. Not to mention that we *really* should know the ACPI namespace -> kernel device mapping in kernel, instead of doing half-assed things in userspace to call back into kernel land later... it may come in handy for other things (proper ACPI/driver exclusion of access to devices, for one), not just libata matters and dock/bay ejects. It is not like it is a policy thing. The only possible correct path to follow when doing an eject is to disable the devices and buses in the "it will be powered off" side of the ejection hardware. And depending on userspace for this is just (IMHO) ugly and error-prone. The kernel really should know how to do it, and doing it is *easy* as long as you know the mapping (which you should know for other reasons). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [ibm-acpi-devel] CONFIG_IBM_BAY 2007-03-15 19:31 ` CONFIG_IBM_BAY Henrique de Moraes Holschuh 2007-03-15 19:50 ` CONFIG_IBM_BAY Kristen Carlson Accardi @ 2007-03-15 20:31 ` Shem Multinymous 2007-03-15 20:49 ` Henrique de Moraes Holschuh 2007-03-19 12:04 ` Theodore Tso 2 siblings, 1 reply; 60+ messages in thread From: Shem Multinymous @ 2007-03-15 20:31 UTC (permalink / raw) To: Henrique de Moraes Holschuh Cc: Kristen Carlson Accardi, linux-acpi, ibm-acpi-devel, Len Brown On 3/15/07, Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote: > 2. It will do the right thing on plug and unplug. This means telling the > rest of the kernel to disable the device in the bay, for example. Right now > we shutdown one end of the PATA/SATA link on ThinkPads eletrically, and > leave libata to scream blood murder until it disables its end due to too > many retries, for example; I'm not sure which stage of the unplug you're referring to, but after a "lever released" event on ThinkPads there must remain a way for userspace code to run before the kernel does anything irreversible to the drivers or hardware (e.g., in order to try unmounting filesystems and, if that failed, tell the user to not pull the lever). The two-stage mechanical eject mechanisms on ThinkPad is pretty useful in this respect. Shem ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [ibm-acpi-devel] CONFIG_IBM_BAY 2007-03-15 20:31 ` [ibm-acpi-devel] CONFIG_IBM_BAY Shem Multinymous @ 2007-03-15 20:49 ` Henrique de Moraes Holschuh 0 siblings, 0 replies; 60+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-15 20:49 UTC (permalink / raw) To: Shem Multinymous Cc: Kristen Carlson Accardi, linux-acpi, ibm-acpi-devel, Len Brown On Thu, 15 Mar 2007, Shem Multinymous wrote: > I'm not sure which stage of the unplug you're referring to, but after > a "lever released" event on ThinkPads there must remain a way for > userspace code to run before the kernel does anything irreversible to I mean when one echo 1 >eject, so it won't clash with what you speak of. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [ibm-acpi-devel] CONFIG_IBM_BAY 2007-03-15 19:31 ` CONFIG_IBM_BAY Henrique de Moraes Holschuh 2007-03-15 19:50 ` CONFIG_IBM_BAY Kristen Carlson Accardi 2007-03-15 20:31 ` [ibm-acpi-devel] CONFIG_IBM_BAY Shem Multinymous @ 2007-03-19 12:04 ` Theodore Tso 2007-03-19 23:24 ` Henrique de Moraes Holschuh 2 siblings, 1 reply; 60+ messages in thread From: Theodore Tso @ 2007-03-19 12:04 UTC (permalink / raw) To: Henrique de Moraes Holschuh Cc: Kristen Carlson Accardi, linux-acpi, ibm-acpi-devel, Len Brown On Thu, Mar 15, 2007 at 04:31:24PM -0300, Henrique de Moraes Holschuh wrote: > I will see what I can do. My "first approach" at a requirements list for a > proper bay module are as follows: > > 1. It will handle all device types (ATAPI, PATA, SATA, batteries); > > 2. It will do the right thing on plug and unplug. This means telling the > rest of the kernel to disable the device in the bay, for example. Right now > we shutdown one end of the PATA/SATA link on ThinkPads eletrically, and > leave libata to scream blood murder until it disables its end due to too > many retries, for example; > > 3. It will allow model-specific drivers (like ibm-acpi) to be notified of > bay events (callbacks or a notifier chain, since ACPICA doesn't allow for > more than one driver notifier per handle) and to request an immediate > attempt of ejection or hotplug/bay device change verification. Some > thinkpads benefit from an eject before S3 sleep -- as long as what is inside > is not a battery... > > I don't see why the generic driver could not do all of the above. But it > will take a while to get there :-) And no, ibm-acpi can't do much more than > (1). One more thing I would add from a power management perspective. It should be able to powerdown the bay cleanly on suspend-to-ram, without necessarily disconnecting libata or unmounting the filesystem. It should also be possible for the user to be able to powerdown the bay (after first unmounting the filesystem and telling libata to let go of the device) if the user wishes to power down the bay for battery life reasons --- *without* requiring the user to eject the lever or remove the bay as a prerequisite to powering down the bay. (The T60 burns enough power as it is, without any additional help from the bay. :-) - Ted ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [ibm-acpi-devel] CONFIG_IBM_BAY 2007-03-19 12:04 ` Theodore Tso @ 2007-03-19 23:24 ` Henrique de Moraes Holschuh 2007-03-20 14:57 ` Theodore Tso 0 siblings, 1 reply; 60+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-19 23:24 UTC (permalink / raw) To: Theodore Tso Cc: Kristen Carlson Accardi, linux-acpi, ibm-acpi-devel, Len Brown On Mon, 19 Mar 2007, Theodore Tso wrote: > One more thing I would add from a power management perspective. It > should be able to powerdown the bay cleanly on suspend-to-ram, without > necessarily disconnecting libata or unmounting the filesystem. The disconnect-or-not needs to be user-configurable, as the user may well swap devices in the bay while the system is sleeping, AND this is supposed to be a valid thing to do from a usercase PoV (earlier ThinkPad laptops only had warm-swap bays, for example). So must be the powerdown, I suppose, just in case. > It should also be possible for the user to be able to powerdown the > bay (after first unmounting the filesystem and telling libata to let > go of the device) if the user wishes to power down the bay for battery > life reasons --- *without* requiring the user to eject the lever or > remove the bay as a prerequisite to powering down the bay. Currently the drivers do allow you to do just that, at least for the bay. I don't know about docks. > (The T60 burns enough power as it is, without any additional help from > the bay. :-) Agreed :) I want to add configurable powerdown-if-it-is-not-a-battery to ibm-acpi, as it is acceptable to Linux. Either Windows or some dumb harddisk must dislike this for some stupid reason, as the DSDT doesn't do it by itself and it could easily do it. In fact, I suppose password-protected HDs might be a nuisance to power off during S3, as they will be locked up when the system resumes... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [ibm-acpi-devel] CONFIG_IBM_BAY 2007-03-19 23:24 ` Henrique de Moraes Holschuh @ 2007-03-20 14:57 ` Theodore Tso 2007-03-20 15:14 ` Henrique de Moraes Holschuh 0 siblings, 1 reply; 60+ messages in thread From: Theodore Tso @ 2007-03-20 14:57 UTC (permalink / raw) To: Henrique de Moraes Holschuh Cc: Kristen Carlson Accardi, linux-acpi, ibm-acpi-devel, Len Brown On Mon, Mar 19, 2007 at 08:24:19PM -0300, Henrique de Moraes Holschuh wrote: > On Mon, 19 Mar 2007, Theodore Tso wrote: > > One more thing I would add from a power management perspective. It > > should be able to powerdown the bay cleanly on suspend-to-ram, without > > necessarily disconnecting libata or unmounting the filesystem. > > The disconnect-or-not needs to be user-configurable, as the user may well > swap devices in the bay while the system is sleeping, AND this is supposed > to be a valid thing to do from a usercase PoV (earlier ThinkPad laptops only > had warm-swap bays, for example). So must be the powerdown, I suppose, just > in case. Maybe, but then the suspend mail have to fail if there are processes that are keeping the filesystem from being unmounted. Or the processes hanging out on the hard drive or CD-ROM could get all of their file descriptors revoked on resume, I suppose, if the bay has been switched out..... - Ted ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [ibm-acpi-devel] CONFIG_IBM_BAY 2007-03-20 14:57 ` Theodore Tso @ 2007-03-20 15:14 ` Henrique de Moraes Holschuh 2007-03-20 18:45 ` Theodore Tso 0 siblings, 1 reply; 60+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-20 15:14 UTC (permalink / raw) To: Theodore Tso Cc: Kristen Carlson Accardi, linux-acpi, ibm-acpi-devel, Len Brown On Tue, 20 Mar 2007, Theodore Tso wrote: > > The disconnect-or-not needs to be user-configurable, as the user may well > > swap devices in the bay while the system is sleeping, AND this is supposed > > to be a valid thing to do from a usercase PoV (earlier ThinkPad laptops only > > had warm-swap bays, for example). So must be the powerdown, I suppose, just > > in case. > > Maybe, but then the suspend mail have to fail if there are processes > that are keeping the filesystem from being unmounted. Or the Yes. But this is standard functionality on the suspend path, anyway. > processes hanging out on the hard drive or CD-ROM could get all of > their file descriptors revoked on resume, I suppose, if the bay has > been switched out..... Urk. It is better to either fail the suspend, or to not power down the bay. Or to give the user a choice of which he'd rather happen. Hmm... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [ibm-acpi-devel] CONFIG_IBM_BAY 2007-03-20 15:14 ` Henrique de Moraes Holschuh @ 2007-03-20 18:45 ` Theodore Tso 2007-03-20 20:25 ` Shem Multinymous [not found] ` <20070320184541.GB29493-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org> 0 siblings, 2 replies; 60+ messages in thread From: Theodore Tso @ 2007-03-20 18:45 UTC (permalink / raw) To: Henrique de Moraes Holschuh Cc: Kristen Carlson Accardi, linux-acpi, ibm-acpi-devel, Len Brown On Tue, Mar 20, 2007 at 12:14:43PM -0300, Henrique de Moraes Holschuh wrote: > > Maybe, but then the suspend mail have to fail if there are processes > > that are keeping the filesystem from being unmounted. Or the > > Yes. But this is standard functionality on the suspend path, anyway. The problem with this is that some users will hit the suspend button, close the lid, put the laptop into their laptop bag, and then immediately head off to the next conference talk (or whatever). If the suspend is going to fail, they might not notice, and they might not swap out the bay in any case. > > processes hanging out on the hard drive or CD-ROM could get all of > > their file descriptors revoked on resume, I suppose, if the bay has > > been switched out..... > > Urk. It is better to either fail the suspend, or to not power down the bay. > Or to give the user a choice of which he'd rather happen. Hmm... Yeah, I think it needs to be configurable. In many cases the right thing to do is for the user to promise not to swap out bay, and in the exception case where they do, all of the processes that have files open on that bay will have to get their fd's revoked. We can try to make it less likely for there to be data loss, like asking filesystems that support write_super_lockfs() to quiesce the filesystem before the suspend, but the assumption should be that users aren't supposed to be swapping out the bay if they request the suspend code not to disconnect the filesystem. - Ted ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [ibm-acpi-devel] CONFIG_IBM_BAY 2007-03-20 18:45 ` Theodore Tso @ 2007-03-20 20:25 ` Shem Multinymous [not found] ` <20070320184541.GB29493-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org> 1 sibling, 0 replies; 60+ messages in thread From: Shem Multinymous @ 2007-03-20 20:25 UTC (permalink / raw) To: Theodore Tso Cc: Henrique de Moraes Holschuh, Kristen Carlson Accardi, linux-acpi, ibm-acpi-devel, Len Brown On 3/20/07, Theodore Tso <tytso@mit.edu> wrote: > > Urk. It is better to either fail the suspend, or to not power down the bay. > > Or to give the user a choice of which he'd rather happen. Hmm... > > Yeah, I think it needs to be configurable. In many cases the right > thing to do is for the user to promise not to swap out bay, and in the > exception case where they do, all of the processes that have files > open on that bay will have to get their fd's revoked. We can try to > make it less likely for there to be data loss, like asking filesystems > that support write_super_lockfs() to quiesce the filesystem before the > suspend, but the assumption should be that users aren't supposed to be > swapping out the bay if they request the suspend code not to > disconnect the filesystem. This is sensical and useful for other devices as well (e.g., USB flash drives). So the interface, and preferably the implementation too, should be generic. Shem ^ permalink raw reply [flat|nested] 60+ messages in thread
[parent not found: <20070320184541.GB29493-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>]
* Re: CONFIG_IBM_BAY [not found] ` <20070320184541.GB29493-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org> @ 2007-03-20 20:44 ` Henrique de Moraes Holschuh 0 siblings, 0 replies; 60+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-20 20:44 UTC (permalink / raw) To: Theodore Tso Cc: linux-acpi-u79uwXL29TY76Z2rM5mHXA, Len Brown, Kristen Carlson Accardi, ibm-acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f On Tue, 20 Mar 2007, Theodore Tso wrote: > On Tue, Mar 20, 2007 at 12:14:43PM -0300, Henrique de Moraes Holschuh wrote: > > > Maybe, but then the suspend mail have to fail if there are processes > > > that are keeping the filesystem from being unmounted. Or the > > > > Yes. But this is standard functionality on the suspend path, anyway. > > The problem with this is that some users will hit the suspend button, > close the lid, put the laptop into their laptop bag, and then > immediately head off to the next conference talk (or whatever). If > the suspend is going to fail, they might not notice, and they might > not swap out the bay in any case. Well, it needs to be *optional* anyway. But the above isn't the reason, though. Suspend *can* already fail, and anyone who acts like the above deserves to have to replace their laptop HD more often than those who actually wait the laptop to be suspended before they toss it into the bag :-) > > > processes hanging out on the hard drive or CD-ROM could get all of > > > their file descriptors revoked on resume, I suppose, if the bay has > > > been switched out..... > > > > Urk. It is better to either fail the suspend, or to not power down the bay. > > Or to give the user a choice of which he'd rather happen. Hmm... > > Yeah, I think it needs to be configurable. In many cases the right > thing to do is for the user to promise not to swap out bay, and in the > exception case where they do, all of the processes that have files > open on that bay will have to get their fd's revoked. We can try to > make it less likely for there to be data loss, like asking filesystems > that support write_super_lockfs() to quiesce the filesystem before the > suspend, but the assumption should be that users aren't supposed to be > swapping out the bay if they request the suspend code not to > disconnect the filesystem. Agreed. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: CONFIG_IBM_BAY 2007-03-15 17:55 ` CONFIG_IBM_BAY Henrique de Moraes Holschuh 2007-03-15 18:01 ` CONFIG_IBM_BAY Kristen Carlson Accardi @ 2007-03-15 18:22 ` Kristen Carlson Accardi 2007-03-15 19:33 ` CONFIG_IBM_BAY Henrique de Moraes Holschuh 1 sibling, 1 reply; 60+ messages in thread From: Kristen Carlson Accardi @ 2007-03-15 18:22 UTC (permalink / raw) To: Henrique de Moraes Holschuh; +Cc: Len Brown, linux-acpi, ibm-acpi-devel On Thu, 15 Mar 2007 14:55:06 -0300 Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote: > Please look at the patch I just sent. It allows ibm-acpi to load if > ACPI_BAY is loaded. It will, of course, cause ACPI_BAY to refuse to load if > ibm-acpi is already loaded, but that's probably fine as ACPI_BAY has just a > single function. The patch you sent seems fine - however, the bay driver will need a patch to correctly refuse to load when ibm_acpi is loaded and handling the bay. I'm testing this out now - will check it with your patch. Thanks, Kristen ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: CONFIG_IBM_BAY 2007-03-15 18:22 ` CONFIG_IBM_BAY Kristen Carlson Accardi @ 2007-03-15 19:33 ` Henrique de Moraes Holschuh 0 siblings, 0 replies; 60+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-15 19:33 UTC (permalink / raw) To: Kristen Carlson Accardi; +Cc: Len Brown, linux-acpi, ibm-acpi-devel On Thu, 15 Mar 2007, Kristen Carlson Accardi wrote: > On Thu, 15 Mar 2007 14:55:06 -0300 > Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote: > > > Please look at the patch I just sent. It allows ibm-acpi to load if > > ACPI_BAY is loaded. It will, of course, cause ACPI_BAY to refuse to load if > > ibm-acpi is already loaded, but that's probably fine as ACPI_BAY has just a > > single function. > > The patch you sent seems fine - however, the bay driver will need a patch > to correctly refuse to load when ibm_acpi is loaded and handling the bay. > I'm testing this out now - will check it with your patch. Will it? On 2.6.20 (I backported it) it bangs out with an error and refuses to load just fine... The only reason that's not quite acceptable in ibm-acpi is because ibm-acpi can do a lot more than just handle bay devices. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ^ permalink raw reply [flat|nested] 60+ messages in thread
end of thread, other threads:[~2007-03-20 20:44 UTC | newest]
Thread overview: 60+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-03-12 0:20 [GIT PULL] ibm-acpi changes acpi-test/2.6.22 Henrique de Moraes Holschuh
2007-03-12 0:20 ` [PATCH 1/6] ACPI: ibm-acpi: kill trailing whitespace Henrique de Moraes Holschuh
[not found] ` <11736588493322-git-send-email-hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>
2007-03-12 0:20 ` [PATCH 2/6] ACPI: ibm-acpi: rename some identifiers Henrique de Moraes Holschuh
[not found] ` <11736588491476-git-send-email-hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>
2007-03-12 0:20 ` [PATCH 3/6] ACPI: ibm-acpi: add header file Henrique de Moraes Holschuh
[not found] ` <11736588493502-git-send-email-hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>
2007-03-12 0:20 ` [PATCH 4/6] ACPI: ibm-acpi: organize code Henrique de Moraes Holschuh
2007-03-12 0:20 ` [PATCH 5/6] ACPI: ibm-acpi: update copyright notice Henrique de Moraes Holschuh
2007-03-12 0:20 ` [PATCH 6/6] ACPI: ibm-acpi: update documentation Henrique de Moraes Holschuh
2007-03-12 0:54 ` [GIT PULL] ibm-acpi changes acpi-test/2.6.22 Len Brown
2007-03-12 1:27 ` Henrique de Moraes Holschuh
2007-03-15 3:10 ` [GIT PULL] ibm-acpi move to drivers/misc Henrique de Moraes Holschuh
2007-03-15 3:12 ` [PATCH] ACPI: ibm-acpi: move driver to drivers/misc hierarchy Henrique de Moraes Holschuh
2007-03-15 6:06 ` CONFIG_IBM_BAY Len Brown
2007-03-15 13:39 ` CONFIG_IBM_BAY Henrique de Moraes Holschuh
2007-03-15 15:06 ` CONFIG_IBM_BAY Kristen Carlson Accardi
2007-03-15 17:55 ` CONFIG_IBM_BAY Henrique de Moraes Holschuh
2007-03-15 18:01 ` CONFIG_IBM_BAY Kristen Carlson Accardi
[not found] ` <20070315110156.09e80b99.kristen.c.accardi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2007-03-15 19:31 ` CONFIG_IBM_BAY Henrique de Moraes Holschuh
2007-03-15 19:50 ` CONFIG_IBM_BAY Kristen Carlson Accardi
2007-03-18 5:38 ` CONFIG_IBM_BAY Tejun Heo
2007-03-18 8:27 ` CONFIG_IBM_BAY Holger Macht
2007-03-18 18:36 ` CONFIG_IBM_BAY Henrique de Moraes Holschuh
2007-03-18 18:55 ` CONFIG_IBM_BAY Holger Macht
2007-03-18 19:00 ` CONFIG_IBM_BAY Henrique de Moraes Holschuh
2007-03-19 18:04 ` CONFIG_IBM_BAY Kristen Carlson Accardi
2007-03-20 15:53 ` CONFIG_IBM_BAY Holger Macht
2007-03-20 16:19 ` CONFIG_IBM_BAY Kristen Carlson Accardi
[not found] ` <20070320091932.f61bbdcc.kristen.c.accardi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2007-03-20 16:34 ` CONFIG_IBM_BAY Holger Macht
2007-03-19 18:17 ` CONFIG_IBM_BAY Kristen Carlson Accardi
2007-03-20 0:07 ` CONFIG_IBM_BAY Henrique de Moraes Holschuh
[not found] ` <20070320000706.GE5932-ZGHd14iZgfaRjzvQDGKj+xxZW9W5cXbT@public.gmane.org>
2007-03-20 16:14 ` CONFIG_IBM_BAY Kristen Carlson Accardi
2007-03-19 13:22 ` CONFIG_IBM_BAY Matthew Garrett
[not found] ` <20070319132243.GA2869-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>
2007-03-19 13:48 ` CONFIG_IBM_BAY Holger Macht
2007-03-19 14:04 ` CONFIG_IBM_BAY Matthew Garrett
2007-03-19 14:37 ` CONFIG_IBM_BAY Holger Macht
[not found] ` <20070319143746.GC4885-tB0uoaAy/Z1bpigZmTR7Iw@public.gmane.org>
2007-03-19 18:11 ` CONFIG_IBM_BAY Kristen Carlson Accardi
2007-03-19 23:11 ` [ibm-acpi-devel] CONFIG_IBM_BAY Henrique de Moraes Holschuh
2007-03-19 23:56 ` Kristen Carlson Accardi
2007-03-20 0:12 ` Henrique de Moraes Holschuh
2007-03-20 16:11 ` Kristen Carlson Accardi
2007-03-20 16:07 ` CONFIG_IBM_BAY Holger Macht
[not found] ` <20070320160707.GB6079-tB0uoaAy/Z1bpigZmTR7Iw@public.gmane.org>
2007-03-20 16:16 ` CONFIG_IBM_BAY Holger Macht
[not found] ` <20070319140403.GA3697-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>
2007-03-19 15:36 ` CONFIG_IBM_BAY Henrique de Moraes Holschuh
2007-03-19 15:47 ` CONFIG_IBM_BAY Holger Macht
[not found] ` <20070319153659.GB15942-ZGHd14iZgfaRjzvQDGKj+xxZW9W5cXbT@public.gmane.org>
2007-03-19 16:41 ` CONFIG_IBM_BAY Shem Multinymous
[not found] ` <41840b750703190941p77fc4a64k49361b678dd6aa90-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2007-03-19 23:04 ` CONFIG_IBM_BAY Henrique de Moraes Holschuh
2007-03-20 14:18 ` [ibm-acpi-devel] CONFIG_IBM_BAY Shem Multinymous
2007-03-20 15:12 ` Henrique de Moraes Holschuh
2007-03-19 18:00 ` CONFIG_IBM_BAY Kristen Carlson Accardi
[not found] ` <45FCD062.3050001-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2007-03-18 18:26 ` CONFIG_IBM_BAY Henrique de Moraes Holschuh
2007-03-15 20:31 ` [ibm-acpi-devel] CONFIG_IBM_BAY Shem Multinymous
2007-03-15 20:49 ` Henrique de Moraes Holschuh
2007-03-19 12:04 ` Theodore Tso
2007-03-19 23:24 ` Henrique de Moraes Holschuh
2007-03-20 14:57 ` Theodore Tso
2007-03-20 15:14 ` Henrique de Moraes Holschuh
2007-03-20 18:45 ` Theodore Tso
2007-03-20 20:25 ` Shem Multinymous
[not found] ` <20070320184541.GB29493-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2007-03-20 20:44 ` CONFIG_IBM_BAY Henrique de Moraes Holschuh
2007-03-15 18:22 ` CONFIG_IBM_BAY Kristen Carlson Accardi
2007-03-15 19:33 ` CONFIG_IBM_BAY Henrique de Moraes Holschuh
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox