<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/net/wireless, branch v3.4.7</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>iwlegacy: don't mess up the SCD when removing a key</title>
<updated>2012-07-19T15:58:57+00:00</updated>
<author>
<name>Emmanuel Grumbach</name>
<email>emmanuel.grumbach@intel.com</email>
</author>
<published>2012-07-04T11:59:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1214b7852425b78a2b73b0a759ec55210340396d'/>
<id>1214b7852425b78a2b73b0a759ec55210340396d</id>
<content type='text'>
commit b48d96652626b315229b1b82c6270eead6a77a6d upstream.

When we remove a key, we put a key index which was supposed
to tell the fw that we are actually removing the key. But
instead the fw took that index as a valid index and messed
up the SRAM of the device.

This memory corruption on the device mangled the data of
the SCD. The impact on the user is that SCD queue 2 got
stuck after having removed keys.

Reported-by: Paul Bolle &lt;pebolle@tiscali.nl&gt;
Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Stanislaw Gruszka &lt;sgruszka@redhat.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 b48d96652626b315229b1b82c6270eead6a77a6d upstream.

When we remove a key, we put a key index which was supposed
to tell the fw that we are actually removing the key. But
instead the fw took that index as a valid index and messed
up the SRAM of the device.

This memory corruption on the device mangled the data of
the SCD. The impact on the user is that SCD queue 2 got
stuck after having removed keys.

Reported-by: Paul Bolle &lt;pebolle@tiscali.nl&gt;
Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Stanislaw Gruszka &lt;sgruszka@redhat.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>iwlegacy: always monitor for stuck queues</title>
<updated>2012-07-19T15:58:57+00:00</updated>
<author>
<name>Stanislaw Gruszka</name>
<email>sgruszka@redhat.com</email>
</author>
<published>2012-07-04T11:20:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=57cff816121720c80b39e3b3fb0ef36128fdc45b'/>
<id>57cff816121720c80b39e3b3fb0ef36128fdc45b</id>
<content type='text'>
commit c2ca7d92ed4bbd779516beb6eb226e19f7f7ab0f upstream.

This is iwlegacy version of:

commit 342bbf3fee2fa9a18147e74b2e3c4229a4564912
Author: Johannes Berg &lt;johannes.berg@intel.com&gt;
Date:   Sun Mar 4 08:50:46 2012 -0800

    iwlwifi: always monitor for stuck queues

    If we only monitor while associated, the following
    can happen:
     - we're associated, and the queue stuck check
       runs, setting the queue "touch" time to X
     - we disassociate, stopping the monitoring,
       which leaves the time set to X
     - almost 2s later, we associate, and enqueue
       a frame
     - before the frame is transmitted, we monitor
       for stuck queues, and find the time set to
       X, although it is now later than X + 2000ms,
       so we decide that the queue is stuck and
       erroneously restart the device

Signed-off-by: Stanislaw Gruszka &lt;sgruszka@redhat.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 c2ca7d92ed4bbd779516beb6eb226e19f7f7ab0f upstream.

This is iwlegacy version of:

commit 342bbf3fee2fa9a18147e74b2e3c4229a4564912
Author: Johannes Berg &lt;johannes.berg@intel.com&gt;
Date:   Sun Mar 4 08:50:46 2012 -0800

    iwlwifi: always monitor for stuck queues

    If we only monitor while associated, the following
    can happen:
     - we're associated, and the queue stuck check
       runs, setting the queue "touch" time to X
     - we disassociate, stopping the monitoring,
       which leaves the time set to X
     - almost 2s later, we associate, and enqueue
       a frame
     - before the frame is transmitted, we monitor
       for stuck queues, and find the time set to
       X, although it is now later than X + 2000ms,
       so we decide that the queue is stuck and
       erroneously restart the device

Signed-off-by: Stanislaw Gruszka &lt;sgruszka@redhat.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>rt2x00usb: fix indexes ordering on RX queue kick</title>
<updated>2012-07-19T15:58:56+00:00</updated>
<author>
<name>Stanislaw Gruszka</name>
<email>sgruszka@redhat.com</email>
</author>
<published>2012-07-04T11:10:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a3c021d25debc6278951e0112b1a06d8b7376d22'/>
<id>a3c021d25debc6278951e0112b1a06d8b7376d22</id>
<content type='text'>
commit efd821182cec8c92babef6e00a95066d3252fda4 upstream.

On rt2x00_dmastart() we increase index specified by Q_INDEX and on
rt2x00_dmadone() we increase index specified by Q_INDEX_DONE. So entries
between Q_INDEX_DONE and Q_INDEX are those we currently process in the
hardware. Entries between Q_INDEX and Q_INDEX_DONE are those we can
submit to the hardware.

According to that fix rt2x00usb_kick_queue(), as we need to submit RX
entries that are not processed by the hardware. It worked before only
for empty queue, otherwise was broken.

Note that for TX queues indexes ordering are ok. We need to kick entries
that have filled skb, but was not submitted to the hardware, i.e.
started from Q_INDEX_DONE and have ENTRY_DATA_PENDING bit set.

From practical standpoint this fixes RX queue stall, usually reproducible
in AP mode, like for example reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=828824

Reported-and-tested-by: Franco Miceli &lt;fmiceli@plan.ceibal.edu.uy&gt;
Reported-and-tested-by: Tom Horsley &lt;horsley1953@gmail.com&gt;
Signed-off-by: Stanislaw Gruszka &lt;sgruszka@redhat.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 efd821182cec8c92babef6e00a95066d3252fda4 upstream.

On rt2x00_dmastart() we increase index specified by Q_INDEX and on
rt2x00_dmadone() we increase index specified by Q_INDEX_DONE. So entries
between Q_INDEX_DONE and Q_INDEX are those we currently process in the
hardware. Entries between Q_INDEX and Q_INDEX_DONE are those we can
submit to the hardware.

According to that fix rt2x00usb_kick_queue(), as we need to submit RX
entries that are not processed by the hardware. It worked before only
for empty queue, otherwise was broken.

Note that for TX queues indexes ordering are ok. We need to kick entries
that have filled skb, but was not submitted to the hardware, i.e.
started from Q_INDEX_DONE and have ENTRY_DATA_PENDING bit set.

From practical standpoint this fixes RX queue stall, usually reproducible
in AP mode, like for example reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=828824

Reported-and-tested-by: Franco Miceli &lt;fmiceli@plan.ceibal.edu.uy&gt;
Reported-and-tested-by: Tom Horsley &lt;horsley1953@gmail.com&gt;
Signed-off-by: Stanislaw Gruszka &lt;sgruszka@redhat.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>net/wireless: ipw2x00: add supported cipher suites to wiphy initialization</title>
<updated>2012-07-16T16:04:42+00:00</updated>
<author>
<name>Stanislav Yakovlev</name>
<email>stas.yakovlev@gmail.com</email>
</author>
<published>2012-04-11T01:44:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5318edefb61eddf91d4c4a089644fcee3ccfda62'/>
<id>5318edefb61eddf91d4c4a089644fcee3ccfda62</id>
<content type='text'>
commit a141e6a0097118bb35024485f1faffc0d9042f5c upstream.

Driver doesn't report its supported cipher suites through cfg80211
interface. It still uses wext interface and probably will not work
through nl80211, but will at least correctly advertise supported
features.

Bug was reported by Omar Siam.
https://bugzilla.kernel.org/show_bug.cgi?id=43049

Signed-off-by: Stanislav Yakovlev &lt;stas.yakovlev@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Cc: Josh Boyer &lt;jwboyer@redhat.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 a141e6a0097118bb35024485f1faffc0d9042f5c upstream.

Driver doesn't report its supported cipher suites through cfg80211
interface. It still uses wext interface and probably will not work
through nl80211, but will at least correctly advertise supported
features.

Bug was reported by Omar Siam.
https://bugzilla.kernel.org/show_bug.cgi?id=43049

Signed-off-by: Stanislav Yakovlev &lt;stas.yakovlev@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Cc: Josh Boyer &lt;jwboyer@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>rtl8187: -&gt;brightness_set can not sleep</title>
<updated>2012-07-16T16:04:42+00:00</updated>
<author>
<name>Stanislaw Gruszka</name>
<email>sgruszka@redhat.com</email>
</author>
<published>2012-05-16T09:06:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=21359ac3aef0455038f6295d6f8b3aca7beabfd9'/>
<id>21359ac3aef0455038f6295d6f8b3aca7beabfd9</id>
<content type='text'>
commit 0fde0a8cfd0ede7f310d6a681c8e5a7cb3e32406 upstream.

Fix:

BUG: sleeping function called from invalid context at kernel/workqueue.c:2547
in_atomic(): 1, irqs_disabled(): 0, pid: 629, name: wpa_supplicant
2 locks held by wpa_supplicant/629:
 #0:  (rtnl_mutex){+.+.+.}, at: [&lt;c08b2b84&gt;] rtnl_lock+0x14/0x20
 #1:  (&amp;trigger-&gt;leddev_list_lock){.+.?..}, at: [&lt;c0867f41&gt;] led_trigger_event+0x21/0x80
Pid: 629, comm: wpa_supplicant Not tainted 3.3.0-0.rc3.git5.1.fc17.i686
Call Trace:
 [&lt;c046a9f6&gt;] __might_sleep+0x126/0x1d0
 [&lt;c0457d6c&gt;] wait_on_work+0x2c/0x1d0
 [&lt;c045a09a&gt;] __cancel_work_timer+0x6a/0x120
 [&lt;c045a160&gt;] cancel_delayed_work_sync+0x10/0x20
 [&lt;f7dd3c22&gt;] rtl8187_led_brightness_set+0x82/0xf0 [rtl8187]
 [&lt;c0867f7c&gt;] led_trigger_event+0x5c/0x80
 [&lt;f7ff5e6d&gt;] ieee80211_led_radio+0x1d/0x40 [mac80211]
 [&lt;f7ff3583&gt;] ieee80211_stop_device+0x13/0x230 [mac80211]

Removing _sync is ok, because if led_on work is currently running
it will be finished before led_off work start to perform, since
they are always queued on the same mac80211 local-&gt;workqueue.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=795176

Signed-off-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Acked-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Acked-by: Hin-Tak Leung &lt;htl10@users.sourceforge.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Cc: Josh Boyer &lt;jwboyer@redhat.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 0fde0a8cfd0ede7f310d6a681c8e5a7cb3e32406 upstream.

Fix:

BUG: sleeping function called from invalid context at kernel/workqueue.c:2547
in_atomic(): 1, irqs_disabled(): 0, pid: 629, name: wpa_supplicant
2 locks held by wpa_supplicant/629:
 #0:  (rtnl_mutex){+.+.+.}, at: [&lt;c08b2b84&gt;] rtnl_lock+0x14/0x20
 #1:  (&amp;trigger-&gt;leddev_list_lock){.+.?..}, at: [&lt;c0867f41&gt;] led_trigger_event+0x21/0x80
Pid: 629, comm: wpa_supplicant Not tainted 3.3.0-0.rc3.git5.1.fc17.i686
Call Trace:
 [&lt;c046a9f6&gt;] __might_sleep+0x126/0x1d0
 [&lt;c0457d6c&gt;] wait_on_work+0x2c/0x1d0
 [&lt;c045a09a&gt;] __cancel_work_timer+0x6a/0x120
 [&lt;c045a160&gt;] cancel_delayed_work_sync+0x10/0x20
 [&lt;f7dd3c22&gt;] rtl8187_led_brightness_set+0x82/0xf0 [rtl8187]
 [&lt;c0867f7c&gt;] led_trigger_event+0x5c/0x80
 [&lt;f7ff5e6d&gt;] ieee80211_led_radio+0x1d/0x40 [mac80211]
 [&lt;f7ff3583&gt;] ieee80211_stop_device+0x13/0x230 [mac80211]

Removing _sync is ok, because if led_on work is currently running
it will be finished before led_off work start to perform, since
they are always queued on the same mac80211 local-&gt;workqueue.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=795176

Signed-off-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Acked-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Acked-by: Hin-Tak Leung &lt;htl10@users.sourceforge.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Cc: Josh Boyer &lt;jwboyer@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ath9k: fix panic caused by returning a descriptor we have queued for reuse</title>
<updated>2012-07-16T16:04:41+00:00</updated>
<author>
<name>Tom Hughes</name>
<email>tom@compton.nu</email>
</author>
<published>2012-06-27T17:21:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e5982925c66c542aa41b17ee35fc233ae1521898'/>
<id>e5982925c66c542aa41b17ee35fc233ae1521898</id>
<content type='text'>
commit 6bb51c70cabaadddc54a6454844eceba91a56083 upstream.

Commit 3a2923e83c introduced a bug when a corrupt descriptor
is encountered - although the following descriptor is discarded
and returned to the queue for reuse the associated frame is
also returned for processing. This leads to a panic:

BUG: unable to handle kernel NULL pointer dereference at 000000000000003a
IP: [&lt;ffffffffa02599a5&gt;] ath_rx_tasklet+0x165/0x1b00 [ath9k]
Call Trace:
&lt;IRQ&gt;
[&lt;ffffffff812d7fa0&gt;] ? map_single+0x60/0x60
[&lt;ffffffffa028f044&gt;] ? ath9k_ioread32+0x34/0x90 [ath9k]
[&lt;ffffffffa0292eec&gt;] athk9k_tasklet+0xdc/0x160 [ath9k]
[&lt;ffffffff8105e133&gt;] tasklet_action+0x63/0xd0
[&lt;ffffffff8105dbc0&gt;] __do_softirq+0xc0/0x1e0
[&lt;ffffffff8101a873&gt;] ? native_sched_clock+0x13/0x80
[&lt;ffffffff815f9d5c&gt;] call_softirq+0x1c/0x30
[&lt;ffffffff810151f5&gt;] do_softirq+0x75/0xb0
[&lt;ffffffff8105df95&gt;] irq_exit+0xb5/0xc0
[&lt;ffffffff815fa5b3&gt;] do_IRQ+0x63/0xe0
[&lt;ffffffff815f0cea&gt;] common_interrupt+0x6a/0x6a
&lt;EOI&gt;
[&lt;ffffffff8131840a&gt;] ? intel_idle+0xea/0x150
[&lt;ffffffff813183eb&gt;] ? intel_idle+0xcb/0x150
[&lt;ffffffff814a1db9&gt;] cpuidle_enter+0x19/0x20
[&lt;ffffffff814a23d9&gt;] cpuidle_idle_call+0xa9/0x240
[&lt;ffffffff8101c4bf&gt;] cpu_idle+0xaf/0x120
[&lt;ffffffff815cda8e&gt;] rest_init+0x72/0x74
[&lt;ffffffff81cf4c1a&gt;] start_kernel+0x3b7/0x3c4
[&lt;ffffffff81cf4662&gt;] ? repair_env_string+0x5e/0x5e
[&lt;ffffffff81cf4346&gt;] x86_64_start_reservations+0x131/0x135
[&lt;ffffffff81cf444a&gt;] x86_64_start_kernel+0x100/0x10f

Making sure bf is cleared to NULL in this case restores the
old behaviour.

Signed-off-by: Tom Hughes &lt;tom@compton.nu&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Cc: Josh Boyer &lt;jwboyer@redhat.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 6bb51c70cabaadddc54a6454844eceba91a56083 upstream.

Commit 3a2923e83c introduced a bug when a corrupt descriptor
is encountered - although the following descriptor is discarded
and returned to the queue for reuse the associated frame is
also returned for processing. This leads to a panic:

BUG: unable to handle kernel NULL pointer dereference at 000000000000003a
IP: [&lt;ffffffffa02599a5&gt;] ath_rx_tasklet+0x165/0x1b00 [ath9k]
Call Trace:
&lt;IRQ&gt;
[&lt;ffffffff812d7fa0&gt;] ? map_single+0x60/0x60
[&lt;ffffffffa028f044&gt;] ? ath9k_ioread32+0x34/0x90 [ath9k]
[&lt;ffffffffa0292eec&gt;] athk9k_tasklet+0xdc/0x160 [ath9k]
[&lt;ffffffff8105e133&gt;] tasklet_action+0x63/0xd0
[&lt;ffffffff8105dbc0&gt;] __do_softirq+0xc0/0x1e0
[&lt;ffffffff8101a873&gt;] ? native_sched_clock+0x13/0x80
[&lt;ffffffff815f9d5c&gt;] call_softirq+0x1c/0x30
[&lt;ffffffff810151f5&gt;] do_softirq+0x75/0xb0
[&lt;ffffffff8105df95&gt;] irq_exit+0xb5/0xc0
[&lt;ffffffff815fa5b3&gt;] do_IRQ+0x63/0xe0
[&lt;ffffffff815f0cea&gt;] common_interrupt+0x6a/0x6a
&lt;EOI&gt;
[&lt;ffffffff8131840a&gt;] ? intel_idle+0xea/0x150
[&lt;ffffffff813183eb&gt;] ? intel_idle+0xcb/0x150
[&lt;ffffffff814a1db9&gt;] cpuidle_enter+0x19/0x20
[&lt;ffffffff814a23d9&gt;] cpuidle_idle_call+0xa9/0x240
[&lt;ffffffff8101c4bf&gt;] cpu_idle+0xaf/0x120
[&lt;ffffffff815cda8e&gt;] rest_init+0x72/0x74
[&lt;ffffffff81cf4c1a&gt;] start_kernel+0x3b7/0x3c4
[&lt;ffffffff81cf4662&gt;] ? repair_env_string+0x5e/0x5e
[&lt;ffffffff81cf4346&gt;] x86_64_start_reservations+0x131/0x135
[&lt;ffffffff81cf444a&gt;] x86_64_start_kernel+0x100/0x10f

Making sure bf is cleared to NULL in this case restores the
old behaviour.

Signed-off-by: Tom Hughes &lt;tom@compton.nu&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Cc: Josh Boyer &lt;jwboyer@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mwifiex: fix wrong return values in add_virtual_intf() error cases</title>
<updated>2012-07-16T16:04:40+00:00</updated>
<author>
<name>Bing Zhao</name>
<email>bzhao@marvell.com</email>
</author>
<published>2012-07-04T03:43:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=445006de7c59a9086b00025f9c3c97c75effd3c5'/>
<id>445006de7c59a9086b00025f9c3c97c75effd3c5</id>
<content type='text'>
commit 858faa57dd9e2b91f3f870fbb1185982e42f5a2b upstream

add_virtual_intf() needs to return an ERR_PTR(), instead of NULL,
on errors, otherwise cfg80211 will crash.

Reported-by: Johannes Berg &lt;johannes@sipsolutions.net&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 858faa57dd9e2b91f3f870fbb1185982e42f5a2b upstream

add_virtual_intf() needs to return an ERR_PTR(), instead of NULL,
on errors, otherwise cfg80211 will crash.

Reported-by: Johannes Berg &lt;johannes@sipsolutions.net&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>iwlwifi: remove log_event debugfs file debugging is disabled</title>
<updated>2012-07-16T16:04:40+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2012-06-20T06:46:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=dbb3e108234bf8e4bf43d2fed8bc57792e3dbd2f'/>
<id>dbb3e108234bf8e4bf43d2fed8bc57792e3dbd2f</id>
<content type='text'>
commit 882b7b7d11d65e8eccce738f1ce97cdfdb998f9f upstream.

When debugging is disabled, the event log functions aren't
functional in the way that the debugfs file expects. This
leads to the debugfs access crashing. Since the event log
functions aren't functional then, remove the debugfs file
when CONFIG_IWLWIFI_DEBUG is not set.

Reported-by: Lekensteyn &lt;lekensteyn@gmail.com&gt;
Reviewed-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&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 882b7b7d11d65e8eccce738f1ce97cdfdb998f9f upstream.

When debugging is disabled, the event log functions aren't
functional in the way that the debugfs file expects. This
leads to the debugfs access crashing. Since the event log
functions aren't functional then, remove the debugfs file
when CONFIG_IWLWIFI_DEBUG is not set.

Reported-by: Lekensteyn &lt;lekensteyn@gmail.com&gt;
Reviewed-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iwlwifi: fix activating inactive stations</title>
<updated>2012-07-16T16:04:24+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2012-06-25T07:36:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c86f7d63a7906495a6742dfe4a0cd708fd41b9e1'/>
<id>c86f7d63a7906495a6742dfe4a0cd708fd41b9e1</id>
<content type='text'>
commit eac9ac6d1f5d0e9d33e4ded682187b630e7606cd upstream.

When authentication/association timed out, the driver would
complain bitterly, printing the message
ACTIVATE a non DRIVER active station id ... addr ...

The cause turns out to be that when the AP station is added
but we don't associate, the IWL_STA_UCODE_INPROGRESS is set
but never cleared. This then causes iwl_restore_stations()
to attempt to resend it because it uses the flag internally
and uploads even if it didn't set it itself.

To fix this issue and not upload the station again when it
has already been removed by mac80211, clear the flag after
adding it in case we add it only for association.

Reviewed-by: Meenakshi Venkataraman &lt;meenakshi.venkataraman@intel.com&gt;
Reviewed-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.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 eac9ac6d1f5d0e9d33e4ded682187b630e7606cd upstream.

When authentication/association timed out, the driver would
complain bitterly, printing the message
ACTIVATE a non DRIVER active station id ... addr ...

The cause turns out to be that when the AP station is added
but we don't associate, the IWL_STA_UCODE_INPROGRESS is set
but never cleared. This then causes iwl_restore_stations()
to attempt to resend it because it uses the flag internally
and uploads even if it didn't set it itself.

To fix this issue and not upload the station again when it
has already been removed by mac80211, clear the flag after
adding it in case we add it only for association.

Reviewed-by: Meenakshi Venkataraman &lt;meenakshi.venkataraman@intel.com&gt;
Reviewed-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.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 WPS eapol handshake failure</title>
<updated>2012-07-16T16:04:23+00:00</updated>
<author>
<name>Stone Piao</name>
<email>piaoyun@marvell.com</email>
</author>
<published>2012-06-21T03:21:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=30716eeec35ce79a2140b4814bd417e02da08450'/>
<id>30716eeec35ce79a2140b4814bd417e02da08450</id>
<content type='text'>
commit f03ba7e9a24e5e9efaad56bd1713b994ea556b16 upstream.

After association, STA will go through eapol handshake with WPS
enabled AP. It's observed that WPS handshake fails with some 11n
AP. The reason for the failure is that the eapol packet is sent
via 11n frame aggregation.

The eapol packet should be sent directly without 11n aggregation.

This patch fixes the problem by adding WPS session control while
dequeuing Tx packets for transmission.

Signed-off-by: Stone Piao &lt;piaoyun@marvell.com&gt;
Signed-off-by: Avinash Patil &lt;patila@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 f03ba7e9a24e5e9efaad56bd1713b994ea556b16 upstream.

After association, STA will go through eapol handshake with WPS
enabled AP. It's observed that WPS handshake fails with some 11n
AP. The reason for the failure is that the eapol packet is sent
via 11n frame aggregation.

The eapol packet should be sent directly without 11n aggregation.

This patch fixes the problem by adding WPS session control while
dequeuing Tx packets for transmission.

Signed-off-by: Stone Piao &lt;piaoyun@marvell.com&gt;
Signed-off-by: Avinash Patil &lt;patila@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>
</feed>
