Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6

		     ThinkPad ACPI Extras Driver

                            Version 0.19

                         January 06th, 2008

                            Version 0.20

                          April 09th, 2008

               Borislav Deianov <borislav@users.sf.net>

             Henrique de Moraes Holschuh <hmh@hmh.eng.br>

moved to the drivers/misc tree and renamed to thinkpad-acpi for kernel

2.6.22, and release 0.14.

The driver is named "thinkpad-acpi".  In some places, like module

names, "thinkpad_acpi" is used because of userspace issues.

"tpacpi" is used as a shorthand where "thinkpad-acpi" would be too

long due to length limitations on some Linux kernel versions.

Status

------

with hotkey_report_mode.

Brightness hotkey notes:

These are the current sane choices for brightness key mapping in

thinkpad-acpi:

For IBM and Lenovo models *without* ACPI backlight control (the ones on

which thinkpad-acpi will autoload its backlight interface by default,

and on which ACPI video does not export a backlight interface):

1. Don't enable or map the brightness hotkeys in thinkpad-acpi, as

   these older firmware versions unfortunately won't respect the hotkey

   mask for brightness keys anyway, and always reacts to them.  This

   usually work fine, unless X.org drivers are doing something to block

   the BIOS.  In that case, use (3) below.  This is the default mode of

   operation.

2. Enable the hotkeys, but map them to something else that is NOT

   KEY_BRIGHTNESS_UP/DOWN or any other keycode that would cause

   userspace to try to change the backlight level, and use that as an

   on-screen-display hint.

3. IF AND ONLY IF X.org drivers find a way to block the firmware from

   automatically changing the brightness, enable the hotkeys and map

   them to KEY_BRIGHTNESS_UP and KEY_BRIGHTNESS_DOWN, and feed that to

   something that calls xbacklight.  thinkpad-acpi will not be able to

   change brightness in that case either, so you should disable its

   backlight interface.

For Lenovo models *with* ACPI backlight control:

1. Load up ACPI video and use that.  ACPI video will report ACPI

   events for brightness change keys.  Do not mess with thinkpad-acpi

   defaults in this case.  thinkpad-acpi should not have anything to do

   with backlight events in a scenario where ACPI video is loaded:

   brightness hotkeys must be disabled, and the backlight interface is

   to be kept disabled as well.  This is the default mode of operation.

2. Do *NOT* load up ACPI video, enable the hotkeys in thinkpad-acpi,

   and map them to KEY_BRIGHTNESS_UP and KEY_BRIGHTNESS_DOWN.  Process

   these keys on userspace somehow (e.g. by calling xbacklight).

Bluetooth

---------

https://bugs.freedesktop.org/show_bug.cgi?id=2000

ThinkLight control -- /proc/acpi/ibm/light

------------------------------------------

ThinkLight control

------------------

procfs: /proc/acpi/ibm/light

sysfs attributes: as per LED class, for the "tpacpi::thinklight" LED

The current status of the ThinkLight can be found in this file. A few

models which do not make the status available will show it as

"unknown". The available commands are:

procfs notes:

The ThinkLight status can be read and set through the procfs interface.  A

few models which do not make the status available will show the ThinkLight

status as "unknown". The available commands are:

	echo on  > /proc/acpi/ibm/light

	echo off > /proc/acpi/ibm/light

sysfs notes:

The ThinkLight sysfs interface is documented by the LED class

documentation, in Documentation/leds-class.txt.  The ThinkLight LED name

is "tpacpi::thinklight".

Due to limitations in the sysfs LED class, if the status of the thinklight

cannot be read or if it is unknown, thinkpad-acpi will report it as "off".

It is impossible to know if the status returned through sysfs is valid.

Docking / undocking -- /proc/acpi/ibm/dock

------------------------------------------

in newer ThinkPads it is just a compatibility layer.  Do not use it, it is

exported just as a debug tool.

LED control -- /proc/acpi/ibm/led

---------------------------------

LED control

-----------

procfs: /proc/acpi/ibm/led

sysfs attributes: as per LED class, see below for names

Some of the LED indicators can be controlled through this feature.  On

some older ThinkPad models, it is possible to query the status of the

