From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
To: davem@davemloft.net
Cc: Jacob Keller <jacob.e.keller@intel.com>,
netdev@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com,
jogreene@redhat.com, Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Subject: [net-next 04/17] fm10k: always check init_hw for errors
Date: Thu, 3 Dec 2015 16:29:41 -0800 [thread overview]
Message-ID: <1449188994-64940-5-git-send-email-jeffrey.t.kirsher@intel.com> (raw)
In-Reply-To: <1449188994-64940-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
A recent change modified init_hw in some flows the function may fail on
VF devices. For example, if a VF doesn't yet own its own queues.
However, many callers of init_hw didn't bother to check the error code.
Other callers checked but only displayed diagnostic messages without
actually handling the consequences.
Fix this by (a) always returning and preventing the netdevice from going
up, and (b) printing the diagnostic in every flow for consistency. This
should resolve an issue where VF drivers would attempt to come up
before the PF has finished assigning queues.
In addition, change the dmesg output to explicitly show the actual
function that failed, instead of combining reset_hw and init_hw into a
single check, to help for future debugging.
Fixes: 1d568b0f6424 ("fm10k: do not assume VF always has 1 queue")
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Krishneil Singh <Krishneil.k.singh@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 34 ++++++++++++++++++++++++----
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_pci.c b/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
index 1af4b22..9c21d1e 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
@@ -163,9 +163,17 @@ static void fm10k_reinit(struct fm10k_intfc *interface)
interface->last_reset = jiffies + (10 * HZ);
/* reset and initialize the hardware so it is in a known state */
- err = hw->mac.ops.reset_hw(hw) ? : hw->mac.ops.init_hw(hw);
- if (err)
+ err = hw->mac.ops.reset_hw(hw);
+ if (err) {
+ dev_err(&interface->pdev->dev, "reset_hw failed: %d\n", err);
+ goto reinit_err;
+ }
+
+ err = hw->mac.ops.init_hw(hw);
+ if (err) {
dev_err(&interface->pdev->dev, "init_hw failed: %d\n", err);
+ goto reinit_err;
+ }
/* reassociate interrupts */
fm10k_mbx_request_irq(interface);
@@ -193,6 +201,10 @@ static void fm10k_reinit(struct fm10k_intfc *interface)
fm10k_iov_resume(interface->pdev);
+reinit_err:
+ if (err)
+ netif_device_detach(netdev);
+
rtnl_unlock();
clear_bit(__FM10K_RESETTING, &interface->state);
@@ -1684,7 +1696,13 @@ static int fm10k_sw_init(struct fm10k_intfc *interface,
interface->last_reset = jiffies + (10 * HZ);
/* reset and initialize the hardware so it is in a known state */
- err = hw->mac.ops.reset_hw(hw) ? : hw->mac.ops.init_hw(hw);
+ err = hw->mac.ops.reset_hw(hw);
+ if (err) {
+ dev_err(&pdev->dev, "reset_hw failed: %d\n", err);
+ return err;
+ }
+
+ err = hw->mac.ops.init_hw(hw);
if (err) {
dev_err(&pdev->dev, "init_hw failed: %d\n", err);
return err;
@@ -2064,8 +2082,10 @@ static int fm10k_resume(struct pci_dev *pdev)
/* reset hardware to known state */
err = hw->mac.ops.init_hw(&interface->hw);
- if (err)
+ if (err) {
+ dev_err(&pdev->dev, "init_hw failed: %d\n", err);
return err;
+ }
/* reset statistics starting values */
hw->mac.ops.rebind_hw_stats(hw, &interface->stats);
@@ -2241,7 +2261,11 @@ static void fm10k_io_resume(struct pci_dev *pdev)
int err = 0;
/* reset hardware to known state */
- hw->mac.ops.init_hw(&interface->hw);
+ err = hw->mac.ops.init_hw(&interface->hw);
+ if (err) {
+ dev_err(&pdev->dev, "init_hw failed: %d\n", err);
+ return;
+ }
/* reset statistics starting values */
hw->mac.ops.rebind_hw_stats(hw, &interface->stats);
--
2.5.0
next prev parent reply other threads:[~2015-12-04 0:29 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-04 0:29 [net-next 00/17][pull request] 100GbE Intel Wired LAN Driver Updates 2015-12-03 Jeff Kirsher
2015-12-04 0:29 ` [net-next 01/17] fm10k: Fix error handling in the function fm10k_setup_tc for certain function calls Jeff Kirsher
2015-12-04 0:41 ` Joe Perches
2015-12-04 0:29 ` [net-next 02/17] fm10k: set netdev features in one location Jeff Kirsher
2015-12-04 0:29 ` [net-next 03/17] fm10k: reset max_queues on init_hw_vf failure Jeff Kirsher
2015-12-04 0:29 ` Jeff Kirsher [this message]
2015-12-04 0:29 ` [net-next 05/17] fm10k: reinitialize queuing scheme after calling init_hw Jeff Kirsher
2015-12-04 0:29 ` [net-next 06/17] fm10k: Correct typecast in fm10k_update_xc_addr_pf Jeff Kirsher
2015-12-04 0:29 ` [net-next 07/17] fm10k: explicitly typecast vlan values to u16 Jeff Kirsher
2015-12-04 0:29 ` [net-next 08/17] fm10k: add statistics for actual DWORD count of mbmem mailbox Jeff Kirsher
2015-12-04 0:29 ` [net-next 09/17] fm10k: rename mbx_tx_oversized statistic to mbx_tx_dropped Jeff Kirsher
2015-12-04 0:29 ` [net-next 10/17] fm10k: add TEB check to fm10k_gre_is_nvgre Jeff Kirsher
2015-12-04 0:54 ` Tom Herbert
2015-12-04 23:03 ` Jeff Kirsher
2015-12-04 0:29 ` [net-next 11/17] fm10k: Add support for ITR scaling based on PCIe link speed Jeff Kirsher
2015-12-04 0:29 ` [net-next 12/17] fm10k: introduce ITR_IS_ADAPTIVE macro Jeff Kirsher
2015-12-04 0:29 ` [net-next 13/17] fm10k: Update adaptive ITR algorithm Jeff Kirsher
2015-12-04 0:29 ` [net-next 14/17] fm10k: use macro for default Tx and Rx ITR values Jeff Kirsher
2015-12-04 0:29 ` [net-next 15/17] fm10k: change default Tx ITR to 25usec Jeff Kirsher
2015-12-04 0:29 ` [net-next 16/17] fm10k: TRIVIAL fix typo of hardware Jeff Kirsher
2015-12-04 0:29 ` [net-next 17/17] fm10k: TRIVIAL cleanup order at top of fm10k_xmit_frame Jeff Kirsher
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=1449188994-64940-5-git-send-email-jeffrey.t.kirsher@intel.com \
--to=jeffrey.t.kirsher@intel.com \
--cc=davem@davemloft.net \
--cc=jacob.e.keller@intel.com \
--cc=jogreene@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=nhorman@redhat.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).