BMC/Intel-BMC/linux.git/drivers/base/power/wakeup.c, branch dev-4.18

Merge branches 'pm-pci', 'acpi-pm', 'pm-sleep' and 'pm-avs'

2018-06-04T08:41:53+00:00

* pm-pci: PCI / PM: Clean up outdated comments in pci_target_state() PCI / PM: Do not clear state_saved for devices that remain suspended * acpi-pm: ACPI: EC: Dispatch the EC GPE directly on s2idle wake ACPICA: Introduce acpi_dispatch_gpe() * pm-sleep: PM / hibernate: Fix oops at snapshot_write() PM / wakeup: Make s2idle_lock a RAW_SPINLOCK PM / s2idle: Make s2idle_wait_head swait based PM / wakeup: Make events_lock a RAW_SPINLOCK PM / suspend: Prevent might sleep splats * pm-avs: PM / AVS: rockchip-io: add io selectors and supplies for PX30

PM / wakeup: Make events_lock a RAW_SPINLOCK

2018-05-27T09:55:02+00:00

The `events_lock' is acquired during suspend while interrupts are disabled even on RT. The lock is taken only for a very brief moment. Make it a RAW lock which avoids "sleeping while atomic" warnings on RT. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Rafael J. Wysocki

PM: wakeup: Use pr_debug() for the "aborting suspend" message

2018-05-24T08:19:16+00:00

The message printed by pm_wakeup_pending() on wakeup detection is not very useful if someone is not interested specifically in debugging wakeup, so turn it into a pm_debug() one. Signed-off-by: Rafael J. Wysocki

PM / wakeup: Only update last time for active wakeup sources

2018-05-10T09:39:19+00:00

When wakelock support was added, the wakeup_source_add() function was updated to set the last_time value of the wakeup source. This has the unintended side effect of producing confusing output from pm_print_active_wakeup_sources() when a wakeup source is added prior to a sleep that is blocked by a different wakeup source. The function pm_print_active_wakeup_sources() will search for the most recently active wakeup source when no active source is found. If a wakeup source is added after a different wakeup source blocks the system from going to sleep it may have a later last_time value than the blocking source and be output as the last active wakeup source even if it has never actually been active. It looks to me like the change to wakeup_source_add() was made to prevent the wakelock garbage collection from accidentally dropping a wakelock during the narrow window between adding the wakelock to the wakelock list in wakelock_lookup_add() and the activation of the wakeup source in pm_wake_lock(). This commit changes the behavior so that only the last_time of the wakeup source used by a wakelock is initialized prior to adding it to the wakeup source list. This preserves the meaning of the last_time value as the last time the wakeup source was active and allows a wakeup source that has never been active to have a last_time value of 0. Fixes: b86ff9820fd5 (PM / Sleep: Add user space interface for manipulating wakeup sources, v3) Signed-off-by: Doug Berger Signed-off-by: Rafael J. Wysocki

PM / wakeup: Use seq_open() to show wakeup stats

2018-05-10T09:36:46+00:00

single_open() interface requires that the whole output must fit into a single buffer. This will lead to timeout when system memory is not in a good situation. This patch use seq_open() to show wakeup stats. This method need only one page, so timeout will not be observed. Signed-off-by: Ganesh Mahendran Signed-off-by: Rafael J. Wysocki

PM / wakeup: Print warn if device gets enabled as wakeup source during sleep

2018-01-11T17:50:54+00:00

In general, wakeup settings are not supposed to be changed during any of the system wide PM phases. The reason is simply that it would break guarantees provided by the PM core, to properly act on active wakeup sources. However, there are exceptions to when, in particular, disabling a device as wakeup source makes sense. For example, in cases when a driver realizes that its device is dead during system suspend. For these scenarios, we don't need to care about acting on the wakeup source correctly, because a dead device shouldn't deliver wakeup signals. To this reasoning and to help users to properly manage wakeup settings, let's print a warning in cases someone calls device_wakeup_enable() during system sleep. Suggested-by: Rafael J. Wysocki Signed-off-by: Ulf Hansson [ rjw: Message to be printed ] Signed-off-by: Rafael J. Wysocki

PM / wakeup: Do not fail dev_pm_attach_wake_irq() unnecessarily

2018-01-09T12:09:16+00:00

Returning an error code from dev_pm_attach_wake_irq() if device_wakeup_attach_irq() called by it returns an error is pointless, because the wakeup source used by it may be deleted by user space via sysfs at any time and in particular right after dev_pm_attach_wake_irq() has returned. Moreover, it requires the callers of dev_pm_attach_wake_irq() to create that wakeup source via device_wakeup_enable() upfront, but that obviously is racy with respect to the sysfs-based manipulations of it. To avoid the race, modify device_wakeup_attach_irq() to check that the wakeup source it is going to use is there (and return early otherwise), make it void (as it cannot fail after that change) and make dev_pm_attach_wake_irq() simply call it for the device unconditionally. Tested-by: Tony Lindgren Signed-off-by: Rafael J. Wysocki

PM / wakeup: Drop redundant check from device_init_wakeup()

2018-01-02T23:29:30+00:00

Since device_wakeup_disable() checks the device's power.can_wakeup flag, device_init_wakeup() doesn't need to do that before calling it, so drop that redundant check from device_init_wakeup(). No intentional changes in functionality. Signed-off-by: Rafael J. Wysocki Reviewed-by: Ulf Hansson

PM / wakeup: Drop redundant check from device_set_wakeup_enable()

2018-01-02T23:28:39+00:00

Since both device_wakeup_enable() and device_wakeup_disable() check if dev is not NULL and whether or not power.can_wakeup is set for it, device_set_wakeup_enable() doesn't have to do that, so drop that check from it. No intentional changes in functionality. Signed-off-by: Rafael J. Wysocki Reviewed-by: Ulf Hansson

PM / wakeup: only recommend "call"ing device_init_wakeup() once

2017-12-19T01:45:06+00:00

I'll admit admit it: I've written bad driver code that tries to configure a device's wake IRQ without having called device_init_wakeup() first. But do you really have to ask ask me twice? Signed-off-by: Brian Norris Signed-off-by: Rafael J. Wysocki