From patchwork Fri Apr 14 21:51:19 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Brian Norris X-Patchwork-Id: 9681817 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 C66DC60386 for ; Fri, 14 Apr 2017 21:52:17 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B7C931FF29 for ; Fri, 14 Apr 2017 21:52:17 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id AB5131FFD6; Fri, 14 Apr 2017 21:52:17 +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 3B4FD1FF29 for ; Fri, 14 Apr 2017 21:52:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755260AbdDNVvv (ORCPT ); Fri, 14 Apr 2017 17:51:51 -0400 Received: from mail-pg0-f46.google.com ([74.125.83.46]:35650 "EHLO mail-pg0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755161AbdDNVvt (ORCPT ); Fri, 14 Apr 2017 17:51:49 -0400 Received: by mail-pg0-f46.google.com with SMTP id 72so39469527pge.2 for ; Fri, 14 Apr 2017 14:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=U15trQRWkCDTB+BwRn1cBqUNUTQMmBxM7SxCrZlnpD0=; b=hJ7M84MHAqYVjcQLyDD3eiFKJEbA+HKrMST0EwLPmE6QPKTqsNq9W/OW8xYcKXk0UZ 4VJem6Nlmw7R8DLmXRXxoK+L3o2okWcaRfphvIZO0JtN8k5sY+saOFUaRdXzHPPGxjDt JaE7nmCrkAuYymmGSUnzFUZbhNdvIzetLY70Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=U15trQRWkCDTB+BwRn1cBqUNUTQMmBxM7SxCrZlnpD0=; b=kb0mvpXnKh6zMrZTYuBL7SKtFIFqyewxE/FStLDDGuplYkrKjkFUZMQHJK8Jb3hGh2 zuHK4T4MXcGt5OrM1xi8S8zgVZXb6gA6RcXk7mnfvQdFmoXOg0YJGtbtM2Q40oO/g5Cy 75EfSTQewbcqAg9iiDwwCmNelfa6o54OGGnOZrJG8tCj2lxB/NcG4iRUzrP3u02CQu/4 LrLysH8phyf0CMg84PdCJ3j32vsQy9jlAkphpf1EkXLe+wk9XpFsDkLGQQSesrfieePP ORWIEQ7PeZpw8ErGCE9krYPc1TJCTJ63ZtovxoQx9gKIYZQ6Ry5BSs2KQItmXEPakKCR sARQ== X-Gm-Message-State: AN3rC/50kEt5aGHHJdb+AoOitekeCZaDdOU/3vaKvMEcqDl9JpVXj9Kc wjW0LyyWgW9R13tz X-Received: by 10.99.232.21 with SMTP id s21mr9244507pgh.67.1492206708538; Fri, 14 Apr 2017 14:51:48 -0700 (PDT) Received: from ban.mtv.corp.google.com ([172.22.64.120]) by smtp.gmail.com with ESMTPSA id n85sm4879081pfi.101.2017.04.14.14.51.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 14 Apr 2017 14:51:48 -0700 (PDT) From: Brian Norris To: Ganapathi Bhat , Nishant Sarmukadam Cc: , Dmitry Torokhov , Kalle Valo , linux-wireless@vger.kernel.org, Brian Norris Subject: [PATCH 3/4] mwifiex: pcie: clear outstanding work when resetting Date: Fri, 14 Apr 2017 14:51:19 -0700 Message-Id: <20170414215120.145038-3-briannorris@chromium.org> X-Mailer: git-send-email 2.12.2.762.g0e3151a226-goog In-Reply-To: <20170414215120.145038-1-briannorris@chromium.org> References: <20170414215120.145038-1-briannorris@chromium.org> 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 When we shut down the device (i.e., during 'reset'), we cancel any outstanding work, but we don't clear any work-related flags. This can cause problems if, e.g., we begin to queue a new firmware dump or card reset while the other one is in progress. That might leave work_flags with a stale value, and we might begin one of these *after* we've completely reset the device. That doesn't make sense, because all firmware context will have been lost by then. This fixes some forms of cascading failures, where I: (a) force a firmware dump (cat /sys/kernel/debug/mwifiex/mlan0/device_dump) (b) run a Wifi scan in parallel (iw mlan0 scan) (c) the scan times out due to (a) hogging the interface (d) the command timeout triggers another firmware dump and a reset [*] (e) the 2nd firmware dump flag persists across the reset (f) as soon as the interface comes back up, we trigger the pending firmware dump (g) subsequent commands time out again, while we are processing the firmware dump; return to (d) [*] Note that automatic card_reset() support is not yet implemented for the mwifiex PCIe driver, so we won't hit *exactly* this behavior yet. But we can see similarly-confusing behaviors today. Signed-off-by: Brian Norris --- This might qualify as 4.11 material (bugfix), though it's probably not too widely triggered yet. drivers/net/wireless/marvell/mwifiex/pcie.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c index 99e8a5cfda1b..bacac2949f10 100644 --- a/drivers/net/wireless/marvell/mwifiex/pcie.c +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c @@ -371,6 +371,8 @@ static void mwifiex_pcie_reset_notify(struct pci_dev *pdev, bool prepare) */ mwifiex_shutdown_sw(adapter); adapter->surprise_removed = true; + clear_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP, &card->work_flags); + clear_bit(MWIFIEX_IFACE_WORK_CARD_RESET, &card->work_flags); } else { /* Kernel stores and restores PCIe function context before and * after performing FLR respectively. Reconfigure the software