linux/drivers/net/wireless, branch v3.3

rt2x00: fix random stalls

2012-03-12T18:00:17Z

Is possible that we stop queue and then do not wake up it again, especially when packets are transmitted fast. That can be easily reproduced with modified tx queue entry_num to some small value e.g. 16. If mac80211 already hold local->queue_stop_reason_lock, then we can wait on that lock in both rt2x00queue_pause_queue() and rt2x00queue_unpause_queue(). After drooping ->queue_stop_reason_lock is possible that __ieee80211_wake_queue() will be performed before __ieee80211_stop_queue(), hence we stop queue and newer wake up it again. Another race condition is possible when between rt2x00queue_threshold() check and rt2x00queue_pause_queue() we will process all pending tx buffers on different cpu. This might happen if for example interrupt will be triggered on cpu performing rt2x00mac_tx(). To prevent race conditions serialize pause/unpause by queue->tx_lock. Cc: stable@vger.kernel.org Signed-off-by: Stanislaw Gruszka Acked-by: Gertjan van Wingerde Signed-off-by: John W. Linville

iwl3945: fix possible il->txq NULL pointer dereference in delayed works

2012-03-12T18:00:16Z

On il3945_down procedure we free tx queue data and nullify il->txq pointer. After that we drop mutex and then cancel delayed works. There is possibility, that after drooping mutex and before the cancel, some delayed work will start and crash while trying to send commands to the device. For example, here is reported crash in il3945_bg_reg_txpower_periodic(): https://bugzilla.kernel.org/show_bug.cgi?id=42766#c10 Patch fix problem by adding il->txq check on works that send commands, hence utilize tx queue. Reported-by: Clemens Eisserer Cc: stable@vger.kernel.org Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville

iwlwifi: fix wowlan suspend

2012-03-05T19:44:39Z

This was broken by the commit 023ca58f1 "iwlwifi: Move the core suspend function to iwl-agn-lib" where for some reason the code changed while moving, from .len[0] = sizeof(*key_data.rsc_tsc), to .len[0] = sizeof(key_data.rsc_tsc), Cc: stable@kernel.org Signed-off-by: Johannes Berg Signed-off-by: Wey-Yi Guy Signed-off-by: John W. Linville

mwifiex: reset encryption mode flag before association

2012-02-29T18:08:52Z

Recent commit "mwifiex: clear previous security setting during association" fixes association failure problems observed in some corner cases by clearing previous security setting before each association. We should reset encryption mode flag as well. This patch takes care of it. Signed-off-by: Amitkumar Karwar Signed-off-by: Bing Zhao Signed-off-by: John W. Linville

carl9170: fix frame delivery if sta is in powersave mode

2012-02-29T18:08:51Z

Nicolas Cavallari discovered that carl9170 has some serious problems delivering data to sleeping stations. It turns out that the driver was not honoring two important flags (IEEE80211_TX_CTL_POLL_RESPONSE and IEEE80211_TX_CTL_CLEAR_PS_FILT) which are set on frames that should be sent although the receiving station is still in powersave mode. Cc: stable Reported-by: Nicolas Cavallari Signed-off-by: Christian Lamparter Signed-off-by: John W. Linville

carl9170: Fix memory accounting when sta is in power-save mode.

2012-02-29T18:08:51Z

On Access Point mode, when transmitting a packet, if the destination station is in powersave mode, we abort transmitting the packet to the device queue, but we do not reclaim the allocated memory. Given enough packets, we can go in a state where there is no packet on the device queue, but we think the device has no memory left, so no packet gets transmitted, connections breaks and the AP stops working. This undo the allocation done in the TX path when the station is in power-save mode. Signed-off-by: Nicolas Cavallari Acked-by: Christian Lamparter Cc: stable Signed-off-by: John W. Linville

brcm80211: smac: only print block-ack timeout message at trace level

2012-02-23T20:57:37Z

In regular use block-ack timeouts can happen so it does not make sense to fill the log with these messages. Reviewed-by: Pieter-Paul Giesberts Reviewed-by: Alwin Beukers Signed-off-by: Arend van Spriel Signed-off-by: John W. Linville

brcm80211: smac: fix endless retry of A-MPDU transmissions

2012-02-23T20:57:35Z

The A-MPDU code checked against a retry limit, but it was using the wrong variable to do so. This patch fixes this to assure proper retry mechanism. This problem had a side-effect causing the mac80211 flush callback to remain waiting forever as well. That side effect has been fixed by commit by Stanislaw Gruszka: commit f96b08a7e6f69c0f0a576554df3df5b1b519c479 Date: Tue Jan 17 12:38:50 2012 +0100 brcmsmac: fix tx queue flush infinite loop Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42576 Cc: Stanislaw Gruszka Reviewed-by: Pieter-Paul Giesberts Reviewed-by: Alwin Beukers Signed-off-by: Arend van Spriel Signed-off-by: John W. Linville

iwlwifi: fix key removal

2012-02-21T19:45:26Z

When trying to remove a key, we always send key flags just setting the key type, not including the multicast flag and the key ID. As a result, whenever any key was removed, the unicast key 0 would be removed, causing a complete connection loss after the second rekey (the first doesn't cause a key removal). Fix the key removal code to include the key ID and multicast flag, thus removing the correct key. Cc: stable@vger.kernel.org Reported-by: Alexander Schnaidt Tested-by: Alexander Schnaidt Signed-off-by: Johannes Berg Signed-off-by: Wey-Yi Guy Signed-off-by: John W. Linville

rt2x00: fix a possible NULL pointer dereference

2012-02-21T19:45:25Z

The 'rt2x00lib_probe_dev' function tries to allocate the workqueue. If the allocation fails, 'rt2x00_lib_remove_dev' is called on the error path. Because 'rt2x00dev->workqueue' is NULL in this case, the 'destroy_workqueue' call will cause a NULL pointer dereference. Signed-off-by: Gabor Juhos Acked-by: Gertjan van Wingerde Acked-by: Ivo van Doorn Signed-off-by: John W. Linville