Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 08 2月, 2022 1 次提交
    • R
      PM: s2idle: ACPI: Fix wakeup interrupts handling · cb1f65c1
      由 Rafael J. Wysocki 提交于 
      After commit e3728b50 ("ACPI: PM: s2idle: Avoid possible race
related to the EC GPE") wakeup interrupts occurring immediately after
the one discarded by acpi_s2idle_wake() may be missed.  Moreover, if
the SCI triggers again immediately after the rearming in
acpi_s2idle_wake(), that wakeup may be missed too.

The problem is that pm_system_irq_wakeup() only calls pm_system_wakeup()
when pm_wakeup_irq is 0, but that's not the case any more after the
interrupt causing acpi_s2idle_wake() to run until pm_wakeup_irq is
cleared by the pm_wakeup_clear() call in s2idle_loop().  However,
there may be wakeup interrupts occurring in that time frame and if
that happens, they will be missed.

To address that issue first move the clearing of pm_wakeup_irq to
the point at which it is known that the interrupt causing
acpi_s2idle_wake() to tun will be discarded, before rearming the SCI
for wakeup.  Moreover, because that only reduces the size of the
time window in which the issue may manifest itself, allow
pm_system_irq_wakeup() to register two second wakeup interrupts in
a row and, when discarding the first one, replace it with the second
one.  [Of course, this assumes that only one wakeup interrupt can be
discarded in one go, but currently that is the case and I am not
aware of any plans to change that.]

Fixes: e3728b50 ("ACPI: PM: s2idle: Avoid possible race related to the EC GPE")
Cc: 5.4+ <stable@vger.kernel.org> # 5.4+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      cb1f65c1
  3. 21 7月, 2021 1 次提交
  5. 08 4月, 2021 1 次提交
    • P
      PM: wakeup: fix kernel-doc warnings and fix typos · beafe82b
      由 Pierre-Louis Bossart 提交于 
      Remove make W=1 warnings and fit 'Itereates' typos

drivers/base/power/wakeup.c:403: warning: wrong kernel-doc identifier on line:
 * device_wakeup_arm_wake_irqs(void)

drivers/base/power/wakeup.c:419: warning: wrong kernel-doc identifier on line:
 * device_wakeup_disarm_wake_irqs(void)

drivers/base/power/wakeup.c:537: warning: Function parameter or member
'enable' not described in 'device_set_wakeup_enable'

drivers/base/power/wakeup.c:592: warning: expecting prototype for
wakup_source_activate(). Prototype was for wakeup_source_activate()
instead

drivers/base/power/wakeup.c:697: warning: expecting prototype for
wakup_source_deactivate(). Prototype was for
wakeup_source_deactivate() instead

drivers/base/power/wakeup.c:795: warning: Function parameter or member
't' not described in 'pm_wakeup_timer_fn'

drivers/base/power/wakeup.c:795: warning: Excess function parameter
'data' description in 'pm_wakeup_timer_fn'

drivers/base/power/wakeup.c:1027: warning: Function parameter or
member 'set' not described in 'pm_wakep_autosleep_enabled'

drivers/base/power/wakeup.c:1027: warning: Excess function parameter
'enabled' description in 'pm_wakep_autosleep_enabled'
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      beafe82b
  7. 25 3月, 2020 1 次提交
  9. 19 3月, 2020 1 次提交
  11. 18 3月, 2020 1 次提交
  13. 04 3月, 2020 1 次提交
    • M
      PM: sleep: wakeup: Use built-in RCU list checking · 2591e7b1
      由 Madhuparna Bhowmik 提交于 
      Pass cond argument to list_for_each_entry_rcu() to fix the
following false positive lockdep warning and other uses of
list_for_each_entry_rcu() in wakeup.c.
(CONFIG_PROVE_RCU_LIST = y)

[  331.934648] =============================
[  331.934650] WARNING: suspicious RCU usage
[  331.934653] 5.6.0-rc1+ #5 Not tainted
[  331.934655] -----------------------------
[  331.934657] drivers/base/power/wakeup.c:408 RCU-list traversed in non-reader section!!

[  333.025156] =============================
[  333.025161] WARNING: suspicious RCU usage
[  333.025168] 5.6.0-rc1+ #5 Not tainted
[  333.025173] -----------------------------
[  333.025180] drivers/base/power/wakeup.c:424 RCU-list traversed in non-reader section!!
Signed-off-by: NMadhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2591e7b1
  15. 20 12月, 2019 1 次提交
  17. 30 10月, 2019 1 次提交
  19. 21 8月, 2019 4 次提交
  21. 23 7月, 2019 1 次提交
  23. 19 6月, 2019 1 次提交
  25. 05 4月, 2019 1 次提交
  27. 02 4月, 2019 1 次提交
    • S
      PM / wakeup: Use pm_pr_dbg() instead of pr_debug() · 74a1dd86
      由 Stephen Boyd 提交于 
      These prints are useful if we're doing PM suspend debugging. Having them
at pr_debug() level means that we need to either enable DEBUG in this
file, or compile the kernel with dynamic debug capabilities. Both of
these options have drawbacks like custom compilation or opting into all
debug statements being included into the kernel image. Given that we
already have infrastructure to collect PM debugging information with
CONFIG_PM_DEBUG and friends, let's change the pr_debug usage here to be
pm_pr_dbg() instead so we can collect the wakeup information in the
kernel logs.
Signed-off-by: NStephen Boyd <swboyd@chromium.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      74a1dd86
  29. 12 3月, 2019 2 次提交
    • R
      PM / wakeup: Drop wakeup_source_drop() · 623217a0
      由 Rafael J. Wysocki 提交于 
      After commit d856f39ac1cc ("PM / wakeup: Rework wakeup source timer
cancellation") wakeup_source_drop() is a trivial wrapper around
__pm_relax() and it has no users except for wakeup_source_destroy()
and wakeup_source_trash() which also has no users, so drop it along
with the latter and make wakeup_source_destroy() call __pm_relax()
directly.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      623217a0
    • V
      PM / wakeup: Rework wakeup source timer cancellation · 1fad17fb
      由 Viresh Kumar 提交于 
      If wakeup_source_add() is called right after wakeup_source_remove()
for the same wakeup source, timer_setup() may be called for a
potentially scheduled timer which is incorrect.

To avoid that, move the wakeup source timer cancellation from
wakeup_source_drop() to wakeup_source_remove().

Moreover, make wakeup_source_remove() clear the timer function after
canceling the timer to let wakeup_source_not_registered() treat
unregistered wakeup sources in the same way as the ones that have
never been registered.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Cc: 4.4+ <stable@vger.kernel.org> # 4.4+
[ rjw: Subject, changelog, merged two patches together ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1fad17fb
  31. 07 3月, 2019 1 次提交
  33. 29 1月, 2019 1 次提交
  35. 27 5月, 2018 1 次提交
  37. 24 5月, 2018 1 次提交
  39. 10 5月, 2018 2 次提交
    • D
      PM / wakeup: Only update last time for active wakeup sources · 2ef7c01c
      由 Doug Berger 提交于 
      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: b86ff982 (PM / Sleep: Add user space interface for manipulating wakeup sources, v3)
Signed-off-by: NDoug Berger <opendmb@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2ef7c01c
    • M
      PM / wakeup: Use seq_open() to show wakeup stats · 00ee22c2
      由 Mahendran Ganesh 提交于 
      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: NGanesh Mahendran <opensource.ganesh@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      00ee22c2
  41. 12 1月, 2018 1 次提交
    • U
      PM / wakeup: Print warn if device gets enabled as wakeup source during sleep · 0026cef0
      由 Ulf Hansson 提交于 
      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: NRafael J. Wysocki <rafael@kernel.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
[ rjw: Message to be printed ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0026cef0
  43. 09 1月, 2018 1 次提交
    • R
      PM / wakeup: Do not fail dev_pm_attach_wake_irq() unnecessarily · 7bf4e594
      由 Rafael J. Wysocki 提交于 
      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: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      7bf4e594
  45. 03 1月, 2018 2 次提交
  47. 19 12月, 2017 1 次提交
  49. 22 11月, 2017 1 次提交
    • K
      treewide: Remove TIMER_FUNC_TYPE and TIMER_DATA_TYPE casts · 841b86f3
      由 Kees Cook 提交于 
      With all callbacks converted, and the timer callback prototype
switched over, the TIMER_FUNC_TYPE cast is no longer needed,
so remove it. Conversion was done with the following scripts:

    perl -pi -e 's|\(TIMER_FUNC_TYPE\)||g' \
        $(git grep TIMER_FUNC_TYPE | cut -d: -f1 | sort -u)

    perl -pi -e 's|\(TIMER_DATA_TYPE\)||g' \
        $(git grep TIMER_DATA_TYPE | cut -d: -f1 | sort -u)

The now unused macros are also dropped from include/linux/timer.h.
Signed-off-by: NKees Cook <keescook@chromium.org>
      841b86f3
  51. 24 10月, 2017 1 次提交
  53. 11 8月, 2017 1 次提交
  55. 08 8月, 2017 1 次提交
    • R
      PM / wakeup: Set power.can_wakeup if wakeup_sysfs_add() fails · 820b9b0c
      由 Rafael J. Wysocki 提交于 
      Currently, an error from wakeup_sysfs_add() in
device_set_wakeup_capable() causes the device's power.can_wakeup
flag to remain unset even though the device technically is capable
of signaling wakeup.

If wakeup_sysfs_add() fails user space may not be able to enable
the device to wake up the system from sleep states, but at least
for some devices that does not matter.

For this reason, set or clear power.can_wakeup upfront and if
wakeup_sysfs_add() returns an error, print a message to the log.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      820b9b0c
  57. 27 6月, 2017 1 次提交
  59. 15 6月, 2017 1 次提交
    • R
      ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idle · 33e4f80e
      由 Rafael J. Wysocki 提交于 
      The ACPI SCI (System Control Interrupt) is set up as a wakeup IRQ
during suspend-to-idle transitions and, consequently, any events
signaled through it wake up the system from that state.  However,
on some systems some of the events signaled via the ACPI SCI while
suspended to idle should not cause the system to wake up.  In fact,
quite often they should just be discarded.

Arguably, systems should not resume entirely on such events, but in
order to decide which events really should cause the system to resume
and which are spurious, it is necessary to resume up to the point
when ACPI SCIs are actually handled and processed, which is after
executing dpm_resume_noirq() in the system resume path.

For this reasons, add a loop around freeze_enter() in which the
platforms can process events signaled via multiplexed IRQ lines
like the ACPI SCI and add suspend-to-idle hooks that can be
used for this purpose to struct platform_freeze_ops.

In the ACPI case, the ->wake hook is used for checking if the SCI
has triggered while suspended and deferring the interrupt-induced
system wakeup until the events signaled through it are actually
processed sufficiently to decide whether or not the system should
resume.  In turn, the ->sync hook allows all of the relevant event
queues to be flushed so as to prevent events from being missed due
to race conditions.

In addition to that, some ACPI code processing wakeup events needs
to be modified to use the "hard" version of wakeup triggers, so that
it will cause a system resume to happen on device-induced wakeup
events even if the "soft" mechanism to prevent the system from
suspending is not enabled.  However, to preserve the existing
behavior with respect to suspend-to-RAM, this only is done in
the suspend-to-idle case and only if an SCI has occurred while
suspended.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      33e4f80e
  61. 07 6月, 2017 1 次提交
  63. 14 5月, 2017 1 次提交
    • R
      PM / wakeup: Fix up wakeup_source_report_event() · 60d4553b
      由 Rafael J. Wysocki 提交于 
      Commit 8a537ece (PM / wakeup: Integrate mechanism to abort
transitions in progress) modified wakeup_source_report_event()
and wakeup_source_activate() to make it possible to call
pm_system_wakeup() from the latter if so indicated by the
caller of the former (via a new function argument added by that
commit), but it overlooked the fact that in some situations
wakeup_source_report_event() is called to signal a "hard" event
(ie. such that should abort a system suspend in progress) after
pm_stay_awake() has been called for the same wakeup source object,
in which case the pm_system_wakeup() will not trigger.

To work around this issue, modify wakeup_source_activate() and
wakeup_source_report_event() again so that pm_system_wakeup() is
called by the latter directly (if its last argument is true), in
which case the additional argument does not need to be passed
to wakeup_source_activate() any more, so drop it from there.

Fixes: 8a537ece (PM / wakeup: Integrate mechanism to abort transitions in progress)
Reported-by: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      60d4553b
  65. 06 5月, 2017 2 次提交
    • R
      ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle · eed4d47e
      由 Rafael J. Wysocki 提交于 
      The ACPI SCI (System Control Interrupt) is set up as a wakeup IRQ
during suspend-to-idle transitions and, consequently, any events
signaled through it wake up the system from that state.  However,
on some systems some of the events signaled via the ACPI SCI while
suspended to idle should not cause the system to wake up.  In fact,
quite often they should just be discarded.

Arguably, systems should not resume entirely on such events, but in
order to decide which events really should cause the system to resume
and which are spurious, it is necessary to resume up to the point
when ACPI SCIs are actually handled and processed, which is after
executing dpm_resume_noirq() in the system resume path.

For this reasons, add a loop around freeze_enter() in which the
platforms can process events signaled via multiplexed IRQ lines
like the ACPI SCI and add suspend-to-idle hooks that can be
used for this purpose to struct platform_freeze_ops.

In the ACPI case, the ->wake hook is used for checking if the SCI
has triggered while suspended and deferring the interrupt-induced
system wakeup until the events signaled through it are actually
processed sufficiently to decide whether or not the system should
resume.  In turn, the ->sync hook allows all of the relevant event
queues to be flushed so as to prevent events from being missed due
to race conditions.

In addition to that, some ACPI code processing wakeup events needs
to be modified to use the "hard" version of wakeup triggers, so that
it will cause a system resume to happen on device-induced wakeup
events even if the "soft" mechanism to prevent the system from
suspending is not enabled (that also helps to catch device-induced
wakeup events occurring during suspend transitions in progress).
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      eed4d47e
    • R
      PM / wakeup: Integrate mechanism to abort transitions in progress · 8a537ece
      由 Rafael J. Wysocki 提交于 
      The system wakeup framework is not very consistent with respect to
the way it handles suspend-to-idle and generally wakeup events
occurring during transitions to system low-power states.

First off, system transitions in progress are aborted by the event
reporting helpers like pm_wakeup_event() only if the wakeup_count
sysfs attribute is in use (as documented), but there are cases in
which system-wide transitions should be aborted even if that is
not the case.  For example, a wakeup signal from a designated
wakeup device during system-wide PM transition, it should cause
the transition to be aborted right away.

Moreover, there is a freeze_wake() call in wakeup_source_activate(),
but that really is only effective after suspend_freeze_state has
been set to FREEZE_STATE_ENTER by freeze_enter().  However, it
is very unlikely that wakeup_source_activate() will ever be called
at that time, as it could only be triggered by a IRQF_NO_SUSPEND
interrupt handler, so wakeups from suspend-to-idle don't really
occur in wakeup_source_activate().

At the same time there is a way to abort a system suspend in
progress (or wake up the system from suspend-to-idle), which is by
calling pm_system_wakeup(), but in turn that doesn't cause any
wakeup source objects to be activated, so it will not be covered
by wakeup source statistics and will not prevent the system from
suspending again immediately (in case autosleep is used, for
example).  Consequently, if anyone wants to abort system transitions
in progress and allow the wakeup_count mechanism to work, they need
to use both pm_system_wakeup() and pm_wakeup_event(), say, at the
same time which is awkward.

For the above reasons, make it possible to trigger
pm_system_wakeup() from within wakeup_source_activate() and
provide a new pm_wakeup_hard_event() helper to do so within the
wakeup framework.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8a537ece