| From 25d20b05a6a31b9434bf5a9b817fdb9da4a00f2e Mon Sep 17 00:00:00 2001 |
| From: Sasha Levin <sashal@kernel.org> |
| Date: Sun, 2 Dec 2018 10:03:24 -0500 |
| Subject: Revert "wlcore: Add missing PM call for |
| wlcore_cmd_wait_for_event_or_timeout()" |
| |
| This reverts commit cbc56a12da05d5333a9020c4d7854ad7d0b5a31d which was |
| upstream commit 4ec7cece87b3ed21ffcd407c62fb2f151a366bc1. |
| |
| From Dietmar May's report on the stable mailing list |
| (https://www.spinics.net/lists/stable/msg272201.html): |
| |
| > I've run into some problems which appear due to (a) recent patch(es) on |
| > the wlcore wifi driver. |
| > |
| > 4.4.160 - commit 3fdd34643ffc378b5924941fad40352c04610294 |
| > 4.9.131 - commit afeeecc764436f31d4447575bb9007732333818c |
| > |
| > Earlier versions (4.9.130 and 4.4.159 - tested back to 4.4.49) do not |
| > exhibit this problem. It is still present in 4.9.141. |
| > |
| > master as of 4.20.0-rc4 does not exhibit this problem. |
| > |
| > Basically, during client association when in AP mode (running hostapd), |
| > handshake may or may not complete following a noticeable delay. If |
| > successful, then the driver fails consistently in warn_slowpath_null |
| > during disassociation. If unsuccessful, the wifi client attempts multiple |
| > times, sometimes failing repeatedly. I've had clients unable to connect |
| > for 3-5 minutes during testing, with the syslog filled with dozens of |
| > backtraces. syslog details are below. |
| > |
| > I'm working on an embedded device with a TI 3352 ARM processor and a |
| > murata wl1271 module in sdio mode. We're running a fully patched ubuntu |
| > 18.04 ARM build, with a kernel built from kernel.org's stable/linux repo <https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.9.y&id=afeeecc764436f31d4447575bb9007732333818c>. |
| > Relevant parts of the kernel config are included below. |
| > |
| > The commit message states: |
| > |
| > > /I've only seen this few times with the runtime PM patches enabled so |
| > > this one is probably not needed before that. This seems to work |
| > > currently based on the current PM implementation timer. Let's apply |
| > > this separately though in case others are hitting this issue./ |
| > We're not doing anything explicit with power management. The device is an |
| > IoT edge gateway with battery backup, normally running on wall power. The |
| > battery is currently used solely to shut down the system cleanly to avoid |
| > filesystem corruption. |
| > |
| > The device tree is configured to keep power in suspend; but the device |
| > should never suspend, so in our case, there is no need to call |
| > wl1271_ps_elp_wakeup() or wl1271_ps_elp_sleep(), as occurs in the patch. |
| |
| Signed-off-by: Sasha Levin <sashal@kernel.org> |
| Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
| --- |
| drivers/net/wireless/ti/wlcore/cmd.c | 6 ------ |
| 1 file changed, 6 deletions(-) |
| |
| --- a/drivers/net/wireless/ti/wlcore/cmd.c |
| +++ b/drivers/net/wireless/ti/wlcore/cmd.c |
| @@ -35,7 +35,6 @@ |
| #include "wl12xx_80211.h" |
| #include "cmd.h" |
| #include "event.h" |
| -#include "ps.h" |
| #include "tx.h" |
| #include "hw_ops.h" |
| |
| @@ -188,10 +187,6 @@ int wlcore_cmd_wait_for_event_or_timeout |
| |
| timeout_time = jiffies + msecs_to_jiffies(WL1271_EVENT_TIMEOUT); |
| |
| - ret = wl1271_ps_elp_wakeup(wl); |
| - if (ret < 0) |
| - return ret; |
| - |
| do { |
| if (time_after(jiffies, timeout_time)) { |
| wl1271_debug(DEBUG_CMD, "timeout waiting for event %d", |
| @@ -223,7 +218,6 @@ int wlcore_cmd_wait_for_event_or_timeout |
| } while (!event); |
| |
| out: |
| - wl1271_ps_elp_sleep(wl); |
| kfree(events_vector); |
| return ret; |
| } |