kernel/linux.git/drivers/net/ethernet/intel, branch linux-4.20.y

igb: Fix an issue that PME is not enabled during runtime suspend

2019-02-12T19:02:26+00:00

[ Upstream commit 1fb3a7a75e2efcc83ef21f2434069cddd6fae6f5 ] I210 ethernet card doesn't wakeup when a cable gets plugged. It's because its PME is not set. Since commit 42eca2302146 ("PCI: Don't touch card regs after runtime suspend D3"), if the PCI state is saved, pci_pm_runtime_suspend() stops calling pci_finish_runtime_suspend(), which enables the PCI PME. To fix the issue, let's not to save PCI states when it's runtime suspend, to let the PCI subsystem enables PME. Fixes: 42eca2302146 ("PCI: Don't touch card regs after runtime suspend D3") Signed-off-by: Kai-Heng Feng Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin

ice: Do not enable NAPI on q_vectors that have no rings

2019-02-12T19:02:26+00:00

[ Upstream commit eec903769b4ea476591ffff73bb7359f14f38c51 ] If ice driver has q_vectors w/ active NAPI that has no rings, then this will result in a divide by zero error. To correct it I am updating the driver code so that we only support NAPI on q_vectors that have 1 or more rings allocated to them. See commit 13a8cd191a2b ("i40e: Do not enable NAPI on q_vectors that have no rings") for detail. Signed-off-by: Young Xiao Acked-by: Anirudh Venkataramanan Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin

i40e: define proper net_device::neigh_priv_len

2019-02-12T19:02:26+00:00

[ Upstream commit 31389b53b3e0b535867af9090a5d19ec64768d55 ] Out of bound read reported by KASan. i40iw_net_event() reads unconditionally 16 bytes from neigh->primary_key while the memory allocated for "neighbour" struct is evaluated in neigh_alloc() as tbl->entry_size + dev->neigh_priv_len where "dev" is a net_device. But the driver does not setup dev->neigh_priv_len and we read beyond the neigh entry allocated memory, so the patch in the next mail fixes this. Signed-off-by: Konstantin Khorenko Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin

i40e: prevent overlapping tx_timeout recover

2019-02-12T19:02:08+00:00

[ Upstream commit d5585b7b6846a6d0f9517afe57be3843150719da ] If a TX hang occurs, we attempt to recover by incrementally resetting. If we're starved for CPU time, it's possible the reset doesn't actually complete (or even fire) before another tx_timeout fires causing us to fly through the different resets without actually doing them. This adds a bit to set and check if a timeout recovery is already pending and, if so, bail out of tx_timeout. The bit will get cleared at the end of i40e_rebuild when reset is complete. Signed-off-by: Alan Brady Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin

i40e: suppress bogus error message

2019-02-12T19:02:08+00:00

[ Upstream commit 7cd8eb0861981ad212ce4242a1870c4b5831ceff ] The i40e driver complains about unprivileged VFs trying to configure promiscuous mode each time a VF reset occurs. This isn't the fault of the poor VF driver - the PF driver itself is making the request. To fix this, skip the privilege check if the request is to disable all promiscuous activity. This gets rid of the bogus message, but doesn't affect privilege checks, since we really only care if the unprivileged VF is trying to enable promiscuous mode. Signed-off-by: Mitch Williams Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin

e1000e: allow non-monotonic SYSTIM readings

2019-01-26T08:20:40+00:00

[ Upstream commit e1f65b0d70e9e5c80e15105cd96fa00174d7c436 ] It seems with some NICs supported by the e1000e driver a SYSTIM reading may occasionally be few microseconds before the previous reading and if enabled also pass e1000e_sanitize_systim() without reaching the maximum number of rereads, even if the function is modified to check three consecutive readings (i.e. it doesn't look like a double read error). This causes an underflow in the timecounter and the PHC time jumps hours ahead. This was observed on 82574, I217 and I219. The fastest way to reproduce it is to run a program that continuously calls the PTP_SYS_OFFSET ioctl on the PHC. Modify e1000e_phc_gettime() to use timecounter_cyc2time() instead of timecounter_read() in order to allow non-monotonic SYSTIM readings and prevent the PHC from jumping. Cc: Richard Cochran Signed-off-by: Miroslav Lichvar Acked-by: Jacob Keller Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin

ixgbe: allow IPsec Tx offload in VEPA mode

2019-01-26T08:20:40+00:00

[ Upstream commit 7fa57ca443cffe81ce8416b57966bfb0370678a1 ] When it's possible that the PF might end up trying to send a packet to one of its own VFs, we have to forbid IPsec offload because the device drops the packets into a black hole. See commit 47b6f50077e6 ("ixgbe: disallow IPsec Tx offload when in SR-IOV mode") for more info. This really is only necessary when the device is in the default VEB mode. If instead the device is running in VEPA mode, the packets will go through the encryption engine and out the MAC/PHY as normal, and get "hairpinned" as needed by the switch. So let's not block IPsec offload when in VEPA mode. To get there with the ixgbe device, use the handy 'bridge' command: bridge link set dev eth1 hwmode vepa Signed-off-by: Shannon Nelson Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin

ixgbe: Fix race when the VF driver does a reset

2018-12-12T23:51:50+00:00

When the VF driver does a reset, it (at least the Linux one) writes to the VFCTRL register to issue a reset and then immediately sends a reset message using the mailbox API. This is racy because when the PF driver detects that the VFCTRL register reset pin has been asserted, it clears the mailbox memory. Depending on ordering, the reset message sent by the VF could be cleared by the PF driver. It then responds to the cleared message with a NACK which causes the VF driver to malfunction. Fix this by deferring clearing the mailbox memory until the reset message is received. Fixes: 939b701ad633 ("ixgbe: fix driver behaviour after issuing VFLR") Signed-off-by: Ross Lagerwall Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher

i40e: DRY rx_ptype handling code

2018-12-12T23:46:02+00:00

Move rx_ptype extracting to i40e_process_skb_fields() to avoid duplicating the code. Signed-off-by: Michał Mirosław Signed-off-by: Michał Mirosław Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher

i40e: fix VLAN.TCI == 0 RX HW offload

2018-12-12T23:40:42+00:00

This fixes two bugs in hardware VLAN offload: 1. VLAN.TCI == 0 was being dropped 2. there was a race between disabling of VLAN RX feature in hardware and processing RX queue, where packets processed in this window could have their VLAN information dropped Fix moves the VLAN handling into i40e_process_skb_fields() to save on duplicated code. i40e_receive_skb() becomes trivial and so is removed. Signed-off-by: Michał Mirosław Signed-off-by: Michał Mirosław Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher