--- /dev/null
+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>
+---
+ drivers/net/wireless/ti/wlcore/cmd.c | 6 ------
+ 1 file changed, 6 deletions(-)
+
+diff --git a/drivers/net/wireless/ti/wlcore/cmd.c b/drivers/net/wireless/ti/wlcore/cmd.c
+index de43c0376143..05604ee31224 100644
+--- 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(struct wl1271 *wl,
+
+ 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(struct wl1271 *wl,
+ } while (!event);
+
+ out:
+- wl1271_ps_elp_sleep(wl);
+ kfree(events_vector);
+ return ret;
+ }
+--
+2.17.1
+