linux-stable.git/drivers/acpi, branch v3.12.20

ACPICA: Restore code that repairs NULL package elements in return values.

2014-05-15T07:54:49+00:00

commit 61db45ca21630f5ab7f678d54c5d969c21647854 upstream.

The original code was lost accidently, it was not generated along with the
following commit of mechanism improvements and thus not get merged:

  Commit: d5a36100f62fa6db5541344e08b361b34e9114c5
  Subject: ACPICA: Add mechanism for early object repairs on a per-name basis

  Adds the framework to allow object repairs very early in the
  return object analysis. Enables repairs like string->unicode,
  etc.

This patch restores the implementation of the NULL element repair code for
ACPI_RTYPE_NONE.  In the original design, ACPI_RTYPE_NONE is defined to
collect simple NULL object repairs.
Lv Zheng.

Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=67901
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jiri Slaby

ACPI / button: Add ACPI Button event via netlink routine

2014-05-05T12:24:36+00:00

commit 0bf6368ee8f25826d0645c0f7a4f17c8845356a4 upstream.

Commit 1696d9d (ACPI: Remove the old /proc/acpi/event interface)
removed ACPI Button event which originally was sent to userspace via
/proc/acpi/event. This caused ACPI shutdown regression on gentoo
in VirtualBox. Now ACPI events are sent to userspace via netlink,
so add ACPI Button event back via netlink routine.

References: https://bugzilla.kernel.org/show_bug.cgi?id=71721
Reported-and-tested-by: Richard Musil 
Signed-off-by: Lan Tianyu 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jiri Slaby

ACPI / sleep: remove panic in case hardware has changed after S4

2014-05-05T12:21:49+00:00

commit 5c551e624abba6782034edd5b9eb58ac6f146b38 upstream.

Some BIOSes change hardware based on the state of
a laptop's lid. If the lid is closed, the touchpad is
disabled and the checksum changes. Windows 8 no longer
aborts resume if the checksum has changed.

Signed-off-by: Oliver Neukum 
[rjw: Use pr_crit() for the message and don't break the string]
Signed-off-by: Rafael J. Wysocki 

Signed-off-by: Jiri Slaby

ACPI / EC: Process rather than discard events in acpi_ec_clear

2014-05-05T09:38:42+00:00

commit 3eba563e280101209bad27d40bfc83ddf1489234 upstream.

Address a regression caused by commit ad332c8a4533:
(ACPI / EC: Clear stale EC events on Samsung systems)

After the earlier patch, there was found to be a race condition on some
earlier Samsung systems (N150/N210/N220). The function acpi_ec_clear was
sometimes discarding a new EC event before its GPE was triggered by the
system. In the case of these systems, this meant that the "lid open"
event was not registered on resume if that was the cause of the wake,
leading to problems when attempting to close the lid to suspend again.

After testing on a number of Samsung systems, both those affected by the
previous EC bug and those affected by the race condition, it seemed that
the best course of action was to process rather than discard the events.
On Samsung systems which accumulate stale EC events, there does not seem
to be any adverse side-effects of running the associated _Q methods.

This patch adds an argument to the static function acpi_ec_sync_query so
that it may be used within the acpi_ec_clear loop in place of
acpi_ec_query_unlocked which was used previously.

With thanks to Stefan Biereigel for reporting the issue, and for all the
people who helped test the new patch on affected systems.

Fixes: ad332c8a4533 (ACPI / EC: Clear stale EC events on Samsung systems)
References: https://lkml.kernel.org/r/532FE3B2.9060808@biereigel-wb.de
References: https://bugzilla.kernel.org/show_bug.cgi?id=44161#c173
Reported-by: Stefan Biereigel 
Signed-off-by: Kieran Clancy 
Tested-by: Stefan Biereigel 
Tested-by: Dennis Jansen 
Tested-by: Nicolas Porcel 
Tested-by: Maurizio D'Addona 
Tested-by: Juan Manuel Cabo 
Tested-by: Giannis Koutsou 
Tested-by: Kieran Clancy 
Cc: 3.14+  # 3.14+
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jiri Slaby

ACPI / sleep: Add extra checks for HW Reduced ACPI mode sleep states

2014-03-22T21:01:58+00:00

commit a4e90bed511220ff601d064c9e5d583e91308f65 upstream.

If the HW Reduced ACPI mode bit is set in the FADT, ACPICA uses
the optional sleep control and sleep status registers for making
the system enter sleep states (including S5), so it is not possible
to use system sleep states or power it off using ACPI if the HW
Reduced ACPI mode bit is set and those registers are not available.

For this reason, add a new function, acpi_sleep_state_supported(),
checking if the HW Reduced ACPI mode bit is set and whether or not
system sleep states are usable in that case in addition to checking
the return value of acpi_get_sleep_type_data() and make the ACPI
sleep setup routines use that function to check the availability of
system sleep states.

Among other things, this prevents the kernel from attempting to
use ACPI for powering off HW Reduced ACPI systems without the sleep
control and sleep status registers, because ACPI power off doesn't
have a chance to work on them.  That allows alternative power off
mechanisms that may actually work to be used on those systems.  The
affected machines include Dell Venue 8 Pro, Asus T100TA, Haswell
Desktop SDP and Ivy Bridge EP Demo depot.

References: https://bugzilla.kernel.org/show_bug.cgi?id=70931
Reported-by: Adam Williamson 
Tested-by: Aubrey Li 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jiri Slaby

ACPI / EC: Clear stale EC events on Samsung systems

2014-03-22T21:01:56+00:00

commit ad332c8a45330d170bb38b95209de449b31cd1b4 upstream.

A number of Samsung notebooks (530Uxx/535Uxx/540Uxx/550Pxx/900Xxx/etc)
continue to log events during sleep (lid open/close, AC plug/unplug,
battery level change), which accumulate in the EC until a buffer fills.
After the buffer is full (tests suggest it holds 8 events), GPEs stop
being triggered for new events. This state persists on wake or even on
power cycle, and prevents new events from being registered until the EC
is manually polled.

This is the root cause of a number of bugs, including AC not being
detected properly, lid close not triggering suspend, and low ambient
light not triggering the keyboard backlight. The bug also seemed to be
responsible for performance issues on at least one user's machine.

Juan Manuel Cabo found the cause of bug and the workaround of polling
the EC manually on wake.

The loop which clears the stale events is based on an earlier patch by
Lan Tianyu (see referenced attachment).

This patch:
 - Adds a function acpi_ec_clear() which polls the EC for stale _Q
   events at most ACPI_EC_CLEAR_MAX (currently 100) times. A warning is
   logged if this limit is reached.
 - Adds a flag EC_FLAGS_CLEAR_ON_RESUME which is set to 1 if the DMI
   system vendor is Samsung. This check could be replaced by several
   more specific DMI vendor/product pairs, but it's likely that the bug
   affects more Samsung products than just the five series mentioned
   above. Further, it should not be harmful to run acpi_ec_clear() on
   systems without the bug; it will return immediately after finding no
   data waiting.
 - Runs acpi_ec_clear() on initialisation (boot), from acpi_ec_add()
 - Runs acpi_ec_clear() on wake, from acpi_ec_unblock_transactions()

References: https://bugzilla.kernel.org/show_bug.cgi?id=44161
References: https://bugzilla.kernel.org/show_bug.cgi?id=45461
References: https://bugzilla.kernel.org/show_bug.cgi?id=57271
References: https://bugzilla.kernel.org/attachment.cgi?id=126801
Suggested-by: Juan Manuel Cabo 
Signed-off-by: Kieran Clancy 
Reviewed-by: Lan Tianyu 
Reviewed-by: Dennis Jansen 
Tested-by: Kieran Clancy 
Tested-by: Juan Manuel Cabo 
Tested-by: Dennis Jansen 
Tested-by: Maurizio D'Addona 
Tested-by: San Zamoyski 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jiri Slaby

ACPI / resources: ignore invalid ACPI device resources

2014-03-22T21:01:56+00:00

commit b355cee88e3b1a193f0e9a81db810f6f83ad728b upstream.

ACPI table may export resource entry with 0 length.
But the current code interprets this kind of resource in a wrong way.
It will create a resource structure with
res->end = acpi_resource->start + acpi_resource->len - 1;

This patch fixes a problem on my machine that a platform device fails
to be created because one of its ACPI IO resource entry (start = 0,
end = 0, length = 0) is translated into a generic resource with
start = 0, end = 0xffffffff.

Signed-off-by: Zhang Rui 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jiri Slaby

ACPI: update win8 OSI blacklist

2014-03-12T08:36:05+00:00

commit b4cb9244a544a1623305eb58267a90418268d31e upstream.

More people have reported they need this for their machines to work
correctly.

References: https://bugzilla.kernel.org/show_bug.cgi?id=60682
Reported-by: Stefan Hellermann 
Reported-by: Benedikt Sauer 
Reported-by: Erno Kuusela 
Reported-by: Jonathan Doman 
Reported-by: Christoph Klaffl 
Reported-by: Jan Hendrik Nielsen 
Signed-off-by: Felipe Contreras 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jiri Slaby

ACPI / processor: Rework processor throttling with work_on_cpu()

2014-03-05T16:13:48+00:00

commit f3ca4164529b875374c410193bbbac0ee960895f upstream.

acpi_processor_set_throttling() uses set_cpus_allowed_ptr() to make
sure that the (struct acpi_processor)->acpi_processor_set_throttling()
callback will run on the right CPU.  However, the function may be
called from a worker thread already bound to a different CPU in which
case that won't work.

Make acpi_processor_set_throttling() use work_on_cpu() as appropriate
instead of abusing set_cpus_allowed_ptr().

Reported-and-tested-by: Jiri Olsa 
Signed-off-by: Lan Tianyu 
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jiri Slaby

ACPI / video: Filter the _BCL table for duplicate brightness values

2014-03-05T16:13:47+00:00

commit bd8ba20597f0cfef3ef65c3fd2aa92ab23d4c8e1 upstream.

Some devices have duplicate entries in there brightness levels table, ie
on my Dell Latitude E6430 the table looks like this:

[    3.686060] acpi backlight index   0, val 80
[    3.686095] acpi backlight index   1, val 50
[    3.686122] acpi backlight index   2, val 5
[    3.686147] acpi backlight index   3, val 5
[    3.686172] acpi backlight index   4, val 5
[    3.686197] acpi backlight index   5, val 5
[    3.686223] acpi backlight index   6, val 5
[    3.686248] acpi backlight index   7, val 5
[    3.686273] acpi backlight index   8, val 6
[    3.686332] acpi backlight index   9, val 7
[    3.686356] acpi backlight index  10, val 8
[    3.686380] acpi backlight index  11, val 9
etc.

Notice that brightness values 0-5 are all mapped to 5. This means that
if userspace writes any value between 0 and 5 to the brightness sysfs attribute
and then reads it, it will always return 0, which is somewhat unexpected.

This is a problem for ie gnome-settings-daemon, which uses read-modify-write
logic when the users presses the brightness up or down keys. This is done
this way to take brightness changes from other sources into account.

On this specific laptop what happens once the brightness has been set to 0,
is that gsd reads 0, adds 5, writes 5, and on the next brightness up key press
again reads 0, so things get stuck at the lowest brightness setting.

Filtering out the duplicate table entries, makes any write to brightness
read back as the written value as one would expect, fixing this.

Signed-off-by: Hans de Goede 
Reviewed-by: Aaron Lu 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jiri Slaby