<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/net/wireless, branch v3.11.7</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>wireless: cw1200: acquire hwbus lock around cw1200_irq_handler() call.</title>
<updated>2013-11-04T12:35:21+00:00</updated>
<author>
<name>Solomon Peachy</name>
<email>pizza@shaftnet.org</email>
</author>
<published>2013-10-09T16:15:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=60fd01d9c7c5114e2bafaf5c57d2300aa9559c02'/>
<id>60fd01d9c7c5114e2bafaf5c57d2300aa9559c02</id>
<content type='text'>
commit 4978705d26149a629b9f50ff221caed6f1ae3048 upstream.

This fixes "lost interrupt" problems that occurred on SPI-based systems.
cw1200_irq_handler() expects the hwbus to be locked, but on the
SPI-path, that lock wasn't taken (unlike in the SDIO-path, where the
generic SDIO-code takes care of acquiring the lock).

Signed-off-by: David Mosberger &lt;davidm@egauge.net&gt;
Signed-off-by: Solomon Peachy &lt;pizza@shaftnet.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.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 4978705d26149a629b9f50ff221caed6f1ae3048 upstream.

This fixes "lost interrupt" problems that occurred on SPI-based systems.
cw1200_irq_handler() expects the hwbus to be locked, but on the
SPI-path, that lock wasn't taken (unlike in the SDIO-path, where the
generic SDIO-code takes care of acquiring the lock).

Signed-off-by: David Mosberger &lt;davidm@egauge.net&gt;
Signed-off-by: Solomon Peachy &lt;pizza@shaftnet.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>p54usb: add USB ID for Corega WLUSB2GTST USB adapter</title>
<updated>2013-10-14T01:14:30+00:00</updated>
<author>
<name>Christian Lamparter</name>
<email>chunkeey@googlemail.com</email>
</author>
<published>2013-09-24T19:56:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=95f985cc6a26d421ddd6617822235dd4597c13ea'/>
<id>95f985cc6a26d421ddd6617822235dd4597c13ea</id>
<content type='text'>
commit 1e43692cdb7cc445d6347d8a5207d9cef0c71434 upstream.

Added USB ID for Corega WLUSB2GTST USB adapter.

Reported-by: Joerg Kalisch &lt;the_force@gmx.de&gt;
Signed-off-by: Christian Lamparter &lt;chunkeey@googlemail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.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 1e43692cdb7cc445d6347d8a5207d9cef0c71434 upstream.

Added USB ID for Corega WLUSB2GTST USB adapter.

Reported-by: Joerg Kalisch &lt;the_force@gmx.de&gt;
Signed-off-by: Christian Lamparter &lt;chunkeey@googlemail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>rtlwifi: Align private space in rtl_priv struct</title>
<updated>2013-10-14T01:14:30+00:00</updated>
<author>
<name>Larry Finger</name>
<email>Larry.Finger@lwfinger.net</email>
</author>
<published>2013-09-19T02:21:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a349c365d5db2b96780078249c73285ac2941920'/>
<id>a349c365d5db2b96780078249c73285ac2941920</id>
<content type='text'>
commit 60ce314d1750fef843e9db70050e09e49f838b69 upstream.

The private array at the end of the rtl_priv struct is not aligned.
On ARM architecture, this causes an alignment trap and is fixed by aligning
that array with __align(sizeof(void *)). That should properly align that
space according to the requirements of all architectures.

Reported-by: Jason Andrews &lt;jasona@cadence.com&gt;
Tested-by: Jason Andrews &lt;jasona@cadence.com&gt;
Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.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 60ce314d1750fef843e9db70050e09e49f838b69 upstream.

The private array at the end of the rtl_priv struct is not aligned.
On ARM architecture, this causes an alignment trap and is fixed by aligning
that array with __align(sizeof(void *)). That should properly align that
space according to the requirements of all architectures.

Reported-by: Jason Andrews &lt;jasona@cadence.com&gt;
Tested-by: Jason Andrews &lt;jasona@cadence.com&gt;
Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mwifiex: fix PCIe hs_cfg cancel cmd timeout</title>
<updated>2013-10-14T01:14:30+00:00</updated>
<author>
<name>Bing Zhao</name>
<email>bzhao@marvell.com</email>
</author>
<published>2013-09-21T02:56:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3ebf6d7dae94cd4a92cf23d428bc9f196835e6f2'/>
<id>3ebf6d7dae94cd4a92cf23d428bc9f196835e6f2</id>
<content type='text'>
commit b7be1522def9a9988b67afd0be999c50a96394b5 upstream.

For pcie8897, the hs_cfg cancel command (0xe5) times out when host
comes out of suspend. This is caused by an incompleted host sleep
handshake between driver and firmware.

Like SDIO interface, PCIe also needs to go through firmware power
save events to complete the handshake for host sleep configuration.
Only USB interface doesn't require power save events for hs_cfg.

Signed-off-by: Bing Zhao &lt;bzhao@marvell.com&gt;
Signed-off-by: Amitkumar Karwar &lt;akarwar@marvell.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.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 b7be1522def9a9988b67afd0be999c50a96394b5 upstream.

For pcie8897, the hs_cfg cancel command (0xe5) times out when host
comes out of suspend. This is caused by an incompleted host sleep
handshake between driver and firmware.

Like SDIO interface, PCIe also needs to go through firmware power
save events to complete the handshake for host sleep configuration.
Only USB interface doesn't require power save events for hs_cfg.

Signed-off-by: Bing Zhao &lt;bzhao@marvell.com&gt;
Signed-off-by: Amitkumar Karwar &lt;akarwar@marvell.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mwifiex: fix hang issue for USB chipsets</title>
<updated>2013-10-14T01:14:30+00:00</updated>
<author>
<name>Amitkumar Karwar</name>
<email>akarwar@marvell.com</email>
</author>
<published>2013-09-25T02:31:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=eaac40050d90a35e97cf965529de4c5ef127d0d4'/>
<id>eaac40050d90a35e97cf965529de4c5ef127d0d4</id>
<content type='text'>
commit bd1c6142edce787b8ac1be15635f845aa9905333 upstream.

Bug 60815 - Interface hangs in mwifiex_usb
https://bugzilla.kernel.org/show_bug.cgi?id=60815

We have 4 bytes of interface header for packets delivered to SDIO
and PCIe, but not for USB interface.

In Tx AMSDU case, currently 4 bytes of garbage data is unnecessarily
appended for USB packets. This sometimes leads to a firmware hang,
because it may not interpret the data packet correctly.

Problem is fixed by removing this redundant headroom for USB.

Tested-by: Dmitry Khromov &lt;icechrome@gmail.com&gt;
Signed-off-by: Amitkumar Karwar &lt;akarwar@marvell.com&gt;
Signed-off-by: Bing Zhao &lt;bzhao@marvell.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.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 bd1c6142edce787b8ac1be15635f845aa9905333 upstream.

Bug 60815 - Interface hangs in mwifiex_usb
https://bugzilla.kernel.org/show_bug.cgi?id=60815

We have 4 bytes of interface header for packets delivered to SDIO
and PCIe, but not for USB interface.

In Tx AMSDU case, currently 4 bytes of garbage data is unnecessarily
appended for USB packets. This sometimes leads to a firmware hang,
because it may not interpret the data packet correctly.

Problem is fixed by removing this redundant headroom for USB.

Tested-by: Dmitry Khromov &lt;icechrome@gmail.com&gt;
Signed-off-by: Amitkumar Karwar &lt;akarwar@marvell.com&gt;
Signed-off-by: Bing Zhao &lt;bzhao@marvell.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mwifiex: fix NULL pointer dereference in usb suspend handler</title>
<updated>2013-10-14T01:14:30+00:00</updated>
<author>
<name>Bing Zhao</name>
<email>bzhao@marvell.com</email>
</author>
<published>2013-09-25T02:31:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1d1f004891d5aa00ee75974e4864e8d5b321e491'/>
<id>1d1f004891d5aa00ee75974e4864e8d5b321e491</id>
<content type='text'>
commit 346ece0b7ba2730b4d633b9e371fe55488803102 upstream.

Bug 60815 - Interface hangs in mwifiex_usb
https://bugzilla.kernel.org/show_bug.cgi?id=60815

[ 2.883807] BUG: unable to handle kernel NULL pointer dereference
            at 0000000000000048
[ 2.883813] IP: [&lt;ffffffff815a65e0&gt;] pfifo_fast_enqueue+0x90/0x90

[ 2.883834] CPU: 1 PID: 3220 Comm: kworker/u8:90 Not tainted
            3.11.1-monotone-l0 #6
[ 2.883834] Hardware name: Microsoft Corporation Surface with
            Windows 8 Pro/Surface with Windows 8 Pro,
            BIOS 1.03.0450 03/29/2013

On Surface Pro, suspend to ram gives a NULL pointer dereference in
pfifo_fast_enqueue(). The stack trace reveals that the offending
call is clearing carrier in mwifiex_usb suspend handler.

Since commit 1499d9f "mwifiex: don't drop carrier flag over suspend"
has removed the carrier flag handling over suspend/resume in SDIO
and PCIe drivers, I'm removing it in USB driver too. This also fixes
the bug for Surface Pro.

Tested-by: Dmitry Khromov &lt;icechrome@gmail.com&gt;
Signed-off-by: Bing Zhao &lt;bzhao@marvell.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.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 346ece0b7ba2730b4d633b9e371fe55488803102 upstream.

Bug 60815 - Interface hangs in mwifiex_usb
https://bugzilla.kernel.org/show_bug.cgi?id=60815

[ 2.883807] BUG: unable to handle kernel NULL pointer dereference
            at 0000000000000048
[ 2.883813] IP: [&lt;ffffffff815a65e0&gt;] pfifo_fast_enqueue+0x90/0x90

[ 2.883834] CPU: 1 PID: 3220 Comm: kworker/u8:90 Not tainted
            3.11.1-monotone-l0 #6
[ 2.883834] Hardware name: Microsoft Corporation Surface with
            Windows 8 Pro/Surface with Windows 8 Pro,
            BIOS 1.03.0450 03/29/2013

On Surface Pro, suspend to ram gives a NULL pointer dereference in
pfifo_fast_enqueue(). The stack trace reveals that the offending
call is clearing carrier in mwifiex_usb suspend handler.

Since commit 1499d9f "mwifiex: don't drop carrier flag over suspend"
has removed the carrier flag handling over suspend/resume in SDIO
and PCIe drivers, I'm removing it in USB driver too. This also fixes
the bug for Surface Pro.

Tested-by: Dmitry Khromov &lt;icechrome@gmail.com&gt;
Signed-off-by: Bing Zhao &lt;bzhao@marvell.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>brcmfmac: obtain platform data upon module initialization</title>
<updated>2013-10-14T01:14:28+00:00</updated>
<author>
<name>Arend van Spriel</name>
<email>arend@broadcom.com</email>
</author>
<published>2013-09-25T10:11:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=17828296b122ed60cf5274cfb481aa1cc0308250'/>
<id>17828296b122ed60cf5274cfb481aa1cc0308250</id>
<content type='text'>
commit db4efbbeb457b6f9f4d8c4b090d1170d12f026e1 upstream.

The driver uses platform_driver_probe() to obtain platform data
if any. However, that function is placed in the .init section so
it must be called upon driver module initialization.

The problem was reported by Fenguang Wu resulting in a kernel
oops because the .init section was already freed.

[   48.966342] Switched to clocksource tsc
[   48.970002] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
[   48.970851] BUG: unable to handle kernel paging request at ffffffff82196446
[   48.970957] IP: [&lt;ffffffff82196446&gt;] classes_init+0x26/0x26
[   48.970957] PGD 1e76067 PUD 1e77063 PMD f388063 PTE 8000000002196163
[   48.970957] Oops: 0011 [#1]
[   48.970957] CPU: 0 PID: 17 Comm: kworker/0:1 Not tainted 3.11.0-rc7-00444-gc52dd7f #23
[   48.970957] Workqueue: events brcmf_driver_init
[   48.970957] task: ffff8800001d2000 ti: ffff8800001d4000 task.ti: ffff8800001d4000
[   48.970957] RIP: 0010:[&lt;ffffffff82196446&gt;]  [&lt;ffffffff82196446&gt;] classes_init+0x26/0x26
[   48.970957] RSP: 0000:ffff8800001d5d40  EFLAGS: 00000286
[   48.970957] RAX: 0000000000000001 RBX: ffffffff820c5620 RCX: 0000000000000000
[   48.970957] RDX: 0000000000000001 RSI: ffffffff816f7380 RDI: ffffffff820c56c0
[   48.970957] RBP: ffff8800001d5d50 R08: ffff8800001d2508 R09: 0000000000000002
[   48.970957] R10: 0000000000000000 R11: 0001f7ce298c5620 R12: ffff8800001c76b0
[   48.970957] R13: ffffffff81e91d40 R14: 0000000000000000 R15: ffff88000e0ce300
[   48.970957] FS:  0000000000000000(0000) GS:ffffffff81e84000(0000) knlGS:0000000000000000
[   48.970957] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[   48.970957] CR2: ffffffff82196446 CR3: 0000000001e75000 CR4: 00000000000006b0
[   48.970957] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   48.970957] DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000
[   48.970957] Stack:
[   48.970957]  ffffffff816f7df8 ffffffff820c5620 ffff8800001d5d60 ffffffff816eeec9
[   48.970957]  ffff8800001d5de0 ffffffff81073dc5 ffffffff81073d68 ffff8800001d5db8
[   48.970957]  0000000000000086 ffffffff820c5620 ffffffff824f7fd0 0000000000000000
[   48.970957] Call Trace:
[   48.970957]  [&lt;ffffffff816f7df8&gt;] ? brcmf_sdio_init+0x18/0x70
[   48.970957]  [&lt;ffffffff816eeec9&gt;] brcmf_driver_init+0x9/0x10
[   48.970957]  [&lt;ffffffff81073dc5&gt;] process_one_work+0x1d5/0x480
[   48.970957]  [&lt;ffffffff81073d68&gt;] ? process_one_work+0x178/0x480
[   48.970957]  [&lt;ffffffff81074188&gt;] worker_thread+0x118/0x3a0
[   48.970957]  [&lt;ffffffff81074070&gt;] ? process_one_work+0x480/0x480
[   48.970957]  [&lt;ffffffff8107aa17&gt;] kthread+0xe7/0xf0
[   48.970957]  [&lt;ffffffff810829f7&gt;] ? finish_task_switch.constprop.57+0x37/0xd0
[   48.970957]  [&lt;ffffffff8107a930&gt;] ? __kthread_parkme+0x80/0x80
[   48.970957]  [&lt;ffffffff81a6923a&gt;] ret_from_fork+0x7a/0xb0
[   48.970957]  [&lt;ffffffff8107a930&gt;] ? __kthread_parkme+0x80/0x80
[   48.970957] Code: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
cc cc cc cc cc cc &lt;cc&gt; cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
[   48.970957] RIP  [&lt;ffffffff82196446&gt;] classes_init+0x26/0x26
[   48.970957]  RSP &lt;ffff8800001d5d40&gt;
[   48.970957] CR2: ffffffff82196446
[   48.970957] ---[ end trace 62980817cd525f14 ]---

Reported-by: Fengguang Wu &lt;fengguang.wu@intel.com&gt;
Reviewed-by: Hante Meuleman &lt;meuleman@broadcom.com&gt;
Reviewed-by: Pieter-Paul Giesberts &lt;pieterpg@broadcom.com&gt;
Tested-by: Fengguang Wu &lt;fengguang.wu@intel.com&gt;
Signed-off-by: Arend van Spriel &lt;arend@broadcom.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.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 db4efbbeb457b6f9f4d8c4b090d1170d12f026e1 upstream.

The driver uses platform_driver_probe() to obtain platform data
if any. However, that function is placed in the .init section so
it must be called upon driver module initialization.

The problem was reported by Fenguang Wu resulting in a kernel
oops because the .init section was already freed.

[   48.966342] Switched to clocksource tsc
[   48.970002] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
[   48.970851] BUG: unable to handle kernel paging request at ffffffff82196446
[   48.970957] IP: [&lt;ffffffff82196446&gt;] classes_init+0x26/0x26
[   48.970957] PGD 1e76067 PUD 1e77063 PMD f388063 PTE 8000000002196163
[   48.970957] Oops: 0011 [#1]
[   48.970957] CPU: 0 PID: 17 Comm: kworker/0:1 Not tainted 3.11.0-rc7-00444-gc52dd7f #23
[   48.970957] Workqueue: events brcmf_driver_init
[   48.970957] task: ffff8800001d2000 ti: ffff8800001d4000 task.ti: ffff8800001d4000
[   48.970957] RIP: 0010:[&lt;ffffffff82196446&gt;]  [&lt;ffffffff82196446&gt;] classes_init+0x26/0x26
[   48.970957] RSP: 0000:ffff8800001d5d40  EFLAGS: 00000286
[   48.970957] RAX: 0000000000000001 RBX: ffffffff820c5620 RCX: 0000000000000000
[   48.970957] RDX: 0000000000000001 RSI: ffffffff816f7380 RDI: ffffffff820c56c0
[   48.970957] RBP: ffff8800001d5d50 R08: ffff8800001d2508 R09: 0000000000000002
[   48.970957] R10: 0000000000000000 R11: 0001f7ce298c5620 R12: ffff8800001c76b0
[   48.970957] R13: ffffffff81e91d40 R14: 0000000000000000 R15: ffff88000e0ce300
[   48.970957] FS:  0000000000000000(0000) GS:ffffffff81e84000(0000) knlGS:0000000000000000
[   48.970957] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[   48.970957] CR2: ffffffff82196446 CR3: 0000000001e75000 CR4: 00000000000006b0
[   48.970957] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   48.970957] DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000
[   48.970957] Stack:
[   48.970957]  ffffffff816f7df8 ffffffff820c5620 ffff8800001d5d60 ffffffff816eeec9
[   48.970957]  ffff8800001d5de0 ffffffff81073dc5 ffffffff81073d68 ffff8800001d5db8
[   48.970957]  0000000000000086 ffffffff820c5620 ffffffff824f7fd0 0000000000000000
[   48.970957] Call Trace:
[   48.970957]  [&lt;ffffffff816f7df8&gt;] ? brcmf_sdio_init+0x18/0x70
[   48.970957]  [&lt;ffffffff816eeec9&gt;] brcmf_driver_init+0x9/0x10
[   48.970957]  [&lt;ffffffff81073dc5&gt;] process_one_work+0x1d5/0x480
[   48.970957]  [&lt;ffffffff81073d68&gt;] ? process_one_work+0x178/0x480
[   48.970957]  [&lt;ffffffff81074188&gt;] worker_thread+0x118/0x3a0
[   48.970957]  [&lt;ffffffff81074070&gt;] ? process_one_work+0x480/0x480
[   48.970957]  [&lt;ffffffff8107aa17&gt;] kthread+0xe7/0xf0
[   48.970957]  [&lt;ffffffff810829f7&gt;] ? finish_task_switch.constprop.57+0x37/0xd0
[   48.970957]  [&lt;ffffffff8107a930&gt;] ? __kthread_parkme+0x80/0x80
[   48.970957]  [&lt;ffffffff81a6923a&gt;] ret_from_fork+0x7a/0xb0
[   48.970957]  [&lt;ffffffff8107a930&gt;] ? __kthread_parkme+0x80/0x80
[   48.970957] Code: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
cc cc cc cc cc cc &lt;cc&gt; cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
[   48.970957] RIP  [&lt;ffffffff82196446&gt;] classes_init+0x26/0x26
[   48.970957]  RSP &lt;ffff8800001d5d40&gt;
[   48.970957] CR2: ffffffff82196446
[   48.970957] ---[ end trace 62980817cd525f14 ]---

Reported-by: Fengguang Wu &lt;fengguang.wu@intel.com&gt;
Reviewed-by: Hante Meuleman &lt;meuleman@broadcom.com&gt;
Reviewed-by: Pieter-Paul Giesberts &lt;pieterpg@broadcom.com&gt;
Tested-by: Fengguang Wu &lt;fengguang.wu@intel.com&gt;
Signed-off-by: Arend van Spriel &lt;arend@broadcom.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>cw1200: Use a threaded oneshot irq handler for cw1200_spi</title>
<updated>2013-10-05T14:17:56+00:00</updated>
<author>
<name>Solomon Peachy</name>
<email>pizza@shaftnet.org</email>
</author>
<published>2013-09-23T20:00:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fa5933365236f916742a6472ff1a3b0b33f2c3e4'/>
<id>fa5933365236f916742a6472ff1a3b0b33f2c3e4</id>
<content type='text'>
commit 87421cb6010a2f6494938fbe0a95e1b096b3b7af upstream.

This supercedes the older patch ("cw1200: Don't perform SPI transfers in
interrupt context") that badly attempted to fix this problem.

This is a far simpler solution, which has the added benefit of
actually working.

Signed-off-by: Solomon Peachy &lt;pizza@shaftnet.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.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 87421cb6010a2f6494938fbe0a95e1b096b3b7af upstream.

This supercedes the older patch ("cw1200: Don't perform SPI transfers in
interrupt context") that badly attempted to fix this problem.

This is a far simpler solution, which has the added benefit of
actually working.

Signed-off-by: Solomon Peachy &lt;pizza@shaftnet.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "cw1200: Don't perform SPI transfers in interrupt context"</title>
<updated>2013-10-05T14:17:56+00:00</updated>
<author>
<name>Solomon Peachy</name>
<email>pizza@shaftnet.org</email>
</author>
<published>2013-09-23T20:00:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=96c7304180c19ca60d2b057e06343f6aac804b92'/>
<id>96c7304180c19ca60d2b057e06343f6aac804b92</id>
<content type='text'>
commit c4fb19d21b003ec99ec490ba2cb60baffabc73f3 upstream.

This reverts commit aec8e88c947b7017e2b4bbcb68a4bfc4a1f8ad35.

This solution turned out to cause interrupt delivery problems, and
rather than trying to fix this approach, it has been scrapped in favor
of an alternative (and far simpler) implementation.

Signed-off-by: Solomon Peachy &lt;pizza@shaftnet.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.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 c4fb19d21b003ec99ec490ba2cb60baffabc73f3 upstream.

This reverts commit aec8e88c947b7017e2b4bbcb68a4bfc4a1f8ad35.

This solution turned out to cause interrupt delivery problems, and
rather than trying to fix this approach, it has been scrapped in favor
of an alternative (and far simpler) implementation.

Signed-off-by: Solomon Peachy &lt;pizza@shaftnet.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>cw1200: Don't perform SPI transfers in interrupt context</title>
<updated>2013-10-01T16:41:02+00:00</updated>
<author>
<name>Solomon Peachy</name>
<email>pizza@shaftnet.org</email>
</author>
<published>2013-08-28T00:29:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2236ad2913d353ecb1d78231600372def5c94473'/>
<id>2236ad2913d353ecb1d78231600372def5c94473</id>
<content type='text'>
commit aec8e88c947b7017e2b4bbcb68a4bfc4a1f8ad35 upstream.

When we get an interrupt from the hardware, the first thing the driver does
is tell the device to mask off the interrupt line.  Unfortunately this
involves a SPI transaction in interrupt context.  Some (most?) SPI
controllers perform the transfer asynchronously and try to sleep.
This is bad, and triggers a BUG().

So, work around this by using adding a hwbus hook for the cw1200 driver
core to call.  The cw1200_spi driver translates this into
irq_disable()/irq_enable() calls instead, which can safely be called in
interrupt context.

Apparently the platforms I used to develop the cw1200_spi driver used
synchronous spi_sync() implementations, which is why this didn't surface
until now.

Many thanks to Dave Sizeburns for the inital bug report and his services
as a tester.

Signed-off-by: Solomon Peachy &lt;pizza@shaftnet.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.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 aec8e88c947b7017e2b4bbcb68a4bfc4a1f8ad35 upstream.

When we get an interrupt from the hardware, the first thing the driver does
is tell the device to mask off the interrupt line.  Unfortunately this
involves a SPI transaction in interrupt context.  Some (most?) SPI
controllers perform the transfer asynchronously and try to sleep.
This is bad, and triggers a BUG().

So, work around this by using adding a hwbus hook for the cw1200 driver
core to call.  The cw1200_spi driver translates this into
irq_disable()/irq_enable() calls instead, which can safely be called in
interrupt context.

Apparently the platforms I used to develop the cw1200_spi driver used
synchronous spi_sync() implementations, which is why this didn't surface
until now.

Many thanks to Dave Sizeburns for the inital bug report and his services
as a tester.

Signed-off-by: Solomon Peachy &lt;pizza@shaftnet.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
