linux-stable.git/drivers/net, branch v4.1.35

can: flexcan: fix resume function

2016-10-03T12:35:19+00:00

[ Upstream commit 4de349e786a3a2d51bd02d56f3de151bbc3c3df9 ]

On a imx6ul-pico board the following error is seen during system suspend:

dpm_run_callback(): platform_pm_resume+0x0/0x54 returns -110
PM: Device 2090000.flexcan failed to resume: error -110

The reason for this suspend error is because when the CAN interface is not
active the clocks are disabled and then flexcan_chip_enable() will
always fail due to a timeout error.

In order to fix this issue, only call flexcan_chip_enable/disable()
when the CAN interface is active.

Based on a patch from Dong Aisheng in the NXP kernel.

Signed-off-by: Fabio Estevam 
Cc: linux-stable 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Sasha Levin

ath9k: fix using sta->drv_priv before initializing it

2016-10-02T16:49:38+00:00

[ Upstream commit 7711aaf08ad3fc4d0e937eec1de0a63620444ce7 ]

A station pointer can be passed to the driver on tx, before it has been
marked as associated. Since ath9k_sta_state was initializing the entry
too late, it resulted in some spurious crashes.

Fixes: df3c6eb34da5 ("ath9k: Use sta_state() callback")
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin

cdc_ncm: workaround for EM7455 "silent" data interface

2016-08-20T03:08:38+00:00

[ Upstream commit c086e7096170390594c425114d98172bc9aceb8a ]

Several Lenovo users have reported problems with their Sierra
Wireless EM7455 modem. The driver has loaded successfully and
the MBIM management channel has appeared to work, including
establishing a connection to the mobile network. But no frames
have been received over the data interface.

The problem affects all EM7455 and MC7455, and is assumed to
affect other modems based on the same Qualcomm chipset and
baseband firmware.

Testing narrowed the problem down to what seems to be a
firmware timing bug during initialization. Adding a short sleep
while probing is sufficient to make the problem disappear.
Experiments have shown that 1-2 ms is too little to have any
effect, while 10-20 ms is enough to reliably succeed.

Reported-by: Stefan Armbruster 
Reported-by: Ralph Plawetzki 
Reported-by: Andreas Fett 
Reported-by: Rasmus Lerdorf 
Reported-by: Samo Ratnik 
Reported-and-tested-by: Aleksander Morgado 
Signed-off-by: Bjørn Mork 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

iwlwifi: add new 8260 PCI IDs

2016-08-17T16:58:31+00:00

[ Upstream commit 4b79deece5d45396422d469afa11f9d69ccb3d8b ]

Add 3 new 8260 series PCI IDs:
  - (0x24F3, 0x10B0)
  - (0x24F3, 0xD0B0)
  - (0x24F3, 0xB0B0)

CC:  [4.1+]
Signed-off-by: Oren Givon 
Signed-off-by: David Spinadel 
Signed-off-by: Luca Coelho 
Signed-off-by: Sasha Levin

net: mvneta: set real interrupt per packet for tx_done

2016-08-03T19:10:43+00:00

[ Upstream commit 06708f81528725148473c0869d6af5f809c6824b ]

Commit aebea2ba0f74 ("net: mvneta: fix Tx interrupt delay") intended to
set coalescing threshold to a value guaranteeing interrupt generation
per each sent packet, so that buffers can be released with no delay.

In fact setting threshold to '1' was wrong, because it causes interrupt
every two packets. According to the documentation a reason behind it is
following - interrupt occurs once sent buffers counter reaches a value,
which is higher than one specified in MVNETA_TXQ_SIZE_REG(q). This
behavior was confirmed during tests. Also when testing the SoC working
as a NAS device, better performance was observed with int-per-packet,
as it strongly depends on the fact that all transmitted packets are
released immediately.

This commit enables NETA controller work in interrupt per sent packet mode
by setting coalescing threshold to 0.

Signed-off-by: Dmitri Epshtein 
Signed-off-by: Marcin Wojtas 
Cc:  # v3.10+
Fixes aebea2ba0f74 ("net: mvneta: fix Tx interrupt delay")
Acked-by: Willy Tarreau 
Signed-off-by: David S. Miller 

Signed-off-by: Sasha Levin

sfc: on MC reset, clear PIO buffer linkage in TXQs

2016-07-11T03:07:29+00:00

[ Upstream commit c0795bf64cba4d1b796fdc5b74b33772841ed1bb ]

Otherwise, if we fail to allocate new PIO buffers, our TXQs will try to
use the old ones, which aren't there any more.

Fixes: 183233bec810 "sfc: Allocate and link PIO buffers; map them with write-combining"
Signed-off-by: Edward Cree 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

tuntap: correctly wake up process during uninit

2016-07-11T03:07:29+00:00

[ Upstream commit addf8fc4acb1cf79492ac64966f07178793cb3d7 ]

We used to check dev->reg_state against NETREG_REGISTERED after each
time we are woke up. But after commit 9e641bdcfa4e ("net-tun:
restructure tun_do_read for better sleep/wakeup efficiency"), it uses
skb_recv_datagram() which does not check dev->reg_state. This will
result if we delete a tun/tap device after a process is blocked in the
reading. The device will wait for the reference count which was held
by that process for ever.

Fixes this by using RCV_SHUTDOWN which will be checked during
sk_recv_datagram() before trying to wake up the process during uninit.

Fixes: 9e641bdcfa4e ("net-tun: restructure tun_do_read for better
sleep/wakeup efficiency")
Cc: Eric Dumazet 
Cc: Xi Wang 
Cc: Michael S. Tsirkin 
Signed-off-by: Jason Wang 
Acked-by: Eric Dumazet 
Acked-by: Michael S. Tsirkin 
Signed-off-by: David S. Miller 

Signed-off-by: Sasha Levin

net/mlx4_en: Fix endianness bug in IPV6 csum calculation

2016-07-11T03:07:24+00:00

[ Upstream commit 82d69203df634b4dfa765c94f60ce9482bcc44d6 ]

Use htons instead of unconditionally byte swapping nexthdr.  On a little
endian systems shifting the byte is correct behavior, but it results in
incorrect csums on big endian architectures.

Fixes: f8c6455bb04b ('net/mlx4_en: Extend checksum offloading by CHECKSUM COMPLETE')
Signed-off-by: Daniel Jurgens 
Reviewed-by: Carol Soto 
Tested-by: Carol Soto 
Signed-off-by: Tariq Toukan 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

net: fec: only clear a queue's work bit if the queue was emptied

2016-07-11T03:07:24+00:00

[ Upstream commit 1c021bb717a70aaeaa4b25c91f43c2aeddd922de ]

In the receive path a queue's work bit was cleared unconditionally even
if fec_enet_rx_queue only read out a part of the available packets from
the hardware. This resulted in not reading any packets in the next napi
turn and so packets were delayed or lost.

The obvious fix is to only clear a queue's bit when the queue was
emptied.

Fixes: 4d494cdc92b3 ("net: fec: change data structure to support multiqueue")
Signed-off-by: Uwe Kleine-König 
Reviewed-by: Lucas Stach 
Tested-by: Fugang Duan 
Acked-by: Fugang Duan 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

net/mlx4_en: fix spurious timestamping callbacks

2016-07-11T03:07:22+00:00

[ Upstream commit fc96256c906362e845d848d0f6a6354450059e81 ]

When multiple skb are TX-completed in a row, we might incorrectly keep
a timestamp of a prior skb and cause extra work.

Fixes: ec693d47010e8 ("net/mlx4_en: Add HW timestamping (TS) support")
Signed-off-by: Eric Dumazet 
Cc: Willem de Bruijn 
Reviewed-by: Eran Ben Elisha 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin