<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/net, branch v3.14.37</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>bnx2x: Force fundamental reset for EEH recovery</title>
<updated>2015-03-26T14:06:56+00:00</updated>
<author>
<name>Brian King</name>
<email>brking@linux.vnet.ibm.com</email>
</author>
<published>2015-03-04T14:09:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5c7a4c4def1e14ff083966ef7ffec6d2ee3bace1'/>
<id>5c7a4c4def1e14ff083966ef7ffec6d2ee3bace1</id>
<content type='text'>
commit da293700568ed3d96fcf062ac15d7d7c41377f11 upstream.

EEH recovery for bnx2x based adapters is not reliable on all Power
systems using the default hot reset, which can result in an
unrecoverable EEH error. Forcing the use of fundamental reset
during EEH recovery fixes this.

Signed-off-by: Brian King &lt;brking@linux.vnet.ibm.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit da293700568ed3d96fcf062ac15d7d7c41377f11 upstream.

EEH recovery for bnx2x based adapters is not reliable on all Power
systems using the default hot reset, which can result in an
unrecoverable EEH error. Forcing the use of fundamental reset
during EEH recovery fixes this.

Signed-off-by: Brian King &lt;brking@linux.vnet.ibm.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>can: add missing initialisations in CAN related skbuffs</title>
<updated>2015-03-26T14:06:54+00:00</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2015-02-23T19:37:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3cc97c83e2051584120819e40e7b0ce4dadf0925'/>
<id>3cc97c83e2051584120819e40e7b0ce4dadf0925</id>
<content type='text'>
commit 969439016d2cf61fef53a973d7e6d2061c3793b1 upstream.

When accessing CAN network interfaces with AF_PACKET sockets e.g. by dhclient
this can lead to a skb_under_panic due to missing skb initialisations.

Add the missing initialisations at the CAN skbuff creation times on driver
level (rx path) and in the network layer (tx path).

Reported-by: Austin Schuh &lt;austin@peloton-tech.com&gt;
Reported-by: Daniel Steer &lt;daniel.steer@mclaren.com&gt;
Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 969439016d2cf61fef53a973d7e6d2061c3793b1 upstream.

When accessing CAN network interfaces with AF_PACKET sockets e.g. by dhclient
this can lead to a skb_under_panic due to missing skb initialisations.

Add the missing initialisations at the CAN skbuff creation times on driver
level (rx path) and in the network layer (tx path).

Reported-by: Austin Schuh &lt;austin@peloton-tech.com&gt;
Reported-by: Daniel Steer &lt;daniel.steer@mclaren.com&gt;
Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "net: cx82310_eth: use common match macro"</title>
<updated>2015-03-26T14:06:50+00:00</updated>
<author>
<name>Ondrej Zary</name>
<email>linux@rainbow-software.org</email>
</author>
<published>2015-03-18T22:01:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=280683cb38e7faa963e50e58286b8b00e8a8b953'/>
<id>280683cb38e7faa963e50e58286b8b00e8a8b953</id>
<content type='text'>
[ Upstream commit 8d006e0105978619fb472e150c88b0d49337fe2b ]

This reverts commit 11ad714b98f6d9ca0067568442afe3e70eb94845 because
it breaks cx82310_eth.

The custom USB_DEVICE_CLASS macro matches
bDeviceClass, bDeviceSubClass and bDeviceProtocol
but the common USB_DEVICE_AND_INTERFACE_INFO matches
bInterfaceClass, bInterfaceSubClass and bInterfaceProtocol instead, which are
not specified.

Signed-off-by: Ondrej Zary &lt;linux@rainbow-software.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 8d006e0105978619fb472e150c88b0d49337fe2b ]

This reverts commit 11ad714b98f6d9ca0067568442afe3e70eb94845 because
it breaks cx82310_eth.

The custom USB_DEVICE_CLASS macro matches
bDeviceClass, bDeviceSubClass and bDeviceProtocol
but the common USB_DEVICE_AND_INTERFACE_INFO matches
bInterfaceClass, bInterfaceSubClass and bInterfaceProtocol instead, which are
not specified.

Signed-off-by: Ondrej Zary &lt;linux@rainbow-software.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ath6kl: fix struct hif_scatter_req list handling</title>
<updated>2015-03-18T12:31:34+00:00</updated>
<author>
<name>Kalle Valo</name>
<email>kvalo@qca.qualcomm.com</email>
</author>
<published>2014-03-11T10:58:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f23e11ca321f7f54be33cbf90932ac9f62db8c9f'/>
<id>f23e11ca321f7f54be33cbf90932ac9f62db8c9f</id>
<content type='text'>
commit 31b9cc9a873dcab161999622314f98a75d838975 upstream.

Jason noticed that with Yocto GCC 4.8.1 ath6kl crashes with this iperf command:

iperf -c $TARGET_IP -i 5 -t 50 -w 1M

The crash was:

Unable to handle kernel paging request at virtual address 1a480000
pgd = 80004000
[1a480000] *pgd=00000000
Internal error: Oops: 805 [#1] SMP ARM
Modules linked in: ath6kl_sdio ath6kl_core [last unloaded: ath6kl_core]
CPU: 0 PID: 1953 Comm: kworker/u4:0 Not tainted 3.10.9-1.0.0_alpha+dbf364b #1
Workqueue: ath6kl ath6kl_sdio_write_async_work [ath6kl_sdio]
task: dcc9a680 ti: dc9ae000 task.ti: dc9ae000
PC is at v7_dma_clean_range+0x20/0x38
LR is at dma_cache_maint_page+0x50/0x54
pc : [&lt;8001a6f8&gt;]    lr : [&lt;800170fc&gt;]    psr: 20000093
sp : dc9afcf8  ip : 8001a748  fp : 00000004
r10: 00000000  r9 : 00000001  r8 : 00000000
r7 : 00000001  r6 : 00000000  r5 : 80cb7000  r4 : 03f9a480
r3 : 0000001f  r2 : 00000020  r1 : 1a480000  r0 : 1a480000
Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c53c7d  Table: 6cc5004a  DAC: 00000015
Process kworker/u4:0 (pid: 1953, stack limit = 0xdc9ae238)
Stack: (0xdc9afcf8 to 0xdc9b0000)
fce0:                                                       80c9b29c 00000000
fd00: 00000000 80017134 8001a748 dc302ac0 00000000 00000000 dc454a00 80c12ed8
fd20: dc115410 80017238 00000000 dc454a10 00000001 80017588 00000001 00000000
fd40: 00000000 dc302ac0 dc9afe38 dc9afe68 00000004 80c12ed8 00000000 dc454a00
fd60: 00000004 80436f88 00000000 00000000 00000600 0000ffff 0000000c 80c113c4
fd80: 80c9b29c 00000001 00000004 dc115470 60000013 dc302ac0 dc46e000 dc302800
fda0: dc9afe10 dc302b78 60000013 dc302ac0 dc46e000 00000035 dc46e5b0 80438c90
fdc0: dc9afe10 dc302800 dc302800 dc9afe68 dc9afe38 80424cb4 00000005 dc9afe10
fde0: dc9afe20 80424de8 dc9afe10 dc302800 dc46e910 80424e90 dc473c00 dc454f00
fe00: 000001b5 7f619d64 dcc7c830 00000000 00000000 dc9afe38 dc9afe68 00000000
fe20: 00000000 00000000 dc9afe28 dc9afe28 80424d80 00000000 00000035 9cac0034
fe40: 00000000 00000000 00000000 00000000 000001b5 00000000 00000000 00000000
fe60: dc9afe68 dc9afe10 3b9aca00 00000000 00000080 00000034 00000000 00000100
fe80: 00000000 00000000 dc9afe10 00000004 dc454a00 00000000 dc46e010 dc46e96c
fea0: dc46e000 dc46e964 00200200 00100100 dc46e910 7f619ec0 00000600 80c0e770
fec0: dc15a900 dcc7c838 00000000 dc46e954 8042d434 dcc44680 dc46e954 dc004400
fee0: dc454500 00000000 00000000 dc9ae038 dc004400 8003c450 dcc44680 dc004414
ff00: dc46e954 dc454500 00000001 dcc44680 dc004414 dcc44698 dc9ae000 dc9ae030
ff20: 00000001 dc9ae000 dc004400 8003d158 8003d020 00000000 00000000 80c53941
ff40: dc9aff64 dcb71ea0 00000000 dcc44680 8003d020 00000000 00000000 00000000
ff60: 00000000 80042480 00000000 00000000 000000f8 dcc44680 00000000 00000000
ff80: dc9aff80 dc9aff80 00000000 00000000 dc9aff90 dc9aff90 dc9affac dcb71ea0
ffa0: 800423cc 00000000 00000000 8000e018 00000000 00000000 00000000 00000000
ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[&lt;8001a6f8&gt;] (v7_dma_clean_range+0x20/0x38) from [&lt;800170fc&gt;] (dma_cache_maint_page+0x50/0x54)
[&lt;800170fc&gt;] (dma_cache_maint_page+0x50/0x54) from [&lt;80017134&gt;] (__dma_page_cpu_to_dev+0x34/0x9c)
[&lt;80017134&gt;] (__dma_page_cpu_to_dev+0x34/0x9c) from [&lt;80017238&gt;] (arm_dma_map_page+0x64/0x68)
[&lt;80017238&gt;] (arm_dma_map_page+0x64/0x68) from [&lt;80017588&gt;] (arm_dma_map_sg+0x7c/0xf4)
[&lt;80017588&gt;] (arm_dma_map_sg+0x7c/0xf4) from [&lt;80436f88&gt;] (sdhci_send_command+0x894/0xe00)
[&lt;80436f88&gt;] (sdhci_send_command+0x894/0xe00) from [&lt;80438c90&gt;] (sdhci_request+0xc0/0x1ec)
[&lt;80438c90&gt;] (sdhci_request+0xc0/0x1ec) from [&lt;80424cb4&gt;] (mmc_start_request+0xb8/0xd4)
[&lt;80424cb4&gt;] (mmc_start_request+0xb8/0xd4) from [&lt;80424de8&gt;] (__mmc_start_req+0x60/0x84)
[&lt;80424de8&gt;] (__mmc_start_req+0x60/0x84) from [&lt;80424e90&gt;] (mmc_wait_for_req+0x10/0x20)
[&lt;80424e90&gt;] (mmc_wait_for_req+0x10/0x20) from [&lt;7f619d64&gt;] (ath6kl_sdio_scat_rw.isra.10+0x1dc/0x240 [ath6kl_sdio])
[&lt;7f619d64&gt;] (ath6kl_sdio_scat_rw.isra.10+0x1dc/0x240 [ath6kl_sdio]) from [&lt;7f619ec0&gt;] (ath6kl_sdio_write_async_work+0x5c/0x104 [ath6kl_sdio])
[&lt;7f619ec0&gt;] (ath6kl_sdio_write_async_work+0x5c/0x104 [ath6kl_sdio]) from [&lt;8003c450&gt;] (process_one_work+0x10c/0x370)
[&lt;8003c450&gt;] (process_one_work+0x10c/0x370) from [&lt;8003d158&gt;] (worker_thread+0x138/0x3fc)
[&lt;8003d158&gt;] (worker_thread+0x138/0x3fc) from [&lt;80042480&gt;] (kthread+0xb4/0xb8)
[&lt;80042480&gt;] (kthread+0xb4/0xb8) from [&lt;8000e018&gt;] (ret_from_fork+0x14/0x3c)
Code: e1a02312 e2423001 e1c00003 f57ff04f (ee070f3a)
---[ end trace 0c038f0b8e0b67a3 ]---
Kernel panic - not syncing: Fatal exception

Jason's analysis:

  "The GCC 4.8.1 compiler will not do the for-loop till scat_entries, instead,
   it only run one round loop. This may be caused by that the GCC 4.8.1 thought
   that the scat_list only have one item and then no need to do full iteration,
   but this is simply wrong by looking at the assebly code. This will cause the sg
   buffer not get set when scat_entries &gt; 1 and thus lead to kernel panic.

   Note: This issue not observed with GCC 4.7.2, only found on the GCC 4.8.1)"

Fix this by using the normal [0] style for defining unknown number of list
entries following the struct. This also fixes corruption with scat_q_depth, which
was mistankely added to the end of struct and overwritten if there were more
than item in the scat list.

Reported-by: Jason Liu &lt;r64343@freescale.com&gt;
Tested-by: Jason Liu &lt;r64343@freescale.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@qca.qualcomm.com&gt;
Cc: Josh Cartwright &lt;joshc@ni.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 31b9cc9a873dcab161999622314f98a75d838975 upstream.

Jason noticed that with Yocto GCC 4.8.1 ath6kl crashes with this iperf command:

iperf -c $TARGET_IP -i 5 -t 50 -w 1M

The crash was:

Unable to handle kernel paging request at virtual address 1a480000
pgd = 80004000
[1a480000] *pgd=00000000
Internal error: Oops: 805 [#1] SMP ARM
Modules linked in: ath6kl_sdio ath6kl_core [last unloaded: ath6kl_core]
CPU: 0 PID: 1953 Comm: kworker/u4:0 Not tainted 3.10.9-1.0.0_alpha+dbf364b #1
Workqueue: ath6kl ath6kl_sdio_write_async_work [ath6kl_sdio]
task: dcc9a680 ti: dc9ae000 task.ti: dc9ae000
PC is at v7_dma_clean_range+0x20/0x38
LR is at dma_cache_maint_page+0x50/0x54
pc : [&lt;8001a6f8&gt;]    lr : [&lt;800170fc&gt;]    psr: 20000093
sp : dc9afcf8  ip : 8001a748  fp : 00000004
r10: 00000000  r9 : 00000001  r8 : 00000000
r7 : 00000001  r6 : 00000000  r5 : 80cb7000  r4 : 03f9a480
r3 : 0000001f  r2 : 00000020  r1 : 1a480000  r0 : 1a480000
Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c53c7d  Table: 6cc5004a  DAC: 00000015
Process kworker/u4:0 (pid: 1953, stack limit = 0xdc9ae238)
Stack: (0xdc9afcf8 to 0xdc9b0000)
fce0:                                                       80c9b29c 00000000
fd00: 00000000 80017134 8001a748 dc302ac0 00000000 00000000 dc454a00 80c12ed8
fd20: dc115410 80017238 00000000 dc454a10 00000001 80017588 00000001 00000000
fd40: 00000000 dc302ac0 dc9afe38 dc9afe68 00000004 80c12ed8 00000000 dc454a00
fd60: 00000004 80436f88 00000000 00000000 00000600 0000ffff 0000000c 80c113c4
fd80: 80c9b29c 00000001 00000004 dc115470 60000013 dc302ac0 dc46e000 dc302800
fda0: dc9afe10 dc302b78 60000013 dc302ac0 dc46e000 00000035 dc46e5b0 80438c90
fdc0: dc9afe10 dc302800 dc302800 dc9afe68 dc9afe38 80424cb4 00000005 dc9afe10
fde0: dc9afe20 80424de8 dc9afe10 dc302800 dc46e910 80424e90 dc473c00 dc454f00
fe00: 000001b5 7f619d64 dcc7c830 00000000 00000000 dc9afe38 dc9afe68 00000000
fe20: 00000000 00000000 dc9afe28 dc9afe28 80424d80 00000000 00000035 9cac0034
fe40: 00000000 00000000 00000000 00000000 000001b5 00000000 00000000 00000000
fe60: dc9afe68 dc9afe10 3b9aca00 00000000 00000080 00000034 00000000 00000100
fe80: 00000000 00000000 dc9afe10 00000004 dc454a00 00000000 dc46e010 dc46e96c
fea0: dc46e000 dc46e964 00200200 00100100 dc46e910 7f619ec0 00000600 80c0e770
fec0: dc15a900 dcc7c838 00000000 dc46e954 8042d434 dcc44680 dc46e954 dc004400
fee0: dc454500 00000000 00000000 dc9ae038 dc004400 8003c450 dcc44680 dc004414
ff00: dc46e954 dc454500 00000001 dcc44680 dc004414 dcc44698 dc9ae000 dc9ae030
ff20: 00000001 dc9ae000 dc004400 8003d158 8003d020 00000000 00000000 80c53941
ff40: dc9aff64 dcb71ea0 00000000 dcc44680 8003d020 00000000 00000000 00000000
ff60: 00000000 80042480 00000000 00000000 000000f8 dcc44680 00000000 00000000
ff80: dc9aff80 dc9aff80 00000000 00000000 dc9aff90 dc9aff90 dc9affac dcb71ea0
ffa0: 800423cc 00000000 00000000 8000e018 00000000 00000000 00000000 00000000
ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[&lt;8001a6f8&gt;] (v7_dma_clean_range+0x20/0x38) from [&lt;800170fc&gt;] (dma_cache_maint_page+0x50/0x54)
[&lt;800170fc&gt;] (dma_cache_maint_page+0x50/0x54) from [&lt;80017134&gt;] (__dma_page_cpu_to_dev+0x34/0x9c)
[&lt;80017134&gt;] (__dma_page_cpu_to_dev+0x34/0x9c) from [&lt;80017238&gt;] (arm_dma_map_page+0x64/0x68)
[&lt;80017238&gt;] (arm_dma_map_page+0x64/0x68) from [&lt;80017588&gt;] (arm_dma_map_sg+0x7c/0xf4)
[&lt;80017588&gt;] (arm_dma_map_sg+0x7c/0xf4) from [&lt;80436f88&gt;] (sdhci_send_command+0x894/0xe00)
[&lt;80436f88&gt;] (sdhci_send_command+0x894/0xe00) from [&lt;80438c90&gt;] (sdhci_request+0xc0/0x1ec)
[&lt;80438c90&gt;] (sdhci_request+0xc0/0x1ec) from [&lt;80424cb4&gt;] (mmc_start_request+0xb8/0xd4)
[&lt;80424cb4&gt;] (mmc_start_request+0xb8/0xd4) from [&lt;80424de8&gt;] (__mmc_start_req+0x60/0x84)
[&lt;80424de8&gt;] (__mmc_start_req+0x60/0x84) from [&lt;80424e90&gt;] (mmc_wait_for_req+0x10/0x20)
[&lt;80424e90&gt;] (mmc_wait_for_req+0x10/0x20) from [&lt;7f619d64&gt;] (ath6kl_sdio_scat_rw.isra.10+0x1dc/0x240 [ath6kl_sdio])
[&lt;7f619d64&gt;] (ath6kl_sdio_scat_rw.isra.10+0x1dc/0x240 [ath6kl_sdio]) from [&lt;7f619ec0&gt;] (ath6kl_sdio_write_async_work+0x5c/0x104 [ath6kl_sdio])
[&lt;7f619ec0&gt;] (ath6kl_sdio_write_async_work+0x5c/0x104 [ath6kl_sdio]) from [&lt;8003c450&gt;] (process_one_work+0x10c/0x370)
[&lt;8003c450&gt;] (process_one_work+0x10c/0x370) from [&lt;8003d158&gt;] (worker_thread+0x138/0x3fc)
[&lt;8003d158&gt;] (worker_thread+0x138/0x3fc) from [&lt;80042480&gt;] (kthread+0xb4/0xb8)
[&lt;80042480&gt;] (kthread+0xb4/0xb8) from [&lt;8000e018&gt;] (ret_from_fork+0x14/0x3c)
Code: e1a02312 e2423001 e1c00003 f57ff04f (ee070f3a)
---[ end trace 0c038f0b8e0b67a3 ]---
Kernel panic - not syncing: Fatal exception

Jason's analysis:

  "The GCC 4.8.1 compiler will not do the for-loop till scat_entries, instead,
   it only run one round loop. This may be caused by that the GCC 4.8.1 thought
   that the scat_list only have one item and then no need to do full iteration,
   but this is simply wrong by looking at the assebly code. This will cause the sg
   buffer not get set when scat_entries &gt; 1 and thus lead to kernel panic.

   Note: This issue not observed with GCC 4.7.2, only found on the GCC 4.8.1)"

Fix this by using the normal [0] style for defining unknown number of list
entries following the struct. This also fixes corruption with scat_q_depth, which
was mistankely added to the end of struct and overwritten if there were more
than item in the scat list.

Reported-by: Jason Liu &lt;r64343@freescale.com&gt;
Tested-by: Jason Liu &lt;r64343@freescale.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@qca.qualcomm.com&gt;
Cc: Josh Cartwright &lt;joshc@ni.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ath5k: fix spontaneus AR5312 freezes</title>
<updated>2015-03-18T12:31:34+00:00</updated>
<author>
<name>Sergey Ryazanov</name>
<email>ryazanov.s.a@gmail.com</email>
</author>
<published>2015-02-03T21:21:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=cd15a8634eb6f6123846cd032f7c43040c7b8a1a'/>
<id>cd15a8634eb6f6123846cd032f7c43040c7b8a1a</id>
<content type='text'>
commit 8bfae4f9938b6c1f033a5159febe97e441d6d526 upstream.

Sometimes while CPU have some load and ath5k doing the wireless
interface reset the whole WiSoC completely freezes. Set of tests shows
that using atomic delay function while we wait interface reset helps to
avoid such freezes.

The easiest way to reproduce this issue: create a station interface,
start continous scan with wpa_supplicant and load CPU by something. Or
just create multiple station interfaces and put them all in continous
scan.

This patch partially reverts the commit 1846ac3dbec0 ("ath5k: Use
usleep_range where possible"), which replaces initial udelay()
by usleep_range().

I do not know actual source of this issue, but all looks like that HW
freeze is caused by transaction on internal SoC bus, while wireless
block is in reset state.

Also I should note that I do not know how many chips are affected, but I
did not see this issue with chips, other than AR5312.

CC: Jiri Slaby &lt;jirislaby@gmail.com&gt;
CC: Nick Kossifidis &lt;mickflemm@gmail.com&gt;
CC: Luis R. Rodriguez &lt;mcgrof@do-not-panic.com&gt;
Fixes: 1846ac3dbec0 ("ath5k: Use usleep_range where possible")
Reported-by: Christophe Prevotaux &lt;c.prevotaux@rural-networks.com&gt;
Tested-by: Christophe Prevotaux &lt;c.prevotaux@rural-networks.com&gt;
Tested-by: Eric Bree &lt;ebree@nltinc.com&gt;
Signed-off-by: Sergey Ryazanov &lt;ryazanov.s.a@gmail.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 8bfae4f9938b6c1f033a5159febe97e441d6d526 upstream.

Sometimes while CPU have some load and ath5k doing the wireless
interface reset the whole WiSoC completely freezes. Set of tests shows
that using atomic delay function while we wait interface reset helps to
avoid such freezes.

The easiest way to reproduce this issue: create a station interface,
start continous scan with wpa_supplicant and load CPU by something. Or
just create multiple station interfaces and put them all in continous
scan.

This patch partially reverts the commit 1846ac3dbec0 ("ath5k: Use
usleep_range where possible"), which replaces initial udelay()
by usleep_range().

I do not know actual source of this issue, but all looks like that HW
freeze is caused by transaction on internal SoC bus, while wireless
block is in reset state.

Also I should note that I do not know how many chips are affected, but I
did not see this issue with chips, other than AR5312.

CC: Jiri Slaby &lt;jirislaby@gmail.com&gt;
CC: Nick Kossifidis &lt;mickflemm@gmail.com&gt;
CC: Luis R. Rodriguez &lt;mcgrof@do-not-panic.com&gt;
Fixes: 1846ac3dbec0 ("ath5k: Use usleep_range where possible")
Reported-by: Christophe Prevotaux &lt;c.prevotaux@rural-networks.com&gt;
Tested-by: Christophe Prevotaux &lt;c.prevotaux@rural-networks.com&gt;
Tested-by: Eric Bree &lt;ebree@nltinc.com&gt;
Signed-off-by: Sergey Ryazanov &lt;ryazanov.s.a@gmail.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>team: don't traverse port list using rcu in team_set_mac_address</title>
<updated>2015-03-18T12:31:23+00:00</updated>
<author>
<name>Jiri Pirko</name>
<email>jiri@resnulli.us</email>
</author>
<published>2015-03-04T07:36:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=67b58fb7d3e7b1e393609e14d95d02a14d7328db'/>
<id>67b58fb7d3e7b1e393609e14d95d02a14d7328db</id>
<content type='text'>
[ Upstream commit 9215f437b85da339a7dfe3db6e288637406f88b2 ]

Currently the list is traversed using rcu variant. That is not correct
since dev_set_mac_address can be called which eventually calls
rtmsg_ifinfo_build_skb and there, skb allocation can sleep. So fix this
by remove the rcu usage here.

Fixes: 3d249d4ca7 "net: introduce ethernet teaming device"
Signed-off-by: Jiri Pirko &lt;jiri@resnulli.us&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 9215f437b85da339a7dfe3db6e288637406f88b2 ]

Currently the list is traversed using rcu variant. That is not correct
since dev_set_mac_address can be called which eventually calls
rtmsg_ifinfo_build_skb and there, skb allocation can sleep. So fix this
by remove the rcu usage here.

Fixes: 3d249d4ca7 "net: introduce ethernet teaming device"
Signed-off-by: Jiri Pirko &lt;jiri@resnulli.us&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb: plusb: Add support for National Instruments host-to-host cable</title>
<updated>2015-03-18T12:31:22+00:00</updated>
<author>
<name>Ben Shelton</name>
<email>ben.shelton@ni.com</email>
</author>
<published>2015-02-16T19:47:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=37aa4dd0a138bc88e42ca02a909367b12042fddf'/>
<id>37aa4dd0a138bc88e42ca02a909367b12042fddf</id>
<content type='text'>
[ Upstream commit 42c972a1f390e3bc51ca1e434b7e28764992067f ]

The National Instruments USB Host-to-Host Cable is based on the Prolific
PL-25A1 chipset.  Add its VID/PID so the plusb driver will recognize it.

Signed-off-by: Ben Shelton &lt;ben.shelton@ni.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 42c972a1f390e3bc51ca1e434b7e28764992067f ]

The National Instruments USB Host-to-Host Cable is based on the Prolific
PL-25A1 chipset.  Add its VID/PID so the plusb driver will recognize it.

Signed-off-by: Ben Shelton &lt;ben.shelton@ni.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>macvtap: make sure neighbour code can push ethernet header</title>
<updated>2015-03-18T12:31:22+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2015-02-28T02:35:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=00ecb618250e0f9369ced3c980becd79f9b6c1f9'/>
<id>00ecb618250e0f9369ced3c980becd79f9b6c1f9</id>
<content type='text'>
[ Upstream commit 2f1d8b9e8afa5a833d96afcd23abcb8cdf8d83ab ]

Brian reported crashes using IPv6 traffic with macvtap/veth combo.

I tracked the crashes in neigh_hh_output()

-&gt; memcpy(skb-&gt;data - HH_DATA_MOD, hh-&gt;hh_data, HH_DATA_MOD);

Neighbour code assumes headroom to push Ethernet header is
at least 16 bytes.

It appears macvtap has only 14 bytes available on arches
where NET_IP_ALIGN is 0 (like x86)

Effect is a corruption of 2 bytes right before skb-&gt;head,
and possible crashes if accessing non existing memory.

This fix should also increase IPv4 performance, as paranoid code
in ip_finish_output2() wont have to call skb_realloc_headroom()

Reported-by: Brian Rak &lt;brak@vultr.com&gt;
Tested-by: Brian Rak &lt;brak@vultr.com&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 2f1d8b9e8afa5a833d96afcd23abcb8cdf8d83ab ]

Brian reported crashes using IPv6 traffic with macvtap/veth combo.

I tracked the crashes in neigh_hh_output()

-&gt; memcpy(skb-&gt;data - HH_DATA_MOD, hh-&gt;hh_data, HH_DATA_MOD);

Neighbour code assumes headroom to push Ethernet header is
at least 16 bytes.

It appears macvtap has only 14 bytes available on arches
where NET_IP_ALIGN is 0 (like x86)

Effect is a corruption of 2 bytes right before skb-&gt;head,
and possible crashes if accessing non existing memory.

This fix should also increase IPv4 performance, as paranoid code
in ip_finish_output2() wont have to call skb_realloc_headroom()

Reported-by: Brian Rak &lt;brak@vultr.com&gt;
Tested-by: Brian Rak &lt;brak@vultr.com&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>team: fix possible null pointer dereference in team_handle_frame</title>
<updated>2015-03-18T12:31:22+00:00</updated>
<author>
<name>Jiri Pirko</name>
<email>jiri@resnulli.us</email>
</author>
<published>2015-02-23T13:02:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fdb35e5a1be06aa0d37dbdc7a987a792011c8bf9'/>
<id>fdb35e5a1be06aa0d37dbdc7a987a792011c8bf9</id>
<content type='text'>
[ Upstream commit 57e595631904c827cfa1a0f7bbd7cc9a49da5745 ]

Currently following race is possible in team:

CPU0                                        CPU1
                                            team_port_del
                                              team_upper_dev_unlink
                                                priv_flags &amp;= ~IFF_TEAM_PORT
team_handle_frame
  team_port_get_rcu
    team_port_exists
      priv_flags &amp; IFF_TEAM_PORT == 0
    return NULL (instead of port got
                 from rx_handler_data)
                                              netdev_rx_handler_unregister

The thing is that the flag is removed before rx_handler is unregistered.
If team_handle_frame is called in between, team_port_exists returns 0
and team_port_get_rcu will return NULL.
So do not check the flag here. It is guaranteed by netdev_rx_handler_unregister
that team_handle_frame will always see valid rx_handler_data pointer.

Signed-off-by: Jiri Pirko &lt;jiri@resnulli.us&gt;
Fixes: 3d249d4ca7d0 ("net: introduce ethernet teaming device")
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 57e595631904c827cfa1a0f7bbd7cc9a49da5745 ]

Currently following race is possible in team:

CPU0                                        CPU1
                                            team_port_del
                                              team_upper_dev_unlink
                                                priv_flags &amp;= ~IFF_TEAM_PORT
team_handle_frame
  team_port_get_rcu
    team_port_exists
      priv_flags &amp; IFF_TEAM_PORT == 0
    return NULL (instead of port got
                 from rx_handler_data)
                                              netdev_rx_handler_unregister

The thing is that the flag is removed before rx_handler is unregistered.
If team_handle_frame is called in between, team_port_exists returns 0
and team_port_get_rcu will return NULL.
So do not check the flag here. It is guaranteed by netdev_rx_handler_unregister
that team_handle_frame will always see valid rx_handler_data pointer.

Signed-off-by: Jiri Pirko &lt;jiri@resnulli.us&gt;
Fixes: 3d249d4ca7d0 ("net: introduce ethernet teaming device")
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: phy: Fix verification of EEE support in phy_init_eee</title>
<updated>2015-03-18T12:31:21+00:00</updated>
<author>
<name>Guenter Roeck</name>
<email>linux@roeck-us.net</email>
</author>
<published>2015-02-17T17:36:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=058969ab33db1707538ad6472964423b8115d642'/>
<id>058969ab33db1707538ad6472964423b8115d642</id>
<content type='text'>
[ Upstream commit 54da5a8be3c1e924c35480eb44c6e9b275f6444e ]

phy_init_eee uses phy_find_setting(phydev-&gt;speed, phydev-&gt;duplex)
to find a valid entry in the settings array for the given speed
and duplex value. For full duplex 1000baseT, this will return
the first matching entry, which is the entry for 1000baseKX_Full.

If the phy eee does not support 1000baseKX_Full, this entry will not
match, causing phy_init_eee to fail for no good reason.

Fixes: 9a9c56cb34e6 ("net: phy: fix a bug when verify the EEE support")
Fixes: 3e7077067e80c ("phy: Expand phy speed/duplex settings array")
Cc: Giuseppe Cavallaro &lt;peppe.cavallaro@st.com&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Acked-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 54da5a8be3c1e924c35480eb44c6e9b275f6444e ]

phy_init_eee uses phy_find_setting(phydev-&gt;speed, phydev-&gt;duplex)
to find a valid entry in the settings array for the given speed
and duplex value. For full duplex 1000baseT, this will return
the first matching entry, which is the entry for 1000baseKX_Full.

If the phy eee does not support 1000baseKX_Full, this entry will not
match, causing phy_init_eee to fail for no good reason.

Fixes: 9a9c56cb34e6 ("net: phy: fix a bug when verify the EEE support")
Fixes: 3e7077067e80c ("phy: Expand phy speed/duplex settings array")
Cc: Giuseppe Cavallaro &lt;peppe.cavallaro@st.com&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Acked-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
