From: Sasha Levin Date: Sun, 2 Dec 2018 15:03:24 +0000 (-0500) Subject: Revert "wlcore: Add missing PM call for wlcore_cmd_wait_for_event_or_timeout()" X-Git-Tag: v3.18.129~53 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=c06ae62e54e55de94b4dbed0c76626fb263c8b05;p=profile%2Fwearable%2Fplatform%2Fkernel%2Flinux-3.18-exynos7270.git 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 . > 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 Signed-off-by: Greg Kroah-Hartman --- diff --git a/drivers/net/wireless/ti/wlcore/cmd.c b/drivers/net/wireless/ti/wlcore/cmd.c index de43c03..05604ee 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; }