doc: fix broken references
[linux-2.6.git] / Documentation / laptops / thinkpad-acpi.txt
index 6c24777..3ff0dad 100644 (file)
@@ -1,7 +1,7 @@
                     ThinkPad ACPI Extras Driver
 
-                            Version 0.19
-                         January 06th, 2008
+                            Version 0.24
+                        December 11th,  2009
 
                Borislav Deianov <borislav@users.sf.net>
              Henrique de Moraes Holschuh <hmh@hmh.eng.br>
@@ -16,8 +16,15 @@ supported by the generic Linux ACPI drivers.
 This driver used to be named ibm-acpi until kernel 2.6.21 and release
 0.13-20070314.  It used to be in the drivers/acpi tree, but it was
 moved to the drivers/misc tree and renamed to thinkpad-acpi for kernel
-2.6.22, and release 0.14.
+2.6.22, and release 0.14.  It was moved to drivers/platform/x86 for
+kernel 2.6.29 and release 0.22.
 
+The driver is named "thinkpad-acpi".  In some places, like module
+names and log messages, "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
 ------
@@ -29,9 +36,7 @@ detailed description):
        - Bluetooth enable and disable
        - video output switching, expansion control
        - ThinkLight on and off
-       - limited docking and undocking
-       - UltraBay eject
-       - CMOS control
+       - CMOS/UCMS control
        - LED control
        - ACPI sounds
        - temperature sensors
@@ -39,7 +44,8 @@ detailed description):
        - LCD brightness control
        - Volume control
        - Fan control and monitoring: fan speed, fan enable/disable
-       - Experimental: WAN enable and disable
+       - WAN enable and disable
+       - UWB enable and disable
 
 A compatibility table by model and feature is maintained on the web
 site, http://ibm-acpi.sf.net/. I appreciate any success or failure
@@ -47,7 +53,7 @@ reports, especially if they add to or correct the compatibility table.
 Please include the following information in your report:
 
        - ThinkPad model name
-       - a copy of your DSDT, from /proc/acpi/dsdt
+       - a copy of your ACPI tables, using the "acpidump" utility
        - a copy of the output of dmidecode, with serial numbers
          and UUIDs masked off
        - which driver features work and which don't
@@ -60,17 +66,18 @@ Installation
 ------------
 
 If you are compiling this driver as included in the Linux kernel
-sources, simply enable the CONFIG_THINKPAD_ACPI option, and optionally
-enable the CONFIG_THINKPAD_ACPI_BAY option if you want the
-thinkpad-specific bay functionality.
+sources, look for the CONFIG_THINKPAD_ACPI Kconfig option.
+It is located on the menu path: "Device Drivers" -> "X86 Platform
+Specific Device Drivers" -> "ThinkPad ACPI Laptop Extras".
+
 
 Features
 --------
 
 The driver exports two different interfaces to userspace, which can be
 used to access the features it provides.  One is a legacy procfs-based
-interface, which will be removed at some time in the distant future.
-The other is a new sysfs-based interface which is not complete yet.
+interface, which will be removed at some time in the future.  The other
+is a new sysfs-based interface which is not complete yet.
 
 The procfs interface creates the /proc/acpi/ibm directory.  There is a
 file under that directory for each feature it supports.  The procfs
@@ -105,15 +112,17 @@ The version of thinkpad-acpi's sysfs interface is exported by the driver
 as a driver attribute (see below).
 
 Sysfs driver attributes are on the driver's sysfs attribute space,
-for 2.6.23 this is /sys/bus/platform/drivers/thinkpad_acpi/ and
+for 2.6.23+ this is /sys/bus/platform/drivers/thinkpad_acpi/ and
 /sys/bus/platform/drivers/thinkpad_hwmon/
 
 Sysfs device attributes are on the thinkpad_acpi device sysfs attribute
-space, for 2.6.23 this is /sys/devices/platform/thinkpad_acpi/.
+space, for 2.6.23+ this is /sys/devices/platform/thinkpad_acpi/.
 
 Sysfs device attributes for the sensors and fan are on the
 thinkpad_hwmon device's sysfs attribute space, but you should locate it
-looking for a hwmon device with the name attribute of "thinkpad".
+looking for a hwmon device with the name attribute of "thinkpad", or
+better yet, through libsensors.
+
 
 Driver version
 --------------
@@ -123,6 +132,7 @@ sysfs driver attribute: version
 
 The driver name and version. No commands can be written to this file.
 
+
 Sysfs interface version
 -----------------------
 
@@ -154,29 +164,27 @@ expect that an attribute might not be there, and deal with it properly
 (an attribute not being there *is* a valid way to make it clear that a
 feature is not available in sysfs).
 
+
 Hot keys
 --------
 
 procfs: /proc/acpi/ibm/hotkey
 sysfs device attribute: hotkey_*
 
-In a ThinkPad, the ACPI HKEY handler is responsible for comunicating
+In a ThinkPad, the ACPI HKEY handler is responsible for communicating
 some important events and also keyboard hot key presses to the operating
 system.  Enabling the hotkey functionality of thinkpad-acpi signals the
 firmware that such a driver is present, and modifies how the ThinkPad
 firmware will behave in many situations.
 
-The driver enables the hot key feature automatically when loaded.  The
-feature can later be disabled and enabled back at runtime.  The driver
-will also restore the hot key feature to its previous state and mask
-when it is unloaded.
+The driver enables the HKEY ("hot key") event reporting automatically
+when loaded, and disables it when it is removed.
 
-When the hotkey feature is enabled and the hot key mask is set (see
-below), the driver will report HKEY events in the following format:
+The driver will report HKEY events in the following format:
 
        ibm/hotkey HKEY 00000080 0000xxxx
 
-Some of these events refer to hot key presses, but not all.
+Some of these events refer to hot key presses, but not all of them.
 
 The driver will generate events over the input layer for hot keys and
 radio switches, and over the ACPI netlink layer for other events.  The
@@ -191,29 +199,37 @@ kind to allow it (and it often doesn't!).
 
 Not all bits in the mask can be modified.  Not all bits that can be
 modified do anything.  Not all hot keys can be individually controlled
-by the mask.  Some models do not support the mask at all, and in those
-models, hot keys cannot be controlled individually.  The behaviour of
-the mask is, therefore, higly dependent on the ThinkPad model.
+by the mask.  Some models do not support the mask at all.  The behaviour
+of the mask is, therefore, highly dependent on the ThinkPad model.
+
+The driver will filter out any unmasked hotkeys, so even if the firmware
+doesn't allow disabling an specific hotkey, the driver will not report
+events for unmasked hotkeys.
 
 Note that unmasking some keys prevents their default behavior.  For
 example, if Fn+F5 is unmasked, that key will no longer enable/disable
-Bluetooth by itself.
+Bluetooth by itself in firmware.
 
-Note also that not all Fn key combinations are supported through ACPI.
-For example, on the X40, the brightness, volume and "Access IBM" buttons
-do not generate ACPI events even with this driver.  They *can* be used
-through the "ThinkPad Buttons" utility, see http://www.nongnu.org/tpb/
+Note also that not all Fn key combinations are supported through ACPI
+depending on the ThinkPad model and firmware version.  On those
+ThinkPads, it is still possible to support some extra hotkeys by
+polling the "CMOS NVRAM" at least 10 times per second.  The driver
+attempts to enables this functionality automatically when required.
 
 procfs notes:
 
 The following commands can be written to the /proc/acpi/ibm/hotkey file:
 
-       echo enable > /proc/acpi/ibm/hotkey -- enable the hot keys feature
-       echo disable > /proc/acpi/ibm/hotkey -- disable the hot keys feature
        echo 0xffffffff > /proc/acpi/ibm/hotkey -- enable all hot keys
        echo 0 > /proc/acpi/ibm/hotkey -- disable all possible hot keys
        ... any other 8-hex-digit mask ...
-       echo reset > /proc/acpi/ibm/hotkey -- restore the original mask
+       echo reset > /proc/acpi/ibm/hotkey -- restore the recommended mask
+
+The following commands have been deprecated and will cause the kernel
+to log a warning:
+
+       echo enable > /proc/acpi/ibm/hotkey -- does nothing
+       echo disable > /proc/acpi/ibm/hotkey -- returns an error
 
 The procfs interface does not support NVRAM polling control.  So as to
 maintain maximum bug-to-bug compatibility, it does not report any masks,
@@ -223,40 +239,31 @@ does not support masks at all, even if NVRAM polling is in use.
 sysfs notes:
 
        hotkey_bios_enabled:
-               Returns the status of the hot keys feature when
-               thinkpad-acpi was loaded.  Upon module unload, the hot
-               key feature status will be restored to this value.
+               DEPRECATED, WILL BE REMOVED SOON.
 
-               0: hot keys were disabled
-               1: hot keys were enabled (unusual)
+               Returns 0.
 
        hotkey_bios_mask:
+               DEPRECATED, DON'T USE, WILL BE REMOVED IN THE FUTURE.
+
                Returns the hot keys mask when thinkpad-acpi was loaded.
                Upon module unload, the hot keys mask will be restored
-               to this value.
+               to this value.   This is always 0x80c, because those are
+               the hotkeys that were supported by ancient firmware
+               without mask support.
 
        hotkey_enable:
-               Enables/disables the hot keys feature in the ACPI
-               firmware, and reports current status of the hot keys
-               feature.  Has no effect on the NVRAM hot key polling
-               functionality.
+               DEPRECATED, WILL BE REMOVED SOON.
 
-               0: disables the hot keys feature / feature disabled
-               1: enables the hot keys feature / feature enabled
+               0: returns -EPERM
+               1: does nothing
 
        hotkey_mask:
-               bit mask to enable driver-handling (and depending on
+               bit mask to enable reporting (and depending on
                the firmware, ACPI event generation) for each hot key
                (see above).  Returns the current status of the hot keys
                mask, and allows one to modify it.
 
-               Note: when NVRAM polling is active, the firmware mask
-               will be different from the value returned by
-               hotkey_mask.  The driver will retain enabled bits for
-               hotkeys that are under NVRAM polling even if the
-               firmware refuses them, and will not set these bits on
-               the firmware hot key mask.
-
        hotkey_all_mask:
                bit mask that should enable event reporting for all
                supported hot keys, when echoed to hotkey_mask above.
@@ -269,7 +276,8 @@ sysfs notes:
                bit mask that should enable event reporting for all
                supported hot keys, except those which are always
                handled by the firmware anyway.  Echo it to
-               hotkey_mask above, to use.
+               hotkey_mask above, to use.  This is the default mask
+               used by the driver.
 
        hotkey_source_mask:
                bit mask that selects which hot keys will the driver
@@ -277,19 +285,20 @@ sysfs notes:
                based on the capabilities reported by the ACPI firmware,
                but it can be overridden at runtime.
 
-               Hot keys whose bits are set in both hotkey_source_mask
-               and also on hotkey_mask are polled for in NVRAM.  Only a
-               few hot keys are available through CMOS NVRAM polling.
+               Hot keys whose bits are set in hotkey_source_mask are
+               polled for in NVRAM, and reported as hotkey events if
+               enabled in hotkey_mask.  Only a few hot keys are
+               available through CMOS NVRAM polling.
 
                Warning: when in NVRAM mode, the volume up/down/mute
                keys are synthesized according to changes in the mixer,
-               so you have to use volume up or volume down to unmute,
-               as per the ThinkPad volume mixer user interface.  When
-               in ACPI event mode, volume up/down/mute are reported as
-               separate events, but this behaviour may be corrected in
-               future releases of this driver, in which case the
-               ThinkPad volume mixer user interface semanthics will be
-               enforced.
+               which uses a single volume up or volume down hotkey
+               press to unmute, as per the ThinkPad volume mixer user
+               interface.  When in ACPI event mode, volume up/down/mute
+               events are reported by the firmware and can behave
+               differently (and that behaviour changes with firmware
+               version -- not just with firmware models -- as well as
+               OSI(Linux) state).
 
        hotkey_poll_freq:
                frequency in Hz for hot key polling. It must be between
@@ -300,19 +309,26 @@ sysfs notes:
                will cause hot key presses that require NVRAM polling
                to never be reported.
 
-               Setting hotkey_poll_freq too low will cause repeated
+               Setting hotkey_poll_freq too low may cause repeated
                pressings of the same hot key to be misreported as a
                single key press, or to not even be detected at all.
                The recommended polling frequency is 10Hz.
 
        hotkey_radio_sw:
-               if the ThinkPad has a hardware radio switch, this
+               If the ThinkPad has a hardware radio switch, this
                attribute will read 0 if the switch is in the "radios
-               disabled" postition, and 1 if the switch is in the
+               disabled" position, and 1 if the switch is in the
                "radios enabled" position.
 
                This attribute has poll()/select() support.
 
+       hotkey_tablet_mode:
+               If the ThinkPad has tablet capabilities, this attribute
+               will read 0 if the ThinkPad is in normal mode, and
+               1 if the ThinkPad is in tablet mode.
+
+               This attribute has poll()/select() support.
+
        hotkey_report_mode:
                Returns the state of the procfs ACPI event report mode
                filter for hot keys.  If it is set to 1 (the default),
@@ -339,7 +355,7 @@ sysfs notes:
        wakeup_hotunplug_complete:
                Set to 1 if the system was waken up because of an
                undock or bay ejection request, and that request
-               was sucessfully completed.  At this point, it might
+               was successfully completed.  At this point, it might
                be useful to send the system back to sleep, at the
                user's choice.  Refer to HKEY events 0x4003 and
                0x3003, below.
@@ -381,6 +397,7 @@ ACPI        Scan
 event  code    Key             Notes
 
 0x1001 0x00    FN+F1           -
+
 0x1002 0x01    FN+F2           IBM: battery (rare)
                                Lenovo: Screen lock
 
@@ -388,11 +405,12 @@ event     code    Key             Notes
                                this hot key, even with hot keys
                                disabled or with Fn+F3 masked
                                off
-                               IBM: screen lock
+                               IBM: screen lock, often turns
+                               off the ThinkLight as side-effect
                                Lenovo: battery
 
 0x1004 0x03    FN+F4           Sleep button (ACPI sleep button
-                               semanthics, i.e. sleep-to-RAM).
+                               semantics, i.e. sleep-to-RAM).
                                It is always generate some kind
                                of event, either the hot key
                                event or a ACPI sleep button
@@ -403,12 +421,12 @@ event     code    Key             Notes
                                time passes.
 
 0x1005 0x04    FN+F5           Radio.  Enables/disables
-                               the internal BlueTooth hardware
+                               the internal Bluetooth hardware
                                and W-WAN card if left in control
                                of the firmware.  Does not affect
                                the WLAN card.
                                Should be used to turn on/off all
-                               radios (bluetooth+W-WAN+WLAN),
+                               radios (Bluetooth+W-WAN+WLAN),
                                really.
 
 0x1006 0x05    FN+F6           -
@@ -417,7 +435,8 @@ event       code    Key             Notes
                                Do you feel lucky today?
 
 0x1008 0x07    FN+F8           IBM: toggle screen expand
-                               Lenovo: configure ultranav
+                               Lenovo: configure UltraNav,
+                               or toggle screen expand
 
 0x1009 0x08    FN+F9           -
        ..      ..              ..
@@ -428,7 +447,7 @@ event       code    Key             Notes
                                either through the ACPI event,
                                or through a hotkey event.
                                The firmware may refuse to
-                               generate further FN+F4 key
+                               generate further FN+F12 key
                                press events until a S3 or S4
                                ACPI sleep cycle is performed,
                                or some time passes.
@@ -444,10 +463,12 @@ event     code    Key             Notes
                                For Lenovo ThinkPads with a new
                                BIOS, it has to be handled either
                                by the ACPI OSI, or by userspace.
+                               The driver does the right thing,
+                               never mess with this.
 0x1011 0x10    FN+END          Brightness down.  See brightness
                                up for details.
 
-0x1012 0x11    FN+PGUP         Thinklight toggle.  This key is
+0x1012 0x11    FN+PGUP         ThinkLight toggle.  This key is
                                always handled by the firmware,
                                even when unmasked.
 
@@ -469,7 +490,7 @@ event       code    Key             Notes
                                key is always handled by the
                                firmware, even when unmasked.
 
-0x1018 0x17    THINKPAD        Thinkpad/Access IBM/Lenovo key
+0x1018 0x17    THINKPAD        ThinkPad/Access IBM/Lenovo key
 
 0x1019 0x18    unknown
 ..     ..      ..
@@ -488,30 +509,70 @@ If a key is mapped to KEY_UNKNOWN, it generates an input event that
 includes an scan code.  If a key is mapped to anything else, it will
 generate input device EV_KEY events.
 
-Non hot-key ACPI HKEY event map:
+In addition to the EV_KEY events, thinkpad-acpi may also issue EV_SW
+events for switches:
+
+SW_RFKILL_ALL  T60 and later hardware rfkill rocker switch
+SW_TABLET_MODE Tablet ThinkPads HKEY events 0x5009 and 0x500A
+
+Non hotkey ACPI HKEY event map:
+-------------------------------
+
+Events that are not propagated by the driver, except for legacy
+compatibility purposes when hotkey_report_mode is set to 1:
+
 0x5001         Lid closed
 0x5002         Lid opened
+0x5009         Tablet swivel: switched to tablet mode
+0x500A         Tablet swivel: switched to normal mode
 0x7000         Radio Switch may have changed state
 
-The above events are not propagated by the driver, except for legacy
-compatibility purposes when hotkey_report_mode is set to 1.
+Events that are never propagated by the driver:
 
 0x2304         System is waking up from suspend to undock
 0x2305         System is waking up from suspend to eject bay
 0x2404         System is waking up from hibernation to undock
 0x2405         System is waking up from hibernation to eject bay
+0x5010         Brightness level changed/control event
+0x6000         KEYBOARD: Numlock key pressed
+0x6005         KEYBOARD: Fn key pressed (TO BE VERIFIED)
 
-The above events are never propagated by the driver.
+Events that are propagated by the driver to userspace:
 
+0x2313         ALARM: System is waking up from suspend because
+               the battery is nearly empty
+0x2413         ALARM: System is waking up from hibernation because
+               the battery is nearly empty
 0x3003         Bay ejection (see 0x2x05) complete, can sleep again
+0x3006         Bay hotplug request (hint to power up SATA link when
+               the optical drive tray is ejected)
 0x4003         Undocked (see 0x2x04), can sleep again
-0x5009         Tablet swivel: switched to tablet mode
-0x500A         Tablet swivel: switched to normal mode
-0x500B         Tablet pen insterted into its storage bay
+0x4010         Docked into hotplug port replicator (non-ACPI dock)
+0x4011         Undocked from hotplug port replicator (non-ACPI dock)
+0x500B         Tablet pen inserted into its storage bay
 0x500C         Tablet pen removed from its storage bay
-0x5010         Brightness level changed (newer Lenovo BIOSes)
-
-The above events are propagated by the driver.
+0x6011         ALARM: battery is too hot
+0x6012         ALARM: battery is extremely hot
+0x6021         ALARM: a sensor is too hot
+0x6022         ALARM: a sensor is extremely hot
+0x6030         System thermal table changed
+0x6040         Nvidia Optimus/AC adapter related (TO BE VERIFIED)
+
+Battery nearly empty alarms are a last resort attempt to get the
+operating system to hibernate or shutdown cleanly (0x2313), or shutdown
+cleanly (0x2413) before power is lost.  They must be acted upon, as the
+wake up caused by the firmware will have negated most safety nets...
+
+When any of the "too hot" alarms happen, according to Lenovo the user
+should suspend or hibernate the laptop (and in the case of battery
+alarms, unplug the AC adapter) to let it cool down.  These alarms do
+signal that something is wrong, they should never happen on normal
+operating conditions.
+
+The "extremely hot" alarms are emergencies.  According to Lenovo, the
+operating system is to force either an immediate suspend or hibernate
+cycle, or a system shutdown.  Obviously, something is very wrong if this
+happens.
 
 Compatibility notes:
 
@@ -539,7 +600,7 @@ sysfs (it is read-only).
 If the hotkey_report_mode module parameter is set to 1 or 2, it cannot
 be changed later through sysfs (any writes will return -EPERM to signal
 that hotkey_report_mode was locked.  On 2.6.23 and later, where
-hotkey_report_mode cannot be changed at all, writes will return -EACES).
+hotkey_report_mode cannot be changed at all, writes will return -EACCES).
 
 hotkey_report_mode set to 1 makes the driver export through the procfs
 ACPI event interface all hot key presses (which are *also* sent to the
@@ -558,15 +619,32 @@ netlink interface and the input layer interface, and don't bother at all
 with hotkey_report_mode.
 
 
+Brightness hotkey notes:
+
+Don't mess with the brightness hotkeys in a Thinkpad.  If you want
+notifications for OSD, use the sysfs backlight class event support.
+
+The driver will issue KEY_BRIGHTNESS_UP and KEY_BRIGHTNESS_DOWN events
+automatically for the cases were userspace has to do something to
+implement brightness changes.  When you override these events, you will
+either fail to handle properly the ThinkPads that require explicit
+action to change backlight brightness, or the ThinkPads that require
+that no action be taken to work properly.
+
+
 Bluetooth
 ---------
 
 procfs: /proc/acpi/ibm/bluetooth
-sysfs device attribute: bluetooth_enable
+sysfs device attribute: bluetooth_enable (deprecated)
+sysfs rfkill class: switch "tpacpi_bluetooth_sw"
 
 This feature shows the presence and current state of a ThinkPad
 Bluetooth device in the internal ThinkPad CDC slot.
 
+If the ThinkPad supports it, the Bluetooth state is stored in NVRAM,
+so it is kept across reboots and power-off.
+
 Procfs notes:
 
 If Bluetooth is installed, the following commands can be used:
@@ -584,8 +662,13 @@ Sysfs notes:
                0: disables Bluetooth / Bluetooth is disabled
                1: enables Bluetooth / Bluetooth is enabled.
 
-       Note: this interface will be probably be superseeded by the
-       generic rfkill class, so it is NOT to be considered stable yet.
+       Note: this interface has been superseded by the generic rfkill
+       class.  It has been deprecated, and it will be removed in year
+       2010.
+
+       rfkill controller switch "tpacpi_bluetooth_sw": refer to
+       Documentation/rfkill.txt for details.
+
 
 Video output control -- /proc/acpi/ibm/video
 --------------------------------------------
@@ -604,6 +687,10 @@ LCD, CRT or DVI (if available). The following commands are available:
        echo expand_toggle > /proc/acpi/ibm/video
        echo video_switch > /proc/acpi/ibm/video
 
+NOTE: Access to this feature is restricted to processes owning the
+CAP_SYS_ADMIN capability for safety reasons, as it can interact badly
+enough with some versions of X.org to crash it.
+
 Each video output device can be enabled or disabled individually.
 Reading /proc/acpi/ibm/video shows the status of each device.
 
@@ -628,147 +715,37 @@ Fn-F7 from working. This also disables the video output switching
 features of this driver, as it uses the same ACPI methods as
 Fn-F7. Video switching on the console should still work.
 
-UPDATE: There's now a patch for the X.org Radeon driver which
-addresses this issue. Some people are reporting success with the patch
-while others are still having problems. For more information:
-
-https://bugs.freedesktop.org/show_bug.cgi?id=2000
-
-ThinkLight control -- /proc/acpi/ibm/light
-------------------------------------------
-
-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:
+UPDATE: refer to https://bugs.freedesktop.org/show_bug.cgi?id=2000
 
-       echo on  > /proc/acpi/ibm/light
-       echo off > /proc/acpi/ibm/light
-
-Docking / undocking -- /proc/acpi/ibm/dock
-------------------------------------------
-
-Docking and undocking (e.g. with the X4 UltraBase) requires some
-actions to be taken by the operating system to safely make or break
-the electrical connections with the dock.
-
-The docking feature of this driver generates the following ACPI events:
-
-       ibm/dock GDCK 00000003 00000001 -- eject request
-       ibm/dock GDCK 00000003 00000002 -- undocked
-       ibm/dock GDCK 00000000 00000003 -- docked
-
-NOTE: These events will only be generated if the laptop was docked
-when originally booted. This is due to the current lack of support for
-hot plugging of devices in the Linux ACPI framework. If the laptop was
-booted while not in the dock, the following message is shown in the
-logs:
-
-       Mar 17 01:42:34 aero kernel: thinkpad_acpi: dock device not present
-
-In this case, no dock-related events are generated but the dock and
-undock commands described below still work. They can be executed
-manually or triggered by Fn key combinations (see the example acpid
-configuration files included in the driver tarball package available
-on the web site).
-
-When the eject request button on the dock is pressed, the first event
-above is generated. The handler for this event should issue the
-following command:
-
-       echo undock > /proc/acpi/ibm/dock
-
-After the LED on the dock goes off, it is safe to eject the laptop.
-Note: if you pressed this key by mistake, go ahead and eject the
-laptop, then dock it back in. Otherwise, the dock may not function as
-expected.
-
-When the laptop is docked, the third event above is generated. The
-handler for this event should issue the following command to fully
-enable the dock:
-
-       echo dock > /proc/acpi/ibm/dock
-
-The contents of the /proc/acpi/ibm/dock file shows the current status
-of the dock, as provided by the ACPI framework.
-
-The docking support in this driver does not take care of enabling or
-disabling any other devices you may have attached to the dock. For
-example, a CD drive plugged into the UltraBase needs to be disabled or
-enabled separately. See the provided example acpid configuration files
-for how this can be accomplished.
-
-There is no support yet for PCI devices that may be attached to a
-docking station, e.g. in the ThinkPad Dock II. The driver currently
-does not recognize, enable or disable such devices. This means that
-the only docking stations currently supported are the X-series
-UltraBase docks and "dumb" port replicators like the Mini Dock (the
-latter don't need any ACPI support, actually).
 
-UltraBay eject -- /proc/acpi/ibm/bay
-------------------------------------
-
-Inserting or ejecting an UltraBay device requires some actions to be
-taken by the operating system to safely make or break the electrical
-connections with the device.
-
-This feature generates the following ACPI events:
-
-       ibm/bay MSTR 00000003 00000000 -- eject request
-       ibm/bay MSTR 00000001 00000000 -- eject lever inserted
-
-NOTE: These events will only be generated if the UltraBay was present
-when the laptop was originally booted (on the X series, the UltraBay
-is in the dock, so it may not be present if the laptop was undocked).
-This is due to the current lack of support for hot plugging of devices
-in the Linux ACPI framework. If the laptop was booted without the
-UltraBay, the following message is shown in the logs:
-
-       Mar 17 01:42:34 aero kernel: thinkpad_acpi: bay device not present
-
-In this case, no bay-related events are generated but the eject
-command described below still works. It can be executed manually or
-triggered by a hot key combination.
-
-Sliding the eject lever generates the first event shown above. The
-handler for this event should take whatever actions are necessary to
-shut down the device in the UltraBay (e.g. call idectl), then issue
-the following command:
-
-       echo eject > /proc/acpi/ibm/bay
+ThinkLight control
+------------------
 
-After the LED on the UltraBay goes off, it is safe to pull out the
-device.
+procfs: /proc/acpi/ibm/light
+sysfs attributes: as per LED class, for the "tpacpi::thinklight" LED
 
-When the eject lever is inserted, the second event above is
-generated. The handler for this event should take whatever actions are
-necessary to enable the UltraBay device (e.g. call idectl).
+procfs notes:
 
-The contents of the /proc/acpi/ibm/bay file shows the current status
-of the UltraBay, as provided by the ACPI framework.
+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:
 
-EXPERIMENTAL warm eject support on the 600e/x, A22p and A3x (To use
-this feature, you need to supply the experimental=1 parameter when
-loading the module):
+       echo on  > /proc/acpi/ibm/light
+       echo off > /proc/acpi/ibm/light
 
-These models do not have a button near the UltraBay device to request
-a hot eject but rather require the laptop to be put to sleep
-(suspend-to-ram) before the bay device is ejected or inserted).
-The sequence of steps to eject the device is as follows:
+sysfs notes:
 
-       echo eject > /proc/acpi/ibm/bay
-       put the ThinkPad to sleep
-       remove the drive
-       resume from sleep
-       cat /proc/acpi/ibm/bay should show that the drive was removed
+The ThinkLight sysfs interface is documented by the LED class
+documentation, in Documentation/leds/leds-class.txt.  The ThinkLight LED name
+is "tpacpi::thinklight".
 
-On the A3x, both the UltraBay 2000 and UltraBay Plus devices are
-supported. Use "eject2" instead of "eject" for the second bay.
+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.
 
-Note: the UltraBay eject support on the 600e/x, A22p and A3x is
-EXPERIMENTAL and may not work as expected. USE WITH CAUTION!
 
-CMOS control
-------------
+CMOS/UCMS control
+-----------------
 
 procfs: /proc/acpi/ibm/cmos
 sysfs device attribute: cmos_command
@@ -791,39 +768,100 @@ on the X40 (tpb is the ThinkPad Buttons utility):
        1 - Related to "Volume up" key press
        2 - Related to "Mute on" key press
        3 - Related to "Access IBM" key press
-       4 - Related to "LCD brightness up" key pess
+       4 - Related to "LCD brightness up" key press
        5 - Related to "LCD brightness down" key press
        11 - Related to "toggle screen expansion" key press/function
        12 - Related to "ThinkLight on"
        13 - Related to "ThinkLight off"
-       14 - Related to "ThinkLight" key press (toggle thinklight)
+       14 - Related to "ThinkLight" key press (toggle ThinkLight)
 
 The cmos command interface is prone to firmware split-brain problems, as
 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
----------------------------------
 
-Some of the LED indicators can be controlled through this feature. The
-available commands are:
+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.
 
-       echo '<led number> on' >/proc/acpi/ibm/led
-       echo '<led number> off' >/proc/acpi/ibm/led
-       echo '<led number> blink' >/proc/acpi/ibm/led
+Because misuse of the LEDs could induce an unaware user to perform
+dangerous actions (like undocking or ejecting a bay device while the
+buses are still active), or mask an important alarm (such as a nearly
+empty battery, or a broken battery), access to most LEDs is
+restricted.
 
-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:
+Unrestricted access to all LEDs requires that thinkpad-acpi be
+compiled with the CONFIG_THINKPAD_ACPI_UNSAFE_LEDS option enabled.
+Distributions must never enable this option.  Individual users that
+are aware of the consequences are welcome to enabling it.
+
+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
+
+The <LED number> range is 0 to 15. 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
+       8 - dock status 1
+       9 - dock status 2
+       10, 11 - (unknown)
+       12 - thinkvantage
+       13, 14, 15 - (unknown)
 
 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/leds-class.txt.
+
+The LEDs are named (in LED ID order, from 0 to 12):
+"tpacpi::power", "tpacpi:orange:batt", "tpacpi:green:batt",
+"tpacpi::dock_active", "tpacpi::bay_active", "tpacpi::dock_batt",
+"tpacpi::unknown_led", "tpacpi::standby", "tpacpi::dock_status1",
+"tpacpi::dock_status2", "tpacpi::unknown_led2", "tpacpi::unknown_led3",
+"tpacpi::thinkvantage".
+
+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).
+
+LEDs that are known not to exist in a given ThinkPad model are not
+made available through the sysfs interface.  If you have a dock and you
+notice there are LEDs listed for your ThinkPad that do not exist (and
+are not in the dock), or if you notice that there are missing LEDs,
+a report to ibm-acpi-devel@lists.sourceforge.net is appreciated.
+
+
 ACPI sounds -- /proc/acpi/ibm/beep
 ----------------------------------
 
@@ -853,6 +891,7 @@ X40:
        16 - one medium-pitched beep repeating constantly, stop with 17
        17 - stop 16
 
+
 Temperature sensors
 -------------------
 
@@ -926,70 +965,21 @@ Sysfs notes:
        subsystem, and follow all of the hwmon guidelines at
        Documentation/hwmon.
 
+EXPERIMENTAL: Embedded controller register dump
+-----------------------------------------------
 
-EXPERIMENTAL: Embedded controller register dump -- /proc/acpi/ibm/ecdump
-------------------------------------------------------------------------
-
-This feature is marked EXPERIMENTAL because the implementation
-directly accesses hardware registers and may not work as expected. USE
-WITH CAUTION! To use this feature, you need to supply the
-experimental=1 parameter when loading the module.
-
-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
-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
-EC 0x20:  00  00  00  00  00  00  00  00  00  00  00  03  43  00  00  80
-EC 0x30:  01  07  1a  00  30  04  00  00 *85  00  00  10  00  50  00  00
-EC 0x40:  00  00  00  00  00  00  14  01  00  04  00  00  00  00  00  00
-EC 0x50:  00  c0  02  0d  00  01  01  02  02  03  03  03  03 *bc *02 *bc
-EC 0x60: *02 *bc *02  00  00  00  00  00  00  00  00  00  00  00  00  00
-EC 0x70:  00  00  00  00  00  12  30  40 *24 *26 *2c *27 *20  80 *1f  80
-EC 0x80:  00  00  00  06 *37 *0e  03  00  00  00  0e  07  00  00  00  00
-EC 0x90:  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
-EC 0xa0: *ff  09  ff  09  ff  ff *64  00 *00 *00 *a2  41 *ff *ff *e0  00
-EC 0xb0:  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
-EC 0xc0:  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
-EC 0xd0:  03  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
-EC 0xe0:  00  00  00  00  00  00  00  00  11  20  49  04  24  06  55  03
-EC 0xf0:  31  55  48  54  35  38  57  57  08  2f  45  73  07  65  6c  1a
-
-This feature can be used to determine the register holding the fan
-speed on some models. To do that, do the following:
+This feature is not included in the thinkpad driver anymore.
+Instead the EC can be accessed through /sys/kernel/debug/ec with
+a userspace tool which can be found here:
+ftp://ftp.suse.com/pub/people/trenn/sources/ec
 
