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

e1000e: Fix tight loop implementation of systime read algorithm

2015-10-22T21:49:35+00:00

commit 37b12910dd11d9ab969f2c310dc9160b7f3e3405 upstream.

Change the algorithm. Read systimel twice and check for overflow.
If there was no overflow, use the first value.
If there was an overflow, read systimeh again and use the second
systimel value.

Signed-off-by: Raanan Avargil 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Cc: "Jason A. Donenfeld" 
Signed-off-by: Greg Kroah-Hartman

igb: do not re-init SR-IOV during probe

2015-10-22T21:49:33+00:00

commit 6423fc34160939142d72ffeaa2db6408317f54df upstream.

During driver probing the following code path is triggered.
igb_probe
->igb_sw_init
  ->igb_probe_vfs
    ->igb_pci_enable_sriov
      ->igb_sriov_reinit

Doing the SR-IOV re-init is not necessary during probing since we're
starting from scratch. Here we can call igb_enable_sriov() right away.

Running igb_sriov_reinit() during igb_probe() also seems to cause
occasional packet loss on some onboard 82576 NICs. Reproduced on
Dell and HP servers with onboard 82576 NICs.
Example:
Intel Corporation 82576 Gigabit Network Connection [8086:10c9] (rev 01)
Subsystem: Dell Device [1028:0481]

Signed-off-by: Stefan Assmann 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Cc: Daniel J Blueman 
Signed-off-by: Greg Kroah-Hartman

net/xen-netfront: only napi_synchronize() if running

2015-10-22T21:49:33+00:00

commit 274b045509175db0405c784be85e8cce116e6f7d upstream.

If an interface isn't running napi_synchronize() will hang forever.

[  392.248403] rmmod           R  running task        0   359    343 0x00000000
[  392.257671]  ffff88003760fc88 ffff880037193b40 ffff880037193160 ffff88003760fc88
[  392.267644]  ffff880037610000 ffff88003760fcd8 0000000100014c22 ffffffff81f75c40
[  392.277524]  0000000000bc7010 ffff88003760fca8 ffffffff81796927 ffffffff81f75c40
[  392.287323] Call Trace:
[  392.291599]  [] schedule+0x37/0x90
[  392.298553]  [] schedule_timeout+0x14b/0x280
[  392.306421]  [] ? irq_free_descs+0x69/0x80
[  392.314006]  [] ? internal_add_timer+0xb0/0xb0
[  392.322125]  [] msleep+0x37/0x50
[  392.329037]  [] xennet_disconnect_backend.isra.24+0xda/0x390 [xen_netfront]
[  392.339658]  [] xennet_remove+0x2c/0x80 [xen_netfront]
[  392.348516]  [] xenbus_dev_remove+0x59/0xc0
[  392.356257]  [] __device_release_driver+0x87/0x120
[  392.364645]  [] driver_detach+0xb8/0xc0
[  392.371989]  [] bus_remove_driver+0x59/0xe0
[  392.379883]  [] driver_unregister+0x30/0x70
[  392.387495]  [] xenbus_unregister_driver+0x12/0x20
[  392.395908]  [] netif_exit+0x10/0x775 [xen_netfront]
[  392.404877]  [] SyS_delete_module+0x1d8/0x230
[  392.412804]  [] system_call_fastpath+0x12/0x71

Signed-off-by: Chas Williams <3chas3@gmail.com>
Signed-off-by: David S. Miller 
Cc: "Kamata, Munehisa" 
Signed-off-by: Greg Kroah-Hartman

net: via/Kconfig: GENERIC_PCI_IOMAP required if PCI not selected

2015-10-22T21:49:32+00:00

commit 21343ac21ec7d871e94e98e288f3398a4207d9c0 upstream.

The builds of allmodconfig of avr32 is failing with:

drivers/net/ethernet/via/via-rhine.c:1098:2: error: implicit declaration
of function 'pci_iomap' [-Werror=implicit-function-declaration]
drivers/net/ethernet/via/via-rhine.c:1119:2: error: implicit declaration
of function 'pci_iounmap' [-Werror=implicit-function-declaration]

