From patchwork Wed Nov 23 02:39:45 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Brian Norris X-Patchwork-Id: 9442499 X-Patchwork-Delegate: kvalo@adurom.com Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 11A4660237 for ; Wed, 23 Nov 2016 02:41:43 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0457D2074F for ; Wed, 23 Nov 2016 02:41:43 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id EBD5124560; Wed, 23 Nov 2016 02:41:42 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A35DF2074F for ; Wed, 23 Nov 2016 02:41:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755476AbcKWClY (ORCPT ); Tue, 22 Nov 2016 21:41:24 -0500 Received: from mail-pg0-f53.google.com ([74.125.83.53]:33476 "EHLO mail-pg0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755330AbcKWClW (ORCPT ); Tue, 22 Nov 2016 21:41:22 -0500 Received: by mail-pg0-f53.google.com with SMTP id 3so158426pgd.0 for ; Tue, 22 Nov 2016 18:41:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id; bh=8TAac/tQlgx6Z0RIe4LNYHdwISOInBZ1ya/pdMsWuCI=; b=WDiVPxcUWgiQhKGZEV/mNXJjIdg0xpl5/QORdl0iyo/77f0FJ5RAEKV/89sevfGiTC XXxgbJ8EjmdB0aEFv05LqCuHcL4aLL9ZiI99lVCk6bT/byGgrpiQ8zu5g/kq5C9PWfVc cnGgWkoxzPdNxdPHFjQBuDkMmjpoE+vDHXGJ4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=8TAac/tQlgx6Z0RIe4LNYHdwISOInBZ1ya/pdMsWuCI=; b=UDTJ1Xl+bn/da+PLDgnuHcSXIdvxn/TDxoDyxmDNvq7I1uOERUlJzIvx2WEL44Csbc KygsQ3a/boi5KQd1/vOU+ND1p5nHarIuEBPHkStKBD0kMH3DuLHMA7H2wjOBrBYLN3eH QgRzG8QRFOSw9BLmItFjY7pYkg7LHytzIrgPa+zBmHUvfLuiynKutRCu86ottoaIl5Fq 6a0H5ohgivh8up2ANzyxIgSWU5yFFJrDIUQnTubeE34llR3fV8S3zExbSrdoreIhixdF HKd/6u9IJZkVWn8CGb55I3ls/KY3hnvxrv9gImapx+kybGomGaU23QtF6a2PvzVdZ9b+ zqpA== X-Gm-Message-State: AKaTC03WVKLWQ0razlZ6uONxoz09P1lErbWC29kbwW0sIt2HRdgRaTFOD9hSB730WHDHYzu0 X-Received: by 10.84.197.1 with SMTP id m1mr1806738pld.159.1479868881822; Tue, 22 Nov 2016 18:41:21 -0800 (PST) Received: from ban.mtv.corp.google.com ([172.22.64.120]) by smtp.gmail.com with ESMTPSA id f81sm48023861pfd.71.2016.11.22.18.41.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 22 Nov 2016 18:41:21 -0800 (PST) From: Brian Norris To: Amitkumar Karwar , Nishant Sarmukadam Cc: , Kalle Valo , linux-wireless@vger.kernel.org, Cathy Luo , Dmitry Torokhov , Brian Norris Subject: [PATCH] mwifiex: pcie: implement timeout loop for FW programming doorbell Date: Tue, 22 Nov 2016 18:39:45 -0800 Message-Id: <1479868785-16263-1-git-send-email-briannorris@chromium.org> X-Mailer: git-send-email 2.8.0.rc3.226.g39d4020 Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Marvell Wifi PCIe modules don't always behave nicely for PCIe power management when their firmware hasn't been loaded, particularly after suspending the PCIe link one or more times. When this happens, we might end up spinning forever in this status-polling tight loop. Let's make this less tight by adding a timeout and by sleeping a bit in between reads, as we do with the other similar loops. This prevents us from hogging a CPU even in such pathological cases, and allows the FW initialization to just fail gracefully instead. I chose the same polling parameters as the earlier loop in this function, and empirically, I found that this loop never makes it more than about 12 cycles in a sane FW init sequence. I had no official information on the actual intended latency for this portion of the download. Signed-off-by: Brian Norris Acked-by: Amitkumar Karwar --- drivers/net/wireless/marvell/mwifiex/pcie.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c index 4b89f557d0b6..9f9ea1350591 100644 --- a/drivers/net/wireless/marvell/mwifiex/pcie.c +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c @@ -2050,7 +2050,7 @@ static int mwifiex_prog_fw_w_helper(struct mwifiex_adapter *adapter, } /* Wait for the command done interrupt */ - do { + for (tries = 0; tries < MAX_POLL_TRIES; tries++) { if (mwifiex_read_reg(adapter, PCIE_CPU_INT_STATUS, &ireg_intr)) { mwifiex_dbg(adapter, ERROR, @@ -2062,8 +2062,18 @@ static int mwifiex_prog_fw_w_helper(struct mwifiex_adapter *adapter, ret = -1; goto done; } - } while ((ireg_intr & CPU_INTR_DOOR_BELL) == - CPU_INTR_DOOR_BELL); + if (!(ireg_intr & CPU_INTR_DOOR_BELL)) + break; + usleep_range(10, 20); + } + if (ireg_intr & CPU_INTR_DOOR_BELL) { + mwifiex_dbg(adapter, ERROR, "%s: Card failed to ACK download\n", + __func__); + mwifiex_unmap_pci_memory(adapter, skb, + PCI_DMA_TODEVICE); + ret = -1; + goto done; + } mwifiex_unmap_pci_memory(adapter, skb, PCI_DMA_TODEVICE);