summaryrefslogtreecommitdiffstats
path: root/drivers/platform/x86/Kconfig
diff options
context:
space:
mode:
authorHenrique de Moraes Holschuh <hmh@hmh.eng.br>2009-04-04 04:25:49 +0000
committerLen Brown <len.brown@intel.com>2009-04-04 03:14:52 -0400
commita4d5effcc73749ee3ebbf578d162905e6fa4e07d (patch)
tree1160b3763004be227cfe3d6c15e4235a9ccf69b7 /drivers/platform/x86/Kconfig
parent2586d5663d0a17d69383acf6110f16a979a07c4e (diff)
downloadkernel-crypto-a4d5effcc73749ee3ebbf578d162905e6fa4e07d.tar.gz
kernel-crypto-a4d5effcc73749ee3ebbf578d162905e6fa4e07d.tar.xz
kernel-crypto-a4d5effcc73749ee3ebbf578d162905e6fa4e07d.zip
thinkpad-acpi: restrict access to some firmware LEDs
Some of the ThinkPad LEDs indicate critical conditions that can cause data loss or cause hardware damage when ignored (e.g. force-ejecting a powered up bay; ignoring a failing battery, or empty battery; force- undocking with the dock buses still active, etc). On almost all ThinkPads, LED access is write-only, and the firmware usually does fire-and-forget signaling on them, so you effectively lose whatever message the firmware was trying to convey to the user when you override the LED state, without any chance to restore it. Restrict access to all LEDs that can convey important alarms, or that could mislead the user into incorrectly operating the hardware. This will make the Lenovo engineers less unhappy about the whole issue. Allow users that really want it to still control all LEDs, it is the unaware user that we have to worry about. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
Diffstat (limited to 'drivers/platform/x86/Kconfig')
-rw-r--r--drivers/platform/x86/Kconfig24
1 files changed, 24 insertions, 0 deletions
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 3608081bc3e..d45c6ab729f 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -226,6 +226,30 @@ config THINKPAD_ACPI_DEBUG
If you are not sure, say N here.
+config THINKPAD_ACPI_UNSAFE_LEDS
+ bool "Allow control of important LEDs (unsafe)"
+ depends on THINKPAD_ACPI
+ default n
+ ---help---
+ Overriding LED state on ThinkPads can mask important
+ firmware alerts (like critical battery condition), or misled
+ the user into damaging the hardware (undocking or ejecting
+ the bay while buses are still active), etc.
+
+ LED control on the ThinkPad is write-only (with very few
+ exceptions on very ancient models), which makes it
+ impossible to know beforehand if important information will
+ be lost when one changes LED state.
+
+ Users that know what they are doing can enable this option
+ and the driver will allow control of every LED, including
+ the ones on the dock stations.
+
+ Never enable this option on a distribution kernel.
+
+ Say N here, unless you are building a kernel for your own
+ use, and need to control the important firmware LEDs.
+
config THINKPAD_ACPI_DOCK
bool "Legacy Docking Station Support"
depends on THINKPAD_ACPI