linux-stable.git/drivers/acpi, branch v4.18.8

ACPI / scan: Initialize status to ACPI_STA_DEFAULT

2018-09-15T07:46:52+00:00

[ Upstream commit 5971b0c1594d6c34e257101ed5fdffec65205c50 ]

Since commit 63347db0affa "ACPI / scan: Use acpi_bus_get_status() to
initialize ACPI_TYPE_DEVICE devs" the status field of normal acpi_devices
gets set to 0 by acpi_bus_type_and_status() and filled with its actual
value later when acpi_add_single_object() calls acpi_bus_get_status().

This means that any acpi_match_device_ids() calls in between will always
fail with -ENOENT.

We already have a workaround for this, which temporary forces status to
ACPI_STA_DEFAULT in drivers/acpi/x86/utils.c: acpi_device_always_present()
and the next commit in this series adds another acpi_match_device_ids()
call between status being initialized as 0 and the acpi_bus_get_status()
call.

Rather then adding another workaround, this commit makes
acpi_bus_type_and_status() initialize status to ACPI_STA_DEFAULT, this is
safe to do as the only code looking at status between the initialization
and the acpi_bus_get_status() call is those acpi_match_device_ids() calls.

Note this does mean that we need to (re)set status to 0 in case the
acpi_bus_get_status() call fails.

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

ACPICA: ACPICA: add status check for acpi_hw_read before assigning return value

2018-09-15T07:46:49+00:00

[ Upstream commit f016b19a9275089a2ab06c2144567c2ad8d5d6ad ]

The value coming from acpi_hw_read() should not be used if it
returns an error code, so check the status returned by it before
using that value in two places in acpi_hw_register_read().

Reported-by: Mark Gross 
Signed-off-by: Erik Schmauss 
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

ACPICA: Clear status of all events when entering sleep states

2018-09-09T08:32:36+00:00

commit f317c7dc12b73eb9d67fdae404563deb907dcfb7 upstream.

Commit fa85015c0d95 (ACPICA: Clear status of all events when entering
S5) made the sleep state entry code in ACPICA clear the status of all
ACPI events when entering S5 to fix a functional regression reported
against commit 18996f2db918 (ACPICA: Events: Stop unconditionally
clearing ACPI IRQs during suspend/resume).  However, it is reported
now that the regression also affects system states other than S5 on
some systems and causes them to wake up from sleep prematurely.

For this reason, make the code in question clear the status of all
ACPI events when entering all sleep states (in addition to S5) to
avoid the premature wakeups (this may cause some wakeup events to
be missed in theory, but the likelihood of that is small and the
change here simply restores the previous behavior of the code).

Fixes: 18996f2db918 (ACPICA: Events: Stop unconditionally clearing ACPI IRQs during suspend/resume)
Reported-by: Paul Menzel 
Tested-by: Paul Menzel 
Cc: 4.17+  # 4.17+: fa85015c0d95 ACPICA: Clear status ...
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPICA: AML Parser: skip opcodes that open a scope upon parse failure

2018-09-09T08:32:36+00:00

commit 4a7c94c721074eafb27298d93dbcc339aa28e745 upstream.

This change skips the entire length of opcodes that open a scope
(Device, Scope, Processor, etc) if the creation of the op fails. The
failure could be caused by various errors including AE_ALREADY_EXISTS
and AE_NOT_FOUND.

Reported-by: Jeremy Linton 
Tested-by: Jeremy Linton 
Signed-off-by: Erik Schmauss 
Cc: 4.17+  # 4.17+
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI / PM: save NVS memory for ASUS 1025C laptop

2018-08-22T05:43:42+00:00

commit 231f9415001138a000cd0f881c46654b7ea3f8c5 upstream.

Every time I tried to upgrade my laptop from 3.10.x to 4.x I faced an
issue by which the fan would run at full speed upon resume. Bisecting
it showed me the issue was introduced in 3.17 by commit 821d6f0359b0
(ACPI / sleep: Do not save NVS for new machines to accelerate S3). This
code only affects machines built starting as of 2012, but this Asus
1025C laptop was made in 2012 and apparently needs the NVS data to be
saved, otherwise the CPU's thermal state is not properly reported on
resume and the fan runs at full speed upon resume.

Here's a very simple way to check if such a machine is affected :

  # cat /sys/class/thermal/thermal_zone0/temp
  55000

  ( now suspend, wait one second and resume )

  # cat /sys/class/thermal/thermal_zone0/temp
  0

  (and after ~15 seconds the fan starts to spin)

Let's apply the same quirk as commit cbc00c13 (ACPI: save NVS memory
for Lenovo G50-45) and reuse the function it provides. Note that this
commit was already backported to 4.9.x but not 4.4.x.

Cc: 3.17+  # 3.17+: requires cbc00c13
Signed-off-by: Willy Tarreau 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

Merge branch 'acpi-soc'

2018-07-31T08:35:47+00:00

Merge a fix for hibernation regression in the ACPI driver for Intel
SoCs (LPSS).

* acpi-soc:
  ACPI / LPSS: Avoid PM quirks on suspend and resume from hibernation

ACPICA: AML Parser: ignore control method status in module-level code

2018-07-29T10:19:45+00:00

Previous change in the AML parser code blindly set all non-successful
dispatcher statuses to AE_OK. That approach is incorrect, though,
because successful control method invocations from module-level
return AE_CTRL_TRANSFER. Overwriting AE_OK to this status causes the
AML parser to think that there was no return value from the control
method invocation.

Fixes: 92c0f4af386 (ACPICA: AML Parser: ignore dispatcher error status during table load)
Reported-by: Linus Torvalds 
Tested-by: Linus Torvalds 
Tested-by: Oleksandr Natalenko 
Signed-off-by: Erik Schmauss 
Signed-off-by: Rafael J. Wysocki

ACPI / LPSS: Avoid PM quirks on suspend and resume from hibernation

2018-07-27T10:23:51+00:00

Commit a09c59130688 (ACPI / LPSS: Avoid PM quirks on suspend and
resume from S3) modified the ACPI driver for Intel SoCs (LPSS) to
avoid applying PM quirks on suspend and resume from S3 to address
system-wide suspend and resume problems on some systems, but it is
reported that the same issue also affects hibernation, so extend
the approach used by that commit to cover hibernation as well.

Fixes: a09c59130688 (ACPI / LPSS: Avoid PM quirks on suspend and resume from S3)
Link: https://bugs.launchpad.net/bugs/1774950
Reported-by: Kai-Heng Feng 
Cc: 4.15+  # 4.15+
Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Mika Westerberg

ACPICA: AML Parser: ignore dispatcher error status during table load

2018-07-23T11:39:33+00:00

The dispatcher and the executer process the parse nodes During table
load. Error status from the evaluation confuses the AML parser. This
results in the parser failing to complete parsing of the current
scope op which becomes problematic. For the incorrect AML below, _ADR
never gets created.

definition_block(...)
{
   Scope (\_SB)
   {
     Device (PCI0){...}
     Name (OBJ1, 0x0)
     OBJ1 = PCI0 + 5 // Results in an operand error.
   } // \_SB not closed

   // parser looks for \_SB._SB.PCI0, results in AE_NOT_FOUND error
   // Entire scope block gets skipped.
   Scope (\_SB.PCI0)
   {
       Name (_ADR, 0x0)
   }
}

Fix the above error by properly completing the initial \_SB scope
after an error by clearing errors that occur during table load. In
the above case, this means that OBJ1 = PIC0 + 5 is skipped.

Fixes: 5088814a6e93 (ACPICA: AML parser: attempt to continue loading table after error)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=200363
Tested-by: Bastien Nocera 
Signed-off-by: Erik Schmauss 
Cc: 4.17+  # 4.17+
Signed-off-by: Rafael J. Wysocki

ACPI / EC: Use ec_no_wakeup on more Thinkpad X1 Carbon 6th systems

2018-07-19T14:42:15+00:00

The ec_no_wakeup matcher added for Thinkpad X1 Carbon 6th gen systems
beyond matched only a single DMI model (20KGS3JF01), that didn't cover
my laptop (20KH002JUS). Change to match based on DMI product family to
cover all X1 6th gen systems.

Signed-off-by: Robin H. Johnson 
Signed-off-by: Rafael J. Wysocki