linux-stable.git/drivers/net/ethernet/intel, branch linux-3.12.y

igb: add i211 to i210 PHY workaround

2017-04-07T07:17:54+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: Jiri Slaby

igb: Workaround for igb i210 firmware issue

2017-04-07T07:17:53+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: Jiri Slaby

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

2016-10-25T16:11:18+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: Jiri Slaby

ixgbe: fix broken PFC with X550

2016-03-07T14:40:54+00:00

commit cb78cf12d6e90f57f6e7d090867ef19b6a189dde upstream.

PFC is configuration is skipped for X550 devices due to a incorrect
device id check, fixing that to include X550 PFC configuration.

Signed-off-by: Vasu Dev 
Tested-by: Phil Schmitt 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Jiri Slaby

ixgbe: use correct FCoE DDP max check

2016-03-07T14:40:43+00:00

commit f10166aba2def9bc6443290231c60f7e2f70129b upstream.

Use fcoe_ddp_xid from netdev as this is correctly set for different
device IDs to avoid DDP skip error on X550 as "xid=0x20b out-of-range"

Signed-off-by: Vasu Dev 
Tested-by: Phil Schmitt 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Jiri Slaby

e1000: add dummy allocator to fix race condition between mtu change and netpoll

2015-05-15T07:10:37+00:00

commit 08e8331654d1d7b2c58045e549005bc356aa7810 upstream.

There is a race condition between e1000_change_mtu's cleanups and
netpoll, when we change the MTU across jumbo size:

Changing MTU frees all the rx buffers:
    e1000_change_mtu -> e1000_down -> e1000_clean_all_rx_rings ->
        e1000_clean_rx_ring

Then, close to the end of e1000_change_mtu:
    pr_info -> ... -> netpoll_poll_dev -> e1000_clean ->
        e1000_clean_rx_irq -> e1000_alloc_rx_buffers -> e1000_alloc_frag

And when we come back to do the rest of the MTU change:
    e1000_up -> e1000_configure -> e1000_configure_rx ->
        e1000_alloc_jumbo_rx_buffers

alloc_jumbo finds the buffers already != NULL, since data (shared with
page in e1000_rx_buffer->rxbuf) has been re-alloc'd, but it's garbage,
or at least not what is expected when in jumbo state.

This results in an unusable adapter (packets don't get through), and a
NULL pointer dereference on the next call to e1000_clean_rx_ring
(other mtu change, link down, shutdown):

BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: [] put_compound_page+0x7e/0x330

    [...]

Call Trace:
 [] put_page+0x55/0x60
 [] e1000_clean_rx_ring+0x134/0x200
 [] e1000_clean_all_rx_rings+0x45/0x60
 [] e1000_down+0x1c0/0x1d0
 [] ? deactivate_slab+0x7f0/0x840
 [] e1000_change_mtu+0xdc/0x170
 [] dev_set_mtu+0xa0/0x140
 [] do_setlink+0x218/0xac0
 [] ? nla_parse+0xb9/0x120
 [] rtnl_newlink+0x6d0/0x890
 [] ? kvm_clock_read+0x20/0x40
 [] ? sched_clock_cpu+0xa8/0x100
 [] rtnetlink_rcv_msg+0x92/0x260

By setting the allocator to a dummy version, netpoll can't mess up our
rx buffers.  The allocator is set back to a sane value in
e1000_configure_rx.

Fixes: edbbb3ca1077 ("e1000: implement jumbo receive with partial descriptors")
Signed-off-by: Sabrina Dubroca 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Jiri Slaby

ixgb: Call dev_kfree_skby_any instead of dev_kfree_skb.

2015-04-27T08:55:27+00:00

commit f7e79913a1d6a6139211ead3b03579b317d25a1f upstream.

Replace dev_kfree_skb with dev_kfree_skb_any in functions that can
be called in hard irq and other contexts.

Signed-off-by: "Eric W. Biederman" 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

igb: bring link up when PHY is powered up

2015-01-07T15:20:16+00:00

commit aec653c43b0c55667355e26d7de1236bda9fb4e3 upstream.

Call igb_setup_link() when the PHY is powered up.

Signed-off-by: Todd Fujinaka 
Reported-by: Jeff Westfahl 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Cc: Vincent Donnefort 
Signed-off-by: Jiri Slaby

igbvf: add missing iounmap() on error in igbvf_probe()

2014-08-26T12:12:18+00:00

commit de524681f88ff4ed293aa239f83c8cb04d59b47d upstream.

Add the missing iounmap() before return from igbvf_probe()
in the error handling case.

Signed-off-by: Wei Yongjun 
Tested-by: Aaron Brown 
Tested-by: Sibai Li 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Jiri Slaby

igbvf: integer wrapping bug setting the mtu

2014-08-26T12:12:18+00:00

commit 3de9e65f011b95235a789b12abc4730570cdb737 upstream.

If new_mtu is very large then "new_mtu + ETH_HLEN + ETH_FCS_LEN" can
wrap and the check on the next line can underflow. This is one of those
bugs which can be triggered by the user if you have namespaces
configured.

Also since this is something the user can trigger then we don't want to
have dev_err() message.

This is a static checker fix and I'm not sure what the impact is.

Signed-off-by: Dan Carpenter 
Tested-by: Aaron Brown 
Tested-by: Sibai Li Sibai.li@intel.com>
Signed-off-by: Jeff Kirsher 
Signed-off-by: Jiri Slaby