netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
To: davem@davemloft.net
Cc: Piotr Kwapulinski <piotr.kwapulinski@intel.com>,
	netdev@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com,
	Andrew Bowers <andrewx.bowers@intel.com>,
	Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Subject: [net-next 13/15] i40e: allow reset in recovery mode
Date: Wed, 21 Aug 2019 13:16:21 -0700	[thread overview]
Message-ID: <20190821201623.5506-14-jeffrey.t.kirsher@intel.com> (raw)
In-Reply-To: <20190821201623.5506-1-jeffrey.t.kirsher@intel.com>

From: Piotr Kwapulinski <piotr.kwapulinski@intel.com>

Driver waits after issuing a reset. When a reset takes too long a driver
gives up. Implemented by invoking PF reset in a loop. After defined
number of unsuccessful PF reset trials it returns error.
Without this patch PF reset fails when NIC is in recovery mode.

Signed-off-by: Piotr Kwapulinski <piotr.kwapulinski@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 drivers/net/ethernet/intel/i40e/i40e_main.c | 67 ++++++++++++++++++---
 1 file changed, 60 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 8d6b9515b595..fdf43d87e983 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -14564,6 +14564,51 @@ static bool i40e_check_recovery_mode(struct i40e_pf *pf)
 	return false;
 }
 
+/**
+ * i40e_pf_loop_reset - perform reset in a loop.
+ * @pf: board private structure
+ *
+ * This function is useful when a NIC is about to enter recovery mode.
+ * When a NIC's internal data structures are corrupted the NIC's
+ * firmware is going to enter recovery mode.
+ * Right after a POR it takes about 7 minutes for firmware to enter
+ * recovery mode. Until that time a NIC is in some kind of intermediate
+ * state. After that time period the NIC almost surely enters
+ * recovery mode. The only way for a driver to detect intermediate
+ * state is to issue a series of pf-resets and check a return value.
+ * If a PF reset returns success then the firmware could be in recovery
+ * mode so the caller of this code needs to check for recovery mode
+ * if this function returns success. There is a little chance that
+ * firmware will hang in intermediate state forever.
+ * Since waiting 7 minutes is quite a lot of time this function waits
+ * 10 seconds and then gives up by returning an error.
+ *
+ * Return 0 on success, negative on failure.
+ **/
+static i40e_status i40e_pf_loop_reset(struct i40e_pf *pf)
+{
+	const unsigned short MAX_CNT = 1000;
+	const unsigned short MSECS = 10;
+	struct i40e_hw *hw = &pf->hw;
+	i40e_status ret;
+	int cnt;
+
+	for (cnt = 0; cnt < MAX_CNT; ++cnt) {
+		ret = i40e_pf_reset(hw);
+		if (!ret)
+			break;
+		msleep(MSECS);
+	}
+
+	if (cnt == MAX_CNT) {
+		dev_info(&pf->pdev->dev, "PF reset failed: %d\n", ret);
+		return ret;
+	}
+
+	pf->pfr_count++;
+	return ret;
+}
+
 /**
  * i40e_init_recovery_mode - initialize subsystems needed in recovery mode
  * @pf: board private structure
@@ -14792,14 +14837,22 @@ static int i40e_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 
 	/* Reset here to make sure all is clean and to define PF 'n' */
 	i40e_clear_hw(hw);
-	if (!i40e_check_recovery_mode(pf)) {
-		err = i40e_pf_reset(hw);
-		if (err) {
-			dev_info(&pdev->dev, "Initial pf_reset failed: %d\n", err);
-			goto err_pf_reset;
-		}
-		pf->pfr_count++;
+
+	err = i40e_set_mac_type(hw);
+	if (err) {
+		dev_warn(&pdev->dev, "unidentified MAC or BLANK NVM: %d\n",
+			 err);
+		goto err_pf_reset;
 	}
+
+	err = i40e_pf_loop_reset(pf);
+	if (err) {
+		dev_info(&pdev->dev, "Initial pf_reset failed: %d\n", err);
+		goto err_pf_reset;
+	}
+
+	i40e_check_recovery_mode(pf);
+
 	hw->aq.num_arq_entries = I40E_AQ_LEN;
 	hw->aq.num_asq_entries = I40E_AQ_LEN;
 	hw->aq.arq_buf_size = I40E_MAX_AQ_BUF_SIZE;
-- 
2.21.0


  parent reply	other threads:[~2019-08-21 20:16 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-21 20:16 [net-next 00/15][pull request] 40GbE Intel Wired LAN Driver Updates 2019-08-21 Jeff Kirsher
2019-08-21 20:16 ` [net-next 01/15] i40e: reduce stack usage in i40e_set_fc Jeff Kirsher
2019-08-21 20:16 ` [net-next 02/15] i40e: Check if transceiver implements DDM before access Jeff Kirsher
2019-08-21 20:16 ` [net-next 03/15] i40e: add check on i40e_configure_tx_ring() return value Jeff Kirsher
2019-08-21 20:16 ` [net-next 04/15] i40e: fix shifts of signed values Jeff Kirsher
2019-08-21 20:16 ` [net-next 05/15] i40e: Add drop mode parameter to set mac config Jeff Kirsher
2019-08-21 20:16 ` [net-next 06/15] i40e: check_recovery_mode had wrong if statement Jeff Kirsher
2019-08-21 20:16 ` [net-next 07/15] i40e: Update x710 FW API version to 1.9 Jeff Kirsher
2019-08-21 20:16 ` [net-next 08/15] i40e: reset veb.tc_stats when resetting veb.stats Jeff Kirsher
2019-08-21 20:16 ` [net-next 09/15] i40e: Update x722 FW API version to 1.9 Jeff Kirsher
2019-08-21 20:16 ` [net-next 10/15] i40e: Fix crash caused by stress setting of VF MAC addresses Jeff Kirsher
2019-08-21 20:16 ` [net-next 11/15] i40e: Remove function i40e_update_dcb_config() Jeff Kirsher
2019-08-21 20:16 ` [net-next 12/15] i40e: make i40e_set_mac_type() public Jeff Kirsher
2019-08-21 20:16 ` Jeff Kirsher [this message]
2019-08-21 20:16 ` [net-next 14/15] i40e: Persistent LLDP support Jeff Kirsher
2019-08-21 20:16 ` [net-next 15/15] i40e: fix retrying in i40e_aq_get_phy_capabilities Jeff Kirsher
2019-08-21 21:31 ` [net-next 00/15][pull request] 40GbE Intel Wired LAN Driver Updates 2019-08-21 Jakub Kicinski
2019-08-21 22:55   ` David Miller

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=20190821201623.5506-14-jeffrey.t.kirsher@intel.com \
    --to=jeffrey.t.kirsher@intel.com \
    --cc=andrewx.bowers@intel.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@redhat.com \
    --cc=piotr.kwapulinski@intel.com \
    --cc=sassmann@redhat.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).