05 Apr, 2020
1 commit
-
Since commit fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from
waking up the system") the SCI triggering without there being a wakeup
cause recognized by the ACPI sleep code will no longer wakeup the system.This works as intended, but this is a problem for devices where the SCI
is shared with another device which is also a wakeup source.In the past these, from the pov of the ACPI sleep code, spurious SCIs
would still cause a wakeup so the wakeup from the device sharing the
interrupt would actually wakeup the system. This now no longer works.This is a problem on e.g. Bay Trail-T and Cherry Trail devices where
some peripherals (typically the XHCI controller) can signal a
Power Management Event (PME) to the Power Management Controller (PMC)
to wakeup the system, this uses the same interrupt as the SCI.
These wakeups are handled through a special INT0002 ACPI device which
checks for events in the GPE0a_STS for this and takes care of acking
the PME so that the shared interrupt stops triggering.The change to the ACPI sleep code to ignore the spurious SCI, causes
the system to no longer wakeup on these PME events. To make things
worse this means that the INT0002 device driver interrupt handler will
no longer run, causing the PME to not get cleared and resulting in the
system hanging. Trying to wakeup the system after such a PME through e.g.
the power button no longer works.Add an acpi_register_wakeup_handler() function which registers
a handler to be called from acpi_s2idle_wake() and when the handler
returns true, return true from acpi_s2idle_wake().The INT0002 driver will use this mechanism to check the GPE0a_STS
register from acpi_s2idle_wake() and to tell the system to wakeup
if a PME is signaled in the register.Fixes: fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system")
Cc: 5.4+ # 5.4+
Signed-off-by: Hans de Goede
Signed-off-by: Rafael J. Wysocki
02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
02 May, 2017
1 commit
-
Commit 660b1113e0f3 (ACPI / PM: Fix consistency check for power resources
during resume) introduced a check for ACPI power resources which have
been turned on by the BIOS during suspend and turns these back off again.This is causing problems on a Dell Venue Pro 11 7130 (i5-4300Y) it causes
the following messages to show up in dmesg:[ 131.014605] ACPI: Waking up from system sleep state S3
[ 131.150271] acpi LNXPOWER:07: Turning OFF
[ 131.150323] acpi LNXPOWER:06: Turning OFF
[ 131.150911] acpi LNXPOWER:00: Turning OFF
[ 131.169014] ACPI : EC: interrupt unblocked
[ 131.181811] xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI
[ 133.535728] pci_raw_set_power_state: 76 callbacks suppressed
[ 133.535735] iwlwifi 0000:01:00.0: Refused to change power state,
currently in D3
[ 133.597672] PM: noirq resume of devices complete after 2428.891 msecsFollowed by a bunch of iwlwifi errors later on and the pcie device
dropping from the bus (acpiphp thinks it has been unplugged).Disabling the turning off of unused power resources fixes this. Instead
of adding a quirk for this system, this commit fixes this by moving the
disabling of unused power resources to later in the resume sequence
when the iwlwifi card has been moved out of D3 so the ref_count for
its power resource no longer is 0.This new behavior seems to match the intend of the original commit which
commit-msg says: "(... which means that no devices are going to need them
any time soon) and we should turn them off".This also avoids power resources which we need when bringing devices out
of D3 from getting bounced off and then back on again.Signed-off-by: Hans de Goede
Signed-off-by: Rafael J. Wysocki
05 Jan, 2016
1 commit
-
Commit f06147f9fbf1 (ACPICA: Hardware: Enable firmware waking vector
for both 32-bit and 64-bit FACS) added three functions that aren't
present in upstream ACPICA, acpi_hw_set_firmware_waking_vectors(),
acpi_set_firmware_waking_vectors() and acpi_set_firmware_waking_vector64(),
to allow Linux to use the previously existing API for setting the
platform firmware waking vector.However, that wasn't necessary, since the ACPI sleep support code
in Linux can be modified to use the upstream ACPICA's API easily
and the additional functions may be dropped which reduces the code
size and puts the kernel's ACPICA code more in line with the upstream.Make the changes as per the above. While at it, make the relevant
function desctiption comments reflect the upstream ACPICA's ones.Signed-off-by: Rafael J. Wysocki
Acked-by: Lv Zheng
18 Mar, 2015
1 commit
-
The acpi_suspend() function has no callers, so drop it.
Signed-off-by: Rafael J. Wysocki
Acked-by: Lorenzo Pieralisi
Reviewed-by: Hanjun Guo
17 Jan, 2013
1 commit
-
The ACPI power resources driver is not very useful, because the only
thing it really does is to restore the state of the power resources
that were "on" before system suspend or hibernation, but that may be
achieved in a different way.Drop the ACPI power resources driver entirely and add
acpi_resume_power_resources() that will walk the list of all
registered power resources during system resume and turn on the ones
that were "on" before the preceding system suspend or hibernation.Signed-off-by: Rafael J. Wysocki
20 Oct, 2010
1 commit
-
Only used in one file so should be static.
Signed-off-by: Stephen Hemminger
Signed-off-by: Len Brown
07 Jul, 2010
1 commit
-
To simplify the enabling of wakeup devices during system suspend and
hibernation, merge acpi_enable_wakeup_device_prep() with
acpi_disable_wakeup_device() and remove unnecessary (and no longer
valid) comments from the latter. Rename acpi_enable_wakeup_device()
to acpi_enable_wakeup_devices() and acpi_disable_wakeup_device()
to acpi_disable_wakeup_devices(), because these functions usually
operate on multiple device objects.Signed-off-by: Rafael J. Wysocki
Signed-off-by: Len Brown
29 May, 2010
1 commit
-
drivers/acpi/sleep.h:3: WARNING: space prohibited between function name and open parenthesis '('
Signed-off-by: Andrea Gelmini
Signed-off-by: Len Brown
07 Apr, 2009
1 commit
-
Convert acpi_device_lock to a mutex to avoid
a potential race upon access to /proc/acpi/wakeupDelete the lock entirely in wakeup.c
since it is not necessary (and can not sleep)Found-by: Linus Torvalds
Signed-off-by: Shaohua Li
Signed-off-by: Len Brown
09 Jan, 2009
1 commit
-
also, delete sleep/ and delete ACPI_CFLAGS from Makefile
Signed-off-by: Len Brown
