All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.