+Use it to determine the register holding the fan
+speed on some models. To do that, do the following:
        - make sure the battery is fully charged
        - make sure the fan is running
-       - run 'cat /proc/acpi/ibm/ecdump' several times, once per second or so
-
-The first step makes sure various charging-related values don't
-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
-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
-EC 0x20:  00  00  00  00  00  00  00  00  00  00  00  03  43  00  00  80
-EC 0x30:  01  07  1a  00  30  04  00  00  85  00  00  10  00  50  00  00
-EC 0x40:  00  00  00  00  00  00  14  01  00  04  00  00  00  00  00  00
-EC 0x50:  00  c0  02  0d  00  01  01  02  02  03  03  03  03  bc  02  bc
-EC 0x60:  02  bc  02  00  00  00  00  00  00  00  00  00  00  00  00  00
-EC 0x70:  00  00  00  00  00  12  30  40  24  27  2c  27  21  80  1f  80
-EC 0x80:  00  00  00  06 *be  0d  03  00  00  00  0e  07  00  00  00  00
-EC 0x90:  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
-EC 0xa0:  ff  09  ff  09  ff  ff  64  00  00  00  a2  41  ff  ff  e0  00
-EC 0xb0:  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
-EC 0xc0:  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
-EC 0xd0:  03  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
-EC 0xe0:  00  00  00  00  00  00  00  00  11  20  49  04  24  06  55  03
-EC 0xf0:  31  55  48  54  35  38  57  57  08  2f  45  73  07  65  6c  1a
-
-Another set of values that varies often is the temperature
+       - use above mentioned tool to read out the EC
+
+Often fan and temperature values vary between
 readings. Since temperatures don't change vary fast, you can take
 several quick dumps to eliminate them.
 
