BMC/Intel-BMC/linux.git/drivers/acpi, branch dev-4.17

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

2018-08-22T05:44:54+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

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

2018-08-03T05:48:06+00:00

commit 460a53106ac39b74625d1104d9a113e0f3716c18 upstream. 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 Signed-off-by: Greg Kroah-Hartman

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

2018-08-03T05:48:06+00:00

commit 12864ff8545f6b8144fdf1bb89b5663357f29ec4 upstream. 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 Signed-off-by: Greg Kroah-Hartman

ACPI / LPSS: Only call pwm_add_table() for Bay Trail PWM if PMIC HRV is 2

2018-08-03T05:47:53+00:00

[ Upstream commit c975e472ec12392a0c34de1350e634310f8a1dea ] The Point of View mobii wintab p800w Bay Trail tablet comes with a Crystal Cove PMIC, yet uses the LPSS PWM for backlight control, rather then the Crystal Cove's PWM, so we need to call pwm_add_table() to add a pwm_backlight mapping for the LPSS pwm despite there being an INT33FD ACPI device present. On all Bay Trail devices the _HRV object of the INT33FD ACPI device will normally return 2, to indicate the Bay Trail variant of the CRC PMIC is present, except on this tablet where _HRV is 0xffff. I guess this is a hack to make the windows Crystal Cove PWM driver not bind. Out of the 44 DSTDs with an INT33FD device in there which I have (from different model devices) only the pov mobii wintab p800w uses 0xffff for the HRV. The byt_pwm_setup code calls acpi_dev_present to check for the presence of a INT33FD ACPI device which indicates that a CRC PMIC is present and if the INT33FD ACPI device is present then byt_pwm_setup will not add a pwm_backlight mapping for the LPSS pwm, so that the CRC PWM will get used instead. acpi_dev_present has a hrv parameter, this commit make us pass 2 instead of -1, so that things still match on normal tablets, but on this special case with its _HRV of 0xffff, the check will now fail so that the pwm_backlight mapping for the LPSS pwm gets added fixing backlight brightness control on this device. Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

PCI: pciehp: Request control of native hotplug only if supported

2018-08-03T05:47:46+00:00

[ Upstream commit 408fec36a1ab3d14273c2116b449ef1e9be3cb8b ] Currently we request control of native PCIe hotplug unconditionally. Native PCIe hotplug events are handled by the pciehp driver, and if it is not enabled those events will be lost. Request control of native PCIe hotplug only if the pciehp driver is enabled, so we will actually handle native PCIe hotplug events. Suggested-by: Bjorn Helgaas Signed-off-by: Mika Westerberg Signed-off-by: Bjorn Helgaas Reviewed-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

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

2018-07-28T05:57:17+00:00

commit 73c2a01c52b657f4a0ead6c95f64c5279efbd000 upstream. 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 Signed-off-by: Greg Kroah-Hartman

acpi, nfit: Fix scrub idle detection

2018-07-17T09:48:30+00:00

commit 33cc2c9667561b224215e6dfb5bf98e8fa17914e upstream. The notification of scrub completion happens within the scrub workqueue. That can clearly race someone running scrub_show() and work_busy() before the workqueue has a chance to flush the recently completed work. Add a flag to reliably indicate the idle vs busy state. Without this change applications using poll(2) to wait for scrub-completion may falsely wakeup and read ARS as being busy even though the thread is going idle and then hang indefinitely. Fixes: bc6ba8085842 ("nfit, address-range-scrub: rework and simplify ARS...") Cc: Reported-by: Vishal Verma Tested-by: Vishal Verma Reported-by: Lukasz Dorau Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman

ACPICA: Clear status of all events when entering S5

2018-07-17T09:48:23+00:00

commit fa85015c0d95884c8dc42f38e2f2d6137d436b67 upstream. After commit 18996f2db918 (ACPICA: Events: Stop unconditionally clearing ACPI IRQs during suspend/resume) the status of ACPI events is not cleared any more when entering the ACPI S5 system state (power off) which causes some systems to power up immediately after turing off power in certain situations. That is a functional regression, so address it by making the code clear the status of all ACPI events again when entering S5 (for system-wide suspend or hibernation the clearing of the status of all events is not desirable, as it might cause the kernel to miss wakeup events sometimes). Fixes: 18996f2db918 (ACPICA: Events: Stop unconditionally clearing ACPI IRQs during suspend/resume) Reported-by: Takashi Iwai Tested-by: Thomas Hänig Cc: 4.17+ # 4.17+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI / battery: Safe unregistering of hooks

2018-07-11T14:31:24+00:00

commit 673b4271665a12fa839a12abb50e6f6e9953c081 upstream. A hooking API was implemented for 4.17 in fa93854f7a7ed63d followed by hooks for Thinkpad laptops in 2801b9683f740012. The Thinkpad drivers did not support the Thinkpad 13 and the hooking API crashes on unsupported batteries by altering a list of hooks during unsafe iteration. Thus, Thinkpad 13 laptops could no longer boot. Additionally, a lock was kept in place and debugging information was printed out of order. Fixes: fa93854f7a7e (battery: Add the battery hooking API) Cc: 4.17+ # 4.17+ Signed-off-by: Jouke Witteveen Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPICA: Drop leading newlines from error messages

2018-07-11T14:31:24+00:00

commit a0d5f3b69af7733f3173a8e19d51f68a08017c76 upstream. Commit 5088814a6e93 (ACPICA: AML parser: attempt to continue loading table after error) unintentionally added leading newlines to error messages emitted by ACPICA which caused unexpected things to be printed to the kernel log. Drop these newlines (which effectively reverts the part of commit 5088814a6e93 adding them). Fixes: 5088814a6e93 (ACPICA: AML parser: attempt to continue loading table after error) Reported-by: Toralf Förster Reported-by: Guenter Roeck Cc: 4.17+ # 4.17+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman