litmus-rt-ext-res.git/drivers/net/ethernet/intel, branch EXT-RES

igb: add i211 to i210 PHY workaround

2017-03-22T11:43:35+00:00

[ 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

igb: Workaround for igb i210 firmware issue

2017-03-22T11:43:35+00:00

[ 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

ixgbe/ixgbevf: Don't use lco_csum to compute IPv4 checksum

2016-12-01T20:41:36+00:00

In the case of IPIP and SIT tunnel frames the outer transport header
offset is actually set to the same offset as the inner transport header.
This results in the lco_csum call not doing any checksum computation over
the inner IPv4/v6 header data.

In order to account for that I am updating the code so that we determine
the location to start the checksum ourselves based on the location of the
IPv4 header and the length.

Fixes: b83e30104bd9 ("ixgbe/ixgbevf: Add support for GSO partial")
Signed-off-by: Alexander Duyck 
Signed-off-by: David S. Miller

igb/igbvf: Don't use lco_csum to compute IPv4 checksum

2016-12-01T20:41:35+00:00

In the case of IPIP and SIT tunnel frames the outer transport header
offset is actually set to the same offset as the inner transport header.
This results in the lco_csum call not doing any checksum computation over
the inner IPv4/v6 header data.

In order to account for that I am updating the code so that we determine
the location to start the checksum ourselves based on the location of the
IPv4 header and the length.

Fixes: e10715d3e961 ("igb/igbvf: Add support for GSO partial")
Reported-by: Stephen Rothwell 
Signed-off-by: Alexander Duyck 
Signed-off-by: David S. Miller

i40e: fix call of ndo_dflt_bridge_getlink()

2016-10-27T21:12:52+00:00

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

i40e: disable MSI-X interrupts if we cannot reserve enough vectors

2016-10-27T21:10:49+00:00

If we fail on allocating enough MSI-X interrupts, we should disable
them since they were previously enabled in this point of code.

Not disabling them can lead to WARN_ON() being triggered and subsequent
failure in enabling MSI as a fallback; the below message was shown without
this patch while we played with interrupt allocation in i40e driver:

[ 21.461346] sysfs: cannot create duplicate filename '/devices/pci0007:00/0007:00:00.0/0007:01:00.3/msi_irqs'
[ 21.461459] ------------[ cut here ]------------
[ 21.461514] WARNING: CPU: 64 PID: 1155 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x88/0xc0

Also, we noticed that without this patch, if we modprobe the module without
enough MSI-X interrupts (triggering the above warning), unload the module
and re-load it again, we got a crash on the system.

Signed-off-by: Guilherme G Piccoli 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher

i40e: Fix configure TCs after initial DCB disable

2016-10-27T21:08:56+00:00

in commit a036244c068612a43fa8c0f33a0eb4daa4d8dba0 a fix
was put into place to avoid a kernel panic when a non-
supported traffic class configuration was put into place
and then lldp was enabled/disabled on the link partner
switch.  This fix caused it to be necessary to
unload/reload the driver to reenable DCB once a supported
TC config was in place.

The root cause of the original panic was that the function
i40e_pf_get_default_tc was allowing for a default TC other
than TC 0, and only TC 0 is supported as a default.

This patch removes the get_default_tc function and replaces
it with a #define since there is only one TC supported as
a default.

Change-Id: I448371974e946386d0a7718d73668b450b7c72ef
Signed-off-by: Dave Ertman 
Tested-by: Ronald Bynoe 
Signed-off-by: Jeff Kirsher

ixgbe: fix panic when using macvlan with l2-fwd-offload enabled

2016-10-27T21:07:21+00:00

Fix NULL pointer dereference in the case where a macvlan interface is
brought up while the PF is still down:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
IP: [] ixgbe_alloc_rx_buffers+0x42/0x1a0 [ixgbe]

Call Trace:
[] ixgbe_configure_rx_ring+0x2eb/0x3d0 [ixgbe]
[] ixgbe_fwd_ring_up+0xd1/0x380 [ixgbe]
[] ixgbe_fwd_add+0x149/0x230 [ixgbe]
[] macvlan_open+0x260/0x2b0 [macvlan]

Reported-by: Matthew Garrett 
Signed-off-by: Emil Tantilov 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher

Merge branch '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue

2016-10-04T03:28:50+00:00

Jeff Kirsher says:

====================
100GbE Intel Wired LAN Driver Updates 2016-10-02

This series contains updates to fm10k only.

Jake fixes an issue where PTP applications requesting software timestamps
may complain that the requested mode is not supported, so add a generic
callback for those drivers that have software transmit timestamp support
enabled.  Then provides a trivial cleanup where a code was not wrapped
properly.  Got make sure that code looks good in a 80 character limit.
====================

Signed-off-by: David S. Miller

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

2016-10-04T03:26:54+00:00

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.

CC: 
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