@@ -1000,6 +990,7 @@ registers contain the current battery capacity, etc. If you experiment
 with this, do send me your results (including some complete dumps with
 a description of the conditions when they were taken.)
 
+
 LCD brightness control
 ----------------------
 
@@ -1009,10 +1000,9 @@ sysfs backlight device "thinkpad_screen"
 This feature allows software control of the LCD brightness on ThinkPad
 models which don't have a hardware brightness slider.
 
-It has some limitations: the LCD backlight cannot be actually turned on or
-off by this interface, and in many ThinkPad models, the "dim while on
-battery" functionality will be enabled by the BIOS when this interface is
-used, and cannot be controlled.
+It has some limitations: the LCD backlight cannot be actually turned
+on or off by this interface, it just controls the backlight brightness
+level.
 
 On IBM (and some of the earlier Lenovo) ThinkPads, the backlight control
 has eight brightness levels, ranging from 0 to 7.  Some of the levels
@@ -1020,11 +1010,18 @@ may not be distinct.  Later Lenovo models that implement the ACPI
 display backlight brightness control methods have 16 levels, ranging
 from 0 to 15.
 
-There are two interfaces to the firmware for direct brightness control,
-EC and CMOS.  To select which one should be used, use the
-brightness_mode module parameter: brightness_mode=1 selects EC mode,
-brightness_mode=2 selects CMOS mode, brightness_mode=3 selects both EC
-and CMOS.  The driver tries to autodetect which interface to use.
+For IBM ThinkPads, there are two interfaces to the firmware for direct
+brightness control, EC and UCMS (or CMOS).  To select which one should be
+used, use the brightness_mode module parameter: brightness_mode=1 selects
+EC mode, brightness_mode=2 selects UCMS mode, brightness_mode=3 selects EC
+mode with NVRAM backing (so that brightness changes are remembered across
+shutdown/reboot).
+
+The driver tries to select which interface to use from a table of
+defaults for each ThinkPad model.  If it makes a wrong choice, please
+report this as a bug, so that we can fix it.
+
+Lenovo ThinkPads only support brightness_mode=2 (UCMS).
 
 When display backlight brightness controls are available through the
 standard ACPI interface, it is best to use it instead of this direct
@@ -1032,6 +1029,10 @@ ThinkPad-specific interface.  The driver will disable its native
 backlight brightness control interface if it detects that the standard
 ACPI interface is available in the ThinkPad.
 
+If you want to use the thinkpad-acpi backlight brightness control
+instead of the generic ACPI video backlight brightness control for some
+reason, you should use the acpi_backlight=vendor kernel parameter.
+
 The brightness_enable module parameter can be used to control whether
 the LCD brightness control feature will be enabled when available.
 brightness_enable=0 forces it to be disabled.  brightness_enable=1
@@ -1077,28 +1078,121 @@ it there will be the following attributes:
                dim the display.
 
 
-Volume control -- /proc/acpi/ibm/volume
----------------------------------------
+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 (Console Audio control)
+--------------------------------------
+
+procfs: /proc/acpi/ibm/volume
+ALSA: "ThinkPad Console Audio Control", default ID: "ThinkPadEC"
+
+NOTE: by default, the volume control interface operates in read-only
+mode, as it is supposed to be used for on-screen-display purposes.
+The read/write mode can be enabled through the use of the
+"volume_control=1" module parameter.
+
+NOTE: distros are urged to not enable volume_control by default, this
+should be done by the local admin only.  The ThinkPad UI is for the
+console audio control to be done through the volume keys only, and for
+the desktop environment to just provide on-screen-display feedback.
+Software volume control should be done only in the main AC97/HDA
+mixer.
+
+
+About the ThinkPad Console Audio control:
+
+ThinkPads have a built-in amplifier and muting circuit that drives the
+console headphone and speakers.  This circuit is after the main AC97
+or HDA mixer in the audio path, and under exclusive control of the
+firmware.
+
+ThinkPads have three special hotkeys to interact with the console
+audio control: volume up, volume down and mute.
+
+It is worth noting that the normal way the mute function works (on
+ThinkPads that do not have a "mute LED") is:
+
+1. Press mute to mute.  It will *always* mute, you can press it as
+   many times as you want, and the sound will remain mute.
 
