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

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

b43: fix support for 14e4:4321 PCI dev with BCM4321 chipset

2015-07-03T16:34:27+00:00

[ Upstream commit 90f91b129810c3f169e443252be30ed7c0130326 ]

It seems Broadcom released two devices with conflicting device id. There
are for sure 14e4:4321 PCI devices with BCM4321 (N-PHY) chipset, they
can be found in routers, e.g. Netgear WNR834Bv2. However, according to
Broadcom public sources 0x4321 is also used for 5 GHz BCM4306 (G-PHY).
It's unsure if they meant PCI device id, or "virtual" id (from SPROM).
To distinguish these devices lets check PHY type (G vs. N).

Signed-off-by: Rafał Miłecki 
Cc:  # 3.16+
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin

mlx5: wrong page mask if CONFIG_ARCH_DMA_ADDR_T_64BIT enabled for 32Bit architectures

2015-06-28T17:39:25+00:00

[ Upstream commit 59d2d18cc4e9ba30b370db18d0e02d792699da96 ]

If CONFIG_ARCH_DMA_ADDR_T_64BIT enabled for x86 systems and physical
memory is more than 4GB, dma_map_page may return a valid memory
address which greater than 0xffffffff. As a result, the mlx5 device page
allocator RB tree will be initialized with valid addresses greater than
0xfffffff.

However, (addr & PAGE_MASK) set the high four bytes to zeros. So, it's
impossible for the function, free_4k, to release the pages whose
addresses greater than 4GB. Memory leaks. And mlx5_ib module can't
release the pages when user try to remove the module, as a result,
system hang.

[root@rdma05 root]# dmesg  | grep addr | head
addr             = 3fe384000
addr & PAGE_MASK =  fe384000
[root@rdma05 root]# rmmod mlx5_ib   <---- hang on

---------------------- cosnole log -----------------
mlx5_ib 0000:04:00.0: irq 138 for MSI/MSI-X
  alloc irq_desc for 139 on node -1
  alloc kstat_irqs on node -1
mlx5_ib 0000:04:00.0: irq 139 for MSI/MSI-X
0000:04:00.0:free_4k:221:(pid 1519): page not found
0000:04:00.0:free_4k:221:(pid 1519): page not found
0000:04:00.0:free_4k:221:(pid 1519): page not found
0000:04:00.0:free_4k:221:(pid 1519): page not found
---------------------- cosnole log -----------------

Fixes: bf0bf77f6519 ('mlx5: Support communicating arbitrary host page size to firmware')
Signed-off-by: Honggang Li 
Signed-off-by: Doug Ledford 
Signed-off-by: Sasha Levin