linux-toradex.git/drivers/net/ethernet/intel, branch v4.4.95

igb: re-assign hw address pointer on reset after PCI error

2017-10-08T08:14:16+00:00

[ Upstream commit 69b97cf6dbce7403845a28bbc75d57f5be7b12ac ]

Whenever the igb driver detects the result of a read operation returns
a value composed only by F's (like 0xFFFFFFFF), it will detach the
net_device, clear the hw_addr pointer and warn to the user that adapter's
link is lost - those steps happen on igb_rd32().

In case a PCI error happens on Power architecture, there's a recovery
mechanism called EEH, that will reset the PCI slot and call driver's
handlers to reset the adapter and network functionality as well.

We observed that once hw_addr is NULL after the error is detected on
igb_rd32(), it's never assigned back, so in the process of resetting
the network functionality we got a NULL pointer dereference in both
igb_configure_tx_ring() and igb_configure_rx_ring(). In order to avoid
such bug, this patch re-assigns the hw_addr value in the slot_reset
handler.

Reported-by: Anthony H Thai 
Reported-by: Harsha Thyagaraja 
Signed-off-by: Guilherme G Piccoli 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

igb: add i211 to i210 PHY workaround

2017-03-30T07:35:19+00:00

From: Todd Fujinaka 

[ Upstream commit 5bc8c230e2a993b49244f9457499f17283da9ec7 ]

i210 and i211 share the same PHY but have different PCI IDs. Don't
forget i211 for any i210 workarounds.

Signed-off-by: Todd Fujinaka 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sumit Semwal 
Signed-off-by: Greg Kroah-Hartman

igb: Workaround for igb i210 firmware issue

2017-03-30T07:35:19+00:00

From: Chris J Arges 

[ Upstream commit 4e684f59d760a2c7c716bb60190783546e2d08a1 ]

Sometimes firmware may not properly initialize I347AT4_PAGE_SELECT causing
the probe of an igb i210 NIC to fail. This patch adds an addition zeroing
of this register during igb_get_phy_id to workaround this issue.

Thanks for Jochen Henneberg for the idea and original patch.

Signed-off-by: Chris J Arges 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sumit Semwal 
Signed-off-by: Greg Kroah-Hartman

i40e: fix call of ndo_dflt_bridge_getlink()

2016-11-18T09:48:36+00:00

commit 599b076d15ee3ead7af20fc907079df00b2d59a0 upstream.

Order of arguments is wrong.
The wrong code has been introduced by commit 7d4f8d871ab1, but is compiled
only since commit 9df70b66418e.

Note that this may break netlink dumps.

Fixes: 9df70b66418e ("i40e: Remove incorrect #ifdef's")
Fixes: 7d4f8d871ab1 ("switchdev; add VLAN support for port's bridge_getlink")
CC: Carolyn Wyborny 
Signed-off-by: Huaibin Wang 
Signed-off-by: Nicolas Dichtel 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Greg Kroah-Hartman

i40e: avoid NULL pointer dereference and recursive errors on early PCI error

2016-10-22T10:26:55+00:00

commit edfc23ee3e0ebbb6713d7574ab1b00abff178f6c upstream.

Although rare, it's possible to hit PCI error early on device
probe, meaning possibly some structs are not entirely initialized,
and some might even be completely uninitialized, leading to NULL
pointer dereference.

The i40e driver currently presents a "bad" behavior if device hits
such early PCI error: firstly, the struct i40e_pf might not be
attached to pci_dev yet, leading to a NULL pointer dereference on
access to pf->state.

Even checking if the struct is NULL and avoiding the access in that
case isn't enough, since the driver cannot recover from PCI error
that early; in our experiments we saw multiple failures on kernel
log, like:

  [549.664] i40e 0007:01:00.1: Initial pf_reset failed: -15
  [549.664] i40e: probe of 0007:01:00.1 failed with error -15
  [...]
  [871.644] i40e 0007:01:00.1: The driver for the device stopped because the
  device firmware failed to init. Try updating your NVM image.
  [871.644] i40e: probe of 0007:01:00.1 failed with error -32
  [...]
  [872.516] i40e 0007:01:00.0: ARQ: Unknown event 0x0000 ignored

Between the first probe failure (error -15) and the second (error -32)
another PCI error happened due to the first bad probe. Also, driver
started to flood console with those ARQ event messages.

This patch will prevent these issues by allowing error recovery
mechanism to remove the failed device from the system instead of
trying to recover from early PCI errors during device probe.

Signed-off-by: Guilherme G Piccoli 
Acked-by: Jacob Keller 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

i40e: avoid null pointer dereference

2016-10-07T13:23:41+00:00

commit cd956722167ba4fdba9c1ce3eed251b04ea2e10f upstream.

In function i40e_debug_aq parameter desc is assumed to be
possibly NULL. Do not dereference it before checking the
value.

Fixes: f905dd62be88 ("i40e/i40evf: add max buf len to aq debug print helper")
Signed-off-by: Heinrich Schuchardt 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Greg Kroah-Hartman

i40e/i40evf: Fix RSS rx-flow-hash configuration through ethtool

2016-09-15T06:27:43+00:00

[ Upstream commit 6e35c04cf633e55648acb9ccabff42aa37bd4044 ]

This patch fixes the Hash PCTYPE enable for X722 since it supports
a broader selection of PCTYPES for TCP and UDP.

This patch also fixes a bug in XL710, X710, X722 support for RSS,
as of now we cannot reduce the (4)tuple for RSS for TCP/IPv4/IPV6 or
UDP/IPv4/IPv6 packets since this requires a product feature change
that comes in a later release.

A VF should never be allowed to change the tuples for RSS for any
PCTYPE since that's a global setting for the device in case of i40e
devices.

Change-ID: I0ee7203c9b24813260f58f3220798bc9d9ac4a12
Signed-off-by: Anjali Singhai Jain 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

fm10k: Cleanup exception handling for mailbox interrupt

2016-09-15T06:27:39+00:00

[ Upstream commit e00e23bceba48a8f0c94fefe26948404cbd43d0a ]

This patch addresses two issues.

First is the fact that the fm10k_mbx_free_irq was assuming msix_entries was
valid and that will not always be the case.  As such we need to add a check
for if it is NULL.

Second is the fact that we weren't freeing the IRQ if the mailbox API
returned an error on trying to connect.

Signed-off-by: Alexander Duyck 
Reviewed-by: Bruce Allan 
Tested-by: Krishneil Singh 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

fm10k: Cleanup MSI-X interrupts in case of failure

2016-09-15T06:27:39+00:00

[ Upstream commit 587731e684dcf3522215194a02357d26b9bc7277 ]

If the q_vector allocation fails we should free the resources associated
with the MSI-X vector table.

Signed-off-by: Alexander Duyck 
Reviewed-by: Bruce Allan 
Tested-by: Krishneil Singh 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

fm10k: reinitialize queuing scheme after calling init_hw

2016-09-15T06:27:39+00:00

[ Upstream commit 875328e4bce696e85edcda3c4b0ec80fd525e3a3 ]

The init_hw function may fail, and in the case of VFs, it might change
the number of maximum queues available. Thus, for every flow which
checks init_hw, we need to ensure that we clear the queue scheme before,
and initialize it after. The fm10k_io_slot_reset path will end up
triggering a reset so fm10k_reinit needs this change. The
fm10k_io_error_detected and fm10k_io_resume also need to properly clear
and reinitialize the queue scheme.

Signed-off-by: Jacob Keller 
Reviewed-by: Bruce Allan 
Tested-by: Krishneil Singh 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman