When ath11k runs into internal errors upon suspend, it returns an error code to pci_pm_suspend, which aborts the entire system suspend.
The driver should not abort system suspend, but should keep its internal errors to itself, and allow the system to suspend. Otherwise, a user can suspend a laptop by closing the lid and sealing it into a case, assuming that is will suspend, rather than heating up and draining the battery when in transit.
In practice, the ath11k device seems to have plenty of transient errors, and subsequent suspend cycles after this failure often succeed.
https://bugzilla.kernel.org/show_bug.cgi?id=216968
Fixes: d1b0c33850d29 ("ath11k: implement suspend for QCA6390 PCI devices")
Signed-off-by: Len Brown len.brown@intel.com Cc: Carl Huang cjhuang@codeaurora.org Cc: Kalle Valo kvalo@codeaurora.org Cc: stable@vger.kernel.org --- drivers/net/wireless/ath/ath11k/pci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath11k/pci.c b/drivers/net/wireless/ath/ath11k/pci.c index 99cf3357c66e..3c6005ab9a71 100644 --- a/drivers/net/wireless/ath/ath11k/pci.c +++ b/drivers/net/wireless/ath/ath11k/pci.c @@ -979,7 +979,7 @@ static __maybe_unused int ath11k_pci_pm_suspend(struct device *dev) if (ret) ath11k_warn(ab, "failed to suspend core: %d\n", ret);
- return ret; + return 0; }
static __maybe_unused int ath11k_pci_pm_resume(struct device *dev)
Len Brown len.brown@intel.com wrote:
When ath11k runs into internal errors upon suspend, it returns an error code to pci_pm_suspend, which aborts the entire system suspend.
The driver should not abort system suspend, but should keep its internal errors to itself, and allow the system to suspend. Otherwise, a user can suspend a laptop by closing the lid and sealing it into a case, assuming that is will suspend, rather than heating up and draining the battery when in transit.
In practice, the ath11k device seems to have plenty of transient errors, and subsequent suspend cycles after this failure often succeed.
https://bugzilla.kernel.org/show_bug.cgi?id=216968
Fixes: d1b0c33850d29 ("ath11k: implement suspend for QCA6390 PCI devices")
Signed-off-by: Len Brown len.brown@intel.com Cc: stable@vger.kernel.org
Patch applied to wireless.git, thanks.
7c15430822e7 wifi: ath11k: allow system suspend to survive ath11k
I'm a bit of a kernel n00b here, but it's unclear to me that this is the right thing to do and I just wanted to get some clarity. If the ath11k device fails to suspend, my understanding is that it might waste power attempting to talk to the host that's currently asleep. Are we sure that ath11k can recover from ignored failures/skipped teardown?
On Wed, Feb 22, 2023 at 2:34 AM Kalle Valo kvalo@kernel.org wrote:
Len Brown len.brown@intel.com wrote:
When ath11k runs into internal errors upon suspend, it returns an error code to pci_pm_suspend, which aborts the entire system suspend.
The driver should not abort system suspend, but should keep its internal errors to itself, and allow the system to suspend. Otherwise, a user can suspend a laptop by closing the lid and sealing it into a case, assuming that is will suspend, rather than heating up and draining the battery when in transit.
In practice, the ath11k device seems to have plenty of transient errors, and subsequent suspend cycles after this failure often succeed.
https://bugzilla.kernel.org/show_bug.cgi?id=216968
Fixes: d1b0c33850d29 ("ath11k: implement suspend for QCA6390 PCI devices")
Signed-off-by: Len Brown len.brown@intel.com Cc: stable@vger.kernel.org
Patch applied to wireless.git, thanks.
7c15430822e7 wifi: ath11k: allow system suspend to survive ath11k
-- https://patchwork.kernel.org/project/linux-wireless/patch/20230201183201.144...
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatch...
linux-stable-mirror@lists.linaro.org