-This feature allows volume control on ThinkPad models which don't have
-a hardware volume knob. The available commands are:
+2. Press either volume key to unmute the ThinkPad (it will _not_
+   change the volume, it will just unmute).
+
+This is a very superior design when compared to the cheap software-only
+mute-toggle solution found on normal consumer laptops:  you can be
+absolutely sure the ThinkPad will not make noise if you press the mute
+button, no matter the previous state.
+
+The IBM ThinkPads, and the earlier Lenovo ThinkPads have variable-gain
+amplifiers driving the speakers and headphone output, and the firmware
+also handles volume control for the headphone and speakers on these
+ThinkPads without any help from the operating system (this volume
+control stage exists after the main AC97 or HDA mixer in the audio
+path).
+
+The newer Lenovo models only have firmware mute control, and depend on
+the main HDA mixer to do volume control (which is done by the operating
+system).  In this case, the volume keys are filtered out for unmute
+key press (there are some firmware bugs in this area) and delivered as
+normal key presses to the operating system (thinkpad-acpi is not
+involved).
+
+
+The ThinkPad-ACPI volume control:
+
+The preferred way to interact with the Console Audio control is the
+ALSA interface.
+
+The legacy procfs interface allows one to read the current state,
+and if volume control is enabled, accepts the following commands:
 
        echo up   >/proc/acpi/ibm/volume
        echo down >/proc/acpi/ibm/volume
        echo mute >/proc/acpi/ibm/volume
+       echo unmute >/proc/acpi/ibm/volume
        echo 'level <level>' >/proc/acpi/ibm/volume
 
-The <level> number range is 0 to 15 although not all of them may be
-distinct. The unmute the volume after the mute command, use either the
-up or down command (the level command will not unmute the volume).
-The current volume level and mute state is shown in the file.
+The <level> number range is 0 to 14 although not all of them may be
+distinct. To unmute the volume after the mute command, use either the
+up or down command (the level command will not unmute the volume), or
+the unmute command.
+
+You can use the volume_capabilities parameter to tell the driver
+whether your thinkpad has volume control or mute-only control:
+volume_capabilities=1 for mixers with mute and volume control,
+volume_capabilities=2 for mixers with only mute control.
+
+If the driver misdetects the capabilities for your ThinkPad model,
+please report this to ibm-acpi-devel@lists.sourceforge.net, so that we
+can update the driver.
+
+There are two strategies for volume control.  To select which one
+should be used, use the volume_mode module parameter: volume_mode=1
+selects EC mode, and volume_mode=3 selects EC mode with NVRAM backing
+(so that volume/mute changes are remembered across shutdown/reboot).
+
+The driver will operate in volume_mode=3 by default. If that does not
+work well on your ThinkPad model, please report this to
+ibm-acpi-devel@lists.sourceforge.net.
+
+The driver supports the standard ALSA module parameters.  If the ALSA
+mixer is disabled, the driver will disable all volume functionality.
+
 
 Fan control and monitoring: fan speed, fan enable/disable
 ---------------------------------------------------------
 
 procfs: /proc/acpi/ibm/fan
 sysfs device attributes: (hwmon "thinkpad") fan1_input, pwm1,
-                         pwm1_enable
+                         pwm1_enable, fan2_input
 sysfs hwmon driver attributes: fan_watchdog
 
 NOTE NOTE NOTE: fan control operations are disabled by default for
@@ -1111,6 +1205,9 @@ from the hardware registers of the embedded controller.  This is known
 to work on later R, T, X and Z series ThinkPads but may show a bogus
 value on other models.
 
+Some Lenovo ThinkPads support a secondary fan.  This fan cannot be
+controlled separately, it shares the main fan control.
+
 Fan levels:
 
 Most ThinkPad fans work in "levels" at the firmware interface.  Level 0
@@ -1241,6 +1338,11 @@ hwmon device attribute fan1_input:
        which can take up to two minutes.  May return rubbish on older
        ThinkPads.
 
+hwmon device attribute fan2_input:
+       Fan tachometer reading, in RPM, for the secondary fan.
+       Available only on some ThinkPads.  If the secondary fan is
+       not installed, will always read 0.
+
 hwmon driver attribute fan_watchdog:
        Fan safety watchdog timer interval, in seconds.  Minimum is
        1 second, maximum is 120 seconds.  0 disables the watchdog.
@@ -1252,22 +1354,21 @@ with EINVAL, try to set pwm1_enable to 1 and pwm1 to at least 128 (255
 would be the safest choice, though).
 
 
-EXPERIMENTAL: WAN
------------------
+WAN
+---
 
 procfs: /proc/acpi/ibm/wan
-sysfs device attribute: wwan_enable
+sysfs device attribute: wwan_enable (deprecated)
+sysfs rfkill class: switch "tpacpi_wwan_sw"
 
-This feature is marked EXPERIMENTAL because the implementation
-directly accesses hardware registers and may not work as expected. USE
-WITH CAUTION! To use this feature, you need to supply the
-experimental=1 parameter when loading the module.
+This feature shows the presence and current state of the built-in
+Wireless WAN device.
 
-This feature shows the presence and current state of a W-WAN (Sierra
-Wireless EV-DO) device.
+If the ThinkPad supports it, the WWAN state is stored in NVRAM,
+so it is kept across reboots and power-off.
 
-It was tested on a Lenovo Thinkpad X60. It should probably work on other
-Thinkpad models which come with this module installed.
+It was tested on a Lenovo ThinkPad X60. It should probably work on other
+ThinkPad models which come with this module installed.
 
 Procfs notes:
 
@@ -1286,8 +1387,32 @@ Sysfs notes:
                0: disables WWAN card / WWAN card is disabled
                1: enables WWAN card / WWAN card is enabled.
 
-       Note: this interface will be probably be superseeded by the
-       generic rfkill class, so it is NOT to be considered stable yet.
+       Note: this interface has been superseded by the generic rfkill
+       class.  It has been deprecated, and it will be removed in year
+       2010.
+
+       rfkill controller switch "tpacpi_wwan_sw": refer to
+       Documentation/rfkill.txt for details.
+
+
+EXPERIMENTAL: UWB
+-----------------
+
+This feature is marked EXPERIMENTAL because it has not been extensively
+tested and validated in various ThinkPad models yet.  The feature may not
+work as expected. USE WITH CAUTION! To use this feature, you need to supply
+the experimental=1 parameter when loading the module.
+
+sysfs rfkill class: switch "tpacpi_uwb_sw"
+
+This feature exports an rfkill controller for the UWB device, if one is
+present and enabled in the BIOS.
+
+Sysfs notes:
+
+       rfkill controller switch "tpacpi_uwb_sw": refer to
+       Documentation/rfkill.txt for details.
+
 
 Multiple Commands, Module Parameters
 ------------------------------------
@@ -1303,20 +1428,29 @@ for example:
 
        modprobe thinkpad_acpi hotkey=enable,0xffff video=auto_disable
 
+
 Enabling debugging output
 -------------------------
 
 The module takes a debug parameter which can be used to selectively
 enable various classes of debugging output, for example:
 
-        modprobe ibm_acpi debug=0xffff
+        modprobe thinkpad_acpi debug=0xffff
 
 will enable all debugging output classes.  It takes a bitmask, so
 to enable more than one output class, just add their values.
 
        Debug bitmask           Description
+       0x8000                  Disclose PID of userspace programs
+                               accessing some functions of the driver
        0x0001                  Initialization and probing
        0x0002                  Removal
+       0x0004                  RF Transmitter control (RFKILL)
+                               (bluetooth, WWAN, UWB...)
+       0x0008                  HKEY event interface, hotkeys
+       0x0010                  Fan control
+       0x0020                  Backlight brightness
+       0x0040                  Audio mixer/volume control
 
 There is also a kernel build option to enable more debugging
 information, which may be necessary to debug driver problems.
@@ -1325,6 +1459,7 @@ The level of debugging information output by the driver can be changed
 at runtime through sysfs, using the driver attribute debug_level.  The
 attribute takes the same bitmask as the debug module parameter above.
 
+
 Force loading of module
 -----------------------
 
@@ -1352,14 +1487,33 @@ Sysfs interface changelog:
 
 0x020100:      Marker for thinkpad-acpi with hot key NVRAM polling
                support.  If you must, use it to know you should not
-               start an userspace NVRAM poller (allows to detect when
+               start a userspace NVRAM poller (allows to detect when
                NVRAM is compiled out by the user because it is
                unneeded/undesired in the first place).
 0x020101:      Marker for thinkpad-acpi with hot key NVRAM polling
-               and proper hotkey_mask semanthics (version 8 of the
+               and proper hotkey_mask semantics (version 8 of the
                NVRAM polling patch).  Some development snapshots of
                0.18 had an earlier version that did strange things
                to hotkey_mask.
 
 0x020200:      Add poll()/select() support to the following attributes:
                hotkey_radio_sw, wakeup_hotunplug_complete, wakeup_reason
+
+0x020300:      hotkey enable/disable support removed, attributes
+               hotkey_bios_enabled and hotkey_enable deprecated and
+               marked for removal.
+
+0x020400:      Marker for 16 LEDs support.  Also, LEDs that are known
+               to not exist in a given model are not registered with
+               the LED sysfs class anymore.
+
+0x020500:      Updated hotkey driver, hotkey_mask is always available
+               and it is always able to disable hot keys.  Very old
+               thinkpads are properly supported.  hotkey_bios_mask
+               is deprecated and marked for removal.
+
+0x020600:      Marker for backlight change event support.
+
+0x020700:      Support for mute-only mixers.
+               Volume control in read-only mode by default.
+               Marker for ALSA mixer support.