diff options
author | Henrique de Moraes Holschuh <hmh@hmh.eng.br> | 2009-04-04 04:25:49 +0000 |
---|---|---|
committer | Len Brown <len.brown@intel.com> | 2009-04-04 03:14:52 -0400 |
commit | a4d5effcc73749ee3ebbf578d162905e6fa4e07d (patch) | |
tree | 1160b3763004be227cfe3d6c15e4235a9ccf69b7 /arch | |
parent | 2586d5663d0a17d69383acf6110f16a979a07c4e (diff) | |
download | linux-3.10-a4d5effcc73749ee3ebbf578d162905e6fa4e07d.tar.gz linux-3.10-a4d5effcc73749ee3ebbf578d162905e6fa4e07d.tar.bz2 linux-3.10-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 'arch')
0 files changed, 0 insertions, 0 deletions