UbiquitousOS
/
OpenCloudOS-Kernel
mirror of https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git
11
0
Fork 0
Code Issues Projects Releases Wiki Activity
OpenCloudOS-Kernel/drivers/platform/x86/Kconfig

453 lines
14 KiB
Plaintext
Raw Normal View History

create drivers/platform/x86/ from drivers/misc/ Move x86 platform specific drivers from drivers/misc/ to a new home under drivers/platform/x86/. The community has been maintaining x86 vendor-specific platform specific drivers under /drivers/misc/ for a few years. The oldest ones started life under drivers/acpi. They moved out of drivers/acpi/ because they don't actually implement the ACPI specification, but either simply use ACPI, or implement vendor-specific ACPI extensions. In the future we anticipate... drivers/misc/ will go away. other architectures will create drivers/platform/<arch> Signed-off-by: Len Brown <len.brown@intel.com>
2008-12-01 13:09:47 +08:00
#
# X86 Platform Specific Drivers
#
menuconfig X86_PLATFORM_DEVICES
bool "X86 Platform Specific Device Drivers"
default y
---help---
Say Y here to get to see options for device drivers for various
x86 platforms, including vendor-specific laptop extension drivers.
This option alone does not add any kernel code.
If you say N, all options in this submenu will be skipped and disabled.
if X86_PLATFORM_DEVICES
config ACER_WMI
acer-wmi: Unmark as 'experimental' This driver has been around and used long enough that we can drop the 'experimental'. Signed-off-by: Carlos Corbacho <carlos@strangeworlds.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-14 17:53:59 +08:00
tristate "Acer WMI Laptop Extras"
create drivers/platform/x86/ from drivers/misc/ Move x86 platform specific drivers from drivers/misc/ to a new home under drivers/platform/x86/. The community has been maintaining x86 vendor-specific platform specific drivers under /drivers/misc/ for a few years. The oldest ones started life under drivers/acpi. They moved out of drivers/acpi/ because they don't actually implement the ACPI specification, but either simply use ACPI, or implement vendor-specific ACPI extensions. In the future we anticipate... drivers/misc/ will go away. other architectures will create drivers/platform/<arch> Signed-off-by: Len Brown <len.brown@intel.com>
2008-12-01 13:09:47 +08:00
depends on ACPI
depends on LEDS_CLASS
depends on NEW_LEDS
depends on BACKLIGHT_CLASS_DEVICE
depends on SERIO_I8042
rfkill: rewrite This patch completely rewrites the rfkill core to address the following deficiencies: * all rfkill drivers need to implement polling where necessary rather than having one central implementation * updating the rfkill state cannot be done from arbitrary contexts, forcing drivers to use schedule_work and requiring lots of code * rfkill drivers need to keep track of soft/hard blocked internally -- the core should do this * the rfkill API has many unexpected quirks, for example being asymmetric wrt. alloc/free and register/unregister * rfkill can call back into a driver from within a function the driver called -- this is prone to deadlocks and generally should be avoided * rfkill-input pointlessly is a separate module * drivers need to #ifdef rfkill functions (unless they want to depend on or select RFKILL) -- rfkill should provide inlines that do nothing if it isn't compiled in * the rfkill structure is not opaque -- drivers need to initialise it correctly (lots of sanity checking code required) -- instead force drivers to pass the right variables to rfkill_alloc() * the documentation is hard to read because it always assumes the reader is completely clueless and contains way TOO MANY CAPS * the rfkill code needlessly uses a lot of locks and atomic operations in locked sections * fix LED trigger to actually change the LED when the radio state changes -- this wasn't done before Tested-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad] Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-02 19:01:37 +08:00
depends on RFKILL || RFKILL = n
create drivers/platform/x86/ from drivers/misc/ Move x86 platform specific drivers from drivers/misc/ to a new home under drivers/platform/x86/. The community has been maintaining x86 vendor-specific platform specific drivers under /drivers/misc/ for a few years. The oldest ones started life under drivers/acpi. They moved out of drivers/acpi/ because they don't actually implement the ACPI specification, but either simply use ACPI, or implement vendor-specific ACPI extensions. In the future we anticipate... drivers/misc/ will go away. other architectures will create drivers/platform/<arch> Signed-off-by: Len Brown <len.brown@intel.com>
2008-12-01 13:09:47 +08:00
select ACPI_WMI
---help---
This is a driver for newer Acer (and Wistron) laptops. It adds
wireless radio and bluetooth control, and on some laptops,
exposes the mail LED and LCD backlight.
For more information about this driver see
<file:Documentation/laptops/acer-wmi.txt>
If you have an ACPI-WMI compatible Acer/ Wistron laptop, say Y or M
here.
acerhdf: Acer Aspire One fan control Acerhdf is a driver for Acer Aspire One netbooks. It allows to access the temperature sensor and to control the fan. Signed-off-by: Peter Feuerer <peter@piie.net> Signed-off-by: Andreas Mohr <andi@lisas.de> Signed-off-by: Borislav Petkov <petkovbb@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-06-22 00:53:03 +08:00
config ACERHDF
tristate "Acer Aspire One temperature and fan driver"
depends on THERMAL && THERMAL_HWMON && ACPI
---help---
This is a driver for Acer Aspire One netbooks. It allows to access
the temperature sensor and to control the fan.
After loading this driver the BIOS is still in control of the fan.
To let the kernel handle the fan, do:
echo -n enabled > /sys/class/thermal/thermal_zone0/mode
For more information about this driver see
<http://piie.net/files/acerhdf_README.txt>
If you have an Acer Aspire One netbook, say Y or M
here.
create drivers/platform/x86/ from drivers/misc/ Move x86 platform specific drivers from drivers/misc/ to a new home under drivers/platform/x86/. The community has been maintaining x86 vendor-specific platform specific drivers under /drivers/misc/ for a few years. The oldest ones started life under drivers/acpi. They moved out of drivers/acpi/ because they don't actually implement the ACPI specification, but either simply use ACPI, or implement vendor-specific ACPI extensions. In the future we anticipate... drivers/misc/ will go away. other architectures will create drivers/platform/<arch> Signed-off-by: Len Brown <len.brown@intel.com>
2008-12-01 13:09:47 +08:00
config ASUS_LAPTOP
tristate "Asus Laptop Extras (EXPERIMENTAL)"
depends on ACPI
depends on EXPERIMENTAL && !ACPI_ASUS
asus-laptop: use select instead of depends on Like thinkpad_acpi or eeepc-laptop, asus-laptop will now use "select" instead of "depends on" for LEDS_CLASS, NEW_LEDS and BACKLIGHT_CLASS_DEVICE Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-16 02:30:21 +08:00
select LEDS_CLASS
select NEW_LEDS
select BACKLIGHT_CLASS_DEVICE
asus-laptop: update Kconfig for input layer Update Kconfig, now asus-laptop use the input layer. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
2009-01-20 23:17:44 +08:00
depends on INPUT
create drivers/platform/x86/ from drivers/misc/ Move x86 platform specific drivers from drivers/misc/ to a new home under drivers/platform/x86/. The community has been maintaining x86 vendor-specific platform specific drivers under /drivers/misc/ for a few years. The oldest ones started life under drivers/acpi. They moved out of drivers/acpi/ because they don't actually implement the ACPI specification, but either simply use ACPI, or implement vendor-specific ACPI extensions. In the future we anticipate... drivers/misc/ will go away. other architectures will create drivers/platform/<arch> Signed-off-by: Len Brown <len.brown@intel.com>
2008-12-01 13:09:47 +08:00
---help---
This is the new Linux driver for Asus laptops. It may also support some
MEDION, JVC or VICTOR laptops. It makes all the extra buttons generate
acpi4asus: update MAINTAINER and KConfig links The bug tracker have moved from sourceforge to http://dev.iksaif.net . The homepage of the project is now http://acpi4asus.sf.net with links to the new bug tracker. No change for the mailing list. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
2009-06-17 03:28:47 +08:00
standard ACPI events and input events. It also adds
create drivers/platform/x86/ from drivers/misc/ Move x86 platform specific drivers from drivers/misc/ to a new home under drivers/platform/x86/. The community has been maintaining x86 vendor-specific platform specific drivers under /drivers/misc/ for a few years. The oldest ones started life under drivers/acpi. They moved out of drivers/acpi/ because they don't actually implement the ACPI specification, but either simply use ACPI, or implement vendor-specific ACPI extensions. In the future we anticipate... drivers/misc/ will go away. other architectures will create drivers/platform/<arch> Signed-off-by: Len Brown <len.brown@intel.com>
2008-12-01 13:09:47 +08:00
support for video output switching, LCD backlight control, Bluetooth and
Wlan control, and most importantly, allows you to blink those fancy LEDs.
For more information and a userspace daemon for handling the extra
acpi4asus: update MAINTAINER and KConfig links The bug tracker have moved from sourceforge to http://dev.iksaif.net . The homepage of the project is now http://acpi4asus.sf.net with links to the new bug tracker. No change for the mailing list. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
2009-06-17 03:28:47 +08:00
buttons see <http://acpi4asus.sf.net>.
create drivers/platform/x86/ from drivers/misc/ Move x86 platform specific drivers from drivers/misc/ to a new home under drivers/platform/x86/. The community has been maintaining x86 vendor-specific platform specific drivers under /drivers/misc/ for a few years. The oldest ones started life under drivers/acpi. They moved out of drivers/acpi/ because they don't actually implement the ACPI specification, but either simply use ACPI, or implement vendor-specific ACPI extensions. In the future we anticipate... drivers/misc/ will go away. other architectures will create drivers/platform/<arch> Signed-off-by: Len Brown <len.brown@intel.com>
2008-12-01 13:09:47 +08:00
If you have an ACPI-compatible ASUS laptop, say Y or M here.
dell-laptop: move to drivers/platform/x86/ from drivers/misc/ Signed-off-by: Len Brown <len.brown@intel.com>
2009-01-10 06:23:38 +08:00
config DELL_LAPTOP
tristate "Dell Laptop Extras (EXPERIMENTAL)"
depends on X86
depends on DCDBAS
depends on EXPERIMENTAL
depends on BACKLIGHT_CLASS_DEVICE
rfkill: rewrite This patch completely rewrites the rfkill core to address the following deficiencies: * all rfkill drivers need to implement polling where necessary rather than having one central implementation * updating the rfkill state cannot be done from arbitrary contexts, forcing drivers to use schedule_work and requiring lots of code * rfkill drivers need to keep track of soft/hard blocked internally -- the core should do this * the rfkill API has many unexpected quirks, for example being asymmetric wrt. alloc/free and register/unregister * rfkill can call back into a driver from within a function the driver called -- this is prone to deadlocks and generally should be avoided * rfkill-input pointlessly is a separate module * drivers need to #ifdef rfkill functions (unless they want to depend on or select RFKILL) -- rfkill should provide inlines that do nothing if it isn't compiled in * the rfkill structure is not opaque -- drivers need to initialise it correctly (lots of sanity checking code required) -- instead force drivers to pass the right variables to rfkill_alloc() * the documentation is hard to read because it always assumes the reader is completely clueless and contains way TOO MANY CAPS * the rfkill code needlessly uses a lot of locks and atomic operations in locked sections * fix LED trigger to actually change the LED when the radio state changes -- this wasn't done before Tested-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad] Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-02 19:01:37 +08:00
depends on RFKILL || RFKILL = n
x86: dell-laptop: depends on POWER_SUPPLY Build breaks when DELL_LAPTOP=y and POWER_SUPPLY=m. DELL_LAPTOP needs to depend on POWER_SUPPLY. dell-laptop.c:(.text+0x1ef3c4): undefined reference to `power_supply_is_system_supplied' dell-laptop.c:(.text+0x1ef45e): undefined reference to `power_supply_is_system_supplied' Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Len Brown <lenb@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-02-19 06:48:39 +08:00
depends on POWER_SUPPLY
dell-laptop: move to drivers/platform/x86/ from drivers/misc/ Signed-off-by: Len Brown <len.brown@intel.com>
2009-01-10 06:23:38 +08:00
default n
---help---
This driver adds support for rfkill and backlight control to Dell
laptops.
dell-wmi: new driver for hotkey control Add a WMI driver for Dell laptops. Currently it does nothing but send a generic input event when a button with a picture of a battery on it is pressed, but maybe other uses will appear over time. Signed-off-by: Matthew Garrett <mjg@redhat.com> Cc: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
2009-01-10 04:17:11 +08:00
config DELL_WMI
tristate "Dell WMI extras"
depends on ACPI_WMI
depends on INPUT
---help---
Say Y here if you want to support WMI-based hotkeys on Dell laptops.
To compile this driver as a module, choose M here: the module will
be called dell-wmi.
create drivers/platform/x86/ from drivers/misc/ Move x86 platform specific drivers from drivers/misc/ to a new home under drivers/platform/x86/. The community has been maintaining x86 vendor-specific platform specific drivers under /drivers/misc/ for a few years. The oldest ones started life under drivers/acpi. They moved out of drivers/acpi/ because they don't actually implement the ACPI specification, but either simply use ACPI, or implement vendor-specific ACPI extensions. In the future we anticipate... drivers/misc/ will go away. other architectures will create drivers/platform/<arch> Signed-off-by: Len Brown <len.brown@intel.com>
2008-12-01 13:09:47 +08:00
config FUJITSU_LAPTOP
tristate "Fujitsu Laptop Extras"
depends on ACPI
depends on INPUT
depends on BACKLIGHT_CLASS_DEVICE
---help---
This is a driver for laptops built by Fujitsu:
* P2xxx/P5xxx/S6xxx/S7xxx series Lifebooks
* Possibly other Fujitsu laptop models
* Tested with S6410 and S7020
It adds support for LCD brightness control and some hotkeys.
If you have a Fujitsu laptop, say Y or M here.
config FUJITSU_LAPTOP_DEBUG
bool "Verbose debug mode for Fujitsu Laptop Extras"
depends on FUJITSU_LAPTOP
default n
---help---
Enables extra debug output from the fujitsu extras driver, at the
expense of a slight increase in driver size.
If you are not sure, say N here.
config TC1100_WMI
tristate "HP Compaq TC1100 Tablet WMI Extras (EXPERIMENTAL)"
depends on !X86_64
depends on EXPERIMENTAL
depends on ACPI
select ACPI_WMI
---help---
This is a driver for the WMI extensions (wireless and bluetooth power
control) of the HP Compaq TC1100 tablet.
config HP_WMI
tristate "HP WMI extras"
depends on ACPI_WMI
depends on INPUT
rfkill: rewrite This patch completely rewrites the rfkill core to address the following deficiencies: * all rfkill drivers need to implement polling where necessary rather than having one central implementation * updating the rfkill state cannot be done from arbitrary contexts, forcing drivers to use schedule_work and requiring lots of code * rfkill drivers need to keep track of soft/hard blocked internally -- the core should do this * the rfkill API has many unexpected quirks, for example being asymmetric wrt. alloc/free and register/unregister * rfkill can call back into a driver from within a function the driver called -- this is prone to deadlocks and generally should be avoided * rfkill-input pointlessly is a separate module * drivers need to #ifdef rfkill functions (unless they want to depend on or select RFKILL) -- rfkill should provide inlines that do nothing if it isn't compiled in * the rfkill structure is not opaque -- drivers need to initialise it correctly (lots of sanity checking code required) -- instead force drivers to pass the right variables to rfkill_alloc() * the documentation is hard to read because it always assumes the reader is completely clueless and contains way TOO MANY CAPS * the rfkill code needlessly uses a lot of locks and atomic operations in locked sections * fix LED trigger to actually change the LED when the radio state changes -- this wasn't done before Tested-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad] Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-02 19:01:37 +08:00
depends on RFKILL || RFKILL = n
create drivers/platform/x86/ from drivers/misc/ Move x86 platform specific drivers from drivers/misc/ to a new home under drivers/platform/x86/. The community has been maintaining x86 vendor-specific platform specific drivers under /drivers/misc/ for a few years. The oldest ones started life under drivers/acpi. They moved out of drivers/acpi/ because they don't actually implement the ACPI specification, but either simply use ACPI, or implement vendor-specific ACPI extensions. In the future we anticipate... drivers/misc/ will go away. other architectures will create drivers/platform/<arch> Signed-off-by: Len Brown <len.brown@intel.com>
2008-12-01 13:09:47 +08:00
help
Say Y here if you want to support WMI-based hotkeys on HP laptops and
to read data from WMI such as docking or ambient light sensor state.
To compile this driver as a module, choose M here: the module will
be called hp-wmi.
config MSI_LAPTOP
tristate "MSI Laptop Extras"
depends on ACPI
depends on BACKLIGHT_CLASS_DEVICE
---help---
This is a driver for laptops built by MSI (MICRO-STAR
INTERNATIONAL):
MSI MegaBook S270 (MS-1013)
Cytron/TCM/Medion/Tchibo MD96100/SAM2000
It adds support for Bluetooth, WLAN and LCD brightness control.
More information about this driver is available at
<http://0pointer.de/lennart/tchibo.html>.
If you have an MSI S270 laptop, say Y or M here.
config PANASONIC_LAPTOP
tristate "Panasonic Laptop Extras"
depends on INPUT && ACPI
depends on BACKLIGHT_CLASS_DEVICE
---help---
This driver adds support for access to backlight control and hotkeys
on Panasonic Let's Note laptops.
If you have a Panasonic Let's note laptop (such as the R1(N variant),
R2, R3, R5, T2, W2 and Y2 series), say Y.
config COMPAL_LAPTOP
tristate "Compal Laptop Extras"
depends on ACPI
depends on BACKLIGHT_CLASS_DEVICE
---help---
This is a driver for laptops built by Compal:
Compal FL90/IFL90
Compal FL91/IFL91
Compal FL92/JFL92
Compal FT00/IFT00
It adds support for Bluetooth, WLAN and LCD brightness control.
If you have an Compal FL9x/IFL9x/FT00 laptop, say Y or M here.
config SONY_LAPTOP
tristate "Sony Laptop Extras"
depends on ACPI
select BACKLIGHT_CLASS_DEVICE
depends on INPUT
sony-laptop should depend on RFKILL Fixes this build error when RFKILL is not set: drivers/platform/x86/sony-laptop.c:1050: undefined reference to `rfkill_unregister' and so on.. Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com> Acked-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Mattia Dongili <malattia@linux.it> Signed-off-by: Len Brown <len.brown@intel.com>
2009-04-01 21:10:46 +08:00
depends on RFKILL
create drivers/platform/x86/ from drivers/misc/ Move x86 platform specific drivers from drivers/misc/ to a new home under drivers/platform/x86/. The community has been maintaining x86 vendor-specific platform specific drivers under /drivers/misc/ for a few years. The oldest ones started life under drivers/acpi. They moved out of drivers/acpi/ because they don't actually implement the ACPI specification, but either simply use ACPI, or implement vendor-specific ACPI extensions. In the future we anticipate... drivers/misc/ will go away. other architectures will create drivers/platform/<arch> Signed-off-by: Len Brown <len.brown@intel.com>
2008-12-01 13:09:47 +08:00
---help---
This mini-driver drives the SNC and SPIC devices present in the ACPI
BIOS of the Sony Vaio laptops.
It gives access to some extra laptop functionalities like Bluetooth,
screen brightness control, Fn keys and allows powering on/off some
devices.
Read <file:Documentation/laptops/sony-laptop.txt> for more information.
config SONYPI_COMPAT
bool "Sonypi compatibility"
depends on SONY_LAPTOP
---help---
Build the sonypi driver compatibility code into the sony-laptop driver.
config THINKPAD_ACPI
tristate "ThinkPad ACPI Laptop Extras"
depends on ACPI
platform/x86: depends instead of select for laptop platform drivers "I hate `select' and will gleefully leap on any s/select/depends/ patch, whether it works or not :)" Andrew Morton select INPUT is not needed here, because if someone doesn't want INPUT, he won't want these drivers either. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-25 16:37:09 +08:00
depends on INPUT
rfkill: rewrite This patch completely rewrites the rfkill core to address the following deficiencies: * all rfkill drivers need to implement polling where necessary rather than having one central implementation * updating the rfkill state cannot be done from arbitrary contexts, forcing drivers to use schedule_work and requiring lots of code * rfkill drivers need to keep track of soft/hard blocked internally -- the core should do this * the rfkill API has many unexpected quirks, for example being asymmetric wrt. alloc/free and register/unregister * rfkill can call back into a driver from within a function the driver called -- this is prone to deadlocks and generally should be avoided * rfkill-input pointlessly is a separate module * drivers need to #ifdef rfkill functions (unless they want to depend on or select RFKILL) -- rfkill should provide inlines that do nothing if it isn't compiled in * the rfkill structure is not opaque -- drivers need to initialise it correctly (lots of sanity checking code required) -- instead force drivers to pass the right variables to rfkill_alloc() * the documentation is hard to read because it always assumes the reader is completely clueless and contains way TOO MANY CAPS * the rfkill code needlessly uses a lot of locks and atomic operations in locked sections * fix LED trigger to actually change the LED when the radio state changes -- this wasn't done before Tested-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad] Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-02 19:01:37 +08:00
depends on RFKILL || RFKILL = n
create drivers/platform/x86/ from drivers/misc/ Move x86 platform specific drivers from drivers/misc/ to a new home under drivers/platform/x86/. The community has been maintaining x86 vendor-specific platform specific drivers under /drivers/misc/ for a few years. The oldest ones started life under drivers/acpi. They moved out of drivers/acpi/ because they don't actually implement the ACPI specification, but either simply use ACPI, or implement vendor-specific ACPI extensions. In the future we anticipate... drivers/misc/ will go away. other architectures will create drivers/platform/<arch> Signed-off-by: Len Brown <len.brown@intel.com>
2008-12-01 13:09:47 +08:00
select BACKLIGHT_LCD_SUPPORT
select BACKLIGHT_CLASS_DEVICE
select HWMON
select NVRAM
select NEW_LEDS
select LEDS_CLASS
---help---
This is a driver for the IBM and Lenovo 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/laptops/thinkpad-acpi.txt> and
<http://ibm-acpi.sf.net/> .
This driver was formerly known as ibm-acpi.
If you have an IBM or Lenovo ThinkPad laptop, say Y or M here.
ACPI: thinkpad-acpi: debug facility to emulate the rf switches This code is required to keep the thinkpad-acpi maintainer sane, and it is disabled by default. Add a debug facility to simulate an rfkill hardware rocker switch, a bluetooth rfkill soft-switch, a WWAN rfkill soft-switch on thinkpads. The simulated switches obviously do not kill any radios in hardware or firmware (unlike the real one). They also don't issue deprecated proc events. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
2009-01-11 13:01:00 +08:00
config THINKPAD_ACPI_DEBUGFACILITIES
bool "Maintainer debug facilities"
depends on THINKPAD_ACPI
default n
---help---
Enables extra stuff in the thinkpad-acpi which is completely useless
for normal use. Read the driver source to find out what it does.
Say N here, unless you were told by a kernel maintainer to do
otherwise.
create drivers/platform/x86/ from drivers/misc/ Move x86 platform specific drivers from drivers/misc/ to a new home under drivers/platform/x86/. The community has been maintaining x86 vendor-specific platform specific drivers under /drivers/misc/ for a few years. The oldest ones started life under drivers/acpi. They moved out of drivers/acpi/ because they don't actually implement the ACPI specification, but either simply use ACPI, or implement vendor-specific ACPI extensions. In the future we anticipate... drivers/misc/ will go away. other architectures will create drivers/platform/<arch> Signed-off-by: Len Brown <len.brown@intel.com>
2008-12-01 13:09:47 +08:00
config THINKPAD_ACPI_DEBUG
bool "Verbose debug mode"
depends on THINKPAD_ACPI
default n
---help---
Enables extra debugging information, at the expense of a slightly
increase in driver size.
If you are not sure, say N here.
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>
2009-04-04 12:25:49 +08:00
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.
create drivers/platform/x86/ from drivers/misc/ Move x86 platform specific drivers from drivers/misc/ to a new home under drivers/platform/x86/. The community has been maintaining x86 vendor-specific platform specific drivers under /drivers/misc/ for a few years. The oldest ones started life under drivers/acpi. They moved out of drivers/acpi/ because they don't actually implement the ACPI specification, but either simply use ACPI, or implement vendor-specific ACPI extensions. In the future we anticipate... drivers/misc/ will go away. other architectures will create drivers/platform/<arch> Signed-off-by: Len Brown <len.brown@intel.com>
2008-12-01 13:09:47 +08:00
config THINKPAD_ACPI_DOCK
bool "Legacy Docking Station Support"
depends on THINKPAD_ACPI
depends on ACPI_DOCK=n
default n
---help---
Allows the thinkpad_acpi driver to handle docking station events.
This support was made obsolete by the generic ACPI docking station
support (CONFIG_ACPI_DOCK). 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 THINKPAD_ACPI_BAY
bool "Legacy Removable Bay Support"
depends on THINKPAD_ACPI
default y
---help---
Allows the thinkpad_acpi driver to handle removable bays. It will
electrically disable 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 THINKPAD_ACPI_VIDEO
bool "Video output control support"
depends on THINKPAD_ACPI
default y
---help---
Allows the thinkpad_acpi driver to provide an interface to control
the various video output ports.
This feature often won't work well, depending on ThinkPad model,
display state, video output devices in use, whether there is a X
server running, phase of the moon, and the current mood of
Schroedinger's cat. If you can use X.org's RandR to control
your ThinkPad's video output ports instead of this feature,
don't think twice: do it and say N here to save some memory.
If you are not sure, say Y here.
config THINKPAD_ACPI_HOTKEY_POLL
bool "Support NVRAM polling for hot keys"
depends on THINKPAD_ACPI
default y
---help---
Some thinkpad models benefit from NVRAM polling to detect a few of
the hot key press events. If you know your ThinkPad model does not
need to do NVRAM polling to support any of the hot keys you use,
unselecting this option will save about 1kB of memory.
ThinkPads T40 and newer, R52 and newer, and X31 and newer are
unlikely to need NVRAM polling in their latest BIOS versions.
NVRAM polling can detect at most the following keys: ThinkPad/Access
IBM, Zoom, Switch Display (fn+F7), ThinkLight, Volume up/down/mute,
Brightness up/down, Display Expand (fn+F8), Hibernate (fn+F12).
If you are not sure, say Y here. The driver enables polling only if
it is strictly necessary to do so.
config INTEL_MENLOW
tristate "Thermal Management driver for Intel menlow platform"
depends on ACPI_THERMAL
select THERMAL
---help---
ACPI thermal management enhancement driver on
Intel Menlow platform.
If unsure, say N.
config EEEPC_LAPTOP
tristate "Eee PC Hotkey Driver (EXPERIMENTAL)"
depends on ACPI
eeepc: should depend on INPUT Otherwise with INPUT=m, EEEPC_LAPTOP=y one gets drivers/built-in.o: In function `input_sync': eeepc-laptop.c:(.text+0x18ce51): undefined reference to `input_event' drivers/built-in.o: In function `input_report_key': eeepc-laptop.c:(.text+0x18ce73): undefined reference to `input_event' drivers/built-in.o: In function `eeepc_hotk_check': eeepc-laptop.c:(.text+0x18d05f): undefined reference to `input_allocate_device' eeepc-laptop.c:(.text+0x18d10f): undefined reference to `input_register_device' eeepc-laptop.c:(.text+0x18d131): undefined reference to `input_free_device' drivers/built-in.o: In function `eeepc_backlight_exit': eeepc-laptop.c:(.text+0x18d546): undefined reference to `input_unregister_device' Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Cc: Len Brown <lenb@kernel.org> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-02-19 06:48:22 +08:00
depends on INPUT
create drivers/platform/x86/ from drivers/misc/ Move x86 platform specific drivers from drivers/misc/ to a new home under drivers/platform/x86/. The community has been maintaining x86 vendor-specific platform specific drivers under /drivers/misc/ for a few years. The oldest ones started life under drivers/acpi. They moved out of drivers/acpi/ because they don't actually implement the ACPI specification, but either simply use ACPI, or implement vendor-specific ACPI extensions. In the future we anticipate... drivers/misc/ will go away. other architectures will create drivers/platform/<arch> Signed-off-by: Len Brown <len.brown@intel.com>
2008-12-01 13:09:47 +08:00
depends on EXPERIMENTAL
rfkill: rewrite This patch completely rewrites the rfkill core to address the following deficiencies: * all rfkill drivers need to implement polling where necessary rather than having one central implementation * updating the rfkill state cannot be done from arbitrary contexts, forcing drivers to use schedule_work and requiring lots of code * rfkill drivers need to keep track of soft/hard blocked internally -- the core should do this * the rfkill API has many unexpected quirks, for example being asymmetric wrt. alloc/free and register/unregister * rfkill can call back into a driver from within a function the driver called -- this is prone to deadlocks and generally should be avoided * rfkill-input pointlessly is a separate module * drivers need to #ifdef rfkill functions (unless they want to depend on or select RFKILL) -- rfkill should provide inlines that do nothing if it isn't compiled in * the rfkill structure is not opaque -- drivers need to initialise it correctly (lots of sanity checking code required) -- instead force drivers to pass the right variables to rfkill_alloc() * the documentation is hard to read because it always assumes the reader is completely clueless and contains way TOO MANY CAPS * the rfkill code needlessly uses a lot of locks and atomic operations in locked sections * fix LED trigger to actually change the LED when the radio state changes -- this wasn't done before Tested-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad] Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-02 19:01:37 +08:00
depends on RFKILL || RFKILL = n
Merge branch 'drivers-platform' into release Conflicts: drivers/misc/Kconfig Signed-off-by: Len Brown <len.brown@intel.com>
2009-01-09 17:01:26 +08:00
select BACKLIGHT_CLASS_DEVICE
select HWMON
create drivers/platform/x86/ from drivers/misc/ Move x86 platform specific drivers from drivers/misc/ to a new home under drivers/platform/x86/. The community has been maintaining x86 vendor-specific platform specific drivers under /drivers/misc/ for a few years. The oldest ones started life under drivers/acpi. They moved out of drivers/acpi/ because they don't actually implement the ACPI specification, but either simply use ACPI, or implement vendor-specific ACPI extensions. In the future we anticipate... drivers/misc/ will go away. other architectures will create drivers/platform/<arch> Signed-off-by: Len Brown <len.brown@intel.com>
2008-12-01 13:09:47 +08:00
---help---
This driver supports the Fn-Fx keys on Eee PC laptops.
acpi4asus: update MAINTAINER and KConfig links The bug tracker have moved from sourceforge to http://dev.iksaif.net . The homepage of the project is now http://acpi4asus.sf.net with links to the new bug tracker. No change for the mailing list. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
2009-06-17 03:28:47 +08:00
It also gives access to some extra laptop functionalities like
Bluetooth, backlight and allows powering on/off some other
devices.
create drivers/platform/x86/ from drivers/misc/ Move x86 platform specific drivers from drivers/misc/ to a new home under drivers/platform/x86/. The community has been maintaining x86 vendor-specific platform specific drivers under /drivers/misc/ for a few years. The oldest ones started life under drivers/acpi. They moved out of drivers/acpi/ because they don't actually implement the ACPI specification, but either simply use ACPI, or implement vendor-specific ACPI extensions. In the future we anticipate... drivers/misc/ will go away. other architectures will create drivers/platform/<arch> Signed-off-by: Len Brown <len.brown@intel.com>
2008-12-01 13:09:47 +08:00
If you have an Eee PC laptop, say Y or M here.
ACPI: move wmi, asus_acpi, toshiba_acpi to drivers/platform/x86 These are platform specific drivers that happen to use ACPI, while drivers/acpi/ is for code that implements ACPI itself. Signed-off-by: Len Brown <len.brown@intel.com>
2008-12-12 03:37:26 +08:00
config ACPI_WMI
acpi-wmi: Unmark as 'experimental' ACPI-WMI isn't experimental anymore, and there are other drivers that now depend on it that aren't either. Signed-off-by: Carlos Corbacho <carlos@strangeworlds.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-14 17:53:53 +08:00
tristate "WMI"
ACPI: move wmi, asus_acpi, toshiba_acpi to drivers/platform/x86 These are platform specific drivers that happen to use ACPI, while drivers/acpi/ is for code that implements ACPI itself. Signed-off-by: Len Brown <len.brown@intel.com>
2008-12-12 03:37:26 +08:00
depends on ACPI
help
This driver adds support for the ACPI-WMI (Windows Management
Instrumentation) mapper device (PNP0C14) found on some systems.
ACPI-WMI is a proprietary extension to ACPI to expose parts of the
ACPI firmware to userspace - this is done through various vendor
defined methods and data blocks in a PNP0C14 device, which are then
made available for userspace to call.
The implementation of this in Linux currently only exposes this to
other kernel space drivers.
This driver is a required dependency to build the firmware specific
drivers needed on many machines, including Acer and HP laptops.
It is safe to enable this driver even if your DSDT doesn't define
any ACPI-WMI devices.
config ACPI_ASUS
tristate "ASUS/Medion Laptop Extras"
depends on ACPI
select BACKLIGHT_CLASS_DEVICE
---help---
This driver provides support for extra features of ACPI-compatible
ASUS laptops. As some of Medion laptops are made by ASUS, it may also
support some Medion laptops (such as 9675 for example). It makes all
the extra buttons generate standard ACPI events that go through
/proc/acpi/events, and (on some models) adds support for changing the
display brightness and output, switching the LCD backlight on and off,
and most importantly, allows you to blink those fancy LEDs intended
for reporting mail and wireless status.
Note: display switching code is currently considered EXPERIMENTAL,
toying with these values may even lock your machine.
All settings are changed via /proc/acpi/asus directory entries. Owner
and group for these entries can be set with asus_uid and asus_gid
parameters.
More information and a userspace daemon for handling the extra buttons
acpi4asus: update MAINTAINER and KConfig links The bug tracker have moved from sourceforge to http://dev.iksaif.net . The homepage of the project is now http://acpi4asus.sf.net with links to the new bug tracker. No change for the mailing list. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
2009-06-17 03:28:47 +08:00
at <http://acpi4asus.sf.net>.
ACPI: move wmi, asus_acpi, toshiba_acpi to drivers/platform/x86 These are platform specific drivers that happen to use ACPI, while drivers/acpi/ is for code that implements ACPI itself. Signed-off-by: Len Brown <len.brown@intel.com>
2008-12-12 03:37:26 +08:00
If you have an ACPI-compatible ASUS laptop, say Y or M here. This
driver is still under development, so if your laptop is unsupported or
something works not quite as expected, please use the mailing list
available on the above page (acpi4asus-user@lists.sourceforge.net).
NOTE: This driver is deprecated and will probably be removed soon,
use asus-laptop instead.
config ACPI_TOSHIBA
tristate "Toshiba Laptop Extras"
depends on ACPI
depends on INPUT
rfkill: rewrite This patch completely rewrites the rfkill core to address the following deficiencies: * all rfkill drivers need to implement polling where necessary rather than having one central implementation * updating the rfkill state cannot be done from arbitrary contexts, forcing drivers to use schedule_work and requiring lots of code * rfkill drivers need to keep track of soft/hard blocked internally -- the core should do this * the rfkill API has many unexpected quirks, for example being asymmetric wrt. alloc/free and register/unregister * rfkill can call back into a driver from within a function the driver called -- this is prone to deadlocks and generally should be avoided * rfkill-input pointlessly is a separate module * drivers need to #ifdef rfkill functions (unless they want to depend on or select RFKILL) -- rfkill should provide inlines that do nothing if it isn't compiled in * the rfkill structure is not opaque -- drivers need to initialise it correctly (lots of sanity checking code required) -- instead force drivers to pass the right variables to rfkill_alloc() * the documentation is hard to read because it always assumes the reader is completely clueless and contains way TOO MANY CAPS * the rfkill code needlessly uses a lot of locks and atomic operations in locked sections * fix LED trigger to actually change the LED when the radio state changes -- this wasn't done before Tested-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad] Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-02 19:01:37 +08:00
depends on RFKILL || RFKILL = n
ACPI: move wmi, asus_acpi, toshiba_acpi to drivers/platform/x86 These are platform specific drivers that happen to use ACPI, while drivers/acpi/ is for code that implements ACPI itself. Signed-off-by: Len Brown <len.brown@intel.com>
2008-12-12 03:37:26 +08:00
select INPUT_POLLDEV
select BACKLIGHT_CLASS_DEVICE
---help---
This driver adds support for access to certain system settings
on "legacy free" Toshiba laptops. These laptops can be recognized by
their lack of a BIOS setup menu and APM support.
On these machines, all system configuration is handled through the
ACPI. This driver is required for access to controls not covered
by the general ACPI drivers, such as LCD brightness, video output,
etc.
This driver differs from the non-ACPI Toshiba laptop driver (located
under "Processor type and features") in several aspects.
Configuration is accessed by reading and writing text files in the
/proc tree instead of by program interface to /dev. Furthermore, no
power management functions are exposed, as those are handled by the
general ACPI drivers.
More information about this driver is available at
<http://memebeam.org/toys/ToshibaAcpiDriver>.
If you have a legacy free Toshiba laptop (such as the Libretto L1
series), say Y.
create drivers/platform/x86/ from drivers/misc/ Move x86 platform specific drivers from drivers/misc/ to a new home under drivers/platform/x86/. The community has been maintaining x86 vendor-specific platform specific drivers under /drivers/misc/ for a few years. The oldest ones started life under drivers/acpi. They moved out of drivers/acpi/ because they don't actually implement the ACPI specification, but either simply use ACPI, or implement vendor-specific ACPI extensions. In the future we anticipate... drivers/misc/ will go away. other architectures will create drivers/platform/<arch> Signed-off-by: Len Brown <len.brown@intel.com>
2008-12-01 13:09:47 +08:00
endif # X86_PLATFORM_DEVICES