+commit e138e0ef9560c46ce93dbb22a728a57888e94d1c
+Author: Sujith Manoharan <c_manoha@qca.qualcomm.com>
+Date: Mon Feb 3 13:31:37 2014 +0530
+
+ ath9k: Fix TX power calculation
+
+ The commit, "ath9k_hw: Fix incorrect Tx control power in AR9003 template"
+ fixed the incorrect values in the eeprom templates, but if
+ boards have already been calibrated with incorrect values,
+ they would still be using the wrong TX power. Fix this by assigning
+ a default value in such cases.
+
+ Cc: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
+ Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
+
+commit b9f268b5b01331c3c82179abca551429450e9417
+Author: Michal Kazior <michal.kazior@tieto.com>
+Date: Wed Jan 29 14:22:27 2014 +0100
+
+ cfg80211: consider existing DFS interfaces
+
+ It was possible to break interface combinations in
+ the following way:
+
+ combo 1: iftype = AP, num_ifaces = 2, num_chans = 2,
+ combo 2: iftype = AP, num_ifaces = 1, num_chans = 1, radar = HT20
+
+ With the above interface combinations it was
+ possible to:
+
+ step 1. start AP on DFS channel by matching combo 2
+ step 2. start AP on non-DFS channel by matching combo 1
+
+ This was possible beacuse (step 2) did not consider
+ if other interfaces require radar detection.
+
+ The patch changes how cfg80211 tracks channels -
+ instead of channel itself now a complete chandef
+ is stored.
+
+ Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
+ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+
+commit bc9c62f5f511cc395c62dbf4cdd437f23db53b28
+Author: Antonio Quartulli <antonio@open-mesh.com>
+Date: Wed Jan 29 17:53:43 2014 +0100
+
+ cfg80211: fix channel configuration in IBSS join
+
+ When receiving an IBSS_JOINED event select the BSS object
+ based on the {bssid, channel} couple rather than the bssid
+ only.
+ With the current approach if another cell having the same
+ BSSID (but using a different channel) exists then cfg80211
+ picks up the wrong BSS object.
+ The result is a mismatching channel configuration between
+ cfg80211 and the driver, that can lead to any sort of
+ problem.
+
+ The issue can be triggered by having an IBSS sitting on
+ given channel and then asking the driver to create a new
+ cell using the same BSSID but with a different frequency.
+ By passing the channel to cfg80211_get_bss() we can solve
+ this ambiguity and retrieve/create the correct BSS object.
+ All the users of cfg80211_ibss_joined() have been changed
+ accordingly.
+
+ Moreover WARN when cfg80211_ibss_joined() gets a NULL
+ channel as argument and remove a bogus call of the same
+ function in ath6kl (it does not make sense to call
+ cfg80211_ibss_joined() with a zero BSSID on ibss-leave).
+
+ Cc: Kalle Valo <kvalo@qca.qualcomm.com>
+ Cc: Arend van Spriel <arend@broadcom.com>
+ Cc: Bing Zhao <bzhao@marvell.com>
+ Cc: Jussi Kivilinna <jussi.kivilinna@iki.fi>
+ Cc: libertas-dev@lists.infradead.org
+ Acked-by: Kalle Valo <kvalo@qca.qualcomm.com>
+ Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
+ [minor code cleanup in ath6kl]
+ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+
+commit 7e0c41cb41f215aba2c39b1c237bb4d42ec49a85
+Author: Johannes Berg <johannes.berg@intel.com>
+Date: Fri Jan 24 14:41:44 2014 +0100
+
+ mac80211: fix bufferable MMPDU RX handling
+
+ Action, disassoc and deauth frames are bufferable, and as such don't
+ have the PM bit in the frame control field reserved which means we
+ need to react to the bit when receiving in such a frame.
+
+ Fix this by introducing a new helper ieee80211_is_bufferable_mmpdu()
+ and using it for the RX path that currently ignores the PM bit in
+ any non-data frames for doze->wake transitions, but listens to it in
+ all frames for wake->doze transitions, both of which are wrong.
+
+ Also use the new helper in the TX path to clean up the code.
+
+ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+
+commit fc0df6d2343636e3f48a069330d5b972e3d8659d
+Author: Janusz Dziedzic <janusz.dziedzic@tieto.com>
+Date: Fri Jan 24 14:29:21 2014 +0100
+
+ cfg80211: set preset_chandef after channel switch
+
+ Set preset_chandef in channel switch notification.
+ In other case we will have old preset_chandef.
+
+ Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
+ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+
+commit cdec895e2344987ff171cece96e25d7407a3ebf6
+Author: Simon Wunderlich <simon@open-mesh.com>
+Date: Fri Jan 24 23:48:29 2014 +0100
+
+ mac80211: send ibss probe responses with noack flag
+
+ Responding to probe requests for scanning clients will often create
+ excessive retries, as it happens quite often that the scanning client
+ already left the channel. Therefore do it like hostapd and send probe
+ responses for wildcard SSID only once by using the noack flag.
+
+ Signed-off-by: Simon Wunderlich <simon@open-mesh.com>
+ [fix typo & 'wildcard SSID' in commit log]
+ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+
+commit 0b865d1e6b9c05052adae9315df7cb195dc60c3b
+Author: Luciano Coelho <luciano.coelho@intel.com>
+Date: Tue Jan 28 17:09:08 2014 +0200
+
+ mac80211: ibss: remove unnecessary call to release channel
+
+ The ieee80211_vif_use_channel() function calls
+ ieee80211_vif_release_channel(), so there's no need to call it
+ explicitly in __ieee80211_sta_join_ibss().
+
+ Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
+ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+
+commit e1b6c17e971f0a51ff86c2dac2584c63cd999cd7
+Author: Michal Kazior <michal.kazior@tieto.com>
+Date: Wed Jan 29 07:56:21 2014 +0100
+
+ mac80211: add missing CSA locking
+
+ The patch adds a missing sdata lock and adds a few
+ lockdeps for easier maintenance.
+
+ Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
+ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+
+commit ad17ba7d14d225b109b73c177cd446afb8050598
+Author: Michal Kazior <michal.kazior@tieto.com>
+Date: Wed Jan 29 07:56:20 2014 +0100
+
+ mac80211: fix sdata->radar_required locking
+
+ radar_required setting wasn't protected by
+ local->mtx in some places. This should prevent
+ from scanning/radar detection/roc colliding.
+
+ Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
+ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+
+commit 5fcd5f1808813a3d9e502fd756e01bee8a79c85d
+Author: Michal Kazior <michal.kazior@tieto.com>
+Date: Wed Jan 29 07:56:19 2014 +0100
+
+ mac80211: move csa_active setting in STA CSA
+
+ The sdata->vif.csa_active could be left set after,
+ e.g. channel context constraints check fail in STA
+ mode leaving the interface in a strange state for
+ a brief period of time until it is disconnected.
+ This was harmless but ugly.
+
+ Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
+ Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
+ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+
+commit e486da4b7eed71821c6b4c1bb9ac62ffd3ab13e9
+Author: Michal Kazior <michal.kazior@tieto.com>
+Date: Wed Jan 29 07:56:18 2014 +0100
+
+ mac80211: fix possible memory leak on AP CSA failure
+
+ If CSA for AP interface failed and the interface
+ was not stopped afterwards another CSA request
+ would leak sdata->u.ap.next_beacon.
+
+ Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
+ Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
+ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+
+commit 3a77ba08940682bf3d52cf14f980337324af9d4a
+Author: Johannes Berg <johannes.berg@intel.com>
+Date: Sat Feb 1 00:33:29 2014 +0100
+
+ mac80211: fix fragmentation code, particularly for encryption
+
+ The "new" fragmentation code (since my rewrite almost 5 years ago)
+ erroneously sets skb->len rather than using skb_trim() to adjust
+ the length of the first fragment after copying out all the others.
+ This leaves the skb tail pointer pointing to after where the data
+ originally ended, and thus causes the encryption MIC to be written
+ at that point, rather than where it belongs: immediately after the
+ data.
+
+ The impact of this is that if software encryption is done, then
+ a) encryption doesn't work for the first fragment, the connection
+ becomes unusable as the first fragment will never be properly
+ verified at the receiver, the MIC is practically guaranteed to
+ be wrong
+ b) we leak up to 8 bytes of plaintext (!) of the packet out into
+ the air
+
+ This is only mitigated by the fact that many devices are capable
+ of doing encryption in hardware, in which case this can't happen
+ as the tail pointer is irrelevant in that case. Additionally,
+ fragmentation is not used very frequently and would normally have
+ to be configured manually.
+
+ Fix this by using skb_trim() properly.
+
+ Cc: stable@vger.kernel.org
+ Fixes: 2de8e0d999b8 ("mac80211: rewrite fragmentation")
+ Reported-by: Jouni Malinen <j@w1.fi>
+ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+
+commit de5f242e0c10e841017e37eb8c38974a642dbca8
+Author: Sujith Manoharan <c_manoha@qca.qualcomm.com>
+Date: Tue Jan 28 06:21:59 2014 +0530
+
+ ath9k: Fix build error on ARM
+
+ Use mdelay instead of udelay to fix this error:
+
+ ERROR: "__bad_udelay" [drivers/net/wireless/ath/ath9k/ath9k_hw.ko] undefined!
+ make[1]: *** [__modpost] Error 1
+ make: *** [modules] Error 2
+
+ Reported-by: Josh Boyer <jwboyer@fedoraproject.org>
+ Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
+
+commit 8e3ea7a51dfc61810fcefd947f6edcf61125252a
+Author: Geert Uytterhoeven <geert@linux-m68k.org>
+Date: Sun Jan 26 11:53:21 2014 +0100
+
+ ath9k: Fix uninitialized variable in ath9k_has_tx_pending()
+
+ drivers/net/wireless/ath/ath9k/main.c: In function ‘ath9k_has_tx_pending’:
+ drivers/net/wireless/ath/ath9k/main.c:1869: warning: ‘npend’ may be used uninitialized in this function
+
+ Introduced by commit 10e2318103f5941aa70c318afe34bc41f1b98529 ("ath9k:
+ optimize ath9k_flush").
+
+ Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
+
+commit a4a634a6937ebdd827fa58e8fcdb8ca49a3769f6
+Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+Date: Mon Jan 27 11:07:42 2014 +0200
+
+ mac80211: release the channel in error path in start_ap
+
+ When the driver cannot start the AP or when the assignement
+ of the beacon goes wrong, we need to unassign the vif.
+
+ Cc: stable@vger.kernel.org
+ Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+
+commit dfb6889a75c601aedb7450b7e606668e77da6679
+Author: Johannes Berg <johannes.berg@intel.com>
+Date: Wed Jan 22 11:14:19 2014 +0200
+
+ cfg80211: send scan results from work queue
+
+ Due to the previous commit, when a scan finishes, it is in theory
+ possible to hit the following sequence:
+ 1. interface starts being removed
+ 2. scan is cancelled by driver and cfg80211 is notified
+ 3. scan done work is scheduled
+ 4. interface is removed completely, rdev->scan_req is freed,
+ event sent to userspace but scan done work remains pending
+ 5. new scan is requested on another virtual interface
+ 6. scan done work runs, freeing the still-running scan
+
+ To fix this situation, hang on to the scan done message and block
+ new scans while that is the case, and only send the message from
+ the work function, regardless of whether the scan_req is already
+ freed from interface removal. This makes step 5 above impossible
+ and changes step 6 to be
+ 5. scan done work runs, sending the scan done message
+
+ As this can't work for wext, so we send the message immediately,
+ but this shouldn't be an issue since we still return -EBUSY.
+
+ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+
+commit 45b7ab41fc08627d9a8428cb413d5d84662a9707
+Author: Johannes Berg <johannes.berg@intel.com>
+Date: Wed Jan 22 11:14:18 2014 +0200
+
+ cfg80211: fix scan done race
+
+ When an interface/wdev is removed, any ongoing scan should be
+ cancelled by the driver. This will make it call cfg80211, which
+ only queues a work struct. If interface/wdev removal is quick
+ enough, this can leave the scan request pending and processed
+ only after the interface is gone, causing a use-after-free.
+
+ Fix this by making sure the scan request is not pending after
+ the interface is destroyed. We can't flush or cancel the work
+ item due to locking concerns, but when it'll run it shouldn't
+ find anything to do. This leaves a potential issue, if a new
+ scan gets requested before the work runs, it prematurely stops
+ the running scan, potentially causing another crash. I'll fix
+ that in the next patch.
+
+ This was particularly observed with P2P_DEVICE wdevs, likely
+ because freeing them is quicker than freeing netdevs.
+
+ Reported-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
+ Fixes: 4a58e7c38443 ("cfg80211: don't "leak" uncompleted scans")
+ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+
+commit ae04fa489ab31b5a10d3cc8399f52761175d4321
+Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+Date: Thu Jan 23 14:28:16 2014 +0200
+
+ mac80211: avoid deadlock revealed by lockdep
+
+ sdata->u.ap.request_smps_work can’t be flushed synchronously
+ under wdev_lock(wdev) since ieee80211_request_smps_ap_work
+ itself locks the same lock.
+ While at it, reset the driver_smps_mode when the ap is
+ stopped to its default: OFF.
+
+ This solves:
+
+ ======================================================
+ [ INFO: possible circular locking dependency detected ]
+ 3.12.0-ipeer+ #2 Tainted: G O
+ -------------------------------------------------------
+ rmmod/2867 is trying to acquire lock:
+ ((&sdata->u.ap.request_smps_work)){+.+...}, at: [<c105b8d0>] flush_work+0x0/0x90
+
+ but task is already holding lock:
+ (&wdev->mtx){+.+.+.}, at: [<f9b32626>] cfg80211_stop_ap+0x26/0x230 [cfg80211]
+
+ which lock already depends on the new lock.
+
+ the existing dependency chain (in reverse order) is:
+
+ -> #1 (&wdev->mtx){+.+.+.}:
+ [<c10aefa9>] lock_acquire+0x79/0xe0
+ [<c1607a1a>] mutex_lock_nested+0x4a/0x360
+ [<fb06288b>] ieee80211_request_smps_ap_work+0x2b/0x50 [mac80211]
+ [<c105cdd8>] process_one_work+0x198/0x450
+ [<c105d469>] worker_thread+0xf9/0x320
+ [<c10669ff>] kthread+0x9f/0xb0
+ [<c1613397>] ret_from_kernel_thread+0x1b/0x28
+
+ -> #0 ((&sdata->u.ap.request_smps_work)){+.+...}:
+ [<c10ae9df>] __lock_acquire+0x183f/0x1910
+ [<c10aefa9>] lock_acquire+0x79/0xe0
+ [<c105b917>] flush_work+0x47/0x90
+ [<c105d867>] __cancel_work_timer+0x67/0xe0
+ [<c105d90f>] cancel_work_sync+0xf/0x20
+ [<fb0765cc>] ieee80211_stop_ap+0x8c/0x340 [mac80211]
+ [<f9b3268c>] cfg80211_stop_ap+0x8c/0x230 [cfg80211]
+ [<f9b0d8f9>] cfg80211_leave+0x79/0x100 [cfg80211]
+ [<f9b0da72>] cfg80211_netdev_notifier_call+0xf2/0x4f0 [cfg80211]
+ [<c160f2c9>] notifier_call_chain+0x59/0x130
+ [<c106c6de>] __raw_notifier_call_chain+0x1e/0x30
+ [<c106c70f>] raw_notifier_call_chain+0x1f/0x30
+ [<c14f8213>] call_netdevice_notifiers_info+0x33/0x70
+ [<c14f8263>] call_netdevice_notifiers+0x13/0x20
+ [<c14f82a4>] __dev_close_many+0x34/0xb0
+ [<c14f83fe>] dev_close_many+0x6e/0xc0
+ [<c14f9c77>] rollback_registered_many+0xa7/0x1f0
+ [<c14f9dd4>] unregister_netdevice_many+0x14/0x60
+ [<fb06f4d9>] ieee80211_remove_interfaces+0xe9/0x170 [mac80211]
+ [<fb055116>] ieee80211_unregister_hw+0x56/0x110 [mac80211]
+ [<fa3e9396>] iwl_op_mode_mvm_stop+0x26/0xe0 [iwlmvm]
+ [<f9b9d8ca>] _iwl_op_mode_stop+0x3a/0x70 [iwlwifi]
+ [<f9b9d96f>] iwl_opmode_deregister+0x6f/0x90 [iwlwifi]
+ [<fa405179>] __exit_compat+0xd/0x19 [iwlmvm]
+ [<c10b8bf9>] SyS_delete_module+0x179/0x2b0
+ [<c1613421>] sysenter_do_call+0x12/0x32
+
+ Fixes: 687da132234f ("mac80211: implement SMPS for AP")
+ Cc: <stable@vger.kernel.org> [3.13]
+ Reported-by: Ilan Peer <ilan.peer@intel.com>
+ Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+
+commit 178b205e96217164fd7c30113464250d0b6f5eca
+Author: Johannes Berg <johannes.berg@intel.com>
+Date: Thu Jan 23 16:32:29 2014 +0100
+
+ cfg80211: re-enable 5/10 MHz support
+
+ Unfortunately I forgot this during the merge window, but the
+ patch seems small enough to go in as a fix. The userspace API
+ bug that was the reason for disabling it has long been fixed.
+
+ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+
+commit 110a1c79acda14edc83b7c8dc5af9c7ddd23eb61
+Author: Pontus Fuchs <pontus.fuchs@gmail.com>
+Date: Thu Jan 16 15:00:40 2014 +0100
+
+ nl80211: Reset split_start when netlink skb is exhausted
+
+ When the netlink skb is exhausted split_start is left set. In the
+ subsequent retry, with a larger buffer, the dump is continued from the
+ failing point instead of from the beginning.
+
+ This was causing my rt28xx based USB dongle to now show up when
+ running "iw list" with an old iw version without split dump support.
+
+ Cc: stable@vger.kernel.org
+ Fixes: 3713b4e364ef ("nl80211: allow splitting wiphy information in dumps")
+ Signed-off-by: Pontus Fuchs <pontus.fuchs@gmail.com>
+ [avoid the entire workaround when state->split is set]
+ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+
+commit b4c31b45ffc7ef110fa9ecc34d7878fe7c5b9da4
+Author: Eliad Peller <eliad@wizery.com>
+Date: Sun Jan 12 11:06:37 2014 +0200
+
+ mac80211: move roc cookie assignment earlier
+
+ ieee80211_start_roc_work() might add a new roc
+ to existing roc, and tell cfg80211 it has already
+ started.
+
+ However, this might happen before the roc cookie
+ was set, resulting in REMAIN_ON_CHANNEL (started)
+ event with null cookie. Consequently, it can make
+ wpa_supplicant go out of sync.
+
+ Fix it by setting the roc cookie earlier.
+
+ Cc: stable@vger.kernel.org
+ Signed-off-by: Eliad Peller <eliad@wizery.com>
+ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+
+commit cfdc9157bfd7bcf88ab4dae08873a9907eba984c
+Author: Johannes Berg <johannes.berg@intel.com>
+Date: Fri Jan 24 14:06:29 2014 +0100
+
+ nl80211: send event when AP operation is stopped
+
+ There are a few cases, e.g. suspend, where an AP interface is
+ stopped by the kernel rather than by userspace request, most
+ commonly when suspending. To let userspace know about this,
+ send the NL80211_CMD_STOP_AP command as an event every time
+ an AP interface is stopped. This also happens when userspace
+ did in fact request the AP stop, but that's not a problem.
+
+ For full-MAC drivers this may need to be extended to also
+ cover cases where the device stopped the AP operation for
+ some reason, this a bit more complicated because then all
+ cfg80211 state also needs to be reset; such API is not part
+ of this patch.
+
+ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+
+commit d5d567eda7704f190379ca852a8f9a4112e3eee3
+Author: Johannes Berg <johannes.berg@intel.com>
+Date: Thu Jan 23 16:20:29 2014 +0100
+
+ mac80211: add length check in ieee80211_is_robust_mgmt_frame()
+
+ A few places weren't checking that the frame passed to the
+ function actually has enough data even though the function
+ clearly documents it must have a payload byte. Make this
+ safer by changing the function to take an skb and checking
+ the length inside. The old version is preserved for now as
+ the rtl* drivers use it and don't have a correct skb.
+
+ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+
+commit f8f6d212a047fc65c7d3442dfc038f65517236fc
+Author: Johannes Berg <johannes.berg@intel.com>
+Date: Fri Jan 24 10:53:53 2014 +0100
+
+ nl80211: fix scheduled scan RSSI matchset attribute confusion
+
+ The scheduled scan matchsets were intended to be a list of filters,
+ with the found BSS having to pass at least one of them to be passed
+ to the host. When the RSSI attribute was added, however, this was
+ broken and currently wpa_supplicant adds that attribute in its own
+ matchset; however, it doesn't intend that to mean that anything
+ that passes the RSSI filter should be passed to the host, instead
+ it wants it to mean that everything needs to also have higher RSSI.
+
+ This is semantically problematic because we have a list of filters
+ like [ SSID1, SSID2, SSID3, RSSI ] with no real indication which
+ one should be OR'ed and which one AND'ed.
+
+ To fix this, move the RSSI filter attribute into each matchset. As
+ we need to stay backward compatible, treat a matchset with only the
+ RSSI attribute as a "default RSSI filter" for all other matchsets,
+ but only if there are other matchsets (an RSSI-only matchset by
+ itself is still desirable.)
+
+ To make driver implementation easier, keep a global min_rssi_thold
+ for the entire request as well. The only affected driver is ath6kl.
+
+ I found this when I looked into the code after Raja Mani submitted
+ a patch fixing the n_match_sets calculation to disregard the RSSI,
+ but that patch didn't address the semantic issue.
+
+ Reported-by: Raja Mani <rmani@qti.qualcomm.com>
+ Acked-by: Luciano Coelho <luciano.coelho@intel.com>
+ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+
+commit de553e8545e65a6dc4e45f43df7e1443d4291922
+Author: Johannes Berg <johannes.berg@intel.com>
+Date: Fri Jan 24 10:17:47 2014 +0100
+
+ nl80211: check nla_parse() return values
+
+ If there's a policy, then nla_parse() return values must be
+ checked, otherwise the policy is useless and there's nothing
+ that ensures the attributes are actually what we expect them
+ to be.
+
+ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+
+commit 652204a0733e9e1c54661d6f9d36e2e1e3b22bb1
+Author: Karl Beldan <karl.beldan@rivierawaves.com>
+Date: Thu Jan 23 20:06:34 2014 +0100
+
+ mac80211: send {ADD,DEL}BA on AC_VO like other mgmt frames, as per spec
+
+ ATM, {ADD,DEL}BA and BAR frames are sent on the AC matching the TID of
+ the BA parameters. In the discussion [1] about this patch, Johannes
+ recalled that it fixed some races with the DELBA and indeed this
+ behavior was introduced in [2].
+ While [2] is right for the BARs, the part queueing the {ADD,DEL}BAs on
+ their BA params TID AC violates the spec and is more a workaround for
+ some drivers. Helmut expressed some concerns wrt such drivers, in
+ particular DELBAs in rt2x00.
+
+ ATM, DELBAs are sent after a driver has called (hence "purposely")
+ ieee80211_start_tx_ba_cb_irqsafe and Johannes and Emmanuel gave some
+ details wrt intentions behind the split of the IEEE80211_AMPDU_TX_STOP_*
+ given to the driver ampdu_action supposed to call this function, which
+ could prove handy to people trying to do the right thing in faulty
+ drivers (if their fw/hw don't get in their way).
+
+ [1] http://mid.gmane.org/1390391564-18481-1-git-send-email-karl.beldan@gmail.com
+ [2] Commit: cf6bb79ad828 ("mac80211: Use appropriate TID for sending BAR, ADDBA and DELBA frames")
+
+ Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com>
+ Cc: Helmut Schaa <helmut.schaa@googlemail.com>
+ Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
++++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
+@@ -790,7 +790,7 @@ void ath6kl_cfg80211_connect_event(struc
+ if (nw_type & ADHOC_NETWORK) {
+ ath6kl_dbg(ATH6KL_DBG_WLAN_CFG, "ad-hoc %s selected\n",
+ nw_type & ADHOC_CREATOR ? "creator" : "joiner");
+- cfg80211_ibss_joined(vif->ndev, bssid, GFP_KERNEL);
++ cfg80211_ibss_joined(vif->ndev, bssid, chan, GFP_KERNEL);
+ cfg80211_put_bss(ar->wiphy, bss);
+ return;
+ }
+@@ -861,13 +861,9 @@ void ath6kl_cfg80211_disconnect_event(st
+ }