linux-toradex.git/drivers/acpi, branch v4.9.41

ACPI / scan: Prefer devices without _HID/_CID for _ADR matching

2017-08-07T01:59:47+00:00

[ Upstream commit c2a6bbaf0c5f90463a7011a295bbdb7e33c80b51 ]

The way acpi_find_child_device() works currently is that, if there
are two (or more) devices with the same _ADR value in the same
namespace scope (which is not specifically allowed by the spec and
the OS behavior in that case is not defined), the first one of them
found to be present (with the help of _STA) will be returned.

This covers the majority of cases, but is not sufficient if some of
the devices in question have a _HID (or _CID) returning some valid
ACPI/PNP device IDs (which is disallowed by the spec) and the
ASL writers' expectation appears to be that the OS will match
devices without a valid ACPI/PNP device ID against a given bus
address first.

To cover this special case as well, modify find_child_checks()
to prefer devices without ACPI/PNP device IDs over devices that
have them.

Suggested-by: Mika Westerberg 
Signed-off-by: Rafael J. Wysocki 
Tested-by: Hans de Goede 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

acpi/nfit: Fix memory corruption/Unregister mce decoder on failure

2017-07-27T22:08:07+00:00

commit 7e700d2c59e5853c9126642976b4f5768f64c9b3 upstream.

nfit_init() calls nfit_mce_register() on module load.  When the module
load fails the nfit mce decoder is not unregistered.  The module's
memory is freed leaving the decoder chain referencing junk.  This will
cause panics as future registrations will reference the free'd memory.

Unregister the nfit mce decoder on module init failure.

[v2]: register and then unregister mce handler to avoid losing mce events
[v3]: also cleanup nfit workqueue

Fixes: 6839a6d96f4e ("nfit: do an ARS scrub on hitting a latent media error")
Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
Cc: Vishal Verma 
Cc: "Lee, Chun-Yi" 
Cc: Linda Knippers 
Cc: lszubowi@redhat.com
Acked-by: Jeff Moyer 
Signed-off-by: Prarit Bhargava 
Reviewed-by: Vishal Verma 
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman

Revert "ACPI / EC: Enable event freeze mode..." to fix a regression

2017-07-27T22:08:04+00:00

commit 9c40f956ce9b331493347d1b3cb7e384f7dc0581 upstream.

On Lenovo ThinkPad X1 Carbon - the 5th Generation, enabling an earlier
EC event freezing timing causes acpitz-virtual-0 to report a stuck
48C temparature.  And with EC firmware revisioned as 1.14, without
reverting back to old EC event freezing timing, the fan still blows
up after a system resume.

This reverts the culprit change so that the regression can be fixed
without upgrading the EC firmware.

Fixes: d30283057ecd (ACPI / EC: Enable event freeze mode to improve event handling)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=191181#c168
Tested-by: Damjan Georgievski 
Signed-off-by: Lv Zheng 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI / EC: Drop EC noirq hooks to fix a regression

2017-07-27T22:08:04+00:00

commit 662591461c4b9a1e3b9b159dbf37648a585ebaae upstream.

According to bug reports, although the busy polling mode can make
noirq stages execute faster, it causes abnormal fan blowing up after
system resume (see the first link below for a video demonstration)
on Lenovo ThinkPad X1 Carbon - the 5th Generation.  The problem can
be fixed by upgrading the EC firmware on that machine.

However, many reporters confirm that the problem can be fixed by
stopping busy polling during suspend/resume and for some of them
upgrading the EC firmware is not an option.

For this reason, drop the noirq stage hooks from the EC driver
to fix the regression.

Fixes: c3a696b6e8f8 (ACPI / EC: Use busy polling mode when GPE is not enabled)
Link: https://youtu.be/9NQ9x-Jm99Q
Link: https://bugzilla.kernel.org/show_bug.cgi?id=196129
Reported-by: Andreas Lindhe 
Tested-by: Gjorgji Jankovski 
Tested-by: Damjan Georgievski 
Tested-by: Fernando Chaves 
Tested-by: Tomislav Ivek 
Tested-by: Denis P. 
Signed-off-by: Lv Zheng 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

Revert "ACPI / button: Change default behavior to lid_init_state=open"

2017-06-07T10:07:47+00:00

commit 878d8db039daac0938238e9a40a5bd6e50ee3c9b upstream.

Revert commit 77e9a4aa9de1 (ACPI / button: Change default behavior to
lid_init_state=open) which changed the kernel's behavior on laptops
that boot with closed lids and expect the lid switch state to be
reported accurately by the kernel.

If you boot or resume your laptop with the lid closed on a docking
station while using an external monitor connected to it, both internal
and external displays will light on, while only the external should.

There is a design choice in gdm to only provide the greeter on the
internal display when lit on, so users only see a gray area on the
external monitor. Also, the cursor will not show up as it's by
default on the internal display too.

To "fix" that, users have to open the laptop once and close it once
again to sync the state of the switch with the hardware state.

Even if the "method" operation mode implementation can be buggy on
some platforms, the "open" choice is worse.  It breaks docking
stations basically and there is no way to have a user-space hwdb to
fix that.

On the contrary, it's rather easy in user-space to have a hwdb
with the problematic platforms. Then,  libinput (1.7.0+) can fix
the state of the lid switch for us: you need to set the udev
property LIBINPUT_ATTR_LID_SWITCH_RELIABILITY to 'write_open'.

When libinput detects internal keyboard events, it will overwrite the
state of the switch to open, making it reliable again.  Given that
logind only checks the lid switch value after a timeout, we can
assume the user will use the internal keyboard before this timeout
expires.

For example, such a hwdb entry is:

libinput:name:*Lid Switch*:dmi:*svnMicrosoftCorporation:pnSurface3:*
 LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=write_open

Link: https://bugzilla.gnome.org/show_bug.cgi?id=782380
Signed-off-by: Benjamin Tissoires 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

acpi, nfit: Fix the memory error check in nfit_handle_mce()

2017-06-07T10:07:47+00:00

commit fc08a4703a418a398bbb575ac311d36d110ac786 upstream.

The check for an MCE being a memory error in the NFIT mce handler was
bogus. Use the new mce_is_memory_error() helper to detect the error
properly.

Reported-by: Tony Luck 
Signed-off-by: Vishal Verma 
Signed-off-by: Borislav Petkov 
Link: http://lkml.kernel.org/r/20170519093915.15413-3-bp@alien8.de
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

ACPI / power: Avoid maybe-uninitialized warning

2017-04-27T07:10:38+00:00

commit fe8c470ab87d90e4b5115902dd94eced7e3305c3 upstream.

gcc -O2 cannot always prove that the loop in acpi_power_get_inferred_state()
is enterered at least once, so it assumes that cur_state might not get
initialized:

drivers/acpi/power.c: In function 'acpi_power_get_inferred_state':
drivers/acpi/power.c:222:9: error: 'cur_state' may be used uninitialized in this function [-Werror=maybe-uninitialized]

This sets the variable to zero at the start of the loop, to ensure that
there is well-defined behavior even for an empty list. This gets rid of
the warning.

The warning first showed up when the -Os flag got removed in a bug fix
patch in linux-4.11-rc5.

I would suggest merging this addon patch on top of that bug fix to avoid
introducing a new warning in the stable kernels.

Fixes: 61b79e16c68d (ACPI: Fix incompatibility with mcount-based function graph tracing)
Signed-off-by: Arnd Bergmann 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI / EC: Use busy polling mode when GPE is not enabled

2017-04-21T07:31:24+00:00

commit c3a696b6e8f8f75f9f75e556a9f9f6472eae2655 upstream.

When GPE is not enabled, it is not efficient to use the wait polling mode
as it introduces an unexpected scheduler delay.
So before the GPE handler is installed, this patch uses busy polling mode
for all EC(s) and the logic can be applied to non boot EC(s) during the
suspend/resume process.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=191561
Tested-by: Jakobus Schurz 
Tested-by: Chen Yu 
Signed-off-by: Lv Zheng 
Signed-off-by: Rafael J. Wysocki 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

ACPI / scan: Set the visited flag for all enumerated devices

2017-04-21T07:31:20+00:00

commit f406270bf73d71ea7b35ee3f7a08a44f6594c9b1 upstream.

Commit 10c7e20b2ff3 (ACPI / scan: fix enumeration (visited) flags for
bus rescans) attempted to fix a problem with ACPI-based enumerateion
of I2C/SPI devices, but it forgot to ensure that the visited flag
will be set for all of the other enumerated devices, so fix that.

Fixes: 10c7e20b2ff3 (ACPI / scan: fix enumeration (visited) flags for bus rescans)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=194885
Reported-and-tested-by: Kevin Locke 
Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Mika Westerberg 
Signed-off-by: Greg Kroah-Hartman

acpi, nfit, libnvdimm: fix interleave set cookie calculation (64-bit comparison)

2017-04-21T07:31:20+00:00

commit b03b99a329a14b7302f37c3ea6da3848db41c8c5 upstream.

While reviewing the -stable patch for commit 86ef58a4e35e "nfit,
libnvdimm: fix interleave set cookie calculation" Ben noted:

    "This is returning an int, thus it's effectively doing a 32-bit
     comparison and not the 64-bit comparison you say is needed."

Update the compare operation to be immune to this integer demotion problem.

Cc: Nicholas Moulin 
Fixes: 86ef58a4e35e ("nfit, libnvdimm: fix interleave set cookie calculation")
Reported-by: Ben Hutchings 
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman