From: Douglas Anderson <dianders@chromium.org>
To: Ulf Hansson <ulf.hansson@linaro.org>,
Kalle Valo <kvalo@codeaurora.org>,
Adrian Hunter <adrian.hunter@intel.com>,
Arend van Spriel <arend.vanspriel@broadcom.com>
Cc: linux-rockchip@lists.infradead.org,
Double Lo <double.lo@cypress.com>,
briannorris@chromium.org,
Madhan Mohan R <madhanmohan.r@cypress.com>,
mka@chromium.org, Wright Feng <wright.feng@cypress.com>,
Chi-Hsien Lin <chi-hsien.lin@cypress.com>,
Douglas Anderson <dianders@chromium.org>,
brcm80211-dev-list.pdl@broadcom.com,
"David S. Miller" <davem@davemloft.net>,
Franky Lin <franky.lin@broadcom.com>,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org,
Hante Meuleman <hante.meuleman@broadcom.com>,
Naveen Gupta <naveen.gupta@cypress.com>,
brcm80211-dev-list@cypress.com,
YueHaibing <yuehaibing@huawei.com>,
Michael Trimarchi <michael@amarulasolutions.com>
Subject: [PATCH 3/3] brcmfmac: sdio: Disable auto-tuning around commands expected to fail
Date: Fri, 17 May 2019 15:54:20 -0700 [thread overview]
Message-ID: <20190517225420.176893-4-dianders@chromium.org> (raw)
In-Reply-To: <20190517225420.176893-1-dianders@chromium.org>
There are certain cases, notably when transitioning between sleep and
active state, when Broadcom SDIO WiFi cards will produce errors on the
SDIO bus. This is evident from the source code where you can see that
we try commands in a loop until we either get success or we've tried
too many times. The comment in the code reinforces this by saying
"just one write attempt may fail"
Unfortunately these failures sometimes end up causing an "-EILSEQ"
back to the core which triggers a retuning of the SDIO card and that
blocks all traffic to the card until it's done.
Let's disable retuning around the commands we expect might fail.
Fixes: bd11e8bd03ca ("mmc: core: Flag re-tuning is needed on CRC errors")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 3fd2d58a3c88..c09bb8965487 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -27,6 +27,7 @@
#include <linux/mmc/sdio_ids.h>
#include <linux/mmc/sdio_func.h>
#include <linux/mmc/card.h>
+#include <linux/mmc/core.h>
#include <linux/semaphore.h>
#include <linux/firmware.h>
#include <linux/module.h>
@@ -708,6 +709,7 @@ brcmf_sdio_kso_control(struct brcmf_sdio *bus, bool on)
bmask = SBSDIO_FUNC1_SLEEPCSR_KSO_MASK;
}
+ mmc_expect_errors_begin(bus->sdiodev->func1->card->host);
do {
/* reliable KSO bit set/clr:
* the sdiod sleep write access is synced to PMU 32khz clk
@@ -730,6 +732,7 @@ brcmf_sdio_kso_control(struct brcmf_sdio *bus, bool on)
&err);
} while (try_cnt++ < MAX_KSO_ATTEMPTS);
+ mmc_expect_errors_end(bus->sdiodev->func1->card->host);
if (try_cnt > 2)
brcmf_dbg(SDIO, "try_cnt=%d rd_val=0x%x err=%d\n", try_cnt,
--
2.21.0.1020.gf2820cf01a-goog
next prev parent reply other threads:[~2019-05-17 22:54 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-17 22:54 [PATCH 0/3] brcmfmac: sdio: Deal better w/ transmission errors waking from sleep Douglas Anderson
2019-05-17 22:54 ` [PATCH 1/3] brcmfmac: re-enable command decode in sdio_aos for BRCM 4354 Douglas Anderson
2019-05-20 8:09 ` Arend Van Spriel
2019-05-20 18:20 ` Doug Anderson
2019-05-28 12:18 ` Kalle Valo
[not found] ` <20190528121833.7D3A460A00@smtp.codeaurora.org>
2019-05-28 15:51 ` Doug Anderson
2019-05-28 16:09 ` Arend Van Spriel
2019-05-28 16:11 ` Arend Van Spriel
2019-06-04 3:20 ` Wright Feng
2019-06-04 16:01 ` Doug Anderson
2019-06-04 16:48 ` Arend Van Spriel
2019-05-29 14:51 ` Kalle Valo
2019-05-17 22:54 ` Douglas Anderson [this message]
2019-05-18 15:09 ` [PATCH 0/3] brcmfmac: sdio: Deal better w/ transmission errors waking from sleep Avri Altman
2019-05-21 0:23 ` Brian Norris
2019-05-20 8:55 ` Arend Van Spriel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190517225420.176893-4-dianders@chromium.org \
--to=dianders@chromium.org \
--cc=adrian.hunter@intel.com \
--cc=arend.vanspriel@broadcom.com \
--cc=brcm80211-dev-list.pdl@broadcom.com \
--cc=brcm80211-dev-list@cypress.com \
--cc=briannorris@chromium.org \
--cc=chi-hsien.lin@cypress.com \
--cc=davem@davemloft.net \
--cc=double.lo@cypress.com \
--cc=franky.lin@broadcom.com \
--cc=hante.meuleman@broadcom.com \
--cc=kvalo@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=madhanmohan.r@cypress.com \
--cc=michael@amarulasolutions.com \
--cc=mka@chromium.org \
--cc=naveen.gupta@cypress.com \
--cc=netdev@vger.kernel.org \
--cc=ulf.hansson@linaro.org \
--cc=wright.feng@cypress.com \
--cc=yuehaibing@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).