From patchwork Mon Aug 30 12:37:03 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: 504533 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, URIBL_BLOCKED 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 23A90C432BE for ; Mon, 30 Aug 2021 12:37:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0BB7C60F23 for ; Mon, 30 Aug 2021 12:37:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236607AbhH3Mik (ORCPT ); Mon, 30 Aug 2021 08:38:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50614 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234822AbhH3Mij (ORCPT ); Mon, 30 Aug 2021 08:38:39 -0400 Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [IPv6:2001:67c:2050::465:101]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BE505C06175F; Mon, 30 Aug 2021 05:37:45 -0700 (PDT) Received: from smtp202.mailbox.org (smtp202.mailbox.org [80.241.60.245]) (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-101.mailbox.org (Postfix) with ESMTPS id 4GyqbX26LtzQkBk; Mon, 30 Aug 2021 14:37:44 +0200 (CEST) Received: from spamfilter04.heinlein-hosting.de (spamfilter04.heinlein-hosting.de [80.241.56.122]) by smtp202.mailbox.org (Postfix) with ESMTP id C001737F; Mon, 30 Aug 2021 14:37:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp202.mailbox.org ([80.241.60.245]) by spamfilter04.heinlein-hosting.de (spamfilter04.heinlein-hosting.de [80.241.56.122]) (amavisd-new, port 10030) with ESMTP id bp41yfpSoChk; Mon, 30 Aug 2021 14:37:40 +0200 (CEST) Received: from suagaze.. (unknown [46.183.103.17]) (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 smtp202.mailbox.org (Postfix) with ESMTPSA id 1B743271; Mon, 30 Aug 2021 14:37:37 +0200 (CEST) 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?= Subject: [PATCH 1/2] mwifiex: Use non-posted PCI register writes Date: Mon, 30 Aug 2021 14:37:03 +0200 Message-Id: <20210830123704.221494-2-verdre@v0yd.nl> In-Reply-To: <20210830123704.221494-1-verdre@v0yd.nl> References: <20210830123704.221494-1-verdre@v0yd.nl> MIME-Version: 1.0 X-Rspamd-Queue-Id: C001737F X-Rspamd-UID: edda12 Precedence: bulk List-ID: X-Mailing-List: linux-wireless@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). 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 forcing non-posted writes. We do that by simply reading back the register after writing it, just as a lot of other drivers do. There are two reproducers that are fixed with this patch: 1) 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. That crash is fixed by using a non-posted write in mwifiex_pcie_send_data(). 2) When sending lots of commands to the card, waking it up from sleep in very quick intervals, the firmware eventually crashes. That crash appears to be fixed by some other non-posted write included here. Signed-off-by: Jonas Dreßler --- drivers/net/wireless/marvell/mwifiex/pcie.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c index c6ccce426b49..bfd6e135ed99 100644 --- a/drivers/net/wireless/marvell/mwifiex/pcie.c +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c @@ -237,6 +237,12 @@ static int mwifiex_write_reg(struct mwifiex_adapter *adapter, int reg, u32 data) iowrite32(data, card->pci_mmap1 + reg); + /* Do a read-back, which makes the write non-posted, ensuring the + * completion before returning. + * The firmware of the 88W8897 card is buggy and this avoids crashes. + */ + ioread32(card->pci_mmap1 + reg); + return 0; } From patchwork Mon Aug 30 12:37:04 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: 504876 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, URIBL_BLOCKED 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 82542C4320E for ; Mon, 30 Aug 2021 12:37:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6CB2960C40 for ; Mon, 30 Aug 2021 12:37:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236679AbhH3Miq (ORCPT ); Mon, 30 Aug 2021 08:38:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50642 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235173AbhH3Mip (ORCPT ); Mon, 30 Aug 2021 08:38:45 -0400 Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [IPv6:2001:67c:2050::465:202]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C329BC061575; Mon, 30 Aug 2021 05:37:51 -0700 (PDT) Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:105:465:1:4: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-202.mailbox.org (Postfix) with ESMTPS id 4Gyqbf3YV9zQkJ0; Mon, 30 Aug 2021 14:37:50 +0200 (CEST) Received: from gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173]) by smtp202.mailbox.org (Postfix) with ESMTP id 7D554272; Mon, 30 Aug 2021 14:37:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp202.mailbox.org ([80.241.60.245]) by gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173]) (amavisd-new, port 10030) with ESMTP id ZmaoWW-eg1AL; Mon, 30 Aug 2021 14:37:47 +0200 (CEST) Received: from suagaze.. (unknown [46.183.103.17]) (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 smtp202.mailbox.org (Postfix) with ESMTPSA id A1F423D0; Mon, 30 Aug 2021 14:37:42 +0200 (CEST) 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?= Subject: [PATCH 2/2] mwifiex: Try waking the firmware until we get an interrupt Date: Mon, 30 Aug 2021 14:37:04 +0200 Message-Id: <20210830123704.221494-3-verdre@v0yd.nl> In-Reply-To: <20210830123704.221494-1-verdre@v0yd.nl> References: <20210830123704.221494-1-verdre@v0yd.nl> MIME-Version: 1.0 X-Rspamd-Queue-Id: 7D554272 X-Rspamd-UID: 160a58 Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org It seems that the firmware of the 88W8897 card sometimes ignores or misses when we try to wake it up by reading 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 doesn't send us an AWAKE event. Trying again to read the firmware status register after a short timeout usually makes the firmware wake we 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 an device on the network every 0.1 seconds. Signed-off-by: Jonas Dreßler --- drivers/net/wireless/marvell/mwifiex/pcie.c | 29 ++++++++++++++++----- 1 file changed, 23 insertions(+), 6 deletions(-) diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c index bfd6e135ed99..14742bdb96ef 100644 --- a/drivers/net/wireless/marvell/mwifiex/pcie.c +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c @@ -658,6 +658,7 @@ 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"); @@ -665,12 +666,28 @@ 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 -1; + } + + n_tries++; + + if (n_tries <= 15) + usleep_range(400, 700); + else + msleep(10); + } while (n_tries <= 50 && 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);