summaryrefslogtreecommitdiff
path: root/drivers/net/ipa/ipa_resource.c
diff options
context:
space:
mode:
authorAlex Elder <elder@linaro.org>2024-02-23 07:39:25 -0600
committerPaolo Abeni <pabeni@redhat.com>2024-02-27 11:24:03 +0100
commit4b2274d3811a25831068025ce20bf2adbd48c101 (patch)
tree6afd703145cee08efe222548c7ae5af7b6b3e6ba /drivers/net/ipa/ipa_resource.c
parentb38061fe9cfa90a781e9e59fc761191fc8b469a1 (diff)
net: ipa: don't bother aborting system resume
The IPA interrupt can fire if there is data to be delivered to a GSI channel that is suspended. This condition occurs in three scenarios. First, runtime power management automatically suspends the IPA hardware after half a second of inactivity. This has nothing to do with system suspend, so a SYSTEM IPA power flag is used to avoid calling pm_wakeup_dev_event() when runtime suspended. Second, if the system is suspended, the receipt of an IPA interrupt should trigger a system resume. Configuring the IPA interrupt for wakeup accomplishes this. Finally, if system suspend is underway and the IPA interrupt fires, we currently call pm_wakeup_dev_event() to abort the system suspend. The IPA driver correctly handles quiescing the hardware before suspending it, so there's really no need to abort a suspend in progress in the third case. We can simply quiesce and suspend things, and be done. Incoming data can still wake the system after it's suspended. The IPA interrupt has wakeup mode enabled, so if it fires *after* we've suspended, it will trigger a wakeup (if not disabled via sysfs). Stop calling pm_wakeup_dev_event() to abort a system suspend in progress in ipa_power_suspend_handler(). Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Diffstat (limited to 'drivers/net/ipa/ipa_resource.c')
0 files changed, 0 insertions, 0 deletions