The generic empty pci_iomap and pci_iounmap is used only if CONFIG_PCI
is not defined and CONFIG_GENERIC_PCI_IOMAP is defined.

Add GENERIC_PCI_IOMAP in the dependency list for VIA_RHINE as we are
getting build failure when CONFIG_PCI and CONFIG_GENERIC_PCI_IOMAP both
are not defined.

Signed-off-by: Sudip Mukherjee 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

rsi: Fix possible leak when loading firmware

2015-10-22T21:49:31+00:00

commit a8b9774571d46506a0774b1ced3493b1245cf893 upstream.

Commit 5d5cd85ff441 ("rsi: Fix failure to load firmware after memory
leak fix and fix the leak") also added a check on the allocation of
DMA-accessible memory that may directly return. In that case the
already allocated firmware data is leaked. Make sure the data is
always freed correctly. Detected by Coverity CID 1316519.

Fixes: 5d5cd85ff441 ("rsi: Fix failure to load firmware after memory leak fix and fix the leak")
Signed-off-by: Christian Engelmayer 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

ath10k: wake up queue upon vif creation

2015-10-22T21:49:29+00:00

commit 6d2d51ecfff13f5f6ffc476dccf4d5b2668072eb upstream.

Vif's vdev_id is used as queue number. However due
to the tx pausing design in ath10k it was possible
for a new interface to be created with its tx
queue stopped (via ieee80211_stop_queues). This
could in turn leave the interface inoperable until
ath10k_mac_tx_unlock() was called.

This problem only affected multi-vif scenarios when
new interfaces were created some time later after
other interfaces have been running for some time
and had Tx queue full at some point prior.

Possible manifestation of the bug was
authentication timeout for a client vif.

Fixes: 96d828d45e16 ("ath10k: rework tx queue locking")
Signed-off-by: Michal Kazior 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

ath10k: wake up offchannel queue properly

2015-10-22T21:49:29+00:00

commit 3a73d1a6f22bf13044056543ad43b2a304ee0022 upstream.

Once HTT Tx queue got full offchannel queue was
stopped and never woken up again. This broke, e.g.
P2P. This could be reproduced after running a lot
of traffic enough to saturate 100% of the driver
Tx queue and then trying to send offchannel
traffic.

Fixes: 96d828d45e16 ("ath10k: rework tx queue locking")
Signed-off-by: Michal Kazior 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

ath10k: fix peer limit enforcement

2015-10-22T21:49:28+00:00

commit e04cafbc38c70af2aad3810ce24ab0eba8114779 upstream.

Firmware peer entries are involved in internal
firmware vdev structures. This was not accounted
for and could lead firmware to crash due to asking
it to do more than it could.

Fixes: 039a0051ec1a ("ath10k: allocate fw resources for iface combinations")
Signed-off-by: Michal Kazior 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

ath10k: reject 11b tx fragmentation configuration

2015-10-22T21:49:28+00:00

commit 92092fe528e79c9bd25784ca0ef341d5a1d1b642 upstream.

Even though there's a WMI enum for fragmentation
threshold no known firmware actually implements
it. Moreover it is not possible to rely frame
fragmentation to mac80211 because firmware clears
the "more fragments" bit in frame control making
it impossible for remote devices to reassemble
frames.

Hence implement a dummy callback just to say
fragmentation isn't supported. This effectively
prevents mac80211 from doing frame fragmentation
in software.

This fixes Tx becoming broken after setting
fragmentation threshold.

Fixes: 1010ba4c5d1c ("ath10k: unregister and remove frag_threshold callback")
Signed-off-by: Michal Kazior 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

ath10k: fix per-vif queue locking

2015-10-22T21:49:28+00:00

commit acd0b27bb13a09dd0a56d4562d3eb4137a7318b2 upstream.

Whenever any vdev was supposed to be paused all Tx
queues were stopped (except offchannel) instead of
only these associated with the given vdev.

This caused subtle issues with
multi-channel/multi-vif scenarios, e.g.
authentication of station vif could sometimes fail
depending on fw tx pause request timing.

Fixes: b4aa539dd8f2 ("ath10k: implement tx pause wmi event")
Signed-off-by: Michal Kazior 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman