linux-toradex.git/drivers/net, branch v3.18.21

Revert "can: fix loss of CAN frames in raw_rcv"

2015-08-04T17:32:39+00:00

This reverts commit c215cf258214858a5a6c3e63cd7ee78b92d210b2.

Signed-off-by: Sasha Levin

can: fix loss of CAN frames in raw_rcv

2015-07-12T16:50:46+00:00

[ Upstream commit 36c01245eb8046c16eee6431e7dbfbb302635fa8 ]

As reported by Manfred Schlaegl here

   http://marc.info/?l=linux-netdev&m=143482089824232&w=2

commit 514ac99c64b "can: fix multiple delivery of a single CAN frame for
overlapping CAN filters" requires the skb->tstamp to be set to check for
identical CAN skbs.

As net timestamping is influenced by several players (netstamp_needed and
netdev_tstamp_prequeue) Manfred missed a proper timestamp which leads to
CAN frame loss.

As skb timestamping became now mandatory for CAN related skbs this patch
makes sure that received CAN skbs always have a proper timestamp set.
Maybe there's a better solution in the future but this patch fixes the
CAN frame loss so far.

Reported-by: Manfred Schlaegl 
Signed-off-by: Oliver Hartkopp 
Cc: linux-stable 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Sasha Levin

bnx2x: fix lockdep splat

2015-07-05T14:13:00+00:00

[ Upstream commit d53c66a5b80698620f7c9ba2372fff4017e987b8 ]

Michel reported following lockdep splat

[   44.718117] INFO: trying to register non-static key.
[   44.723081] the code is fine but needs lockdep annotation.
[   44.728559] turning off the locking correctness validator.
[   44.734036] CPU: 8 PID: 5483 Comm: ethtool Not tainted 4.1.0
[   44.770289] Call Trace:
[   44.772741]  [] dump_stack+0x4c/0x65
[   44.777879]  [] ? console_unlock+0x1f1/0x510
[   44.783708]  [] __lock_acquire+0x1d05/0x1f10
[   44.789538]  [] ? mark_held_locks+0x6a/0x90
[   44.795276]  [] ? trace_hardirqs_on_caller+0x105/0x1d0
[   44.801967]  [] ? trace_hardirqs_on+0xd/0x10
[   44.807793]  [] ? hrtimer_try_to_cancel+0x4a/0x250
[   44.814142]  [] lock_acquire+0xb6/0x290
[   44.819537]  [] ? flush_work+0x5/0x280
[   44.824844]  [] flush_work+0x3d/0x280
[   44.830061]  [] ? flush_work+0x5/0x280
[   44.835366]  [] ? schedule_hrtimeout_range+0x13/0x20
[   44.841889]  [] ? usleep_range+0x4b/0x50
[   44.847365]  [] ? mark_held_locks+0x6a/0x90
[   44.853102]  [] ? __cancel_work_timer+0x105/0x1c0
[   44.859359]  [] ? trace_hardirqs_on_caller+0x105/0x1d0
[   44.866045]  [] __cancel_work_timer+0x9f/0x1c0
[   44.872048]  [] ? bnx2x_func_stop+0x42/0x90 [bnx2x]
[   44.878481]  [] cancel_work_sync+0x10/0x20
[   44.884134]  [] bnx2x_chip_cleanup+0x245/0x730 [bnx2x]
[   44.890829]  [] ? up+0x32/0x50
[   44.895439]  [] ? del_timer_sync+0x5/0xd0
[   44.901005]  [] bnx2x_nic_unload+0x20d/0x8e0 [bnx2x]
[   44.907527]  [] ? might_fault+0x5f/0xb0
[   44.912921]  [] bnx2x_reload_if_running+0x2c/0x50 [bnx2x]
[   44.919879]  [] bnx2x_set_ringparam+0x2b5/0x460 [bnx2x]
[   44.926664]  [] dev_ethtool+0x55b/0x1c40
[   44.932148]  [] ? rtnl_lock+0x17/0x20
[   44.937364]  [] dev_ioctl+0x17b/0x630
[   44.942582]  [] sock_do_ioctl+0x5d/0x70
[   44.947972]  [] sock_ioctl+0x73/0x280
[   44.953192]  [] do_vfs_ioctl+0x88/0x5b0
[   44.958587]  [] ? up_read+0x23/0x40
[   44.963631]  [] ? __fget_light+0x6c/0xa0
[   44.969105]  [] SyS_ioctl+0x91/0xb0
[   44.974149]  [] system_call_fastpath+0x12/0x6f

As bnx2x_init_ptp() is only called if bp->flags contains PTP_SUPPORTED,
we also need to guard bnx2x_stop_ptp() with same condition, otherwise
ptp_task workqueue is not initialized and kernel barfs on
cancel_work_sync()

Fixes: eeed018cbfa30 ("bnx2x: Add timestamping and PTP hardware clock support")
Reported-by: Michel Lespinasse 
Signed-off-by: Eric Dumazet 
Cc: Michal Kalderon 
Cc: Ariel Elior 
Cc: Yuval Mintz 
Cc: David Decotigny 
Acked-by: Sony Chacko 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

net: phy: fix phy link up when limiting speed via device tree

2015-07-05T14:13:00+00:00

[ Upstream commit eb686231fce3770299760f24fdcf5ad041f44153 ]

When limiting phy link speed using "max-speed" to 100mbps or less on a
giga bit phy, phy never completes auto negotiation and phy state
machine is held in PHY_AN. Fixing this issue by comparing the giga
bit advertise though phydev->supported doesn't have it but phy has
BMSR_ESTATEN set. So that auto negotiation is restarted as old and
new advertise are different and link comes up fine.

Signed-off-by: Mugunthan V N 
Reviewed-by: Florian Fainelli 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

net/mlx4_en: Wake TX queues only when there's enough room

2015-07-05T14:12:59+00:00

[ Upstream commit 488a9b48e398b157703766e2cd91ea45ac6997c5 ]

Indication of a single completed packet, marked by txbbs_skipped
being bigger then zero, in not enough in order to wake up a
stopped TX queue. The completed packet may contain a single TXBB,
while next packet to be sent (after the wake up) may have multiple
TXBBs (LSO/TSO packets for example), causing overflow in queue followed
by WQE corruption and TX queue timeout.
Instead, wake the stopped queue only when there's enough room for the
worst case (maximum sized WQE) packet that we should need to handle after
the queue is opened again.

Also created an helper routine - mlx4_en_is_tx_ring_full, which checks
if the current TX ring is full or not. It provides better code readability
and removes code duplication.

Signed-off-by: Ido Shamay 
Signed-off-by: Or Gerlitz 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

net: mvneta: disable IP checksum with jumbo frames for Armada 370

2015-07-05T14:12:55+00:00

[ Upstream commit b65657fc240ae6c1d2a1e62db9a0e61ac9631d7a ]

The Ethernet controller found in the Armada 370, 380 and 385 SoCs don't
support TCP/IP checksumming with frame sizes larger than 1600 bytes.

This patch fixes the issue by disabling the features NETIF_F_IP_CSUM and
NETIF_F_TSO for the Armada 370 and compatibles SoCs when the MTU is set
to a value greater than 1600 bytes.

Signed-off-by: Simon Guinot 
Fixes: c5aff18204da ("net: mvneta: driver for Marvell Armada 370/XP network unit")
Cc:  # v3.8+
Acked-by: Thomas Petazzoni 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

net: mvneta: introduce compatible string "marvell, armada-xp-neta"

2015-07-05T14:12:54+00:00

[ Upstream commit f522a975a8101895a85354b9c143f41b8248e71a ]

The mvneta driver supports the Ethernet IP found in the Armada 370, XP,
380 and 385 SoCs. Since at least one more hardware feature is available
for the Armada XP SoCs then a way to identify them is needed.

This patch introduces a new compatible string "marvell,armada-xp-neta".

Signed-off-by: Simon Guinot 
Fixes: c5aff18204da ("net: mvneta: driver for Marvell Armada 370/XP network unit")
Cc:  # v3.8+
Acked-by: Gregory CLEMENT 
Acked-by: Thomas Petazzoni 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

stmmac: troubleshoot unexpected bits in des0 & des1

2015-07-05T14:12:49+00:00

[ Upstream commit f1590670ce069eefeb93916391a67643e6ad1630 ]

Current implementation of descriptor init procedure only takes
care about setting/clearing ownership flag in "des0"/"des1"
fields while it is perfectly possible to get unexpected bits
set because of the following factors:

 [1] On driver probe underlying memory allocated with
     dma_alloc_coherent() might not be zeroed and so
     it will be filled with garbage.

 [2] During driver operation some bits could be set by SD/MMC
     controller (for example error flags etc).

And unexpected and/or randomly set flags in "des0"/"des1"
fields may lead to unpredictable behavior of GMAC DMA block.

This change addresses both items above with:

 [1] Use of dma_zalloc_coherent() instead of simple
     dma_alloc_coherent() to make sure allocated memory is
     zeroed. That shouldn't affect performance because
     this allocation only happens once on driver probe.

 [2] Do explicit zeroing of both "des0" and "des1" fields
     of all buffer descriptors during initialization of
     DMA transfer.

And while at it fixed identation of dma_free_coherent()
counterpart as well.

Signed-off-by: Alexey Brodkin 
Cc: Giuseppe Cavallaro 
Cc: arc-linux-dev@synopsys.com
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org
Cc: David Miller 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

ath9k: fix DMA stop sequence for AR9003+

2015-07-04T03:02:24+00:00

[ Upstream commit 300f77c08ded96d33f492aaa02549103852f0c12 ]

AR93xx and newer needs to stop rx before tx to avoid getting the DMA
engine or MAC into a stuck state.
This should reduce/fix the occurence of "Failed to stop Tx DMA" logspam.

Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin

rtlwifi: Remove the clear interrupt routine from all drivers

2015-07-04T03:02:19+00:00

[ Upstream commit 1277fa2ab2f9a624a4b0177119ca13b5fd65edd0 ]

Several of these drivers have there TX randomly blocked for 3~5 seconds while
measuring tx throughput (iperf). The root couse happens in rtl_pci_flush().
The function uses a while-loop to wait for TX queue length to decrease to 0.
The TX queue length counts the number of packets that are queued in the driver.
The driver relys on the TX OK interrupt to return skb and reduce TX queue length.

The interrupt subroutine disables interupts, reads the interrupt registers, and
then clears the registers in the beginning of _rtl_pci_interrupt(). After all
interupts process are finished, the driver invokes enable_interrupt() to enable
interupts. This behavior is normal for an interrupt subroutine.

But enable_interrupt() invokes clear_interrupt() again. This unexpected interrupt
clearing may cleari me fresh TX OK interrupts. These missing interrupts cause TX
queue length to never reduce to 0i, which causes rtl_pci_flush() to be stuck in
unterminated while-loop.

This patch removes clear_interrupt() in enable_interrupt() to avoid this behavior.

Signed-off-by: Vincent Fann 
Signed-off-by: Shao Fu 
Signed-off-by: Larry Finger 
Cc: Stable  [3.18+]
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin