From patchwork Tue Sep 14 11:48:12 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Jonas_Dre=C3=9Fler?= X-Patchwork-Id: 512909 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CDF94C4332F for ; Tue, 14 Sep 2021 11:49:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B242D60E52 for ; Tue, 14 Sep 2021 11:49:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232315AbhINLue (ORCPT ); Tue, 14 Sep 2021 07:50:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56400 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232462AbhINLuB (ORCPT ); Tue, 14 Sep 2021 07:50:01 -0400 Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [IPv6:2001:67c:2050::465:102]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CB8A2C061574; Tue, 14 Sep 2021 04:48:43 -0700 (PDT) Received: from smtp102.mailbox.org (smtp102.mailbox.org [IPv6:2001:67c:2050:105:465:1:3:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4H81p14VPvzQkBN; Tue, 14 Sep 2021 13:48:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de From: =?utf-8?q?Jonas_Dre=C3=9Fler?= To: Amitkumar Karwar , Ganapathi Bhat , Xinming Hu , Kalle Valo , "David S. Miller" , Jakub Kicinski Cc: =?utf-8?q?Jonas_Dre=C3=9Fler?= , Tsuchiya Yuto , linux-wireless@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, Maximilian Luz , Andy Shevchenko , Bjorn Helgaas , =?utf-8?q?Pali_Roh=C3=A1r?= , Heiner Kallweit , Johannes Berg , Brian Norris , stable@vger.kernel.org Subject: [PATCH v2 1/2] mwifiex: Use non-posted PCI write when setting TX ring write pointer Date: Tue, 14 Sep 2021 13:48:12 +0200 Message-Id: <20210914114813.15404-2-verdre@v0yd.nl> In-Reply-To: <20210914114813.15404-1-verdre@v0yd.nl> References: <20210914114813.15404-1-verdre@v0yd.nl> MIME-Version: 1.0 X-Rspamd-Queue-Id: 98AA0268 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On the 88W8897 card it's very important the TX ring write pointer is updated correctly to its new value before setting the TX ready interrupt, otherwise the firmware appears to crash (probably because it's trying to DMA-read from the wrong place). The issue is present in the latest firmware version 15.68.19.p21 of the pcie+usb card. Since PCI uses "posted writes" when writing to a register, it's not guaranteed that a write will happen immediately. That means the pointer might be outdated when setting the TX ready interrupt, leading to firmware crashes especially when ASPM L1 and L1 substates are enabled (because of the higher link latency, the write will probably take longer). So fix those firmware crashes by always using a non-posted write for this specific register write. We do that by simply reading back the register after writing it, just as a few other PCI drivers do. This fixes a bug where during rx/tx traffic and with ASPM L1 substates enabled (the enabled substates are platform dependent), the firmware crashes and eventually a command timeout appears in the logs. Cc: stable@vger.kernel.org Signed-off-by: Jonas Dreßler --- drivers/net/wireless/marvell/mwifiex/pcie.c | 26 ++++++++++++++++++--- 1 file changed, 23 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c index c6ccce426b49..0eff717ac5fa 100644 --- a/drivers/net/wireless/marvell/mwifiex/pcie.c +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c @@ -240,6 +240,20 @@ static int mwifiex_write_reg(struct mwifiex_adapter *adapter, int reg, u32 data) return 0; } +/* + * This function does a non-posted write into a PCIE card register, ensuring + * it's completion before returning. + */ +static int mwifiex_write_reg_np(struct mwifiex_adapter *adapter, int reg, u32 data) +{ + struct pcie_service_card *card = adapter->card; + + iowrite32(data, card->pci_mmap1 + reg); + ioread32(card->pci_mmap1 + reg); + + return 0; +} + /* This function reads data from PCIE card register. */ static int mwifiex_read_reg(struct mwifiex_adapter *adapter, int reg, u32 *data) @@ -1482,9 +1496,15 @@ mwifiex_pcie_send_data(struct mwifiex_adapter *adapter, struct sk_buff *skb, reg->tx_rollover_ind); rx_val = card->rxbd_rdptr & reg->rx_wrap_mask; - /* Write the TX ring write pointer in to reg->tx_wrptr */ - if (mwifiex_write_reg(adapter, reg->tx_wrptr, - card->txbd_wrptr | rx_val)) { + /* Write the TX ring write pointer in to reg->tx_wrptr. + * The firmware (latest version 15.68.19.p21) of the 88W8897 + * pcie+usb card seems to crash when getting the TX ready + * interrupt but the TX ring write pointer points to an outdated + * address, so it's important we do a non-posted write here to + * force the completion of the write. + */ + if (mwifiex_write_reg_np(adapter, reg->tx_wrptr, + card->txbd_wrptr | rx_val)) { mwifiex_dbg(adapter, ERROR, "SEND DATA: failed to write reg->tx_wrptr\n"); ret = -1; From patchwork Tue Sep 14 11:48:13 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Jonas_Dre=C3=9Fler?= X-Patchwork-Id: 511667 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F0F44C43219 for ; Tue, 14 Sep 2021 11:49:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D612160E52 for ; Tue, 14 Sep 2021 11:49:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232341AbhINLuf (ORCPT ); Tue, 14 Sep 2021 07:50:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56412 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232524AbhINLuD (ORCPT ); Tue, 14 Sep 2021 07:50:03 -0400 Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [IPv6:2001:67c:2050::465:102]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4CED3C061574; Tue, 14 Sep 2021 04:48:46 -0700 (PDT) Received: from smtp102.mailbox.org (smtp102.mailbox.org [IPv6:2001:67c:2050:105:465:1:3:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4H81p43fQSzQkBS; Tue, 14 Sep 2021 13:48:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de From: =?utf-8?q?Jonas_Dre=C3=9Fler?= To: Amitkumar Karwar , Ganapathi Bhat , Xinming Hu , Kalle Valo , "David S. Miller" , Jakub Kicinski Cc: =?utf-8?q?Jonas_Dre=C3=9Fler?= , Tsuchiya Yuto , linux-wireless@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, Maximilian Luz , Andy Shevchenko , Bjorn Helgaas , =?utf-8?q?Pali_Roh=C3=A1r?= , Heiner Kallweit , Johannes Berg , Brian Norris , stable@vger.kernel.org Subject: [PATCH v2 2/2] mwifiex: Try waking the firmware until we get an interrupt Date: Tue, 14 Sep 2021 13:48:13 +0200 Message-Id: <20210914114813.15404-3-verdre@v0yd.nl> In-Reply-To: <20210914114813.15404-1-verdre@v0yd.nl> References: <20210914114813.15404-1-verdre@v0yd.nl> MIME-Version: 1.0 X-Rspamd-Queue-Id: 94A12268 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org It seems that the firmware of the 88W8897 card sometimes ignores or misses when we try to wake it up by writing to the firmware status register. This leads to the firmware wakeup timeout expiring and the driver resetting the card because we assume the firmware has hung up or crashed (unfortunately that's not unlikely with this card). Turns out that most of the time the firmware actually didn't hang up, but simply "missed" our wakeup request and didn't send us an AWAKE event. Trying again to read the firmware status register after a short timeout usually makes the firmware wake up as expected, so add a small retry loop to mwifiex_pm_wakeup_card() that looks at the interrupt status to check whether the card woke up. The number of tries and timeout lengths for this were determined experimentally: The firmware usually takes about 500 us to wake up after we attempt to read the status register. In some cases where the firmware is very busy (for example while doing a bluetooth scan) it might even miss our requests for multiple milliseconds, which is why after 15 tries the waiting time gets increased to 10 ms. The maximum number of tries it took to wake the firmware when testing this was around 20, so a maximum number of 50 tries should give us plenty of safety margin. A good reproducer for this issue is letting the firmware sleep and wake up in very short intervals, for example by pinging a device on the network every 0.1 seconds. Cc: stable@vger.kernel.org Signed-off-by: Jonas Dreßler --- drivers/net/wireless/marvell/mwifiex/pcie.c | 33 +++++++++++++++++---- 1 file changed, 27 insertions(+), 6 deletions(-) diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c index 0eff717ac5fa..7fea319e013c 100644 --- a/drivers/net/wireless/marvell/mwifiex/pcie.c +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c @@ -661,11 +661,15 @@ static void mwifiex_delay_for_sleep_cookie(struct mwifiex_adapter *adapter, "max count reached while accessing sleep cookie\n"); } +#define N_WAKEUP_TRIES_SHORT_INTERVAL 15 +#define N_WAKEUP_TRIES_LONG_INTERVAL 35 + /* This function wakes up the card by reading fw_status register. */ static int mwifiex_pm_wakeup_card(struct mwifiex_adapter *adapter) { struct pcie_service_card *card = adapter->card; const struct mwifiex_pcie_card_reg *reg = card->pcie.reg; + int n_tries = 0; mwifiex_dbg(adapter, EVENT, "event: Wakeup device...\n"); @@ -673,12 +677,29 @@ static int mwifiex_pm_wakeup_card(struct mwifiex_adapter *adapter) if (reg->sleep_cookie) mwifiex_pcie_dev_wakeup_delay(adapter); - /* Accessing fw_status register will wakeup device */ - if (mwifiex_write_reg(adapter, reg->fw_status, FIRMWARE_READY_PCIE)) { - mwifiex_dbg(adapter, ERROR, - "Writing fw_status register failed\n"); - return -1; - } + /* Access the fw_status register to wake up the device. + * Since the 88W8897 firmware sometimes appears to ignore or miss + * that wakeup request, we continue trying until we receive an + * interrupt from the card. + */ + do { + if (mwifiex_write_reg(adapter, reg->fw_status, FIRMWARE_READY_PCIE)) { + mwifiex_dbg(adapter, ERROR, + "Writing fw_status register failed\n"); + return -EIO; + } + + n_tries++; + + if (n_tries <= N_WAKEUP_TRIES_SHORT_INTERVAL) + usleep_range(400, 700); + else + msleep(10); + } while (n_tries <= N_WAKEUP_TRIES_SHORT_INTERVAL + N_WAKEUP_TRIES_LONG_INTERVAL && + READ_ONCE(adapter->int_status) == 0); + + mwifiex_dbg(adapter, EVENT, + "event: Tried %d times until firmware woke up\n", n_tries); if (reg->sleep_cookie) { mwifiex_pcie_dev_wakeup_delay(adapter);