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

ACPI / LPSS: Only call pwm_add_table() for the first PWM controller

2017-08-11T15:33:49+00:00

commit dd242a080d178c36442a0bb28b6acf6f126d0569 upstream.

At least on the UP board SBC both PWMs are enabled leading to us
trying to add the same pwm_lookup twice, which leads to the following:

[    0.902224] list_add double add: new=ffffffffb8efd400,
               prev=ffffffffb8efd400, next=ffffffffb8eeede0.
[    0.912466] ------------[ cut here ]------------
[    0.917624] kernel BUG at lib/list_debug.c:31!
[    0.922588] invalid opcode: 0000 [#1] SMP
...
[    1.027450] Call Trace:
[    1.030185]  pwm_add_table+0x4c/0x90
[    1.034181]  bsw_pwm_setup+0x1a/0x20
[    1.038175]  acpi_lpss_create_device+0xfe/0x420
...

This commit fixes this by only calling pwm_add_table() for the first
PWM controller (which is the one used for the backlight).

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1458599
Fixes: bf7696a12071 (acpi: lpss: call pwm_add_table() for BSW...)
Fixes: 04434ab5120a (ACPI / LPSS: Call pwm_add_table() for Bay Trail...)
Signed-off-by: Hans de Goede 
Acked-by: Andy Shevchenko 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

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

2017-07-27T22:10:23+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:10:18+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:10:18+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

ACPI / scan: Fix enumeration for special SPI and I2C devices

2017-06-21T21:14:55+00:00

Commit f406270bf73d ("ACPI / scan: Set the visited flag for all
enumerated devices") caused that two group of special SPI or I2C
devices do not enumerate. SPI and I2C devices are expected to be
enumerated by the SPI and I2C subsystems but change caused that
acpi_bus_attach() marks those devices with acpi_device_set_enumerated().

First group of devices are matched using Device Tree compatible property
with special _HID "PRP0001". Those devices have matched scan handler,
acpi_scan_attach_handler() retuns 1 and acpi_bus_attach() marks them
with acpi_device_set_enumerated().

Second group of devices without valid _HID such as "LNXVIDEO" have
device->pnp.type.platform_id set to zero and change again marks them
with acpi_device_set_enumerated().

Fix this by flagging the SPI and I2C devices during struct acpi_device
object initialization time and let the code in acpi_bus_attach() to go
through the device_attach() and acpi_default_enumeration() path for all
SPI and I2C devices.

Fixes: f406270bf73d (ACPI / scan: Set the visited flag for all enumerated devices)
Signed-off-by: Jarkko Nikula 
Acked-by: Mika Westerberg 
Cc: 4.11+  # 4.11+
Signed-off-by: Rafael J. Wysocki

Merge branch 'acpica-fixes'

2017-06-14T23:52:32+00:00

* acpica-fixes:
  ACPICA: Tables: Mechanism to handle late stage acpi_get_table() imbalance
  Revert "ACPICA: Disassembler: Enhance resource descriptor detection"

ACPICA: Tables: Mechanism to handle late stage acpi_get_table() imbalance

2017-06-12T12:09:29+00:00

Considering this case:

 1. A program opens a sysfs table file 65535 times, it can increase
    validation_count and first increment cause the table to be mapped:

     validation_count = 65535

 2. AML execution causes "Load" to be executed on the same
    table, this time it cannot increase validation_count, so
    validation_count remains:

      validation_count = 65535

 3. The program closes sysfs table file 65535 times, it can decrease
    validation_count and the last decrement cause the table to be
    unmapped:

     validation_count = 0

 4. AML code still accessing the loaded table, kernel crash can be
    observed.

To prevent that from happening, add a validation_count threashold.
When it is reached, the validation_count can no longer be
incremented/decremented to invalidate the table descriptor (means
preventing table unmappings)

Note that code added in acpi_tb_put_table() is actually a no-op but
changes the warning message into a "warn once" one. Lv Zheng.

Signed-off-by: Lv Zheng 
[ rjw: Changelog, comments ]
Signed-off-by: Rafael J. Wysocki

Merge tag 'iommu-fixes-v4.12-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu

2017-06-10T05:30:55+00:00

Pull IOMMU fixes from Joerg Roedel:

 - another compile-fix for my header cleanup

 - a couple of fixes for the recently merged IOMMU probe deferal code

 - fixes for ACPI/IORT code necessary with IOMMU probe deferal

* tag 'iommu-fixes-v4.12-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
  arm: dma-mapping: Reset the device's dma_ops
  ACPI/IORT: Move the check to get iommu_ops from translated fwspec
  ARM: dma-mapping: Don't tear down third-party mappings
  ACPI/IORT: Ignore all errors except EPROBE_DEFER
  iommu/of: Ignore all errors except EPROBE_DEFER
  iommu/of: Fix check for returning EPROBE_DEFER
  iommu/dma: Fix function declaration

Merge branches 'intel_pstate' and 'pm-sleep'

2017-06-08T23:25:16+00:00

* intel_pstate:
  cpufreq: intel_pstate: Avoid division by 0 in min_perf_pct_min()

* pm-sleep:
  Revert "ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle"

Revert "ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle"

2017-06-06T22:57:37+00:00

Revert commit eed4d47efe95 (ACPI / sleep: Ignore spurious SCI wakeups
from suspend-to-idle) as it turned out to be premature and triggered
a number of different issues on various systems.

That includes, but is not limited to, premature suspend-to-RAM aborts
on Dell XPS 13 (9343) reported by Dominik.

The issue the commit in question attempted to address is real and
will need to be taken care of going forward, but evidently more work
is needed for this purpose.

Reported-by: Dominik Brodowski 
Signed-off-by: Rafael J. Wysocki