summaryrefslogtreecommitdiff
path: root/drivers/acpi/ec.c
AgeCommit message (Collapse)Author
2019-08-21ACPI: PM: s2idle: Always set up EC GPE for system wakeupRafael J. Wysocki
Commit 10a08fd65ec1 ("ACPI: PM: Set up EC GPE for system wakeup from drivers that need it") assumed that the EC GPE would only need to be set up for system wakeup if either the intel-hid or the intel-vbtn driver was in use, but that turns out to be incorrect. In particular, on ASUS Zenbook UX430UNR/i7-8550U, if the EC GPE is not enabled while suspended, the system cannot be woken up by opening the lid or pressing a key, and that machine doesn't use any of the drivers mentioned above. For this reason, always set up the EC GPE for system wakeup from suspend-to-idle by setting and clearing its wake mask in the ACPI suspend-to-idle callbacks. Fixes: 10a08fd65ec1 ("ACPI: PM: Set up EC GPE for system wakeup from drivers that need it") Reported-by: Kristian Klausen <kristian@klausen.dk> Tested-by: Kristian Klausen <kristian@klausen.dk> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-08-08ACPI: EC: PM: Make acpi_ec_dispatch_gpe() print debug messageRafael J. Wysocki
Add a pm_pr_dbg() debug statement to acpi_ec_dispatch_gpe() to print a message when the EC GPE has been dispatched (because its status was set). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
2019-08-08ACPI: EC: PM: Consolidate some code depending on PM_SLEEPRafael J. Wysocki
Move some routines, including acpi_ec_dispatch_gpe(), that are only used if CONFIG_PM_SLEEP is set to the #ifdef block containing the EC suspend and resume callbacks, to make the "full EC PM picture" easier to follow. While at it, move the header of acpi_ec_dispatch_gpe() in the header file to a CONFIG_PM_SLEEP #ifdef block. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
2019-08-08ACPI: PM: s2idle: Eliminate acpi_sleep_no_ec_events()Rafael J. Wysocki
Change acpi_ec_suspend() to use pm_suspend_no_platform() instead of acpi_sleep_no_ec_events(), which allows the latter to be eliminated along with the s2idle_in_progress variable which is only used by it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
2019-08-08ACPI: PM: s2idle: Switch EC over to polling during "noirq" suspendRafael J. Wysocki
Since the ACPI SCI is set up for system wakeup before the "noirq" suspend of devices, it is better to make suspend-to-idle follow suspend-to-RAM (S3) and switch over the EC to polling during "noirq" suspend (and back to interrupt-based flow during "noirq" resume). The frequency of spurious wakeup interrupts from the EC may be reduced this way. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
2019-07-30ACPI: PM: Set up EC GPE for system wakeup from drivers that need itRafael J. Wysocki
The EC GPE needs to be set up for system wakeup only if there is a driver depending on it, either intel-hid or intel-vbtn, bound to a button device that is expected to wake up the system from sleep (such as the power button on some Dell systems, like the XPS13 9360). It doesn't need to be set up for waking up the system from sleep in any other cases and whether or not it is expected to wake up the system from sleep doesn't depend on whether or not the LPS0 device is present in the ACPI namespace. For this reason, rearrange the ACPI suspend-to-idle code to make the drivers depending on the EC GPE wakeup take care of setting it up and decouple that from the LPS0 device handling. While at it, make intel-hid and intel-vbtn prepare for system wakeup only if they are allowed to wake up the system from sleep by user space (via sysfs). [Note that acpi_ec_mark_gpe_for_wake() and acpi_ec_set_gpe_wake_mask() are there to prevent the EC GPE from being disabled by the acpi_enable_all_wakeup_gpes() call in acpi_s2idle_prepare(), so on systems with either intel-hid or intel-vbtn this change doesn't affect any interactions with the hardware or platform firmware.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
2019-07-23ACPI: EC: Return bool from acpi_ec_dispatch_gpe()Rafael J. Wysocki
On some systems, if suspend-to-idle is used, the EC may signal system wakeup events (power button events, for example) as well as events that should not cause the system to resume and acpi_ec_dispatch_gpe() needs to be called to determine whether or not the system should resume then. In particular, if acpi_ec_dispatch_gpe() doesn't detect any EC events at all, the system should remain suspended, so it is useful to know when that is the case. For this reason, make acpi_ec_dispatch_gpe() return a bool value indicating whether or not any EC events have been detected by it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Thomas Gleixner <tglx@linutronix.de>
2019-05-30treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 157Thomas Gleixner
Based on 3 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version [author] [kishon] [vijay] [abraham] [i] [kishon]@[ti] [com] this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version [author] [graeme] [gregory] [gg]@[slimlogic] [co] [uk] [author] [kishon] [vijay] [abraham] [i] [kishon]@[ti] [com] [based] [on] [twl6030]_[usb] [c] [author] [hema] [hk] [hemahk]@[ti] [com] this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 1105 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Richard Fontana <rfontana@redhat.com> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070033.202006027@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-01Revert "ACPI / EC: Remove old CLEAR_ON_RESUME quirk"Zhang Rui
On some Samsung hardware, it is necessary to clear events accumulated by the EC during sleep. These ECs stop reporting GPEs until they are manually polled, if too many events are accumulated. Thus the CLEAR_ON_RESUME quirk is introduced to send EC query commands unconditionally after resume to clear all the EC query events on those platforms. Later, commit 4c237371f290 ("ACPI / EC: Remove old CLEAR_ON_RESUME quirk") removes the CLEAR_ON_RESUME quirk because we thought the new EC IRQ polling logic should handle this case. Now it has been proved that the EC IRQ Polling logic does not fix the issue actually because we got regression report on these Samsung platforms after removing the quirk. Thus revert commit 4c237371f290 ("ACPI / EC: Remove old CLEAR_ON_RESUME quirk") to introduce back the Samsung quirk in this patch. Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161 Tested-by: Ortwin Glück <odi@odi.ch> Tested-by: Francisco Cribari <cribari@gmail.com> Tested-by: Balazs Varga <balazs4web@gmail.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-02-01ACPI: EC: Simplify boot EC checks in acpi_ec_add()Rafael J. Wysocki
Consolidate boot EC checks in acpi_ec_add(), put the acpi_is_boot_ec() checks directly into it and drop the latter. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-02-01ACPI: EC: Eliminate acpi_config_boot_ec()Rafael J. Wysocki
Notice that acpi_ec_add() calls acpi_config_boot_ec() when it finds that the device object passed to it represents a "boot" EC, but in that case the ec pointer passed to acpi_config_boot_ec() is guaranteed to be equal to boot_ec and ec->handle is passed as the handle argument to it, so acpi_config_boot_ec() really only calls acpi_ec_setup() and prints a message. Avoid the pointless checks in acpi_config_boot_ec() by calling acpi_ec_setup() directly and print the message separately. With the above changes in place, there are no users of acpi_config_boot_ec(), so drop it. No intentional functional impact except for a changed message. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-02-01ACPI: EC: Make acpi_ec_dsdt_probe() more straightforwardRafael J. Wysocki
Since acpi_ec_dsdt_probe() returns early if boot_ec is set, it is always unset when that function calls acpi_config_boot_ec() (passing ec->handle as the handle argument to it). Thus it is not really useful to call acpi_config_boot_ec() at that point. It is sufficient to call acpi_ec_setup() directly and (if that is successful) set boot_ec, so make acpi_ec_dsdt_probe() do that and avoid some pointless checks in acpi_config_boot_ec(). No intentional functional impact except for a changed message. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-02-01ACPI: EC: Make acpi_ec_ecdt_probe() more straightforwardRafael J. Wysocki
Since acpi_ec_ecdt_probe() is called when boot_ec is not set, it doesn't neeed to take the other possibility into account. Accordingly, it only needs to set the handle field in the ec object to ACPI_ROOT_OBJECT, call acpi_ec_setup() and (if that is successful) set boot_ec to ec and boot_ec_is_ecdt to 'true'. Make it do so directly, without calling acpi_config_boot_ec(), and avoid some pointless checks in the latter. No intentional functional impact except for a changed message. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-02-01ACPI: EC: Declare boot_ec as staticRafael J. Wysocki
The boot_ec variable is not used outside of the file it is defined in, so declare it as static. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-01-29ACPI: EC: Clean up probing for early ECRafael J. Wysocki
Both acpi_ec_dsdt_probe() and acpi_ec_ecdt_probe() may be void as their return values are ignored anyway. This allows a couple of gotos and labels to go away from there. Moreover, acpi_ec_ecdt_probe() only needs to allocate the ec object after getting the ECDT pointer and checking it, so the pointless memory allocation and release on systems without the ECDT can be avoided by reordering it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-12-18ACPI: EC / PM: Disable non-wakeup GPEs for suspend-to-idleRafael J. Wysocki
There are systems in which non-wakeup GPEs fire during the "noirq" suspend stage of suspending devices and that effectively prevents the system that tries to suspend to idle from entering any low-power state at all. If the offending GPE fires regularly and often enough, the system appears to be suspended, but in fact it is in a tight loop over "noirq" suspend and "noirq" resume of devices all the time. To prevent that from happening, disable all non-wakeup GPEs except for the EC GPE for suspend-to-idle (the EC GPE is special, because on some systems it has to be enabled for power button wakeup events to be generated as expected). Fixes: 147a7d9d25ca (ACPI / PM: Do not reconfigure GPEs for suspend-to-idle) Link: https://bugzilla.kernel.org/show_bug.cgi?id=201987 Reported-by: Zhang Rui <rui.zhang@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-08-09ACPI / EC: Add another entry for Thinkpad X1 Carbon 6thMika Westerberg
Commit 2c4d6baf1bc4 (ACPI / EC: Use ec_no_wakeup on more Thinkpad X1 Carbon 6th systems) changed the DMI table to match all systems where DMI product family is "Thinkpad X1 Carbon 6th". However, the system I have here has this string written differently (ThinkPad vs. Thinkpad) which makes the match fail. In addition to that, after BIOS upgrade Robin now has the same string than my system has (perhaps newer BIOS has changed the string). In any case add another DMI entry to acpi_ec_no_wakeup[] table hopefully covering all the X1 Carbon 6th systems out there. Fixes: 2c4d6baf1bc4 (ACPI / EC: Use ec_no_wakeup on more Thinkpad X1 Carbon 6th systems) Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> [ rjw: Rebase and change the ident string to match the product familiy ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-08-06ACPI / EC: Use ec_no_wakeup on ThinkPad X1 Yoga 3rdAaron Ma
Like on X1C6, on X1Y3 EC interrupts constantly wake up system from s2idle, the power consumption is extremely high. So make ec_no_wakeup be true as default to keep system in s2idle mode and reduce power consumption. Power button works when ec_no_wakeup=true. Signed-off-by: Aaron Ma <aaron.ma@canonical.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-07-19ACPI / EC: Use ec_no_wakeup on more Thinkpad X1 Carbon 6th systemsRobin H. Johnson
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 <robbat2@gentoo.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-06-18ACPI / EC: Use ec_no_wakeup on Thinkpad X1 Carbon 6thMika Westerberg
On this system EC interrupt triggers constantly kicking devices out of low power states and thus blocking power management. The system also has a PCIe root port hosting Alpine Ridge Thunderbolt controller and it never gets a chance to go to D3cold because of this. Since the power button works the same regardless if EC interrupt is enabled or not during s2idle, add a quirk for this machine that sets ec_no_wakeup=true preventing spurious wakeups. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-05-25ACPI: EC: Dispatch the EC GPE directly on s2idle wakeRafael J. Wysocki
On platforms where the Low Power S0 Idle _DSM interface is used, on wakeup from suspend-to-idle, when it is known that the ACPI SCI has triggered while suspended, dispatch the EC GPE in order to catch all EC events that may have triggered the wakeup before carrying out the noirq phase of device resume. That is needed to handle power button wakeup on some platforms where the EC goes into a low-power mode during suspend-to-idle and while in that mode it will discard events after a timeout. If that timeout is shorter than the time it takes to complete the noirq resume of devices, looking for EC events after the latter is too late. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reported-by: Zhang Rui <rui.zhang@intel.com> Tested-by: Wendy Wang <wendy.wang@intel.com>
2018-02-12ACPI / EC: Restore polling during noirq suspend/resume phasesRafael J. Wysocki
Commit 662591461c4b (ACPI / EC: Drop EC noirq hooks to fix a regression) modified the ACPI EC driver so that it doesn't switch over to busy polling mode during noirq stages of system suspend and resume in an attempt to fix an issue resulting from that behavior. However, that modification introduced a system resume regression on Thinkpad X240, so make the EC driver switch over to the polling mode during noirq stages of system suspend and resume again, which effectively reverts the problematic commit. Fixes: 662591461c4b (ACPI / EC: Drop EC noirq hooks to fix a regression) Link: https://bugzilla.kernel.org/show_bug.cgi?id=197863 Reported-by: Markus Demleitner <m@tfiu.de> Tested-by: Markus Demleitner <m@tfiu.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-01-04ACPI: EC: Fix debugfs_create_*() usageGeert Uytterhoeven
acpi_ec.gpe is "unsigned long", hence treating it as "u32" would expose the wrong half on big-endian 64-bit systems. Fix this by changing its type to "u32" and removing the cast, as all other code already uses u32 or sometimes even only u8. Fixes: 1195a098168fcacf (ACPI: Provide /sys/kernel/debug/ec/...) Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-11-30Merge branch 'acpi-ec' into acpiRafael J. Wysocki
* acpi-ec: ACPI / EC: Fix regression related to PM ops support in ECDT device
2017-11-21ACPI / EC: Fix regression related to PM ops support in ECDT deviceLv Zheng
On platforms (ASUS X550ZE and possibly all ASUS X series) with valid ECDT EC but invalid DSDT EC, EC PM ops won't be invoked as ECDT EC is not an ACPI device. Thus the following commit actually removed post-resume acpi_ec_enable_event() invocation for such platforms, and triggered a regression on them that after being resumed, EC (actually should be ECDT) driver stops handling EC events: Commit: c2b46d679b30c5c0d7eb47a21085943242bdd8dc Subject: ACPI / EC: Add PM operations to improve event handling for resume process Notice that the root cause actually is "ECDT is not an ACPI device" rather than "the timing of acpi_ec_enable_event() invocation", this patch fixes this issue by enumerating ECDT EC as an ACPI device. Due to the existence of the noirq stage, the ability of tuning the timing of acpi_ec_enable_event() invocation is still meaningful. This patch is a little bit different from the posted fix by moving acpi_config_boot_ec() from acpi_ec_ecdt_start() to acpi_ec_add() to make sure that EC event handling won't be stopped as long as the ACPI EC driver is bound. Thus the following sequence shouldn't disable EC event handling: unbind,suspend,resume,bind. Fixes: c2b46d679b30 (ACPI / EC: Add PM operations to improve event handling for resume process) Link: https://bugzilla.kernel.org/show_bug.cgi?id=196847 Reported-by: Luya Tshimbalanga <luya@fedoraproject.org> Tested-by: Luya Tshimbalanga <luya@fedoraproject.org> Cc: 4.9+ <stable@vger.kernel.org> # 4.9+ Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-11-15Merge tag 'modules-for-v4.15' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux Pull module updates from Jessica Yu: "Summary of modules changes for the 4.15 merge window: - treewide module_param_call() cleanup, fix up set/get function prototype mismatches, from Kees Cook - minor code cleanups" * tag 'modules-for-v4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux: module: Do not paper over type mismatches in module_param_call() treewide: Fix function prototypes for module_param_call() module: Prepare to convert all module_param_call() prototypes kernel/module: Delete an error message for a failed memory allocation in add_module_usage()
2017-11-09ACPI / EC: Fix regression related to triggering source of EC event handlingLv Zheng
Originally the Samsung quirks removed by commit 4c237371 can be covered by commit e923e8e7 and ec_freeze_events=Y mode. But commit 9c40f956 changed ec_freeze_events=Y back to N, making this problem re-surface. Actually, if commit e923e8e7 is robust enough, we can freely change ec_freeze_events mode, so this patch fixes the issue by improving commit e923e8e7. Related commits listed in the merged order: Commit: e923e8e79e18fd6be9162f1be6b99a002e9df2cb Subject: ACPI / EC: Fix an issue that SCI_EVT cannot be detected after event is enabled Commit: 4c237371f290d1ed3b2071dd43554362137b1cce Subject: ACPI / EC: Remove old CLEAR_ON_RESUME quirk Commit: 9c40f956ce9b331493347d1b3cb7e384f7dc0581 Subject: Revert "ACPI / EC: Enable event freeze mode..." to fix a regression This patch not only fixes the reported post-resume EC event triggering source issue, but also fixes an unreported similar issue related to the driver bind by adding EC event triggering source in ec_install_handlers(). Fixes: e923e8e79e18 (ACPI / EC: Fix an issue that SCI_EVT cannot be detected after event is enabled) Fixes: 4c237371f290 (ACPI / EC: Remove old CLEAR_ON_RESUME quirk) Fixes: 9c40f956ce9b (Revert "ACPI / EC: Enable event freeze mode..." to fix a regression) Link: https://bugzilla.kernel.org/show_bug.cgi?id=196833 Signed-off-by: Lv Zheng <lv.zheng@intel.com> Reported-by: Alistair Hamilton <ahpatent@gmail.com> Tested-by: Alistair Hamilton <ahpatent@gmail.com> Cc: 4.11+ <stable@vger.kernel.org> # 4.11+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-10-31treewide: Fix function prototypes for module_param_call()Kees Cook
Several function prototypes for the set/get functions defined by module_param_call() have a slightly wrong argument types. This fixes those in an effort to clean up the calls when running under type-enforced compiler instrumentation for CFI. This is the result of running the following semantic patch: @match_module_param_call_function@ declarer name module_param_call; identifier _name, _set_func, _get_func; expression _arg, _mode; @@ module_param_call(_name, _set_func, _get_func, _arg, _mode); @fix_set_prototype depends on match_module_param_call_function@ identifier match_module_param_call_function._set_func; identifier _val, _param; type _val_type, _param_type; @@ int _set_func( -_val_type _val +const char * _val , -_param_type _param +const struct kernel_param * _param ) { ... } @fix_get_prototype depends on match_module_param_call_function@ identifier match_module_param_call_function._get_func; identifier _val, _param; type _val_type, _param_type; @@ int _get_func( -_val_type _val +char * _val , -_param_type _param +const struct kernel_param * _param ) { ... } Two additional by-hand changes are included for places where the above Coccinelle script didn't notice them: drivers/platform/x86/thinkpad_acpi.c fs/lockd/svc.c Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Jessica Yu <jeyu@kernel.org>
2017-09-14dmi: Mark all struct dmi_system_id instances constChristoph Hellwig
... and __initconst if applicable. Based on similar work for an older kernel in the Grsecurity patch. [JD: fix toshiba-wmi build] [JD: add htcpen] [JD: move __initconst where checkscript wants it] Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jean Delvare <jdelvare@suse.de>
2017-08-19ACPI / EC: Clean up EC GPE mask flagLv Zheng
EC_FLAGS_COMMAND_STORM is actually used to mask GPE during IRQ processing. This patch cleans it up using more readable flag/function names. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Tested-by: Tomislav Ivek <tomislav.ivek@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-18ACPI: EC: Fix possible issues related to EC initialization orderLv Zheng
Use the observation that the EC command/data register addresses are sufficient to determine if two EC devices are equivelent to modify acpi_is_boot_ec(). Then, for the removed comparison factors, EC ID and EC GPE, they need to be synchronized for the boot_ec: 1. Before registering the BIOS-provided EC event handlers in acpi_ec_register_query_methods(), the namespace node holding _Qxx methods should be located. The real namespace PNP0C09 device location then is apparently more trustworthy than the ECDT EC ID. 2. Because of the ASUS quirks, the ECDT EC GPE is more trustworthy than the namespace PNP0C09 device's _GPE setting. Use the above observations to synchronize the boot_ec settings in acpi_ec_add(). Finally, change the order of acpi_ec_ecdt_start() and acpi_ec_add(), called from acpi_bus_register_driver(), so as to follow the fast path of determining the location of _Qxx. Signed-off-by: Lv Zheng <lv.zheng@intel.com> [ rjw : Changelog & comments ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-17ACPI: EC: Fix regression related to wrong ECDT initialization orderLv Zheng
Commit 2a5708409e4e (ACPI / EC: Fix a gap that ECDT EC cannot handle EC events) introduced acpi_ec_ecdt_start(), but that function is invoked before acpi_ec_query_init(), which is too early. This causes the kernel to crash if an EC event occurs after boot, when ec_query_wq is not valid: BUG: unable to handle kernel NULL pointer dereference at 0000000000000102 ... Workqueue: events acpi_ec_event_handler task: ffff9f539790dac0 task.stack: ffffb437c0e10000 RIP: 0010:__queue_work+0x32/0x430 Normally, the DSDT EC should always be valid, so acpi_ec_ecdt_start() is actually a no-op in the majority of cases. However, commit c712bb58d827 (ACPI / EC: Add support to skip boot stage DSDT probe) caused the probing of the DSDT EC as the "boot EC" to be skipped when the ECDT EC is valid and uncovered the bug. Fix this issue by invoking acpi_ec_ecdt_start() after acpi_ec_query_init() in acpi_ec_init(). Link: https://jira01.devtools.intel.com/browse/LCK-4348 Fixes: 2a5708409e4e (ACPI / EC: Fix a gap that ECDT EC cannot handle EC events) Fixes: c712bb58d827 (ACPI / EC: Add support to skip boot stage DSDT probe) Reported-by: Wang Wendy <wendy.wang@intel.com> Tested-by: Feng Chenzhou <chenzhoux.feng@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-20ACPI / PM / EC: Flush all EC work in acpi_freeze_sync()Rafael J. Wysocki
Commit eed4d47efe95 (ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle) introduced acpi_freeze_sync() whose purpose is to flush all of the processing of possible wakeup events signaled via the ACPI SCI. However, it doesn't flush the query workqueue used by the EC driver, so the events generated by the EC may not be processed timely which leads to issues (increased overhead at least, lost events possibly). To fix that introduce acpi_ec_flush_work() that will flush all of the outstanding EC work and call it from acpi_freeze_sync(). Fixes: eed4d47efe95 (ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-20Merge branch 'acpi-ec' into acpi-pmRafael J. Wysocki
2017-07-19ACPI / EC: Add parameter to force disable the GPE on suspendRafael J. Wysocki
After commit 8110dd281e15 (ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems) the configuration of GPEs, including the EC one, is not changed during suspend-to-idle on recent systems. That's in order to make system wakeup events generated by the EC work, in particular. However, on some of the systems in question (for example on Dell XPS13 9365), in addition to generating system wakeup events the EC generates a heartbeat sequence of interrupts that have nothing to do with wakeup while suspended, and the Low Power Idle S0 _DSM interface doesn't change that behavior. The users of those systems may prefer to disable the EC GPE during system suspend, for the cost of non-functional power button wakeup or similar, but currently there is no way to do that. For this reason, add a new module parameter, ec_no_wakeup, for the EC driver module that, if set, will cause the EC GPE to be disabled during system suspend and re-enabled during the subsequent system resume. Link: https://bugzilla.kernel.org/show_bug.cgi?id=192591#c106 Amends: 8110dd281e15 (ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems) Reported-and-tested-by: Patrik Kullman <patrik.kullman@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-14Merge branches 'acpi-ec', 'acpi-irq' and 'acpi-quirks'Rafael J. Wysocki
* acpi-ec: Revert "ACPI / EC: Enable event freeze mode..." to fix a regression ACPI / EC: Drop EC noirq hooks to fix a regression * acpi-irq: ACPI / irq: Fix return code of acpi_gsi_to_irq() * acpi-quirks: ACPI / x86: Add KIOX000A accelerometer on GPD win to always_present_ids array ACPI / x86: Add Dell Venue 11 Pro 7130 touchscreen to always_present_ids ACPI / x86: Allow matching always_present_id array entries by DMI
2017-07-12Revert "ACPI / EC: Enable event freeze mode..." to fix a regressionLv Zheng
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 <gdamjan@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: 4.9+ <stable@vger.kernel.org> # 4.9+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-12ACPI / EC: Drop EC noirq hooks to fix a regressionLv Zheng
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 <andreas@lindhe.io> Tested-by: Gjorgji Jankovski <j.gjorgji@gmail.com> Tested-by: Damjan Georgievski <gdamjan@gmail.com> Tested-by: Fernando Chaves <nanochaves@gmail.com> Tested-by: Tomislav Ivek <tomislav.ivek@gmail.com> Tested-by: Denis P. <theoriginal.skullburner@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-04Merge tag 'acpi-4.13-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI updates from Rafael Wysocki: "These mostly update the ACPICA code in the kernel to upstream revision 20170531 which covers all of the new material from ACPI 6.2, including new tables (WSMT, HMAT, PPTT), new subtables and definition changes for some existing tables (BGRT, HEST, SRAT, TPM2, PCCT), new resource descriptor macros for pin control, support for new predefined methods (_LSI, _LSR, _LSW, _HMA), fixes and cleanups. On top of that, an additional ACPICA change from Kees (which also is upstream already) switches all of the definitions of function pointer structures in ACPICA to use designated initializers so as to make the structure layout randomization GCC plugin work with it. The rest is a few fixes and cleanups in the EC driver, an xpower PMIC driver update, a new backlight blacklist entry, and update of the tables configfs interface and a messages formatting cleanup. Specifics: - Update the ACPICA code in the kernel to upstream revision revision 20170531 (which covers all of the new material from ACPI 6.2) including: * Support for the PinFunction(), PinConfig(), PinGroup(), PinGroupFunction(), and PinGroupConfig() resource descriptors (Mika Westerberg). * Support for new subtables in HEST and SRAT, new notify value for HEST, header support for TPM2 table changes, and BGRT Status field update (Bob Moore). * Support for new PCCT subtables (David Box). * Support for _LSI, _LSR, _LSW, and _HMA as predefined methods (Erik Schmauss). * Support for the new WSMT, HMAT, and PPTT tables (Lv Zheng). * New UUID values for Processor Properties (Bob Moore). * New notify values for memory attributes and graceful shutdown (Bob Moore). * Fix related to the PCAT_COMPAT MADT flag (Janosch Hildebrand). * Resource to AML conversion fix for resources containing GPIOs (Mika Westerberg). * Disassembler-related updates (Bob Moore, David Box, Erik Schmauss). * Assorted fixes and cleanups (Bob Moore, Erik Schmauss, Lv Zheng, Cao Jin). - Modify ACPICA to always use designated initializers for function pointer structures to make the structure layout randomization GCC plugin work with it (Kees Cook). - Update the tables configfs interface to unload SSDTs on configfs entry removal (Jan Kiszka). - Add support for the GPI1 regulator to the xpower PMIC Operation Region handler (Hans de Goede). - Fix ACPI EC issues related to conflicting EC definitions in the ECDT and in the ACPI namespace (Lv Zheng, Carlo Caione, Chris Chiu). - Fix an interrupt storm issue in the EC driver and make its debug output work with dynamic debug as expected (Lv Zheng). - Add ACPI backlight quirk for Dell Precision 7510 (Shih-Yuan Lee). - Fix whitespace in pr_fmt() to align log entries properly in some places in the ACPI subsystem (Vincent Legoll)" * tag 'acpi-4.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (63 commits) ACPI / EC: Add quirk for GL720VMK ACPI / EC: Fix media keys not working problem on some Asus laptops ACPI / EC: Add support to skip boot stage DSDT probe ACPI / EC: Enhance boot EC sanity check ACPI / video: Add quirks for the Dell Precision 7510 ACPI: EC: Fix EC command visibility for dynamic debug ACPI: EC: Fix an EC event IRQ storming issue ACPICA: Use designated initializers ACPICA: Update version to 20170531 ACPICA: Update a couple of debug output messages ACPICA: acpiexec: enhance local signal handler ACPICA: Simplify output for the ACPI Debug Object ACPICA: Unix application OSL: Correctly handle control-c (EINTR) ACPICA: Improvements for debug output only ACPICA: Disassembler: allow conflicting external declarations to be emitted. ACPICA: Disassembler: add external op to namespace on first pass ACPICA: Disassembler: prevent external op's from opening a new scope ACPICA: Changed Gbl_disasm_flag to acpi_gbl_disasm_flag ACPICA: Changing External to a named object ACPICA: Update two error messages to emit control method name ...
2017-07-03Merge branches 'acpi-ec' and 'acpi-video'Rafael J. Wysocki
* acpi-ec: ACPI / EC: Add quirk for GL720VMK ACPI / EC: Fix media keys not working problem on some Asus laptops ACPI / EC: Add support to skip boot stage DSDT probe ACPI / EC: Enhance boot EC sanity check ACPI: EC: Fix EC command visibility for dynamic debug ACPI: EC: Fix an EC event IRQ storming issue * acpi-video: ACPI / video: Add quirks for the Dell Precision 7510
2017-06-29ACPI / EC: Add quirk for GL720VMKCarlo Caione
ASUS GL720VMK is also affected by the EC GPE preference issue. Signed-off-by: Carlo Caione <carlo@caione.org> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-29ACPI / EC: Fix media keys not working problem on some Asus laptopsChris Chiu
Some Asus laptops (verified on X550VXK/FX502VD/FX502VE) get no interrupts when pressing media keys thus the corresponding functions are not invoked. It's due to the _GPE defines in DSDT for EC returns differnt value compared to the GPE Number in ECDT. Confirmed with Asus that the vale in ECDT is the correct one. This commit uses DMI quirks to prevent calling _GPE when doing ec_parse_device() and keep the ECDT GPE number setting for the EC device. With previous commit, it is ensured that if there is an ECDT, it can always be kept as boot_ec, this patch thus can implement a quirk on top of the determined ECDT boot_ec. Link: https://phabricator.endlessm.com/T16033 Link: https://phabricator.endlessm.com/T16722 Link: https://bugzilla.kernel.org/show_bug.cgi?id=195651 Tested-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Carlo Caione <carlo@caione.org> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-29ACPI / EC: Add support to skip boot stage DSDT probeLv Zheng
We prepared _INI/_STA methods for \_SB, \_SB.PCI0, \_SB.LID0 and \_SB.EC, _HID(PNP0C09)/_CRS/_GPE for \_SB.EC to poke Windows behavior with qemu, we got the following execution sequence: \_SB._INI \_SB.PCI0._STA \_SB.LID0._STA \_SB.EC._STA \_SB.PCI0._INI \_SB.LID0._INI \_SB.EC._INI There is no extra DSDT EC device enumeration process occurring before the main ACPI device enumeration process. That means acpi_ec_dsdt_probe() is not Windows-compatible. Tracking back, it was added by the following commit: Commit: c5279dee26c0e8d7c4200993bfc4b540d2469598 Subject: ACPI: EC: Add some basic check for ECDT data but that commit was misguided. Why we shouldn't enumerate DSDT EC before the main ACPI device enumeration? The only way to know if the DSDT EC is valid would be to evaluate its _STA control method, but it's not safe to evaluate this control method that early and out of the ACPI enumeration process, because _STA may refer to entities (such as resources or ACPI device objects) that may not have been initialized before OSPM starts to enumerate them via the main ACPI device enumeration. But after we had reverted back to the expected behavior, a regression was reported. On that platform, there is no ECDT, but the platform control methods access EC operation region earlier than Linux expects causing some ACPI method execution errors. For this reason, we just go back to old behavior to still probe DSDT EC as the boot EC. However, that turns out to lead to yet another functional breakage and in order to work around all of the problems, we skip boot stage DSDT probe when the ECDT exists so that a later quirk can always use correct ECDT GPE setting. Link: http://bugzilla.kernel.org/show_bug.cgi?id=11880 Link: http://bugzilla.kernel.org/show_bug.cgi?id=119261 Link: http://bugzilla.kernel.org/show_bug.cgi?id=195651 Tested-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> [ rjw: Changelog & comments massage ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-29ACPI / EC: Enhance boot EC sanity checkLv Zheng
It's reported that some buggy BIOS tables can contain 2 DSDT ECs, one of them is invalid but acpi_ec_dsdt_probe() fails to pick the valid one. This patch simply enhances sanity checks in ec_parse_device() as a workaround to skip probing wrong namespace ECs. Link: https://bugzilla.kernel.org/show_bug.cgi?id=195651 Tested-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-28ACPI: EC: Fix EC command visibility for dynamic debugLv Zheng
acpi_ec_cmd_string() currently is only enabled for "DEBUG" macro, but users trend to use CONFIG_DYNAMIC_DEBUG and enable ec.c pr_debug() print-outs by "dyndbg='file ec.c +p'". In this use case, all command names are turned into UNDEF and the log is confusing. This affects bugzilla triage work. This patch fixes this issue by enabling acpi_ec_cmd_string() for CONFIG_DYNAMIC_DEBUG. Tested-by: Wang Wendy <wendy.wang@intel.com> Tested-by: Feng Chenzhou <chenzhoux.feng@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-28ACPI: EC: Fix an EC event IRQ storming issueLv Zheng
The EC event IRQ (SCI_EVT) can only be handled by submitting QR_EC. As the EC driver handles SCI_EVT in a workqueue, after SCI_EVT is flagged and before QR_EC is submitted, there is a period risking IRQ storming. EC IRQ must be masked for this period but linux EC driver never does so. No end user notices the IRQ storming and no developer fixes this known issue because: 1. The EC IRQ is always edge triggered GPE, and 2. The kernel can execute no-op EC IRQ handler very fast. For edge-triggered EC GPE platforms, it is only reported of post-resume EC event lost issues, there won't be an IRQ storming. For level triggered EC GPE platforms, fortunately the kernel is always fast enough to execute such a no-op EC IRQ handler so that the IRQ handler won't be accumulated to starve the task contexts, causing a real IRQ storming. But the IRQ storming actually can still happen when: 1. The EC IRQ performs like level triggered GPE, and 2. The kernel EC debugging log is turned on but the console is slow enough. There are more and more platforms using EC GPE as wake GPE where the EC GPE is likely designed as level triggered. Then when EC debugging log is enabled, the EC IRQ handler is no longer a no-op but dumps IRQ status to the consoles. If the consoles are slow enough, the EC IRQs can arrive much faster than executing the handler. Finally the accumulated EC event IRQ handlers starve the task contexts, causing the IRQ storming to occur, and the kernel hangs can be observed during boot/resume. This patch fixes this issue by masking EC IRQ for this period: 1. Begins when there is an SCI_EVT IRQ pending, and 2. Ends when there is a QR_EC completed (SCI_EVT acknowledged). Tested-by: Wang Wendy <wendy.wang@intel.com> Tested-by: Feng Chenzhou <chenzhoux.feng@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-23ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systemsRafael J. Wysocki
Some recent Dell laptops, including the XPS13 model numbers 9360 and 9365, cannot be woken up from suspend-to-idle by pressing the power button which is unexpected and makes that feature less usable on those systems. Moreover, on the 9365 ACPI S3 (suspend-to-RAM) is not expected to be used at all (the OS these systems ship with never exercises the ACPI S3 path in the firmware) and suspend-to-idle is the only viable system suspend mechanism there. The reason why the power button wakeup from suspend-to-idle doesn't work on those systems is because their power button events are signaled by the EC (Embedded Controller), whose GPE (General Purpose Event) line is disabled during suspend-to-idle transitions in Linux. That is done on purpose, because in general the EC tends to be noisy for various reasons (battery and thermal updates and similar, for example) and all events signaled by it would kick the CPUs out of deep idle states while in suspend-to-idle, which effectively might defeat its purpose. Of course, on the Dell systems in question the EC GPE must be enabled during suspend-to-idle transitions for the button press events to be signaled while suspended at all, but fortunately there is a way out of this puzzle. First of all, those systems have the ACPI_FADT_LOW_POWER_S0 flag set in their ACPI tables, which means that the OS is expected to prefer the "low power S0 idle" system state over ACPI S3 on them. That causes the most recent versions of other OSes to simply ignore ACPI S3 on those systems, so it is reasonable to expect that it should not be necessary to block GPEs during suspend-to-idle on them. Second, in addition to that, the systems in question provide a special firmware interface that can be used to indicate to the platform that the OS is transitioning into a system-wide low-power state in which certain types of activity are not desirable or that it is leaving such a state and that (in principle) should allow the platform to adjust its operation mode accordingly. That interface is a special _DSM object under a System Power Management Controller device (PNP0D80). The expected way to use it is to invoke function 0 from it on system initialization, functions 3 and 5 during suspend transitions and functions 4 and 6 during resume transitions (to reverse the actions carried out by the former). In particular, function 5 from the "Low-Power S0" device _DSM is expected to cause the platform to put itself into a low-power operation mode which should include making the EC less verbose (so to speak). Next, on resume, function 6 switches the platform back to the "working-state" operation mode. In accordance with the above, modify the ACPI suspend-to-idle code to look for the "Low-Power S0" _DSM interface on platforms with the ACPI_FADT_LOW_POWER_S0 flag set in the ACPI tables. If it's there, use it during suspend-to-idle transitions as prescribed and avoid changing the GPE configuration in that case. [That should reflect what the most recent versions of other OSes do.] Also modify the ACPI EC driver to make it handle events during suspend-to-idle in the usual way if the "Low-Power S0" _DSM interface is going to be used to make the power button events work while suspended on the Dell machines mentioned above Link: http://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-22ACPI: fix whitespace in pr_fmt() to align log entriesVincent Legoll
See this dmesg extract before the patch: [ 0.679466] ACPI: Dynamic OEM Table Load: [ 0.679470] ACPI: SSDT 0xFFFF910F6B497E00 00018A (v02 PmRef ApCst 00003000 INTL 20160422) [ 0.679579] ACPI: Executed 1 blocks of module-level executable AML code [ 0.681477] ACPI : EC: EC started [ 0.681478] ACPI : EC: interrupt blocked [ 0.684798] ACPI: Interpreter enabled [ 0.684835] ACPI: (supports S0 S3 S4 S5) Signed-off-by: Vincent Legoll <vincent.legoll@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-01-30ACPI / EC: Use busy polling mode when GPE is not enabledLv Zheng
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 <jakobus.schurz@gmail.com> Tested-by: Chen Yu <yu.c.chen@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-01-30ACPI / EC: Remove old CLEAR_ON_RESUME quirkLv Zheng
IRQ polling logic has been implemented to drain the post-boot/resume EC events: 1. Triggered by the following code, invoked from acpi_ec_enable_event(): if (!test_bit(EC_FLAGS_QUERY_PENDING, &ec->flags)) advance_transaction(ec); 2. Drained by the following code, invoked after acpi_ec_complete_query(): if (status & ACPI_EC_FLAG_SCI) acpi_ec_submit_query(ec); This facility is safer than the old CLEAR_ON_RESUME quirk as the CLEAR_ON_RESUME quirk sends EC query commands unconditionally. The behavior is apparently not suitable for firmware that requires QUERY_HANDSHAKE quirk. Though the QUERY_HANDSHAKE quirk isn't used now because of the improvement done in the EC transaction state machine (ec_event_clearing=QUERY), it is the proof that we cannot send EC query command unconditionally. So it's time to delete the out-dated CLEAR_ON_RESUME quirk to let the users to try the newer approach. Link: https://bugzilla.kernel.org/show_bug.cgi?id=191211 Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>