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

net: mvpp2: fix dma unmapping of TX buffers for fragments

2017-01-09T07:32:25+00:00

commit 8354491c9d5b06709384cea91d13019bf5e61449 upstream.

Since commit 71ce391dfb784 ("net: mvpp2: enable proper per-CPU TX
buffers unmapping"), we are not correctly DMA unmapping TX buffers for
fragments.

Indeed, the mvpp2_txq_inc_put() function only stores in the
txq_cpu->tx_buffs[] array the physical address of the buffer to be
DMA-unmapped when skb != NULL. In addition, when DMA-unmapping, we use
skb_headlen(skb) to get the size to be unmapped. Both of this works fine
for TX descriptors that are associated directly to a SKB, but not the
ones that are used for fragments, with a NULL pointer as skb:

 - We have a NULL physical address when calling DMA unmap
 - skb_headlen(skb) crashes because skb is NULL

This causes random crashes when fragments are used.

To solve this problem, we need to:

 - Store the physical address of the buffer to be unmapped
   unconditionally, regardless of whether it is tied to a SKB or not.

 - Store the length of the buffer to be unmapped, which requires a new
   field.

Instead of adding a third array to store the length of the buffer to be
unmapped, and as suggested by David Miller, this commit refactors the
tx_buffs[] and tx_skb[] arrays of 'struct mvpp2_txq_pcpu' into a
separate structure 'mvpp2_txq_pcpu_buf', to which a 'size' field is
added. Therefore, instead of having three arrays to allocate/free, we
have a single one, which also improve data locality, reducing the
impact on the CPU cache.

Fixes: 71ce391dfb784 ("net: mvpp2: enable proper per-CPU TX buffers unmapping")
Reported-by: Raphael G 
Cc: Raphael G 
Signed-off-by: Thomas Petazzoni 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: mlx5: Fix Kconfig help text

2016-12-10T04:08:32+00:00

Since the following commit, Infiniband and Ethernet have not been
mutually exclusive.

Fixes: 4aa17b28 mlx5: Enable mutual support for IB and Ethernet
Signed-off-by: Christopher Covington 
Signed-off-by: David S. Miller

net: smsc911x: back out silently on probe deferrals

2016-12-10T04:05:16+00:00

When trying to get a regulator we may get deferred and we see
this noise:

smsc911x 1b800000.ethernet-ebi2 (unnamed net_device) (uninitialized):
   couldn't get regulators -517

Then the driver continues anyway. Which means that the regulator
may not be properly retrieved and reference counted, and may be
switched off in case noone else is using it.

Fix this by returning silently on deferred probe and let the
system work it out.

Cc: Jeremy Linton 
Signed-off-by: Linus Walleij 
Signed-off-by: David S. Miller

ibmveth: set correct gso_size and gso_type

2016-12-10T03:47:22+00:00

This patch is based on an earlier one submitted
by Jon Maxwell with the following commit message:

"We recently encountered a bug where a few customers using ibmveth on the
same LPAR hit an issue where a TCP session hung when large receive was
enabled. Closer analysis revealed that the session was stuck because the
one side was advertising a zero window repeatedly.

We narrowed this down to the fact the ibmveth driver did not set gso_size
which is translated by TCP into the MSS later up the stack. The MSS is
used to calculate the TCP window size and as that was abnormally large,
it was calculating a zero window, even although the sockets receive buffer
was completely empty."

We rely on the Virtual I/O Server partition in a pseries
environment to provide the MSS through the TCP header checksum
field. The stipulation is that users should not disable checksum
offloading if rx packet aggregation is enabled through VIOS.

Some firmware offerings provide the MSS in the RX buffer.
This is signalled by a bit in the RX queue descriptor.

Reviewed-by: Brian King 
Reviewed-by: Pradeep Satyanarayana 
Reviewed-by: Marcelo Ricardo Leitner 
Reviewed-by: Jonathan Maxwell 
Reviewed-by: David Dai 
Signed-off-by: Thomas Falcon 
Signed-off-by: David S. Miller

net: ethernet: cpmac: Call SET_NETDEV_DEV()

2016-12-09T02:26:58+00:00

The TI CPMAC driver calls into PHYLIB which now checks for
net_device->dev.parent, so make sure we do set it before calling into
any MDIO/PHYLIB related function.

Fixes: ec988ad78ed6 ("phy: Don't increment MDIO bus refcount unless it's a different owner")
Signed-off-by: Florian Fainelli 
Signed-off-by: David S. Miller

net: ethernet: lantiq_etop: Call SET_NETDEV_DEV()

2016-12-09T02:26:58+00:00

The Lantiq Etop driver calls into PHYLIB which now checks for
net_device->dev.parent, so make sure we do set it before calling into
any MDIO/PHYLIB related function.

Fixes: ec988ad78ed6 ("phy: Don't increment MDIO bus refcount unless it's a different owner")
Signed-off-by: Florian Fainelli 
Signed-off-by: David S. Miller

cxgb4/cxgb4vf: Assign netdev->dev_port with port ID

2016-12-08T23:20:08+00:00

Added missing dev_port assignment in cxgb4vf driver.
Also made dev_port assignment of cxgb4 in sync with cxgb4vf driver.

Signed-off-by: Casey Leedom 
Signed-off-by: Arjun V 
Signed-off-by: Hariprasad Shenai 
Signed-off-by: Ganesh Goudar 
Signed-off-by: David S. Miller

drivers: net: cpsw-phy-sel: Clear RGMII_IDMODE on "rgmii" links

2016-12-07T18:12:17+00:00

Support for setting the RGMII_IDMODE bit was added in the commit
referenced below. However, that commit did not add the symmetrical
clearing of the bit by way of setting it in "mask". Add it here.

Note that the documentation marks clearing this bit as "reserved",
however, according to TI, support for delaying the clock does exist in
the MAC, although it is not officially supported.
We tested this on a board with an RGMII to RGMII link that will not
work unless this bit is cleared.

Fixes: 0fb26c3063ea ("drivers: net: cpsw-phy-sel: add support to configure rgmii internal delay")
Signed-off-by: Alexandru Gagniuc 
Signed-off-by: David S. Miller

net/mlx5e: Change the SQ/RQ operational state to positive logic

2016-12-06T16:44:45+00:00

When using the negative logic (i.e. FLUSH state), after the RQ/SQ reopen
we will have a time interval that the RQ/SQ is not really ready and the
state indicates that its not in FLUSH state because the initial SQ/RQ struct
memory starts as zeros.
Now we changed the state to indicate if the SQ/RQ is opened and we will
set the READY state after finishing preparing all the SQ/RQ resources.

Fixes: 6e8dd6d6f4bd ("net/mlx5e: Don't wait for SQ completions on close")
Fixes: f2fde18c52a7 ("net/mlx5e: Don't wait for RQ completions on close")
Signed-off-by: Mohamad Haj Yahia 
Signed-off-by: Saeed Mahameed 
Signed-off-by: David S. Miller

net/mlx5e: Don't flush SQ on error

2016-12-06T16:44:44+00:00

We are doing SQ descriptors cleanup in driver.

Fixes: 6e8dd6d6f4bd ("net/mlx5e: Don't wait for SQ completions on close")
Signed-off-by: Saeed Mahameed 
Signed-off-by: David S. Miller