kernel/linux.git/drivers/net/ethernet, branch v3.18.62

bgmac: reset & enable Ethernet core before using it

2017-07-15T08:14:38+00:00

commit b4dfd8e92956b396d3438212bc9a0be6267b8b34 upstream. This fixes Ethernet on D-Link DIR-885L with BCM47094 SoC. Felix reported similar fix was needed for his BCM4709 device (Buffalo WXR-1900DHP?). I tested this for regressions on BCM4706, BCM4708A0 and BCM47081A0. Cc: Felix Fietkau Signed-off-by: Rafał Miłecki Signed-off-by: David S. Miller Signed-off-by: Amit Pundir Signed-off-by: Greg Kroah-Hartman

bgmac: fix device initialization on Northstar SoCs (condition typo)

2017-07-15T08:14:38+00:00

commit 21697336d46b71dd031f29e426dda0b1e7f06cc0 upstream. On Northstar (Broadcom's ARM architecture) we need to manually enable all cores. Code for that is already in place, but the condition for it was wrong. Signed-off-by: Rafał Miłecki Signed-off-by: David S. Miller Signed-off-by: Amit Pundir Signed-off-by: Greg Kroah-Hartman

net: korina: Fix NAPI versus resources freeing

2017-07-05T12:35:14+00:00

commit e6afb1ad88feddf2347ea779cfaf4d03d3cd40b6 upstream. Commit beb0babfb77e ("korina: disable napi on close and restart") introduced calls to napi_disable() that were missing before, unfortunately this leaves a small window during which NAPI has a chance to run, yet we just freed resources since korina_free_ring() has been called: Fix this by disabling NAPI first then freeing resource, and make sure that we also cancel the restart task before doing the resource freeing. Fixes: beb0babfb77e ("korina: disable napi on close and restart") Reported-by: Alexandros C. Couloumbis Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Amit Pundir Signed-off-by: Greg Kroah-Hartman

net: xilinx_emaclite: fix receive buffer overflow

2017-06-26T05:10:49+00:00

[ Upstream commit cd224553641848dd17800fe559e4ff5d208553e8 ] xilinx_emaclite looks at the received data to try to determine the Ethernet packet length but does not properly clamp it if proto_type == ETH_P_IP or 1500 < proto_type <= 1518, causing a buffer overflow and a panic via skb_panic() as the length exceeds the allocated skb size. Fix those cases. Also add an additional unconditional check with WARN_ON() at the end. Signed-off-by: Anssi Hannula Fixes: bb81b2ddfa19 ("net: add Xilinx emac lite device driver") Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

net: xilinx_emaclite: fix freezes due to unordered I/O

2017-06-26T05:10:48+00:00

[ Upstream commit acf138f1b00bdd1b7cd9894562ed0c2a1670888e ] The xilinx_emaclite uses __raw_writel and __raw_readl for register accesses. Those functions do not imply any kind of memory barriers and they may be reordered. The driver does not seem to take that into account, though, and the driver does not satisfy the ordering requirements of the hardware. For clear examples, see xemaclite_mdio_write() and xemaclite_mdio_read() which try to set MDIO address before initiating the transaction. I'm seeing system freezes with the driver with GCC 5.4 and current Linux kernels on Zynq-7000 SoC immediately when trying to use the interface. In commit 123c1407af87 ("net: emaclite: Do not use microblaze and ppc IO functions") the driver was switched from non-generic in_be32/out_be32 (memory barriers, big endian) to __raw_readl/__raw_writel (no memory barriers, native endian), so apparently the device follows system endianness and the driver was originally written with the assumption of memory barriers. Rather than try to hunt for each case of missing barrier, just switch the driver to use iowrite32/ioread32/iowrite32be/ioread32be depending on endianness instead. Tested on little-endian Zynq-7000 ARM SoC FPGA. Signed-off-by: Anssi Hannula Fixes: 123c1407af87 ("net: emaclite: Do not use microblaze and ppc IO functions") Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

mlx5: stop including

2017-06-14T10:54:21+00:00

commit adec640e03668e42f30f3b09c0b4d60d44545f6f upstream. is the placace the get the kmap type flags, asm-generic files are generic implementations only to be used by architecture code. Signed-off-by: Christoph Hellwig Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman

net: ethoc: enable NAPI before poll may be scheduled

2017-06-14T10:54:17+00:00

[ Upstream commit d220b942a4b6a0640aee78841608f4aa5e8e185e ] ethoc_reset enables device interrupts, ethoc_interrupt may schedule a NAPI poll before NAPI is enabled in the ethoc_open, which results in device being unable to send or receive anything until it's closed and reopened. In case the device is flooded with ingress packets it may be unable to recover at all. Move napi_enable above ethoc_reset in the ethoc_open to fix that. Fixes: a1702857724f ("net: Add support for the OpenCores 10/100 Mbps Ethernet MAC.") Signed-off-by: Max Filippov Reviewed-by: Tobias Klauser Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

cxgb4: avoid enabling napi twice to the same queue

2017-06-14T10:54:16+00:00

[ Upstream commit e7519f9926f1d0d11c776eb0475eb098c7760f68 ] Take uld mutex to avoid race between cxgb_up() and cxgb4_register_uld() to enable napi for the same uld queue. Signed-off-by: Ganesh Goudar Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

bnx2x: Fix Multi-Cos

2017-06-14T10:54:16+00:00

[ Upstream commit 3968d38917eb9bd0cd391265f6c9c538d9b33ffa ] Apparently multi-cos isn't working for bnx2x quite some time - driver implements ndo_select_queue() to allow queue-selection for FCoE, but the regular L2 flow would cause it to modulo the fallback's result by the number of queues. The fallback would return a queue matching the needed tc [via __skb_tx_hash()], but since the modulo is by the number of TSS queues where number of TCs is not accounted, transmission would always be done by a queue configured into using TC0. Fixes: ada7c19e6d27 ("bnx2x: use XPS if possible for bnx2x_select_queue instead of pure hash") Signed-off-by: Yuval Mintz Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

e1000e: fix call to do_div() to use u64 arg

2017-05-08T05:44:12+00:00

commit 30544af5483755b11bb5924736e9e0b45ef0644a upstream. We were using s64 for lat_ns (latency nano-second value) since in our calculations a negative value could be a resultant. For negative values, we then assign lat_ns to be zero, so the value passed to do_div() was never negative, but do_div() expects the argument type to be u64, so do a cast to resolve a compile warning seen on PowerPC. CC: Yanjiang Jin CC: Yanir Lubetkin Reported-by: Yanjiang Jin Signed-off-by: Jeff Kirsher Tested-by: Aaron Brown Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman