Bug 194791 - iwlwifi: 7260: WoWLAN prevents suspend if CONFIG_IWLWIFI_PCIE_RTPM=y - WIFILNX-697
Summary: iwlwifi: 7260: WoWLAN prevents suspend if CONFIG_IWLWIFI_PCIE_RTPM=y - WIFILN...
Alias: None
Product: Drivers
Classification: Unclassified
Component: network-wireless (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: DO NOT USE - assign "network-wireless-intel" component instead
Depends on:
Reported: 2017-03-05 14:57 UTC by Oliver Freyermuth
Modified: 2017-04-07 11:04 UTC (History)
2 users (show)

See Also:
Kernel Version: 4.10.1
Tree: Mainline
Regression: No


Description Oliver Freyermuth 2017-03-05 14:57:11 UTC
If CONFIG_IWLWIFI_PCIE_RTPM=y is set and WoWLAN is activated for an "Intel Corporation Wireless 7260", suspend to RAM fails. 

Hardware (lspci): 
03:00.0 Network controller: Intel Corporation Wireless 7260 (rev bb)

[    6.918741] iwlwifi 0000:03:00.0: loaded firmware version 17.459231.0 op_mode iwlmvm
[    7.017580] iwlwifi 0000:03:00.0: Detected Intel(R) Dual Band Wireless AC 7260, REV=0x144

Enable WoWLAN (reproducible with other modes...): 
$ iw phy phy0 wowlan enable magic-packet
$ iw phy phy0 wowlan show
WoWLAN is enabled:
 * wake up on magic packet

$ echo mem > /sys/power/state
bash: echo: write error: Device or resource busy

Kernel log shows then:
[ 2038.786956] PM: Syncing filesystems ... done.
[ 2040.699117] PM: Preparing system for sleep (mem)
[ 2040.699504] Freezing user space processes ... (elapsed 0.001 seconds) done.
[ 2040.700862] Freezing remaining freezable tasks ... (elapsed 0.000 seconds) done.
[ 2040.701864] PM: Suspending system (mem)
[ 2040.701882] Suspending console(s) (use no_console_suspend to debug)
[ 2040.702229] sd 5:0:0:0: [sdb] Synchronizing SCSI cache
[ 2040.702243] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 2040.702303] sd 5:0:0:0: [sdb] Stopping disk
[ 2040.702313] sd 0:0:0:0: [sda] Stopping disk
[ 2040.703805] dpm_run_callback(): wiphy_suspend+0x0/0x97 [cfg80211] returns -16
[ 2040.703815] PM: Device phy0 failed to suspend async: error -16
[ 2040.762209] PM: Some devices failed to suspend, or early wake event detected
[ 2040.762308] Suspended for 3599.288 seconds
[ 2040.763049] sd 0:0:0:0: [sda] Starting disk
[ 2040.763088] sd 5:0:0:0: [sdb] Starting disk
[ 2040.858298] PM: resume of devices complete after 96.083 msecs
[ 2040.858777] PM: Finishing wakeup.
[ 2040.858779] Restarting tasks ... done.
[ 2041.732392] psmouse serio2: synaptics: queried max coordinates: x [..5692], y [..4680]

"fixes" this, tested on two machines with different HW (apart from the WiFi card). 

Let me know if more info is needed.
Comment 1 Luca Coelho 2017-03-17 14:52:25 UTC
As we mentioned in bug 172411, this feature requires some integration with the platform to work correctly.  We have recently added "EXPERT" to the config dependency and improved the help to reflect that.

This is the commit where this was changed (merged in 4.11-rc1):

commit 6eac0e817aee2518a96b5ce9d02b904e0667f370
Author:     Emmanuel Grumbach <emmanuel.grumbach@intel.com>
AuthorDate: Sat Jan 7 23:03:40 2017 +0200
Commit:     Luca Coelho <luciano.coelho@intel.com>
CommitDate: Wed Feb 8 17:54:20 2017 +0200

    iwlwifi: make RTPM depend on EXPERT
    Enabling the RTPM Kconfig option can be fairly risky.
    Runtime PM must be validated against a specific platform
    before it can be safely enabled. Hence, it makes no sense
    for distros and other big OS vendors to enable it since
    they ship code to various systems and unknown platform.
    Make sure that this is hinted properly by making the
    IWLWIFI_PCIE_RTPM Kconfig option depend on EXPERT.
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=172411
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Comment 2 Luca Coelho 2017-03-17 14:53:04 UTC
I'll change this since we already have a "fix".
Comment 3 Luca Coelho 2017-03-17 14:57:56 UTC
Okay, reopening it since this is not the same as before.  You're not even using RTPM and it is preventing suspend.  We'll try to fix it properly. :)
Comment 4 Oliver Freyermuth 2017-03-17 15:07:35 UTC
No wait - it only fails if I set CONFIG_IWLWIFI_PCIE_RTPM=y , but suspending works just fine if I set CONFIG_IWLWIFI_PCIE_RTPM=n. 

So indeed "hiding" the option would "fix" the issue. 
Note, however, that on the two platforms I tested on this was the only issue I ever encountered after enabling RTPM in the kernel, apart from that, wifi was working very fine.
Comment 5 Luca Coelho 2017-03-17 15:55:13 UTC
Yes, you're right, but suspend should work when PCIE_RTPM=y, especially if we are *not* entering runtime suspend. :)

I believe I found out the reason for this problem.  Since RTPM is not configured properly in the platform side, we keep an RTPM reference to prevent it from entering runtime suspend.  The interaction between RTPM suspend and system suspend is messy and, in this case, we are preventing suspend because we couldn't properly enter D0i3 mode.  This should only be the case if WoWLAN "any" was set, so we also need to check the system_pm_mode.

Could you try this fix and check whether it works for you?

diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
index 7f05fc56587a..d73c7a58db1d 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
@@ -2877,7 +2877,8 @@ static struct iwl_trans_dump_data
 static int iwl_trans_pcie_suspend(struct iwl_trans *trans)
-       if (trans->runtime_pm_mode == IWL_PLAT_PM_MODE_D0I3)
+       if ((trans->runtime_pm_mode == IWL_PLAT_PM_MODE_D0I3) &&
+           (trans->system_pm_mode == IWL_PLAT_PM_MODE_D0I3))
                return iwl_pci_fw_enter_d0i3(trans);
        return 0;

Comment 6 Oliver Freyermuth 2017-03-18 14:46:08 UTC
Understood :-). 

The test was successful: I can confirm that, applying your patch, I can now enter suspend just fine with WoWLAN active (tried magic packet and tcp modes) even if CONFIG_IWLWIFI_PCIE_RTPM=y is set. 
I tested with 4.10.1. 

Thanks a lot and cheers!
Comment 7 Luca Coelho 2017-03-18 15:30:42 UTC
Great! Thank you very much for reporting and testing.  I'll push this patch via the normal route.

Note You need to log in before you can comment on or make changes to this bug.