user/sven/linux.git/drivers/net, branch v4.20.5

ath10k: fix peer stats null pointer dereference

2019-01-26T08:20:50Z

[ Upstream commit 2d3b55853b123c177037cf534c5aaa2650310094 ] There was a race condition in SMP that an ath10k_peer was created but its member sta was null. Following are procedures of ath10k_peer creation and member sta access in peer statistics path. 1. Peer creation: ath10k_peer_create() =>ath10k_wmi_peer_create() =>ath10k_wait_for_peer_created() ... # another kernel path, RX from firmware ath10k_htt_t2h_msg_handler() =>ath10k_peer_map_event() =>wake_up() # ar->peer_map[id] = peer //add peer to map #wake up original path from waiting ... # peer->sta = sta //sta assignment 2. RX path of statistics ath10k_htt_t2h_msg_handler() =>ath10k_update_per_peer_tx_stats() =>ath10k_htt_fetch_peer_stats() # peer->sta //sta accessing Any access of peer->sta after peer was added to peer_map but before sta was assigned could cause a null pointer issue. And because these two steps are asynchronous, no proper lock can protect them. So both peer and sta need to be checked before access. Tested: QCA9984 with firmware ver 10.4-3.9.0.1-00005 Signed-off-by: Zhi Chen Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin

net: ethernet: ave: Set initial wol state to disabled

2019-01-26T08:20:43Z

[ Upstream commit 7200f2e3c9e267d29e2bfa075794339032e0b98e ] If wol state of phy hardware is enabled after reset, phy_ethtool_get_wol() returns that wol.wolopts is true. However, since net_device.wol_enabled is zero and this doesn't apply wol state until calling ethtool_set_wol(), so mdio_bus_phy_may_suspend() returns true, that is, it's in a state where phy can suspend even though wol state is enabled. In this inconsistency, phy_suspend() returns -EBUSY, and at last, suspend sequence fails with the following message: dpm_run_callback(): mdio_bus_phy_suspend+0x0/0x58 returns -16 PM: Device 65000000.ethernet-ffffffff:01 failed to suspend: error -16 PM: Some devices failed to suspend, or early wake event detected In order to fix the above issue, this patch forces to set initial wol state to disabled as default. Signed-off-by: Kunihiko Hayashi Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

e1000e: allow non-monotonic SYSTIM readings

2019-01-26T08:20:40Z

[ 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:40Z

[ 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

qtnfmac: fix error handling in control path

2019-01-26T08:20:39Z

[ Upstream commit 1066bd193d681bda0fbacda9df351241a5ee04d9 ] This patch fixes the following warnings: - smatch drivers/net/wireless/quantenna/qtnfmac/commands.c:132 qtnf_cmd_send_with_reply() warn: variable dereferenced before check 'resp' (see line 117) drivers/net/wireless/quantenna/qtnfmac/commands.c:716 qtnf_cmd_get_sta_info() error: uninitialized symbol 'var_resp_len'. drivers/net/wireless/quantenna/qtnfmac/commands.c:1668 qtnf_cmd_get_mac_info() error: uninitialized symbol 'var_data_len'. drivers/net/wireless/quantenna/qtnfmac/commands.c:1697 qtnf_cmd_get_hw_info() error: uninitialized symbol 'info_len'. drivers/net/wireless/quantenna/qtnfmac/commands.c:1753 qtnf_cmd_band_info_get() error: uninitialized symbol 'info_len'. drivers/net/wireless/quantenna/qtnfmac/commands.c:1782 qtnf_cmd_send_get_phy_params() error: uninitialized symbol 'response_size'. drivers/net/wireless/quantenna/qtnfmac/commands.c:2438 qtnf_cmd_get_chan_stats() error: uninitialized symbol 'var_data_len'. - gcc-8.2.1 drivers/net/wireless/quantenna/qtnfmac/commands.c: In function 'qtnf_cmd_send_with_reply': drivers/net/wireless/quantenna/qtnfmac/commands.c:133:54: error: 'resp' may be used uninitialized in this function [-Werror=maybe-uninitialized] Reported-by: Dan Carpenter Reported-by: Arnd Bergmann Signed-off-by: Sergey Matyukevich Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin

octeontx2-af: Fix a resource leak in an error handling path in 'cgx_probe()'

2019-01-26T08:20:38Z

[ Upstream commit 1492623e837fe7ca6296f7f5411328307e242771 ] If an error occurs after the call to 'pci_alloc_irq_vectors()', we must call 'pci_free_irq_vectors()' in order to avoid a resource leak. The same sequence is already in place in the corresponding 'cgx_remove()' function. Fixes: 1463f382f58d ("octeontx2-af: Add support for CGX link management") Signed-off-by: Christophe JAILLET Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

r8169: Add support for new Realtek Ethernet

2019-01-26T08:20:38Z

[ Upstream commit 36352991835ce99e46b4441dd0eb6980f9a83e8f ] There are two new Realtek Ethernet devices which are re-branded r8168h. Add the IDs to to support them. Signed-off-by: Kai-Heng Feng Reviewed-by: Heiner Kallweit Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

qmi_wwan: add MTU default to qmap network interface

2019-01-26T08:20:38Z

[ Upstream commit f87118d5760f00af7228033fbe783c7f380d2866 ] This patch adds MTU default value to qmap network interface in order to avoid "RTNETLINK answers: No buffer space available" error when setting an ipv6 address. Signed-off-by: Daniele Palmas Acked-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net: dsa: mv88x6xxx: mv88e6390 errata

2019-01-26T08:20:38Z

[ Upstream commit ea89098ef9a574bceca00d3b5df14aaf0b3f9ccf ] The 6390 copper ports have an errata which require poking magic values into undocumented magic registers and then performing a software reset. Signed-off-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

mlxsw: spectrum_switchdev: Set PVID correctly during VLAN deletion

2019-01-26T08:20:37Z

[ Upstream commit 674bed5df4cab8f96d04f7b99608883a48f9226b ] When a VLAN is deleted from a bridge port we should not change the PVID unless the deleted VLAN is the PVID. Fixes: fe9ccc785de5 ("mlxsw: spectrum_switchdev: Don't batch VLAN operations") Signed-off-by: Ido Schimmel Acked-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman