<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/net, branch v3.19.3</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>b43: fix support for 5 GHz only BCM43228 model</title>
<updated>2015-03-26T12:59:49+00:00</updated>
<author>
<name>Rafał Miłecki</name>
<email>zajec5@gmail.com</email>
</author>
<published>2015-03-02T16:18:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fe9c9b2a4545e2ec3eea3369dbd8fccfccd40c44'/>
<id>fe9c9b2a4545e2ec3eea3369dbd8fccfccd40c44</id>
<content type='text'>
commit 0ff66cffde47de51c155ebdd2356403276c04cc4 upstream.

It was incorrectly detected as 2 GHz device.

Signed-off-by: Rafał Miłecki &lt;zajec5@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 0ff66cffde47de51c155ebdd2356403276c04cc4 upstream.

It was incorrectly detected as 2 GHz device.

Signed-off-by: Rafał Miłecki &lt;zajec5@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>net: fec: fix rcv is not last issue when do suspend/resume test</title>
<updated>2015-03-26T12:59:44+00:00</updated>
<author>
<name>Fugang Duan</name>
<email>b38611@freescale.com</email>
</author>
<published>2015-03-03T23:52:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8b86cf382cada10567345a558e38911f179f3c1a'/>
<id>8b86cf382cada10567345a558e38911f179f3c1a</id>
<content type='text'>
commit 61615cd27e2fdcf698261ba77c7d93f7a7739c65 upstream.

When do suspend/resume stress test, some log shows "rcv is not +last".
The issue is that enet suspend will disable phy clock, phy link down,
after resume back, enet MAC redo initial and ready to tx/rx packet,
but phy still is not ready which is doing auto-negotiation. When phy
link is not up, don't schdule napi soft irq.

[Peter]
It has fixed kernel panic after long time suspend/resume test
with nfs rootfs.

[ 8864.429458] fec 2188000.ethernet eth0: rcv is not +last
[ 8864.434799] fec 2188000.ethernet eth0: rcv is not +last
[ 8864.440088] fec 2188000.ethernet eth0: rcv is not +last
[ 8864.445424] fec 2188000.ethernet eth0: rcv is not +last
[ 8864.450782] fec 2188000.ethernet eth0: rcv is not +last
[ 8864.456111] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[ 8864.464225] pgd = 80004000
[ 8864.466997] [00000000] *pgd=00000000
[ 8864.470627] Internal error: Oops: 17 [#1] SMP ARM
[ 8864.475353] Modules linked in: evbug
[ 8864.479006] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 4.0.0-rc1-00044-g7a2a1d2 #234
[ 8864.486854] Hardware name: Freescale i.MX6 SoloX (Device Tree)
[ 8864.492709] task: be069380 ti: be07a000 task.ti: be07a000
[ 8864.498137] PC is at memcpy+0x80/0x330
[ 8864.501919] LR is at gro_pull_from_frag0+0x34/0xa8
[ 8864.506735] pc : [&lt;802bb080&gt;]    lr : [&lt;8057c204&gt;]    psr: 00000113
[ 8864.506735] sp : be07bbd4  ip : 00000010  fp : be07bc0c
[ 8864.518235] r10: 0000000e  r9 : 00000000  r8 : 809c7754
[ 8864.523479] r7 : 809c7754  r6 : bb43c040  r5 : bd280cc0  r4 : 00000012
[ 8864.530025] r3 : 00000804  r2 : fffffff2  r1 : 00000000  r0 : bb43b83c
[ 8864.536575] Flags: nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[ 8864.543904] Control: 10c5387d  Table: bd14c04a  DAC: 00000015
[ 8864.549669] Process ksoftirqd/0 (pid: 3, stack limit = 0xbe07a210)
[ 8864.555869] Stack: (0xbe07bbd4 to 0xbe07c000)
[ 8864.560250] bbc0:                                              bd280cc0 bb43c040 809c7754
[ 8864.568455] bbe0: 809c7754 bb43b83c 00000012 8057c204 00000000 bd280cc0 bd8a0718 00000003
[ 8864.576658] bc00: be07bc5c be07bc10 8057ebf0 8057c1dc 00000000 00000000 8057ecc4 bef59760
[ 8864.584863] bc20: 00000002 bd8a0000 be07bc64 809c7754 00000000 bd8a0718 bd280cc0 bd8a0000
[ 8864.593066] bc40: 00000000 0000001c 00000000 bd8a0000 be07bc74 be07bc60 8057f148 8057eb90
[ 8864.601268] bc60: bf0810a0 00000000 be07bcf4 be07bc78 8044e7b4 8057f12c 00000000 8007df6c
[ 8864.609470] bc80: bd8a0718 00000040 00000000 bd280a80 00000002 00000019 bd8a0600 bd8a1214
[ 8864.617672] bca0: bd8a0690 bf0810a0 00000000 00000000 bd8a1000 00000000 00000027 bd280cc0
[ 8864.625874] bcc0: 80062708 800625cc 000943db bd8a0718 00000001 000d1166 00000040 be7c1ec0
[ 8864.634077] bce0: 0000012c be07bd00 be07bd3c be07bcf8 8057fc98 8044e3ac 809c2ec0 3ddff000
[ 8864.642280] bd00: be07bd00 be07bd00 be07bd08 be07bd08 00000000 00000020 809c608c 00000003
[ 8864.650481] bd20: 809c6080 40000001 809c6088 00200100 be07bd84 be07bd40 8002e690 8057fac8
[ 8864.658684] bd40: be07bd64 be07bd50 00000001 04208040 000d1165 0000000a be07bd84 809c0d7c
[ 8864.666885] bd60: 00000000 809c6af8 00000000 00000001 be008000 00000000 be07bd9c be07bd88
[ 8864.675087] bd80: 8002eb64 8002e564 00000125 809c0d7c be07bdc4 be07bda0 8006f100 8002eaac
[ 8864.683291] bda0: c080e10c be07bde8 809c6c6c c080e100 00000002 00000000 be07bde4 be07bdc8
[ 8864.691492] bdc0: 800087a0 8006f098 806f2934 20000013 ffffffff be07be1c be07be44 be07bde8
[ 8864.699695] bde0: 800133a4 80008784 00000001 00000001 00000000 00000000 be7c1680 00000000
[ 8864.707896] be00: be0cfe00 bd93eb40 00000002 00000000 00000000 be07be44 be07be00 be07be30
[ 8864.716098] be20: 8006278c 806f2934 20000013 ffffffff be069380 be7c1680 be07be7c be07be48
[ 8864.724300] be40: 80049cfc 806f2910 00000001 00000000 80049cb4 00000000 be07be7c be7c1680
[ 8864.732502] be60: be3289c0 be069380 bd23b600 be0cfe00 be07bebc be07be80 806ed614 80049c68
[ 8864.740706] be80: be07a000 0000020a 809c608c 00000003 00000001 8002e858 be07a000 be035740
[ 8864.748907] bea0: 00000000 00000001 809d4598 00000000 be07bed4 be07bec0 806edd0c 806ed440
[ 8864.757110] bec0: be07a000 be07a000 be07bee4 be07bed8 806edd68 806edcf0 be07bef4 be07bee8
[ 8864.765311] bee0: 8002e860 806edd34 be07bf24 be07bef8 800494b0 8002e828 be069380 00000000
[ 8864.773512] bf00: be035780 be035740 8004938c 00000000 00000000 00000000 be07bfac be07bf28
[ 8864.781715] bf20: 80045928 80049398 be07bf44 00000001 00000000 be035740 00000000 00030003
[ 8864.789917] bf40: dead4ead ffffffff ffffffff 80a2716c 80b59b00 00000000 8088c954 be07bf5c
[ 8864.798120] bf60: be07bf5c 00000000 00000000 dead4ead ffffffff ffffffff 80a2716c 00000000
[ 8864.806320] bf80: 00000000 8088c954 be07bf88 be07bf88 be035780 8004584c 00000000 00000000
[ 8864.814523] bfa0: 00000000 be07bfb0 8000ed10 80045858 00000000 00000000 00000000 00000000
[ 8864.822723] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 8864.830925] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 5ffbb5f7 f9fcf5e7
[ 8864.839115] Backtrace:
[ 8864.841631] [&lt;8057c1d0&gt;] (gro_pull_from_frag0) from [&lt;8057ebf0&gt;] (dev_gro_receive+0x6c/0x3f8)
[ 8864.850173]  r6:00000003 r5:bd8a0718 r4:bd280cc0 r3:00000000
[ 8864.855958] [&lt;8057eb84&gt;] (dev_gro_receive) from [&lt;8057f148&gt;] (napi_gro_receive+0x28/0xac)
[ 8864.864152]  r10:bd8a0000 r9:00000000 r8:0000001c r7:00000000 r6:bd8a0000 r5:bd280cc0
[ 8864.872115]  r4:bd8a0718
[ 8864.874713] [&lt;8057f120&gt;] (napi_gro_receive) from [&lt;8044e7b4&gt;] (fec_enet_rx_napi+0x414/0xc74)
[ 8864.883167]  r5:00000000 r4:bf0810a0
[ 8864.886823] [&lt;8044e3a0&gt;] (fec_enet_rx_napi) from [&lt;8057fc98&gt;] (net_rx_action+0x1dc/0x2ec)
[ 8864.895016]  r10:be07bd00 r9:0000012c r8:be7c1ec0 r7:00000040 r6:000d1166 r5:00000001
[ 8864.902982]  r4:bd8a0718
[ 8864.905570] [&lt;8057fabc&gt;] (net_rx_action) from [&lt;8002e690&gt;] (__do_softirq+0x138/0x2c4)
[ 8864.913417]  r10:00200100 r9:809c6088 r8:40000001 r7:809c6080 r6:00000003 r5:809c608c
[ 8864.921382]  r4:00000020
[ 8864.923966] [&lt;8002e558&gt;] (__do_softirq) from [&lt;8002eb64&gt;] (irq_exit+0xc4/0x138)
[ 8864.931289]  r10:00000000 r9:be008000 r8:00000001 r7:00000000 r6:809c6af8 r5:00000000
[ 8864.939252]  r4:809c0d7c
[ 8864.941841] [&lt;8002eaa0&gt;] (irq_exit) from [&lt;8006f100&gt;] (__handle_domain_irq+0x74/0xe8)
[ 8864.949688]  r4:809c0d7c r3:00000125
[ 8864.953342] [&lt;8006f08c&gt;] (__handle_domain_irq) from [&lt;800087a0&gt;] (gic_handle_irq+0x28/0x68)
[ 8864.961707]  r9:00000000 r8:00000002 r7:c080e100 r6:809c6c6c r5:be07bde8 r4:c080e10c
[ 8864.969597] [&lt;80008778&gt;] (gic_handle_irq) from [&lt;800133a4&gt;] (__irq_svc+0x44/0x5c)
[ 8864.977097] Exception stack(0xbe07bde8 to 0xbe07be30)
[ 8864.982173] bde0:                   00000001 00000001 00000000 00000000 be7c1680 00000000
[ 8864.990377] be00: be0cfe00 bd93eb40 00000002 00000000 00000000 be07be44 be07be00 be07be30
[ 8864.998573] be20: 8006278c 806f2934 20000013 ffffffff
[ 8865.003638]  r7:be07be1c r6:ffffffff r5:20000013 r4:806f2934
[ 8865.009447] [&lt;806f2904&gt;] (_raw_spin_unlock_irq) from [&lt;80049cfc&gt;] (finish_task_switch+0xa0/0x160)
[ 8865.018334]  r4:be7c1680 r3:be069380
[ 8865.021993] [&lt;80049c5c&gt;] (finish_task_switch) from [&lt;806ed614&gt;] (__schedule+0x1e0/0x5dc)
[ 8865.030098]  r8:be0cfe00 r7:bd23b600 r6:be069380 r5:be3289c0 r4:be7c1680
[ 8865.036942] [&lt;806ed434&gt;] (__schedule) from [&lt;806edd0c&gt;] (preempt_schedule_common+0x28/0x44)
[ 8865.045307]  r9:00000000 r8:809d4598 r7:00000001 r6:00000000 r5:be035740 r4:be07a000
[ 8865.053197] [&lt;806edce4&gt;] (preempt_schedule_common) from [&lt;806edd68&gt;] (_cond_resched+0x40/0x48)
[ 8865.061822]  r4:be07a000 r3:be07a000
[ 8865.065472] [&lt;806edd28&gt;] (_cond_resched) from [&lt;8002e860&gt;] (run_ksoftirqd+0x44/0x64)
[ 8865.073252] [&lt;8002e81c&gt;] (run_ksoftirqd) from [&lt;800494b0&gt;] (smpboot_thread_fn+0x124/0x190)
[ 8865.081550] [&lt;8004938c&gt;] (smpboot_thread_fn) from [&lt;80045928&gt;] (kthread+0xdc/0xf8)
[ 8865.089133]  r10:00000000 r9:00000000 r8:00000000 r7:8004938c r6:be035740 r5:be035780
[ 8865.097097]  r4:00000000 r3:be069380
[ 8865.100752] [&lt;8004584c&gt;] (kthread) from [&lt;8000ed10&gt;] (ret_from_fork+0x14/0x24)
[ 8865.107990]  r7:00000000 r6:00000000 r5:8004584c r4:be035780
[ 8865.113767] Code: e320f000 e4913004 e4914004 e4915004 (e4916004)
[ 8865.120006] ---[ end trace b0a4c6bd499288ca ]---
[ 8865.124697] Kernel panic - not syncing: Fatal exception in interrupt
[ 8865.131084] ---[ end Kernel panic - not syncing: Fatal exception in interrupt

Tested-by: Peter Chen &lt;peter.chen@freescale.com&gt;
Signed-off-by: Peter Chen &lt;peter.chen@freescale.com&gt;
Signed-off-by: Fugang Duan &lt;B38611@freescale.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 61615cd27e2fdcf698261ba77c7d93f7a7739c65 upstream.

When do suspend/resume stress test, some log shows "rcv is not +last".
The issue is that enet suspend will disable phy clock, phy link down,
after resume back, enet MAC redo initial and ready to tx/rx packet,
but phy still is not ready which is doing auto-negotiation. When phy
link is not up, don't schdule napi soft irq.

[Peter]
It has fixed kernel panic after long time suspend/resume test
with nfs rootfs.

[ 8864.429458] fec 2188000.ethernet eth0: rcv is not +last
[ 8864.434799] fec 2188000.ethernet eth0: rcv is not +last
[ 8864.440088] fec 2188000.ethernet eth0: rcv is not +last
[ 8864.445424] fec 2188000.ethernet eth0: rcv is not +last
[ 8864.450782] fec 2188000.ethernet eth0: rcv is not +last
[ 8864.456111] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[ 8864.464225] pgd = 80004000
[ 8864.466997] [00000000] *pgd=00000000
[ 8864.470627] Internal error: Oops: 17 [#1] SMP ARM
[ 8864.475353] Modules linked in: evbug
[ 8864.479006] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 4.0.0-rc1-00044-g7a2a1d2 #234
[ 8864.486854] Hardware name: Freescale i.MX6 SoloX (Device Tree)
[ 8864.492709] task: be069380 ti: be07a000 task.ti: be07a000
[ 8864.498137] PC is at memcpy+0x80/0x330
[ 8864.501919] LR is at gro_pull_from_frag0+0x34/0xa8
[ 8864.506735] pc : [&lt;802bb080&gt;]    lr : [&lt;8057c204&gt;]    psr: 00000113
[ 8864.506735] sp : be07bbd4  ip : 00000010  fp : be07bc0c
[ 8864.518235] r10: 0000000e  r9 : 00000000  r8 : 809c7754
[ 8864.523479] r7 : 809c7754  r6 : bb43c040  r5 : bd280cc0  r4 : 00000012
[ 8864.530025] r3 : 00000804  r2 : fffffff2  r1 : 00000000  r0 : bb43b83c
[ 8864.536575] Flags: nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[ 8864.543904] Control: 10c5387d  Table: bd14c04a  DAC: 00000015
[ 8864.549669] Process ksoftirqd/0 (pid: 3, stack limit = 0xbe07a210)
[ 8864.555869] Stack: (0xbe07bbd4 to 0xbe07c000)
[ 8864.560250] bbc0:                                              bd280cc0 bb43c040 809c7754
[ 8864.568455] bbe0: 809c7754 bb43b83c 00000012 8057c204 00000000 bd280cc0 bd8a0718 00000003
[ 8864.576658] bc00: be07bc5c be07bc10 8057ebf0 8057c1dc 00000000 00000000 8057ecc4 bef59760
[ 8864.584863] bc20: 00000002 bd8a0000 be07bc64 809c7754 00000000 bd8a0718 bd280cc0 bd8a0000
[ 8864.593066] bc40: 00000000 0000001c 00000000 bd8a0000 be07bc74 be07bc60 8057f148 8057eb90
[ 8864.601268] bc60: bf0810a0 00000000 be07bcf4 be07bc78 8044e7b4 8057f12c 00000000 8007df6c
[ 8864.609470] bc80: bd8a0718 00000040 00000000 bd280a80 00000002 00000019 bd8a0600 bd8a1214
[ 8864.617672] bca0: bd8a0690 bf0810a0 00000000 00000000 bd8a1000 00000000 00000027 bd280cc0
[ 8864.625874] bcc0: 80062708 800625cc 000943db bd8a0718 00000001 000d1166 00000040 be7c1ec0
[ 8864.634077] bce0: 0000012c be07bd00 be07bd3c be07bcf8 8057fc98 8044e3ac 809c2ec0 3ddff000
[ 8864.642280] bd00: be07bd00 be07bd00 be07bd08 be07bd08 00000000 00000020 809c608c 00000003
[ 8864.650481] bd20: 809c6080 40000001 809c6088 00200100 be07bd84 be07bd40 8002e690 8057fac8
[ 8864.658684] bd40: be07bd64 be07bd50 00000001 04208040 000d1165 0000000a be07bd84 809c0d7c
[ 8864.666885] bd60: 00000000 809c6af8 00000000 00000001 be008000 00000000 be07bd9c be07bd88
[ 8864.675087] bd80: 8002eb64 8002e564 00000125 809c0d7c be07bdc4 be07bda0 8006f100 8002eaac
[ 8864.683291] bda0: c080e10c be07bde8 809c6c6c c080e100 00000002 00000000 be07bde4 be07bdc8
[ 8864.691492] bdc0: 800087a0 8006f098 806f2934 20000013 ffffffff be07be1c be07be44 be07bde8
[ 8864.699695] bde0: 800133a4 80008784 00000001 00000001 00000000 00000000 be7c1680 00000000
[ 8864.707896] be00: be0cfe00 bd93eb40 00000002 00000000 00000000 be07be44 be07be00 be07be30
[ 8864.716098] be20: 8006278c 806f2934 20000013 ffffffff be069380 be7c1680 be07be7c be07be48
[ 8864.724300] be40: 80049cfc 806f2910 00000001 00000000 80049cb4 00000000 be07be7c be7c1680
[ 8864.732502] be60: be3289c0 be069380 bd23b600 be0cfe00 be07bebc be07be80 806ed614 80049c68
[ 8864.740706] be80: be07a000 0000020a 809c608c 00000003 00000001 8002e858 be07a000 be035740
[ 8864.748907] bea0: 00000000 00000001 809d4598 00000000 be07bed4 be07bec0 806edd0c 806ed440
[ 8864.757110] bec0: be07a000 be07a000 be07bee4 be07bed8 806edd68 806edcf0 be07bef4 be07bee8
[ 8864.765311] bee0: 8002e860 806edd34 be07bf24 be07bef8 800494b0 8002e828 be069380 00000000
[ 8864.773512] bf00: be035780 be035740 8004938c 00000000 00000000 00000000 be07bfac be07bf28
[ 8864.781715] bf20: 80045928 80049398 be07bf44 00000001 00000000 be035740 00000000 00030003
[ 8864.789917] bf40: dead4ead ffffffff ffffffff 80a2716c 80b59b00 00000000 8088c954 be07bf5c
[ 8864.798120] bf60: be07bf5c 00000000 00000000 dead4ead ffffffff ffffffff 80a2716c 00000000
[ 8864.806320] bf80: 00000000 8088c954 be07bf88 be07bf88 be035780 8004584c 00000000 00000000
[ 8864.814523] bfa0: 00000000 be07bfb0 8000ed10 80045858 00000000 00000000 00000000 00000000
[ 8864.822723] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 8864.830925] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 5ffbb5f7 f9fcf5e7
[ 8864.839115] Backtrace:
[ 8864.841631] [&lt;8057c1d0&gt;] (gro_pull_from_frag0) from [&lt;8057ebf0&gt;] (dev_gro_receive+0x6c/0x3f8)
[ 8864.850173]  r6:00000003 r5:bd8a0718 r4:bd280cc0 r3:00000000
[ 8864.855958] [&lt;8057eb84&gt;] (dev_gro_receive) from [&lt;8057f148&gt;] (napi_gro_receive+0x28/0xac)
[ 8864.864152]  r10:bd8a0000 r9:00000000 r8:0000001c r7:00000000 r6:bd8a0000 r5:bd280cc0
[ 8864.872115]  r4:bd8a0718
[ 8864.874713] [&lt;8057f120&gt;] (napi_gro_receive) from [&lt;8044e7b4&gt;] (fec_enet_rx_napi+0x414/0xc74)
[ 8864.883167]  r5:00000000 r4:bf0810a0
[ 8864.886823] [&lt;8044e3a0&gt;] (fec_enet_rx_napi) from [&lt;8057fc98&gt;] (net_rx_action+0x1dc/0x2ec)
[ 8864.895016]  r10:be07bd00 r9:0000012c r8:be7c1ec0 r7:00000040 r6:000d1166 r5:00000001
[ 8864.902982]  r4:bd8a0718
[ 8864.905570] [&lt;8057fabc&gt;] (net_rx_action) from [&lt;8002e690&gt;] (__do_softirq+0x138/0x2c4)
[ 8864.913417]  r10:00200100 r9:809c6088 r8:40000001 r7:809c6080 r6:00000003 r5:809c608c
[ 8864.921382]  r4:00000020
[ 8864.923966] [&lt;8002e558&gt;] (__do_softirq) from [&lt;8002eb64&gt;] (irq_exit+0xc4/0x138)
[ 8864.931289]  r10:00000000 r9:be008000 r8:00000001 r7:00000000 r6:809c6af8 r5:00000000
[ 8864.939252]  r4:809c0d7c
[ 8864.941841] [&lt;8002eaa0&gt;] (irq_exit) from [&lt;8006f100&gt;] (__handle_domain_irq+0x74/0xe8)
[ 8864.949688]  r4:809c0d7c r3:00000125
[ 8864.953342] [&lt;8006f08c&gt;] (__handle_domain_irq) from [&lt;800087a0&gt;] (gic_handle_irq+0x28/0x68)
[ 8864.961707]  r9:00000000 r8:00000002 r7:c080e100 r6:809c6c6c r5:be07bde8 r4:c080e10c
[ 8864.969597] [&lt;80008778&gt;] (gic_handle_irq) from [&lt;800133a4&gt;] (__irq_svc+0x44/0x5c)
[ 8864.977097] Exception stack(0xbe07bde8 to 0xbe07be30)
[ 8864.982173] bde0:                   00000001 00000001 00000000 00000000 be7c1680 00000000
[ 8864.990377] be00: be0cfe00 bd93eb40 00000002 00000000 00000000 be07be44 be07be00 be07be30
[ 8864.998573] be20: 8006278c 806f2934 20000013 ffffffff
[ 8865.003638]  r7:be07be1c r6:ffffffff r5:20000013 r4:806f2934
[ 8865.009447] [&lt;806f2904&gt;] (_raw_spin_unlock_irq) from [&lt;80049cfc&gt;] (finish_task_switch+0xa0/0x160)
[ 8865.018334]  r4:be7c1680 r3:be069380
[ 8865.021993] [&lt;80049c5c&gt;] (finish_task_switch) from [&lt;806ed614&gt;] (__schedule+0x1e0/0x5dc)
[ 8865.030098]  r8:be0cfe00 r7:bd23b600 r6:be069380 r5:be3289c0 r4:be7c1680
[ 8865.036942] [&lt;806ed434&gt;] (__schedule) from [&lt;806edd0c&gt;] (preempt_schedule_common+0x28/0x44)
[ 8865.045307]  r9:00000000 r8:809d4598 r7:00000001 r6:00000000 r5:be035740 r4:be07a000
[ 8865.053197] [&lt;806edce4&gt;] (preempt_schedule_common) from [&lt;806edd68&gt;] (_cond_resched+0x40/0x48)
[ 8865.061822]  r4:be07a000 r3:be07a000
[ 8865.065472] [&lt;806edd28&gt;] (_cond_resched) from [&lt;8002e860&gt;] (run_ksoftirqd+0x44/0x64)
[ 8865.073252] [&lt;8002e81c&gt;] (run_ksoftirqd) from [&lt;800494b0&gt;] (smpboot_thread_fn+0x124/0x190)
[ 8865.081550] [&lt;8004938c&gt;] (smpboot_thread_fn) from [&lt;80045928&gt;] (kthread+0xdc/0xf8)
[ 8865.089133]  r10:00000000 r9:00000000 r8:00000000 r7:8004938c r6:be035740 r5:be035780
[ 8865.097097]  r4:00000000 r3:be069380
[ 8865.100752] [&lt;8004584c&gt;] (kthread) from [&lt;8000ed10&gt;] (ret_from_fork+0x14/0x24)
[ 8865.107990]  r7:00000000 r6:00000000 r5:8004584c r4:be035780
[ 8865.113767] Code: e320f000 e4913004 e4914004 e4915004 (e4916004)
[ 8865.120006] ---[ end trace b0a4c6bd499288ca ]---
[ 8865.124697] Kernel panic - not syncing: Fatal exception in interrupt
[ 8865.131084] ---[ end Kernel panic - not syncing: Fatal exception in interrupt

Tested-by: Peter Chen &lt;peter.chen@freescale.com&gt;
Signed-off-by: Peter Chen &lt;peter.chen@freescale.com&gt;
Signed-off-by: Fugang Duan &lt;B38611@freescale.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>bnx2x: Force fundamental reset for EEH recovery</title>
<updated>2015-03-26T12:59:44+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=4f500c93b2cd2d1c81883039131c6077c933474c'/>
<id>4f500c93b2cd2d1c81883039131c6077c933474c</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: kvaser_usb: Read all messages in a bulk-in URB buffer</title>
<updated>2015-03-26T12:59:41+00:00</updated>
<author>
<name>Ahmed S. Darwish</name>
<email>ahmed.darwish@valeo.com</email>
</author>
<published>2015-02-26T15:22:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=add9df23fcbaff2c77cedb0056ef08159420a1a8'/>
<id>add9df23fcbaff2c77cedb0056ef08159420a1a8</id>
<content type='text'>
commit 2fec5104f9c61de4cf2205aa355101e19a81f490 upstream.

The Kvaser firmware can only read and write messages that are
not crossing the USB endpoint's wMaxPacketSize boundary. While
receiving commands from the CAN device, if the next command in
the same URB buffer crossed that max packet size boundary, the
firmware puts a zero-length placeholder command in its place
then moves the real command to the next boundary mark.

The driver did not recognize such behavior, leading to missing
a good number of rx events during a heavy rx load session.

Moreover, a tx URB context only gets freed upon receiving its
respective tx ACK event. Over time, the free tx URB contexts
pool gets depleted due to the missing ACK events. Consequently,
the netif transmission queue gets __permanently__ stopped; no
frames could be sent again except after restarting the CAN
newtwork interface.

Signed-off-by: Ahmed S. Darwish &lt;ahmed.darwish@valeo.com&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 2fec5104f9c61de4cf2205aa355101e19a81f490 upstream.

The Kvaser firmware can only read and write messages that are
not crossing the USB endpoint's wMaxPacketSize boundary. While
receiving commands from the CAN device, if the next command in
the same URB buffer crossed that max packet size boundary, the
firmware puts a zero-length placeholder command in its place
then moves the real command to the next boundary mark.

The driver did not recognize such behavior, leading to missing
a good number of rx events during a heavy rx load session.

Moreover, a tx URB context only gets freed upon receiving its
respective tx ACK event. Over time, the free tx URB contexts
pool gets depleted due to the missing ACK events. Consequently,
the netif transmission queue gets __permanently__ stopped; no
frames could be sent again except after restarting the CAN
newtwork interface.

Signed-off-by: Ahmed S. Darwish &lt;ahmed.darwish@valeo.com&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>can: add missing initialisations in CAN related skbuffs</title>
<updated>2015-03-26T12:59:41+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=1db8d02526e3e224c7dc4df2b2cda7cf37a9ae80'/>
<id>1db8d02526e3e224c7dc4df2b2cda7cf37a9ae80</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-26T12:59:34+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=2604c9c02808f95da9b7c0cf6b03f381b3c4483c'/>
<id>2604c9c02808f95da9b7c0cf6b03f381b3c4483c</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>net/mlx4_en: Fix off-by-one in ethtool statistics display</title>
<updated>2015-03-26T12:59:34+00:00</updated>
<author>
<name>Eran Ben Elisha</name>
<email>eranbe@mellanox.com</email>
</author>
<published>2015-03-18T14:51:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7e1df1a11cc1cc993b924400e46d48085eb281b2'/>
<id>7e1df1a11cc1cc993b924400e46d48085eb281b2</id>
<content type='text'>
[ Upstream commit a16f3565703cfc3094938fb3c979cbb90f6d9eb4 ]

NUM_PORT_STATS was 9 instead of 10, which caused off-by-one bug when
displaying the statistics starting from tx_chksum_offload in ethtool.

Fixes: f8c6455bb04b ('net/mlx4_en: Extend checksum offloading by CHECKSUM COMPLETE')
Signed-off-by: Eran Ben Elisha &lt;eranbe@mellanox.com&gt;
Signed-off-by: Hadar Hen Zion &lt;hadarh@mellanox.com&gt;
Signed-off-by: Or Gerlitz &lt;ogerlitz@mellanox.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 a16f3565703cfc3094938fb3c979cbb90f6d9eb4 ]

NUM_PORT_STATS was 9 instead of 10, which caused off-by-one bug when
displaying the statistics starting from tx_chksum_offload in ethtool.

Fixes: f8c6455bb04b ('net/mlx4_en: Extend checksum offloading by CHECKSUM COMPLETE')
Signed-off-by: Eran Ben Elisha &lt;eranbe@mellanox.com&gt;
Signed-off-by: Hadar Hen Zion &lt;hadarh@mellanox.com&gt;
Signed-off-by: Or Gerlitz &lt;ogerlitz@mellanox.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>virtio-net: correctly delete napi hash</title>
<updated>2015-03-26T12:59:33+00:00</updated>
<author>
<name>Jason Wang</name>
<email>jasowang@redhat.com</email>
</author>
<published>2015-03-12T05:57:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=cdffd074bb2d55d7acbd8b6ba73a6e04ce2b080d'/>
<id>cdffd074bb2d55d7acbd8b6ba73a6e04ce2b080d</id>
<content type='text'>
[ Upstream commit ab3971b1e7d72270a2a259a29c1a40351b889740 ]

We don't delete napi from hash list during module exit. This will
cause the following panic when doing module load and unload:

BUG: unable to handle kernel paging request at 0000004e00000075
IP: [&lt;ffffffff816bd01b&gt;] napi_hash_add+0x6b/0xf0
PGD 3c5d5067 PUD 0
Oops: 0000 [#1] SMP
...
Call Trace:
[&lt;ffffffffa0a5bfb7&gt;] init_vqs+0x107/0x490 [virtio_net]
[&lt;ffffffffa0a5c9f2&gt;] virtnet_probe+0x562/0x791815639d880be [virtio_net]
[&lt;ffffffff8139e667&gt;] virtio_dev_probe+0x137/0x200
[&lt;ffffffff814c7f2a&gt;] driver_probe_device+0x7a/0x250
[&lt;ffffffff814c81d3&gt;] __driver_attach+0x93/0xa0
[&lt;ffffffff814c8140&gt;] ? __device_attach+0x40/0x40
[&lt;ffffffff814c6053&gt;] bus_for_each_dev+0x63/0xa0
[&lt;ffffffff814c7a79&gt;] driver_attach+0x19/0x20
[&lt;ffffffff814c76f0&gt;] bus_add_driver+0x170/0x220
[&lt;ffffffffa0a60000&gt;] ? 0xffffffffa0a60000
[&lt;ffffffff814c894f&gt;] driver_register+0x5f/0xf0
[&lt;ffffffff8139e41b&gt;] register_virtio_driver+0x1b/0x30
[&lt;ffffffffa0a60010&gt;] virtio_net_driver_init+0x10/0x12 [virtio_net]

This patch fixes this by doing this in virtnet_free_queues(). And also
don't delete napi in virtnet_freeze() since it will call
virtnet_free_queues() which has already did this.

Fixes 91815639d880 ("virtio-net: rx busy polling support")
Cc: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Cc: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: Jason Wang &lt;jasowang@redhat.com&gt;
Acked-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Reviewed-by: Michael S. Tsirkin &lt;mst@redhat.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 ab3971b1e7d72270a2a259a29c1a40351b889740 ]

We don't delete napi from hash list during module exit. This will
cause the following panic when doing module load and unload:

BUG: unable to handle kernel paging request at 0000004e00000075
IP: [&lt;ffffffff816bd01b&gt;] napi_hash_add+0x6b/0xf0
PGD 3c5d5067 PUD 0
Oops: 0000 [#1] SMP
...
Call Trace:
[&lt;ffffffffa0a5bfb7&gt;] init_vqs+0x107/0x490 [virtio_net]
[&lt;ffffffffa0a5c9f2&gt;] virtnet_probe+0x562/0x791815639d880be [virtio_net]
[&lt;ffffffff8139e667&gt;] virtio_dev_probe+0x137/0x200
[&lt;ffffffff814c7f2a&gt;] driver_probe_device+0x7a/0x250
[&lt;ffffffff814c81d3&gt;] __driver_attach+0x93/0xa0
[&lt;ffffffff814c8140&gt;] ? __device_attach+0x40/0x40
[&lt;ffffffff814c6053&gt;] bus_for_each_dev+0x63/0xa0
[&lt;ffffffff814c7a79&gt;] driver_attach+0x19/0x20
[&lt;ffffffff814c76f0&gt;] bus_add_driver+0x170/0x220
[&lt;ffffffffa0a60000&gt;] ? 0xffffffffa0a60000
[&lt;ffffffff814c894f&gt;] driver_register+0x5f/0xf0
[&lt;ffffffff8139e41b&gt;] register_virtio_driver+0x1b/0x30
[&lt;ffffffffa0a60010&gt;] virtio_net_driver_init+0x10/0x12 [virtio_net]

This patch fixes this by doing this in virtnet_free_queues(). And also
don't delete napi in virtnet_freeze() since it will call
virtnet_free_queues() which has already did this.

Fixes 91815639d880 ("virtio-net: rx busy polling support")
Cc: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Cc: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: Jason Wang &lt;jasowang@redhat.com&gt;
Acked-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Reviewed-by: Michael S. Tsirkin &lt;mst@redhat.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>net: fec: fix receive VLAN CTAG HW acceleration issue</title>
<updated>2015-03-26T12:59:33+00:00</updated>
<author>
<name>Nimrod Andy</name>
<email>B38611@freescale.com</email>
</author>
<published>2015-03-10T11:09:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=be0e858e52ea730c06486a954b1984e07c9c39f1'/>
<id>be0e858e52ea730c06486a954b1984e07c9c39f1</id>
<content type='text'>
[ Upstream commit af5cbc9822f6bbe399925760a4d5ee82c21f258c ]

The current driver support receive VLAN CTAG HW acceleration feature
(NETIF_F_HW_VLAN_CTAG_RX) through software simulation. There calls the
api .skb_copy_to_linear_data_offset() to skip the VLAN tag, but there
have overlap between the two memory data point range. The patch just fix
the issue.

V2:
Michael Grzeschik suggest to use memmove() instead of skb_copy_to_linear_data_offset().

Reported-by: Michael Grzeschik &lt;m.grzeschik@pengutronix.de&gt;
Fixes: 1b7bde6d659d ("net: fec: implement rx_copybreak to improve rx performance")
Signed-off-by: Fugang Duan &lt;B38611@freescale.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 af5cbc9822f6bbe399925760a4d5ee82c21f258c ]

The current driver support receive VLAN CTAG HW acceleration feature
(NETIF_F_HW_VLAN_CTAG_RX) through software simulation. There calls the
api .skb_copy_to_linear_data_offset() to skip the VLAN tag, but there
have overlap between the two memory data point range. The patch just fix
the issue.

V2:
Michael Grzeschik suggest to use memmove() instead of skb_copy_to_linear_data_offset().

Reported-by: Michael Grzeschik &lt;m.grzeschik@pengutronix.de&gt;
Fixes: 1b7bde6d659d ("net: fec: implement rx_copybreak to improve rx performance")
Signed-off-by: Fugang Duan &lt;B38611@freescale.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>ath5k: fix spontaneus AR5312 freezes</title>
<updated>2015-03-18T13:11:12+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=5f98283000a62ec475de3d9a3f2080d1a73e865c'/>
<id>5f98283000a62ec475de3d9a3f2080d1a73e865c</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>
</feed>
