-tip testing found:

eeepc-wmi.c:(.text+0x36673c): undefined reference to `sparse_keymap_report_event'
drivers/built-in.o: In function `eeepc_wmi_init':
eeepc-wmi.c:(.init.text+0x19cd0): undefined reference to `sparse_keymap_setup'
eeepc-wmi.c:(.init.text+0x19cf0): undefined reference to `sparse_keymap_free'
eeepc-wmi.c:(.init.text+0x19d0b): undefined reference to `sparse_keymap_free'
drivers/built-in.o: In function `eeepc_wmi_exit':
eeepc-wmi.c:(.exit.text+0x2e87): undefined reference to `sparse_keymap_free'

To fix this select INPUT_SPARSEKMAP, like the ASUS driver does.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Add a WMI driver for Eee PC laptops. Currently it only supports hotkeys.
Signed-off-by: NYong Wang <yong.y.wang@intel.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Acked-by: NDmitry Torokhov <dtor@mail.ru>

msi-laptop uses rfkill*() interfaces so it should depend on RFKILL.

msi-laptop.c:(.text+0x1fcd1b): undefined reference to `rfkill_alloc'
msi-laptop.c:(.text+0x1fcd76): undefined reference to `rfkill_register'
msi-laptop.c:(.text+0x1fcdc8): undefined reference to `rfkill_destroy'
msi-laptop.c:(.text+0x1fcdd9): undefined reference to `rfkill_unregister'

This repairs "msi-laptop: Detect 3G device exists by standard ec command",
which is in some gregkh tree.
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Cc: Lennart Poettering <mzxreary@0pointer.de>
Cc: Lee, Chun-Yi <jlee@novell.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

-tip testing found this build failure (x86 randconfig):

 drivers/built-in.o: In function `setup_rfkill':
 compal-laptop.c:(.text+0x36abe8): undefined reference to `rfkill_alloc'
 compal-laptop.c:(.text+0x36abfc): undefined reference to `rfkill_register'
 compal-laptop.c:(.text+0x36ac30): undefined reference to `rfkill_alloc'
 compal-laptop.c:(.text+0x36ac44): undefined reference to `rfkill_register'

Which can happen with CONFIG_COMPAL_LAPTOP=y but COMPAL_LAPTOP=m.
Signed-off-by: NIngo Molnar <mingo@elte.hu>

The rfkill subsystem will enable gps by default.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>

This patch is based on Dmitry Torokhov's patch with
some modifications and cleanups.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>

Given the right combination of ThinkPad and X.org, just reading the
video output control state is enough to hard-crash X.org.

Until the day I somehow find out a model or BIOS cut date to not
provide this feature to ThinkPads that can do video switching through
X RandR, change permissions so that only processes with CAP_SYS_ADMIN
can access any sort of video output control state.

This bug could be considered a local DoS I suppose, as it allows any
non-privledged local user to cause some versions of X.org to
hard-crash some ThinkPads.
Reported-by: NJidanni <jidanni@jidanni.org>
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: stable@kernel.org

The rfkill interface on Dells only sends a notification that the switch
has been changed via the keyboard controller. Add a filter so we can
pick these notifications up and update the rfkill state appropriately.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
Tested-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Acked-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

Document that rfkill and ALSA functionality exists, but requires the
subsystems to be available, and not modular if thinkpad-acpi is not
modular.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Allow the user to choose through Kconfig if the Console Audio Control
interface (aka "volume subdriver") should be available or not.

This not only saves some memory, but also allows the thinkpad-acpi
driver to be built-in even if ALSA is modular when the console audio
control interface is not wanted.

This change fixes a build problem that is causing some annoyances, in
a way that doesn't disable the entire driver on kernels without ALSA
support.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Amerigo Wang <amwang@redhat.com>
Cc: Helight Xu <helight.xu@gmail.com>
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

This add supports for devices like keyboard, backlight, tablet and
accelerometer.

This work is supported by International Syst S/A.

[randy.dunlap@oracle.com: cmpc_acpi: depends on ACPI]
[akpm@linux-foundation.org: readability tweaks]
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Now depends on BACKLIGHT_CLASS_DEVICE.
Driver will return an error if it can't get actual backlight value
Fix remapping of brightness keys when backlight is not controlled by ACPI.
Signed-off-by: NAnisse Astier <anisse@astier.eu>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NAnisse Astier <anisse@astier.eu>
Signed-off-by: NLen Brown <len.brown@intel.com>

This driver serves backlight (including switching) and volume up/down
keys for MSI machines providing a specific wmi interface:
551A1F84-FBDD-4125-91DB-3EA8F44F1D45
B6F3EEF2-3D2F-49DC-9DE3-85BCE18C62F2
Signed-off-by: NThomas Renninger <trenn@suse.de>
CC: Carlos Corbacho <carlos@strangeworlds.co.uk>
CC: Matthew Garrett <mjg59@srcf.ucam.org>
Tested-by: NMatt Chen <machen@novell.com>
Reviewed-by: NAnisse Astier <anisse@astier.eu>
Signed-off-by: NLen Brown <len.brown@intel.com>

This patch adds support for the ACPI events generated by the RFKill
switch on modern Toshiba laptops, and re-enables the Bluetooth USB
device when the switch is flipped back to the 'on' position.

The RFKill switch brute force pulls out the USB device when flipped to
'off', but it doesn't automatically re-enable it. Without this driver,
the Bluetooth is gone until after a reboot on my Portege R500.
Signed-off-by: NJes Sorensen <Jes.Sorensen@gmail.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

This led can be found on Eeepc 1005 series.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

This adds Topstar Laptop Extras ACPI driver. It enables hotkeys
functionality with Topstar N01 netbook. Besides hotkeys there are
other functions exposed by its ACPI firmware, but for now only
hotkeys reporting on Topstar N01 is supported. Topstar is a chinese
manufacturer, its website can be currently reached at
http://www.topstardigital.cn/Signed-off-by: NHerton Ronaldo Krzesinski <herton@mandriva.com.br>
Reviewed-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Reviewed-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

This patch is a trivial fix for a config corner case, ensuring that
fujitsu-laptop doesn't get compiled into the kernel when the led class
is a module.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NJonathan Woithe <jwoithe@physics.adelaide.edu.au>
Signed-off-by: NLen Brown <len.brown@intel.com>

The standard ACPI dock driver can handle the hotplug bays and docks of
the ThinkPads just fine (including batteries) as of 2.6.27, and the
code in thinkpad-acpi for the dock and bay subdrivers is currently
broken anyway...

Userspace needs some love to support the two-stage ejection nicely,
but it is simple enough to do through udev rules (you don't even need
HAL) so this wouldn't justify fixing the dock and bay subdrivers,
either.

That leaves warm-swap bays (_EJ3) support for thinkpad-acpi, as well
as support for the weird dock of the model 570, but since such support
has never left the "experimental" stage, it is also not a strong
enough reason to find a way to fix this code.

Users of ThinkPads with warm-swap bays are urged to request that _EJ3
support be added to the regular ACPI dock driver, if such feature is
indeed useful for them.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Currently, the ThinkPad-ACPI bay and dock drivers are completely
broken, and cause a NULL pointer derreference in kernel mode (and,
therefore, an OOPS) when they try to issue events (i.e. on dock,
undock, bay ejection, etc).

OTOH, the standard ACPI dock driver can handle the hotplug bays and
docks of the ThinkPads just fine (including batteries) as of 2.6.27.
In fact, it does a much better job of it than thinkpad-acpi ever did.

It is just not worth the hassle to find a way to fix this crap without
breaking the (deprecated) thinkpad-acpi dock/bay ABI.  This is old,
deprecated code that sees little testing or use.

As a quick fix suitable for -stable backports, mark the thinkpad-acpi
bay and dock subdrivers as BROKEN in Kconfig.  The dead code will be
removed by a later patch.

This fixes bugzilla #13669, and should be applied to 2.6.27 and later.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Reported-by: NJoerg Platte <jplatte@naasa.net>
Cc: stable@kernel.org
Signed-off-by: NLen Brown <len.brown@intel.com>

FYI, there's a post-rc1 build regression with certain configs:

 drivers/built-in.o: In function `pci_hp_deregister':
 (.text+0xb166): undefined reference to `pci_hp_remove_module_link'
 drivers/built-in.o: In function `pci_hp_deregister':
 (.text+0xb19f): undefined reference to `pci_destroy_slot'
 drivers/built-in.o: In function `__pci_hp_register':
 (.text+0xb583): undefined reference to `pci_create_slot'
 drivers/built-in.o: In function `__pci_hp_register':
 (.text+0xb5b1): undefined reference to `pci_hp_create_module_link'
 make: *** [.tmp_vmlinux1] Error 1

Caused by:

| 2b121bc2 is first bad commit
| commit 2b121bc2
| Date:   Thu Jun 25 13:25:36 2009 +0200
|
|     eeepc-laptop: Register as a pci-hotplug device

which changed the driver to use the PCI hotplug infrastructure, but
didn't do a good job on the Kconfig rules.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Acked-by: NRandy Dunlap <randy.dunlap@oracle.com>
Acked-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The eee contains a logically (but not physically) hotpluggable PCIe slot.
Currently this is handled by adding or removing the PCI device in response
to rfkill events, but if a user has forced pciehp to bind to it (with the
force=1 argument) then both drivers will try to handle the event and
hilarity (in the form of oopses) will ensue. This can be avoided by having
eee-laptop register the slot as a hotplug slot. Only one of pciehp and
eee-laptop will successfully register this, avoiding the problem.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Tested-by: NDarren Salt <linux@youmustbejoking.demon.co.uk>
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

asus-laptop have been merged in the kernel two years ago,
it is now stable and used by most distribution instead of
the old asus_acpi driver.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

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: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

Acerhdf is a driver for Acer Aspire One netbooks. It allows
to access the temperature sensor and to control the fan.
Signed-off-by: NPeter Feuerer <peter@piie.net>
Signed-off-by: NAndreas Mohr <andi@lisas.de>
Signed-off-by: NBorislav Petkov <petkovbb@gmail.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

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: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad]
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

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: NMatthew Garrett <mjg@redhat.com>
Cc: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

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: NAlexander Beregalov <a.beregalov@gmail.com>
Acked-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NMattia Dongili <malattia@linux.it>
Signed-off-by: NLen Brown <len.brown@intel.com>

This driver has been around and used long enough that we can drop the
'experimental'.
Signed-off-by: NCarlos Corbacho <carlos@strangeworlds.co.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

ACPI-WMI isn't experimental anymore, and there are other drivers that now
depend on it that aren't either.
Signed-off-by: NCarlos Corbacho <carlos@strangeworlds.co.uk>
Signed-off-by: NLen Brown <len.brown@intel.com>

"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: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

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: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

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: NRandy 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: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

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: NAlexey Dobriyan <adobriyan@gmail.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Update Kconfig, now asus-laptop use the input layer.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NLen Brown <len.brown@intel.com>

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: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>