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: Anisse Astier <anisse@astier.eu>
Signed-off-by: Len Brown <len.brown@intel.com>

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

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

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

Rely on DYNAMIC_DEBUG instead if needed
Signed-off-by: Anisse Astier <anisse@astier.eu>
Signed-off-by: Len Brown <len.brown@intel.com>

There should be less code duplication with usage of gotos
Driver won't load if there's no hardware to control
Safer error handling at input driver allocation
Signed-off-by: Anisse Astier <anisse@astier.eu>
Signed-off-by: Len Brown <len.brown@intel.com>

Signed-off-by: Anisse Astier <anisse@astier.eu>
Signed-off-by: Len 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: Thomas Renninger <trenn@suse.de>
CC: Carlos Corbacho <carlos@strangeworlds.co.uk>
CC: Matthew Garrett <mjg59@srcf.ucam.org>
Tested-by: Matt Chen <machen@novell.com>
Reviewed-by: Anisse Astier <anisse@astier.eu>
Signed-off-by: Len Brown <len.brown@intel.com>

Conflicts:
	drivers/acpi/dock.c
Signed-off-by: Len Brown <len.brown@intel.com>

Removed some stray whitespaces
Added whitespace when needed for legibility
Removed unneeded curly braces
Removed useless void casts
Removed unnecessary local variable initialization
Renamed variables to help out with 80-column fixes
Signed-off-by: Alex Chiang <achiang@hp.com>
Acked-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

Instead of adding a (struct dock_station **) to our dock device's
platform data, we can add the (struct dock_station *) directly.

This change saves us some ugly casting and improves readability.

The cost of making this change is an extra 290 bytes of stack usage,
but this is an infrequently called code-path and unlikely to cause
the kernel to blow up.
Signed-off-by: Alex Chiang <achiang@hp.com>
Acked-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

Move the call to platform_device_register_simple so that we do it
before allocating and initializing our struct dock_station.
Signed-off-by: Alex Chiang <achiang@hp.com>
Acked-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

We only use it in one spot, so it probably gets optimized out, but there's
still no need to use a global variable for this.
Signed-off-by: Alex Chiang <achiang@hp.com>
Acked-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

There's no real need to have a separate allocation step when adding
a dock dependent device.

Combining the two functions is both logical and helps with legibility.
Signed-off-by: Alex Chiang <achiang@hp.com>
Acked-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

Conflicts:
	include/acpi/processor.h
Signed-off-by: Len Brown <len.brown@intel.com>

On some laptops it will return NOTIFY_OK(non-zero) when calling the ACPI LID
notifier. Then it is used as the result of ACPI LID resume function, which
will complain the following warning message in course of suspend/resume:

     >PM: Device PNP0C0D:00 failed to resume: error 1

This patch is to eliminate the above warning message.

http://bugzilla.kernel.org/show_bug.cgi?id=14782Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>

Add the basic ALSA mixer functionality.  The mixer is event-driven,
and will work fine on IBM ThinkPads.  I expect Lenovo ThinkPads will
cause some trouble with the event interface.

Heavily based on work by Lorne Applebaum <lorne.applebaum@gmail.com>
and ideas from Matthew Garrett <mjg@redhat.com>.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Lorne Applebaum <lorne.applebaum@gmail.com>
Cc: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Len Brown <len.brown@intel.com>

Disable volume control by default.  It can be enabled at module load
time by a module parameter (volume_control=1).

The audio control mixer that thinkpad-acpi interacts with is fully
functional without any drivers, and operated by hotkeys.

The idea behind the console audio control is that the human operator
is the only one that can interact with it.  The ThinkVantage suite in
Windows does not allow any software-based overrides, and only does OSD
(on-screen-display) functions.

The Linux driver will, with the addition of the ALSA interface, try to
follow and enforce the ThinkVantage UI design:

The user is supposed to use the keyboard hotkeys to interact with the
console audio control.  The kernel and the desktop environment is
supposed to cooperate to provide proper user feedback through
on-screen-display functions.

Distros are urged to not to enable volume control by default.
Enabling this must be a local admin's decision.  This is the reason
why there is no Kconfig option.

Keep in mind that all ThinkPads have a normal, main mixer (AC97 or
HDA) for regular software-based audio control.  We are not talking
about that mixer here.

Advanced users are, of course, free to enable volume control and do as
they please.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Lorne Applebaum <lorne.applebaum@gmail.com>
Cc: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Len Brown <len.brown@intel.com>

Lenovo removed the extra mixer since the T61 and thereabouts.
Newer Lenovo models only have the mute gate function, and leave
the volume control to the HDA mixer.

Until a way to automatically query the firmware about its audio
control capabilities is discovered (there might not be any), use a
white/black list.

We will likely need to ask T60 (old and new model) and Z60/Z61 users
whether they have volume control to populate the black/white list.
Meanwhile, provide a volume_capabilities parameter that can be used to
override the defaults.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Lorne Applebaum <lorne.applebaum@gmail.com>
Cc: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Len Brown <len.brown@intel.com>

I don't trust the coupled EC writes and SMI calls the current volume
control code does very much, although it is exactly what the IBM DSDTs
seem to do (they never do more than a single step though).

Change the driver to stop issuing SMIs, and just drive the EC directly
to the desired level (DSDTs seem to confirm this will work even on
very old models like the 570 and 600e/x).

We checkpoint directly to NVRAM (this can be turned off) at
suspend/shutdown/driver unload, which from what I can see in tbp,
should also work on every ThinkPad.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Lorne Applebaum <lorne.applebaum@gmail.com>
Cc: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Len Brown <len.brown@intel.com>

We already log the initial state of the hardware rfkill switch (WLSW),
might as well log the state of the softswitches as well.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Josip Rodin <joy+kernel@entuzijast.net>
Signed-off-by: Len Brown <len.brown@intel.com>

Before we register the input device, sync the input layer EV_SW state
through a call to input_report_switch(), to avoid issuing a gratuitous
event for the initial state of these switches.

This fixes some annoyances caused by the interaction with rfkill and
EV_SW SW_RFKILL_ALL events.
Reported-by: Kevin Locke <kevin@kevinlocke.name>
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Len Brown <len.brown@intel.com>

Add kernel tainting after overriding an ACPI control method successfully.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

Conflicts:
	Documentation/feature-removal-schedule.txt
	drivers/platform/x86/eeepc-laptop.c
Signed-off-by: Len Brown <len.brown@intel.com>

The light sensor disable brightness key and
/sys/class/backlight/ control. There was a lot of report
from users who didn't understand why they couldn't change their
brightness, including:

https://bugs.launchpad.net/bugs/222171
https://bugzilla.novell.com/show_bug.cgi?id=514747
http://bugzilla.kernel.org/show_bug.cgi?id=13671
http://bugzilla.kernel.org/show_bug.cgi?id=14432

Now the light sensor is disabled, and if the user want to enable
it, the level should be ok.

The funny thing is that comments where ok, not code.

Cc: stable@kernel.org
Cc: Thomas Renninger <trenn@suse.de>
Cc: Peter Küppers <peter-mailbox@web.de>
Cc: Michael Franzl <michaelfranzl@gmx.at>
Cc: Ian Turner <vectro@vectro.org>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>

This allows ipmi_si_intf.c to claim IPMI devices described in the ACPI
namespace.  Using PNP makes it simpler to parse the IRQ/IO/memory resources
of the device.

We look at any SPMI tables before looking for devices in the namespace.

This is based on ipmi_pci_probe().
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Myron Stowe <myron.stowe@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>