ACPI Thinkpad: We must always call va_end() after va_start() but do not do so in thinkpad_acpi.c::acpi_evalf()

Hi,

In drivers/platform/x86/thinkpad_acpi.c::acpi_evalf() we don't always call
va_end() after va_start(). This patch corrects that.
Signed-off-by: NJesper Juhl <jj@chaosbits.net>
Acked-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Delete successive assignments to the same location.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@@
expression i;
@@

*i = ...;
 i = ...;
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Change the code so that it will use the correct size for keymap entries.
Do it in a way that makes it harder to screw it up in the future.
Reported-by: NJaime Velasco Juan <jsagarribay@gmail.com>
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

On the T410s and most likely other current models, Fn-F6 is labeled as
Camera/Headphone key.  Report key presses as KEY_CAMERA.
Signed-off-by: NJens Taprogge <jens.taprogge@taprogge.org>
Acked-by: NJerone Young <jerone.young@canonical.com>
Acked-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Use the quirks engine to select model-specific keymaps, which makes
it much easier to extend should we need it.

Keycodes are based on the tables at
http://www.thinkwiki.org/wiki/Default_meanings_of_special_keys.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Use a safer coding style for the hotkey keymap.  This does not fix any
problems, as the current code is correct.  But it might help avoid
mistakes in the future.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

acpi_video_backlight_support() already tells us if ACPI is handling
backlight control through the generic ACPI handle.  It is better to just
trust it.

While at it, adjust down a printk priority, and test earlier for
brightness_enable=0.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

The Linux ACPI core locates the ACPI video devices for us and marks them
with ACPI_VIDEO_HID.  Use that information to locate the video device
instead of a half-baked hunt for _BCL.

This uncouples the detection of the number of backlight brightness
levels on ThinkPads from the ACPI paths in vid_handle.

With this change, the driver should be able to always detect whether the
ThinkPad uses a 8-level or 16-level brightness scale even on newer
models for which the vid_handle paths have not been updated yet.

It will skip deactivated devices in the ACPI device tree, which is a
change in behaviour.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

There is a general interface for that now (provided by
other patches in this patch series):
/sys/kernel/debug/ec/*/io
Signed-off-by: NThomas Renninger <trenn@suse.de>

CC: Alexey Starikovskiy <astarikovskiy@suse.de>
CC: Len Brown <lenb@kernel.org>
CC: linux-kernel@vger.kernel.org
CC: linux-acpi@vger.kernel.org
CC: platform-driver-x86@vger.kernel.org
CC: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
CC: ibm-acpi-devel@lists.sourceforge.net
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Document this, it is no fun to try to second guess why this sort of
stuff is in place years after it was added...
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>

1. Remove <handle>_path, as its only user was already removed in
   a previous commit

2. Move all handle initialization, as well as <handle>_parent and
   <handle>_paths to __init.* sections.  This reduces the driver's
   runtime footprint nicely.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>

Don't depend on the contents of led_path to know which LED interface
the firmware wants.

This removes the only user of *_path for the thinkpad-acpi ACPI
handlers, which will simplify future code.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>

Log more human-friendly errors instead of numeric values when
setup_acpi_notify() fails to install a notification handler.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>

Use acpi_format_exception() in acpi_evalf() instead of logging numeric
errors.

Also, when ACPICA returns an error, we should not be touching the return
object, as it is invalid.  In debug mode, acpi_evalf() callers would
printk the returned crap (but fortunately, not use it).
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>

Use the EC HID (PNP0C09) to locate its main node, instead of a static
list.
Suggested-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Matthew Garrett <mjg@redhat.com>

Disclose the user task doing ALSA access when requested by
the debug bitmask.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>

Handle multiple brightness hotkey presses between two polling cycles.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>

Extract the backlight level range size detection from the brightness
subdriver, and allow the other subdrivers access to that information.

This also allows us to relocate some code to a more convenient place.
The moved code was largerly unmodified, except for the return type of
tpacpi_check_std_acpi_brightness_support(), which now is correctly
marked as returning "unsigned int", and and two cosmetic fixes to make
checkpatch.pl happy.

Fixes for the NVRAM polling mode for the brightness hotkeys will need
this.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>

Move the driver initial greetings out of the first subdriver, as we do a
lot of other initialization before that point, and the initial greetings
should go as soon as the driver decides that it should load.

These greetings are not cosmetic, they make my life easier when users
report bugs.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>

The hotkey polling code is supposed to generate hotkey messages as
close to the way the IBM event-based volume hotkey firmware does as
possible, i.e:

* Pressing MUTE issues a mute hotkey event, even if already mute;

* Pressing Volume up/down issues a volume up/down hotkey event,
  even if already at maximum or minumum volume;

* The act of unmuting issues a volume up/down event, depending on
  which hotkey was used to unmute.

Fix the code to do just that (mute handling was incorrect), and handle
multiple hotkey presses between two polling cycles.

The new code uses the volume_toggle bit in NVRAM only to detect
repeated presses of the mute key and multiple presses of the volume
keys trying to go past the end of the volume scale.  This will work
around a bug in recent Lenovo firmware (e.g. T400), which causes the
firmware to not update the volume_toggle bit in certain situations.
Reported-by: NYang Zhe <yangzhe1990@gmail.com>
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>

The X100e needs some quick fixes to work semi-right with this driver.
There are much better ways to do this, but we can start with a quick
update and do it properly later.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>

Lenovo is playing around with its ACPI BIOS, and will end up reusing
method names.  Their memory is not nearly as long as thinkpad-acpi's...

Secure most of the old IBM codepaths against running in a non-IBM box.
This would happen on the Lenovo X100e in video_init(), for example.  We
would misdetect it as an ancient model 570 firmware.

Also, refuse to load the driver if we cannot identify the vendor.  No
ACPI ThinkPad in existence lacks this information, AFAIK.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: NTejun Heo <tj@kernel.org>
Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

Values such as max_brightness should be set before backlights are
registered, but the current API doesn't allow that. Add a parameter to
backlight_device_register and update drivers to ensure that they
set this correctly.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

Clemens Ladisch reports that thinkpad-acpi improperly implements the
ALSA API, and always returns 0 for success for the "put" callbacks
while the API requires it to return "1" when the control value has
been changed in the hardware/firmware.

Rework the volume subdriver to be able to properly implement the ALSA
API.  Based on a patch by Clemens Ladisch <clemens@ladisch.de>.

This fix is also needed on 2.6.33.
Reported-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: stable@kernel.org

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

Studying the DSDTs of various thinkpads, it looks like bit 3 of the
argument to SBDC and SWAN is not "set radio to last state on resume".
Rather, it seems to be "if this bit is set, enable radio on resume,
otherwise disable it on resume".

So, the proper way to prepare the radios for S3 suspend is: disable
radio and clear bit 3 on the SBDC/SWAN call to to resume with radio
disabled, and enable radio and set bit 3 on the SBDC/SWAN call to
resume with the radio enabled.

Also, for persistent devices, the rfkill core does not restore state,
so we really need to get the firmware to do the right thing.

We don't sync the radio state on suspend, instead we trust the BIOS to
not do anything weird if we never touched the radio state since boot.
Time will tell if that's a wise way of doing things...
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: stable@kernel.org

Thadeu Lima de Souza Cascardo reports this:

Brightness notification does not work until the user writes to
hotkey_mask attribute.  That's because the polling thread will only run
if hotkey_user_mask is set and someone is reading the input device or
if hotkey_driver_mask is set.  In this second case, this condition is
not tested after the mask is changed, because the brightness and
volume drivers are started after the hotkey drivers.

Fix tpacpi_hotkey_driver_mask_set() to call hotkey_poll_setup(), so
that the poller kthread will be started when needed.
Reported-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Tested-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: stable@kernel.org

The driver was not starting the NVRAM polling thread if the input
device was bound immediately after registration.

This fixes:
http://bugzilla.kernel.org/show_bug.cgi?id=15118Reported-by: NFlorian Zumbiehl <florz@florz.de>
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: stable@kernel.org

We can stop pestering users for confirmation of the brightness_mode
default for firmware TP-76.

While at it, add a few missing comments in that quirk table.
Reported-by: NWhoopie <whoopie79@gmx.net>
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: stable@kernel.org

Event 0x3006 is used to help power management of the ODD in the
UltraBay.  The EC generates this event when the ODD eject button is
pressed (even if the bay is powered down).

Normally, Linux doesn't need this as we keep the SATA link powered
up (which wastes power).  The EC powers up the bay by itself when the
ODD eject button is pressed, and the SATA PHY reports the hotplug.

However, we could also power that SATA link down (and for that matter,
also power down the Ultrabay) if the ODD is left idle for a while with
no disk inside, and use event 0x3006 to know when we need that SATA link
powered back up.

For now, just stop asking for more information when event 0x3006 is
seen, there is no point in pestering users about it anymore.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: stable@kernel.org

sysfs_remove_group() removed the wrong attribute_group for
thermal_read_mode TPEC_8, ACPI_TMP07 and ACPI_UPDT
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Acked-by: NHenrique de Moraes Holschuh <ibm-acpi@hmh.eng.br>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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>

If we cannot create the ALSA mixer, it is a good reason to fail to
load the volume subdriver, and not to fail to load the entire module.

While at it, add more debugging messages, as the error paths are being
used a lot more than I'd expect, and it is failing to set up the ALSA
mixer on a number of ThinkPads.
Reported-by: NPeter Jordan <usernetwork@gmx.info>
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

We don't want to be the first soundcard.  We don't want to shift other
soundcards out of the way either, even if they load much later.

Ask ALSA to (by default) load us in one of the last three slots.  This
can be overriden at will using the "index" parameter.
Reported-by: NWhoopie <whoopie79@gmx.net>
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Take advantage of the new events capabilities of the backlight class to
notify userspace of backlight changes.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

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

Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>