LED indicators as well.  Newer ThinkPads cannot query the real status

of the LED indicators.

Some of the LED indicators can be controlled through this feature. The

available commands are:

procfs notes:

The available commands are:

	echo '<led number> on' >/proc/acpi/ibm/led

	echo '<led number> off' >/proc/acpi/ibm/led

	echo '<led number> blink' >/proc/acpi/ibm/led

	echo '<LED number> on' >/proc/acpi/ibm/led

	echo '<LED number> off' >/proc/acpi/ibm/led

	echo '<LED number> blink' >/proc/acpi/ibm/led

The <led number> range is 0 to 7. The set of LEDs that can be

controlled varies from model to model. Here is the mapping on the X40:

The <LED number> range is 0 to 7. The set of LEDs that can be

controlled varies from model to model. Here is the common ThinkPad

mapping:

	0 - power

	1 - battery (orange)

	2 - battery (green)

	3 - UltraBase

	3 - UltraBase/dock

	4 - UltraBay

	5 - UltraBase battery slot

	6 - (unknown)

	7 - standby

All of the above can be turned on and off and can be made to blink.

sysfs notes:

The ThinkPad LED sysfs interface is described in detail by the LED class

documentation, in Documentation/leds-class.txt.

The leds are named (in LED ID order, from 0 to 7):

"tpacpi::power", "tpacpi:orange:batt", "tpacpi:green:batt",

"tpacpi::dock_active", "tpacpi::bay_active", "tpacpi::dock_batt",

"tpacpi::unknown_led", "tpacpi::standby".

Due to limitations in the sysfs LED class, if the status of the LED

indicators cannot be read due to an error, thinkpad-acpi will report it as

a brightness of zero (same as LED off).

If the thinkpad firmware doesn't support reading the current status,

trying to read the current LED brightness will just return whatever

brightness was last written to that attribute.

These LEDs can blink using hardware acceleration.  To request that a

ThinkPad indicator LED should blink in hardware accelerated mode, use the

"timer" trigger, and leave the delay_on and delay_off parameters set to

zero (to request hardware acceleration autodetection).

ACPI sounds -- /proc/acpi/ibm/beep

----------------------------------

		dim the display.

WARNING:

    Whatever you do, do NOT ever call thinkpad-acpi backlight-level change

    interface and the ACPI-based backlight level change interface

    (available on newer BIOSes, and driven by the Linux ACPI video driver)

    at the same time.  The two will interact in bad ways, do funny things,

    and maybe reduce the life of the backlight lamps by needlessly kicking

    its level up and down at every change.

Volume control -- /proc/acpi/ibm/volume

---------------------------------------

RO	read only value

RW	read/write value

All thermal sysfs attributes will be represented under /sys/class/thermal

Thermal sysfs attributes will be represented under /sys/class/thermal.

Hwmon sysfs I/F extension is also available under /sys/class/hwmon

if hwmon is compiled in or built as a module.

Thermal zone device sys I/F, created once it's registered:

|thermal_zone[0-*]:

/sys/class/thermal/thermal_zone[0-*]:

	|-----type:			Type of the thermal zone

	|-----temp:			Current temperature

	|-----mode:			Working mode of the thermal zone

	|-----trip_point_[0-*]_type:	Trip point type

Thermal cooling device sys I/F, created once it's registered:

|cooling_device[0-*]:

/sys/class/thermal/cooling_device[0-*]:

	|-----type :			Type of the cooling device(processor/fan/...)

	|-----max_state:		Maximum cooling state of the cooling device

	|-----cur_state:		Current cooling state of the cooling device

They are created/removed for each

thermal_zone_bind_cooling_device/thermal_zone_unbind_cooling_device successful execution.

|thermal_zone[0-*]

/sys/class/thermal/thermal_zone[0-*]

	|-----cdev[0-*]:		The [0-*]th cooling device in the current thermal zone

	|-----cdev[0-*]_trip_point:	Trip point that cdev[0-*] is associated with

Besides the thermal zone device sysfs I/F and cooling device sysfs I/F,

the generic thermal driver also creates a hwmon sysfs I/F for each _type_ of

thermal zone device. E.g. the generic thermal driver registers one hwmon class device

and build the associated hwmon sysfs I/F for all the registered ACPI thermal zones.

/sys/class/hwmon/hwmon[0-*]:

	|-----name:			The type of the thermal zone devices.

	|-----temp[1-*]_input:		The current temperature of thermal zone [1-*].

	|-----temp[1-*]_critical:	The critical trip point of thermal zone [1-*].

Please read Documentation/hwmon/sysfs-interface for additional information.

***************************

* Thermal zone attributes *

type				Strings which represent the thermal zone type.

				This is given by thermal zone driver as part of registration.

				Eg: "ACPI thermal zone" indicates it's a ACPI thermal device

				Eg: "acpitz" indicates it's an ACPI thermal device.

				In order to keep it consistent with hwmon sys attribute,

				this should be a short, lowercase string,

				not containing spaces nor dashes.

				RO

				Required

/sys/class/thermal:

|thermal_zone1:

	|-----type:			ACPI thermal zone

	|-----type:			acpitz

	|-----temp:			37000

	|-----mode:			kernel

	|-----trip_point_0_temp:	100000

	|-----type:			Fan

	|-----max_state:		2

	|-----cur_state:		0

/sys/class/hwmon:

|hwmon0:

	|-----name:			acpitz

	|-----temp1_input:		37000

	|-----temp1_crit:		100000

W:	bluesmoke.sourceforge.net

S:	Maintained

EEEPC LAPTOP EXTRAS DRIVER

P:	Corentin Chary

M:	corentincj@iksaif.net

L:	acpi4asus-user@lists.sourceforge.net

W:	http://sourceforge.net/projects/acpi4asus

S:	Maintained

EEPRO100 NETWORK DRIVER

P:	Andrey V. Savochkin

M:	saw@saw.sw.com.sg

	if ((mode != 1) && (mode != 5))

		return -EINVAL;

	retval = pm_send_all(PM_SUSPEND, (void *)3);

	if (retval == 0) {

		if (mode == 5)

		    retval = pm_do_bus_sleep();

		else

		    retval = pm_do_suspend();

		pm_send_all(PM_RESUME, (void *)0);

	}

	return retval;

	if (!(clock_cmodes_permitted & (1<<new_cmode)))

		return -EINVAL;

	/* tell all the drivers we're suspending */

	pm_send_all(PM_SUSPEND, (void *)3);

	/* now change cmode */

	local_irq_disable();

	frv_dma_pause_all();

	frv_dma_resume_all();

	local_irq_enable();

	/* tell all the drivers we're resuming */

	pm_send_all(PM_RESUME, (void *)0);

	return 0;

}

static int pm_do_sleep(ctl_table * ctl, int write, struct file *file,

		       void __user *buffer, size_t * len, loff_t *ppos)

{

	int retval = 0;

#ifdef SLEEP_TEST_TIMEOUT

#define TMPBUFLEN2 16

	char buf[TMPBUFLEN2], *p;

		p = buf;

		sleep_ticks = simple_strtoul(p, &p, 0);

#endif

		retval = pm_send_all(PM_SUSPEND, (void *) 2);

		if (retval)

			return retval;

		au_sleep();

		retval = pm_send_all(PM_RESUME, (void *) 0);

	}

	return retval;

	}

static int pm_do_suspend(ctl_table * ctl, int write, struct file *file,

			 void __user *buffer, size_t * len, loff_t *ppos)

{

	int retval = 0;

	if (!write) {

		*len = 0;

	} else {

		retval = pm_send_all(PM_SUSPEND, (void *) 2);

		if (retval)

			return retval;

		suspend_mode = 1;

		retval = pm_send_all(PM_RESUME, (void *) 0);

	}

	return retval;

	return 0;

}

static int pm_do_freq(ctl_table * ctl, int write, struct file *file,

		      void __user *buffer, size_t * len, loff_t *ppos)

{

static struct ctl_table pm_table[] = {

	{

		.ctl_name 	= CTL_UNNUMBERED,

		.procname	= "suspend",

		.data		= NULL,

		.maxlen		= 0,

		.mode		= 0600,

		.proc_handler	= &pm_do_suspend

	},

	{

		.ctl_name	= CTL_UNNUMBERED,

		.procname	= "sleep",