linux-stable.git/drivers/net/ethernet, branch v4.2.7

net: mvneta: fix error path for building skb

2015-12-09T19:31:16+00:00

commit 26c17a179f3f64f92de6e837c14279a6431a7ab6 upstream.

In the actual RX processing, there is same error path for both descriptor
ring refilling and building skb fails. This is not correct, because after
successful refill, the ring is already updated with newly allocated
buffer. Then, in case of build_skb() fail, hitherto code left the original
buffer unmapped.

This patch fixes above situation by swapping error check of skb build with
DMA-unmap of original buffer.

Signed-off-by: Marcin Wojtas 
Acked-by: Simon Guinot 
Fixes a84e32894191 ("net: mvneta: fix refilling for Rx DMA buffers")
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: mvneta: Fix CPU_MAP registers initialisation

2015-12-09T19:31:16+00:00

commit 2502d0ef272da7058ef303b849a2c8dc324c2e2e upstream.

The CPU_MAP register is duplicated for each CPUs at different addresses,
each instance being at a different address.

However, the code so far was using CONFIG_NR_CPUS to initialise the CPU_MAP
registers for each registers, while the SoCs embed at most 4 CPUs.

This is especially an issue with multi_v7_defconfig, where CONFIG_NR_CPUS
is currently set to 16, resulting in writes to registers that are not
CPU_MAP.

Fixes: c5aff18204da ("net: mvneta: driver for Marvell Armada 370/XP network unit")
Signed-off-by: Maxime Ripard 
Signed-off-by: Gregory CLEMENT 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sfc: push partner queue for skb->xmit_more

2015-12-09T19:31:06+00:00

[ Upstream commit b2663a4f30e85ec606b806f5135413e6d5c78d1e ]

When the IP stack passes SKBs the sfc driver puts them in 2 different TX
queues (called partners), one for checksummed and one for not checksummed.
If the SKB has xmit_more set the driver will delay pushing the work to the
NIC.

When later it does decide to push the buffers this patch ensures it also
pushes the partner queue, if that also has any delayed work. Before this
fix the work in the partner queue would be left for a long time and cause
a netdev watchdog.

Fixes: 70b33fb ("sfc: add support for skb->xmit_more")
Reported-by: Jianlin Shi 
Signed-off-by: Martin Habets 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

stmmac: Correctly report PTP capabilities.

2015-12-09T19:31:05+00:00

[ Upstream commit e6dbe1eb2db0d7a14991c06278dd3030c45fb825 ]

priv->hwts_*_en indicate if timestamping is enabled/disabled at run
time. But  priv->dma_cap.time_stamp  and priv->dma_cap.atime_stamp
indicates HW is support for PTPv1/PTPv2.

Signed-off-by: Phil Reid 
Acked-by: Richard Cochran 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net/mlx4: Copy/set only sizeof struct mlx4_eqe bytes

2015-12-09T19:31:04+00:00

[ Upstream commit c02b05011fadf8e409e41910217ca689f2fc9d91 ]

When doing memcpy/memset of EQEs, we should use sizeof struct
mlx4_eqe as the base size and not caps.eqe_size which could be bigger.

If caps.eqe_size is bigger than the struct mlx4_eqe then we corrupt
data in the master context.

When using a 64 byte stride, the memcpy copied over 63 bytes to the
slave_eq structure.  This resulted in copying over the entire eqe of
interest, including its ownership bit -- and also 31 bytes of garbage
into the next WQE in the slave EQ -- which did NOT include the ownership
bit (and therefore had no impact).

However, once the stride is increased to 128, we are overwriting the
ownership bits of *three* eqes in the slave_eq struct.  This results
in an incorrect ownership bit for those eqes, which causes the eq to
seem to be full. The issue therefore surfaced only once 128-byte EQEs
started being used in SRIOV and (overarchitectures that have 128/256
byte cache-lines such as PPC) - e.g after commit 77507aa249ae
"net/mlx4_core: Enable CQE/EQE stride support".

Fixes: 08ff32352d6f ('mlx4: 64-byte CQE/EQE support')
Signed-off-by: Carol L Soto 
Signed-off-by: Jack Morgenstein 
Signed-off-by: Or Gerlitz 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: fec: normalize return value of pm_runtime_get_sync() in MDIO write

2015-12-09T19:31:04+00:00

[ Upstream commit 42ea4457aea7aaeddf0c0b06724f297608f5e9d2 ]

If fec MDIO write method succeeds its return value comes from
call to pm_runtime_get_sync().
But pm_runtime_get_sync() can also return 1.

In case of Micrel KSZ9031 PHY this value will then
be returned along the call chain of phy_write() ->
ksz9031_extended_write() -> ksz9031_center_flp_timing() ->
ksz9031_config_init() -> phy_init_hw() -> phy_attach_direct() ->
phy_connect_direct().

Then phy_connect() will cast it into a pointer using ERR_PTR(),
which then fec_enet_mii_probe() will try to dereference
resulting in an oops.

Fix it by normalizing return value of pm_runtime_get_sync()
to be zero if positive in MDIO write method.

Fixes: 8fff755e9f8d ("net: fec: Ensure clocks are enabled while using mdio bus")
Signed-off-by: Maciej Szmigiero 
Acked-by: Andrew Lunn 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: fec: Remove unneeded use of IS_ERR_VALUE() macro

2015-12-09T19:31:04+00:00

[ Upstream commit b0c6ce24911fcb64715de9569f0f7b4f54d1d045 ]

There is no need to use the IS_ERR_VALUE() macro for checking
the return value from pm_runtime_* functions.

Just do a simple negative test instead.

The semantic patch that makes this change is available
in scripts/coccinelle/api/pm_runtime.cocci.

Signed-off-by: Fabio Estevam 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

amd-xgbe: Fix race between access of desc and desc index

2015-12-09T19:31:03+00:00

[ Upstream commit 20986ed826cbb36bb8f2d77f872e3c52d8d30647 ]

During Tx cleanup it's still possible for the descriptor data to be
read ahead of the descriptor index. A memory barrier is required between
the read of the descriptor index and the start of the Tx cleanup loop.
This allows a change to a lighter-weight barrier in the Tx transmit
routine just before updating the current descriptor index.

Since the memory barrier does result in extra overhead on arm64, keep
the previous change to not chase the current descriptor value. This
prevents the execution of the barrier for each loop performed.

Suggested-by: Alexander Duyck 
Signed-off-by: Tom Lendacky 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

amd-xgbe: Use wmb before updating current descriptor count

2015-12-09T19:31:03+00:00

[ Upstream commit 20a41fba679d665cdae2808e2b9cae97c073351f ]

The code currently uses the lightweight dma_wmb barrier before updating
the current descriptor count. Under heavy load, the Tx cleanup routine
was seeing the updated current descriptor count before the updated
descriptor information. As a result, the Tx descriptor was being cleaned
up before it was used because it was not "owned" by the hardware yet,
resulting in a Tx queue hang.

Using the wmb barrier insures that the descriptor is updated before the
descriptor counter preventing the Tx queue hang. For extra insurance,
the Tx cleanup routine is changed to grab the current decriptor count on
entry and uses that initial value in the processing loop rather than
trying to chase the current value.

Signed-off-by: Tom Lendacky 
Tested-by: Christoffer Dall 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net/ibm/emac: bump version numbers for correct work with ethtool

2015-10-27T00:53:34+00:00

[ Upstream commit 661dfc65f7981481ba2e31aaa702371e82336e56 ]

The size of the MAC register dump used to be the size specified by the
reg property in the device tree.  Userland has no good way of finding
out that size, and it was not specified consistently for each MAC type,
so ethtool would end up printing junk at the end of the register dump
if the device tree didn't match the size it assumed.

Using the new version numbers indicates unambiguously that the size of
the MAC register dump is dependent only on the MAC type.

Fixes: 5369c71f7ca2 ("net/ibm/emac: fix size of emac dump memory areas")
Signed-off-by: Ivan Mikhaylov 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman