+commit 31959d8df39319e32c6d5ba9c135727be90cfad7
+Author: Michal Kazior <michal.kazior@tieto.com>
+Date: Fri Mar 7 08:09:38 2014 +0100
+
+ mac80211: fix possible NULL dereference
+
+ If chanctx is missing on a given vif then the band
+ is assumed to be 2GHz. However if hw doesn't
+ support 2GHz band then mac80211 ended up with a
+ NULL dereference.
+
+ This fixes a splat:
+
+ [ 4605.207223] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
+ [ 4605.210789] IP: [<ffffffffa07b5635>] ieee80211_parse_bitrates+0x65/0x110 [mac80211]
+
+ The splat was preceeded by WARN_ON(!chanctx_conf)
+ in ieee80211_get_sdata_band().
+
+ Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
+
+commit 6c5a3ffa0a2d22c091a2717f427259bacf77ac5e
+Author: Michael Braun <michael-dev@fami-braun.de>
+Date: Thu Mar 6 15:08:43 2014 +0100
+
+ mac80211: fix WPA with VLAN on AP side with ps-sta again
+
+ commit de74a1d9032f4d37ea453ad2a647e1aff4cd2591
+ "mac80211: fix WPA with VLAN on AP side with ps-sta"
+ fixed an issue where queued multicast packets would
+ be sent out encrypted with the key of an other bss.
+
+ commit "7cbf9d017dbb5e3276de7d527925d42d4c11e732"
+ "mac80211: fix oops on mesh PS broadcast forwarding"
+ essentially reverted it, because vif.type cannot be AP_VLAN
+ due to the check to vif.type in ieee80211_get_buffered_bc before.
+
+ As the later commit intended to fix the MESH case, fix it
+ by checking for IFTYPE_AP instead of IFTYPE_AP_VLAN.
+
+ Fixes: 7cbf9d017dbb
+ Cc: <stable@vger.kernel.org> # 3.10.x
+ Cc: <stable@vger.kernel.org> # 3.11.x
+ Cc: <stable@vger.kernel.org> # 3.12.x
+ Cc: <stable@vger.kernel.org> # 3.13.x
+ Cc: <linux-wireless@vger.kernel.org>
+ Cc: <projekt-wlan@fem.tu-ilmenau.de>
+ Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
+
+commit 9d6ab9bdb9b368a6cf9519f0f92509b5b2c297ec
+Author: Johannes Berg <johannes.berg@intel.com>
+Date: Mon Mar 3 14:19:08 2014 +0100
+
+ cfg80211: remove racy beacon_interval assignment
+
+ In case of AP mode, the beacon interval is already reset to
+ zero inside cfg80211_stop_ap(), and in the other modes it
+ isn't relevant. Remove the assignment to remove a potential
+ race since the assignment isn't properly locked.
+
+ Reported-by: Michal Kazior <michal.kazior@tieto.com>
+ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+
+commit 1abdeca3c6fb9cf1f84f85e78ed8d1c33bd69db0
+Author: Felix Fietkau <nbd@openwrt.org>
+Date: Fri Feb 28 18:52:56 2014 +0100
+
+ ath9k_hw: tweak noise immunity thresholds for older chipsets
+
+ Older chipsets are more sensitive to high PHY error counts, and the
+ current noise immunity thresholds were based on tests run at QCA with
+ newer chipsets.
+
+ This patch brings back the values from the old ANI implementation for
+ old chipsets, and it also disables weak signal detection on an earlier
+ noise immunity level, to improve overall radio stability on affected
+ devices.
+
+ Signed-off-by: Felix Fietkau <nbd@openwrt.org>
+
+commit 431e506da5953adc3b65af25f4b90873d528c115
+Author: Felix Fietkau <nbd@openwrt.org>
+Date: Fri Feb 28 18:44:13 2014 +0100
+
+ ath9k_hw: toggle weak signal detection in AP mode on older chipsets
+
+ The commit 80b4205b "ath9k: Fix OFDM weak signal detection for AP mode"
+ prevented weak signal detection changes from taking effect in AP mode on
+ all chipsets, claiming it is "not allowed".
+
+ The main reason for not disabling weak signal detection in AP mode is
+ that typically beacon RSSI is used to track whether it is needed to
+ boost range, and this is unavailable in AP mode for obvious reasons.
+
+ The problem with not disabling weak signal detection is that older
+ chipsets are very sensitive to high PHY error counts. When faced with
+ heavy noise, this can lead to an excessive amount of "Failed to stop
+ TX DMA" errors in the field.
+
+ Signed-off-by: Felix Fietkau <nbd@openwrt.org>
+
+commit 98d1a6c5b14688ed030e81b889f607be308e0df9
+Author: Felix Fietkau <nbd@openwrt.org>
+Date: Mon Feb 24 22:20:32 2014 +0100
+
+ ath9k: fix invalid descriptor discarding
+
+ Only set sc->rx.discard_next to rx_stats->rs_more when actually
+ discarding the current descriptor.
+
+ Also, fix a detection of broken descriptors:
+ First the code checks if the current descriptor is not done.
+ Then it checks if the next descriptor is done.
+ Add a check that afterwards checks the first descriptor again, because
+ it might have been completed in the mean time.
+
+ This fixes a regression introduced in
+ commit 723e711356b5a8a95728a890e254e8b0d47b55cf
+ "ath9k: fix handling of broken descriptors"
+
+ Cc: stable@vger.kernel.org
+ Reported-by: Marco André Dinis <marcoandredinis@gmail.com>
+ Signed-off-by: Felix Fietkau <nbd@openwrt.org>
+
+commit 52a46300e782fe6994466523eb2b0b59091ea59f
+Author: Felix Fietkau <nbd@openwrt.org>
+Date: Mon Feb 24 11:43:50 2014 +0100
+
+ ath9k: reduce baseband hang detection false positive rate
+
+ Check if the baseband state remains stable, and add a small delay
+ between register reads.
+
+ Signed-off-by: Felix Fietkau <nbd@openwrt.org>
+
+commit 118945bb12082e9d4edddc868d88143164e0f440
+Author: Felix Fietkau <nbd@openwrt.org>
+Date: Sat Feb 22 14:55:23 2014 +0100
+
+ ath5k: set SURVEY_INFO_IN_USE on get_survey
+
+ Only one channel is returned - the one currently being used.
+
+ Signed-off-by: Felix Fietkau <nbd@openwrt.org>
+
+commit ee41f72476e1ea44283dfe1cbf75b9543a1e15c8
+Author: Felix Fietkau <nbd@openwrt.org>
+Date: Sat Feb 22 14:44:52 2014 +0100
+
+ ath9k: make some hardware reset log messages debug-only
+
+ On some chips, baseband watchdog hangs are more common than others, and
+ the driver has support for handling them.
+ Interrupts even after a watchdog hang are also quite common, so there's
+ not much point in spamming the user's logfiles.
+
+ Signed-off-by: Felix Fietkau <nbd@openwrt.org>
+
+commit b14fbb554fc65a2e0b5c41a319269b0350f187e7
+Author: Felix Fietkau <nbd@openwrt.org>
+Date: Sat Feb 22 14:35:25 2014 +0100
+
+ ath9k: do not set half/quarter channel flags in AR_PHY_MODE
+
+ 5/10 MHz channel bandwidth is configured via the PLL clock, instead of
+ the AR_PHY_MODE register. Using that register is AR93xx specific, and
+ makes the mode incompatible with earlier chipsets.
+
+ In some early versions, these flags were apparently applied at the wrong
+ point in time and thus did not cause connectivity issues, however now
+ they are causing problems, as pointed out in this OpenWrt ticket:
+
+ https://dev.openwrt.org/ticket/14916
+
+ Signed-off-by: Felix Fietkau <nbd@openwrt.org>
+
+commit 0f1cb7be2551b30b02cd54c897e0e29e483cfda5
+Author: Felix Fietkau <nbd@openwrt.org>
+Date: Sat Feb 22 13:43:29 2014 +0100
+
+ ath9k: fix ps-poll responses under a-mpdu sessions
+
+ When passing tx frames to the U-APSD queue for powersave poll responses,
+ the ath_atx_tid pointer needs to be passed to ath_tx_setup_buffer for
+ proper sequence number accounting.
+
+ This fixes high latency and connection stability issues with ath9k
+ running as AP and a few kinds of mobile phones as client, when PS-Poll
+ is heavily used
+
+ Cc: stable@vger.kernel.org
+ Signed-off-by: Felix Fietkau <nbd@openwrt.org>
+
+commit d5d87a37bbd6066b2c3c5d0bd0fe2a6e2ea45cc5
+Author: Felix Fietkau <nbd@openwrt.org>
+Date: Fri Feb 21 11:39:59 2014 +0100
+
+ ath9k: list more reset causes in debugfs
+
+ Number of MAC hangs and stuck beacons were missing
+
+ Signed-off-by: Felix Fietkau <nbd@openwrt.org>
+
+commit d84856012e0f10fe598a5ad3b7b869397a089e07
+Author: Johannes Berg <johannes.berg@intel.com>
+Date: Thu Feb 20 11:19:58 2014 +0100
+
+ mac80211: fix station wakeup powersave race
+
+ Consider the following (relatively unlikely) scenario:
+ 1) station goes to sleep while frames are buffered in driver
+ 2) driver blocks wakeup (until no more frames are buffered)
+ 3) station wakes up again
+ 4) driver unblocks wakeup
+
+ In this case, the current mac80211 code will do the following:
+ 1) WLAN_STA_PS_STA set
+ 2) WLAN_STA_PS_DRIVER set
+ 3) - nothing -
+ 4) WLAN_STA_PS_DRIVER cleared
+
+ As a result, no frames will be delivered to the client, even
+ though it is awake, until it sends another frame to us that
+ triggers ieee80211_sta_ps_deliver_wakeup() in sta_ps_end().
+
+ Since we now take the PS spinlock, we can fix this while at
+ the same time removing the complexity with the pending skb
+ queue function. This was broken since my commit 50a9432daeec
+ ("mac80211: fix powersaving clients races") due to removing
+ the clearing of WLAN_STA_PS_STA in the RX path.
+
+ While at it, fix a cleanup path issue when a station is
+ removed while the driver is still blocking its wakeup.
+
+ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+
+commit 798f2786602cbe93e6b928299614aa36ebf50692
+Author: Johannes Berg <johannes.berg@intel.com>
+Date: Mon Feb 17 20:49:03 2014 +0100
+
+ mac80211: insert stations before adding to driver
+
+ There's a race condition in mac80211 because we add stations
+ to the internal lists after adding them to the driver, which
+ means that (for example) the following can happen:
+ 1. a station connects and is added
+ 2. first, it is added to the driver
+ 3. then, it is added to the mac80211 lists
+
+ If the station goes to sleep between steps 2 and 3, and the
+ firmware/hardware records it as being asleep, mac80211 will
+ never instruct the driver to wake it up again as it never
+ realized it went to sleep since the RX path discarded the
+ frame as a "spurious class 3 frame", no station entry was
+ present yet.
+
+ Fix this by adding the station in software first, and only
+ then adding it to the driver. That way, any state that the
+ driver changes will be reflected properly in mac80211's
+ station state. The problematic part is the roll-back if the
+ driver fails to add the station, in that case a bit more is
+ needed. To not make that overly complex prevent starting BA
+ sessions in the meantime.
+
+ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+
+commit b9ba6a520cb07ab3aa7aaaf9ce4a0bc7a6bc06fe
+Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+Date: Thu Feb 20 09:22:11 2014 +0200
+
+ mac80211: fix AP powersave TX vs. wakeup race
+
+ There is a race between the TX path and the STA wakeup: while
+ a station is sleeping, mac80211 buffers frames until it wakes
+ up, then the frames are transmitted. However, the RX and TX
+ path are concurrent, so the packet indicating wakeup can be
+ processed while a packet is being transmitted.
+
+ This can lead to a situation where the buffered frames list
+ is emptied on the one side, while a frame is being added on
+ the other side, as the station is still seen as sleeping in
+ the TX path.
+
+ As a result, the newly added frame will not be send anytime
+ soon. It might be sent much later (and out of order) when the
+ station goes to sleep and wakes up the next time.
+
+ Additionally, it can lead to the crash below.
+
+ Fix all this by synchronising both paths with a new lock.
+ Both path are not fastpath since they handle PS situations.
+
+ In a later patch we'll remove the extra skb queue locks to
+ reduce locking overhead.
+
+ BUG: unable to handle kernel
+ NULL pointer dereference at 000000b0
+ IP: [<ff6f1791>] ieee80211_report_used_skb+0x11/0x3e0 [mac80211]
+ *pde = 00000000
+ Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
+ EIP: 0060:[<ff6f1791>] EFLAGS: 00210282 CPU: 1
+ EIP is at ieee80211_report_used_skb+0x11/0x3e0 [mac80211]
+ EAX: e5900da0 EBX: 00000000 ECX: 00000001 EDX: 00000000
+ ESI: e41d00c0 EDI: e5900da0 EBP: ebe458e4 ESP: ebe458b0
+ DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
+ CR0: 8005003b CR2: 000000b0 CR3: 25a78000 CR4: 000407d0
+ DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
+ DR6: ffff0ff0 DR7: 00000400
+ Process iperf (pid: 3934, ti=ebe44000 task=e757c0b0 task.ti=ebe44000)
+ iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command LQ_CMD (#4e), seq: 0x0903, 92 bytes at 3[3]:9
+ Stack:
+ e403b32c ebe458c4 00200002 00200286 e403b338 ebe458cc c10960bb e5900da0
+ ff76a6ec ebe458d8 00000000 e41d00c0 e5900da0 ebe458f0 ff6f1b75 e403b210
+ ebe4598c ff723dc1 00000000 ff76a6ec e597c978 e403b758 00000002 00000002
+ Call Trace:
+ [<ff6f1b75>] ieee80211_free_txskb+0x15/0x20 [mac80211]
+ [<ff723dc1>] invoke_tx_handlers+0x1661/0x1780 [mac80211]
+ [<ff7248a5>] ieee80211_tx+0x75/0x100 [mac80211]
+ [<ff7249bf>] ieee80211_xmit+0x8f/0xc0 [mac80211]
+ [<ff72550e>] ieee80211_subif_start_xmit+0x4fe/0xe20 [mac80211]
+ [<c149ef70>] dev_hard_start_xmit+0x450/0x950
+ [<c14b9aa9>] sch_direct_xmit+0xa9/0x250
+ [<c14b9c9b>] __qdisc_run+0x4b/0x150
+ [<c149f732>] dev_queue_xmit+0x2c2/0xca0
+
+ Cc: stable@vger.kernel.org
+ Reported-by: Yaara Rozenblum <yaara.rozenblum@intel.com>
+ Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+ Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
+ [reword commit log, use a separate lock]
+ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+
+commit 80e419de0dff38436b30d363311c625766193f86
+Author: Inbal Hacohen <Inbal.Hacohen@intel.com>
+Date: Wed Feb 12 09:32:27 2014 +0200
+
+ cfg80211: bugfix in regulatory user hint process
+
+ After processing hint_user, we would want to schedule the
+ timeout work only if we are actually waiting to CRDA. This happens
+ when the status is not "IGNORE" nor "ALREADY_SET".
+
+ Signed-off-by: Inbal Hacohen <Inbal.Hacohen@intel.com>
+ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+
+commit 6514c93afede55284e2cb63359aadedb85884c80
+Author: Jouni Malinen <jouni@qca.qualcomm.com>
+Date: Tue Feb 18 20:41:08 2014 +0200
+
+ ath9k: Enable U-APSD AP mode support
+
+ mac80211 handles the actual operations, so ath9k can just indicate
+ support for this. Based on initial tests, this combination seems to
+ work fine.
+
+ Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
+
+commit a63caf0a357ad5c1f08d6b7827dc76c451445017
+Author: Stanislaw Gruszka <sgruszka@redhat.com>
+Date: Wed Feb 19 13:15:17 2014 +0100
+
+ ath9k: protect tid->sched check
+
+ We check tid->sched without a lock taken on ath_tx_aggr_sleep(). That
+ is race condition which can result of doing list_del(&tid->list) twice
+ (second time with poisoned list node) and cause crash like shown below:
+
+ [424271.637220] BUG: unable to handle kernel paging request at 00100104
+ [424271.637328] IP: [<f90fc072>] ath_tx_aggr_sleep+0x62/0xe0 [ath9k]
+ ...
+ [424271.639953] Call Trace:
+ [424271.639998] [<f90f6900>] ? ath9k_get_survey+0x110/0x110 [ath9k]
+ [424271.640083] [<f90f6942>] ath9k_sta_notify+0x42/0x50 [ath9k]
+ [424271.640177] [<f809cfef>] sta_ps_start+0x8f/0x1c0 [mac80211]
+ [424271.640258] [<c10f730e>] ? free_compound_page+0x2e/0x40
+ [424271.640346] [<f809e915>] ieee80211_rx_handlers+0x9d5/0x2340 [mac80211]
+ [424271.640437] [<c112f048>] ? kmem_cache_free+0x1d8/0x1f0
+ [424271.640510] [<c1345a84>] ? kfree_skbmem+0x34/0x90
+ [424271.640578] [<c10fc23c>] ? put_page+0x2c/0x40
+ [424271.640640] [<c1345a84>] ? kfree_skbmem+0x34/0x90
+ [424271.640706] [<c1345a84>] ? kfree_skbmem+0x34/0x90
+ [424271.640787] [<f809dde3>] ? ieee80211_rx_handlers_result+0x73/0x1d0 [mac80211]
+ [424271.640897] [<f80a07a0>] ieee80211_prepare_and_rx_handle+0x520/0xad0 [mac80211]
+ [424271.641009] [<f809e22d>] ? ieee80211_rx_handlers+0x2ed/0x2340 [mac80211]
+ [424271.641104] [<c13846ce>] ? ip_output+0x7e/0xd0
+ [424271.641182] [<f80a1057>] ieee80211_rx+0x307/0x7c0 [mac80211]
+ [424271.641266] [<f90fa6ee>] ath_rx_tasklet+0x88e/0xf70 [ath9k]
+ [424271.641358] [<f80a0f2c>] ? ieee80211_rx+0x1dc/0x7c0 [mac80211]
+ [424271.641445] [<f90f82db>] ath9k_tasklet+0xcb/0x130 [ath9k]
+
+ Bug report:
+ https://bugzilla.kernel.org/show_bug.cgi?id=70551
+
+ Reported-and-tested-by: Max Sydorenko <maxim.stargazer@gmail.com>
+ Cc: stable@vger.kernel.org
+ Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
+
+commit 82ed9e3ccc02797df2ffe4b78127c4cd5f799a41
+Author: Felix Fietkau <nbd@openwrt.org>
+Date: Tue Feb 11 15:54:13 2014 +0100
+
+ mac80211: send control port protocol frames to the VO queue
+
+ Improves reliability of wifi connections with WPA, since authentication
+ frames are prioritized over normal traffic and also typically exempt
+ from aggregation.
+
+ Cc: stable@vger.kernel.org
+ Signed-off-by: Felix Fietkau <nbd@openwrt.org>
+
+commit d4426800f71e972feaa33e04c5801fc730627bdd
+Author: Stanislaw Gruszka <stf_xl@wp.pl>
+Date: Mon Feb 10 22:38:28 2014 +0100
+
+ rtl8187: fix regression on MIPS without coherent DMA
+
+ This patch fixes regression caused by commit a16dad77634 "MIPS: Fix
+ potencial corruption". That commit fixes one corruption scenario in
+ cost of adding another one, which actually start to cause crashes
+ on Yeeloong laptop when rtl8187 driver is used.
+
+ For correct DMA read operation on machines without DMA coherence, kernel
+ have to invalidate cache, such it will refill later with new data that
+ device wrote to memory, when that data is needed to process. We can only
+ invalidate full cache line. Hence when cache line includes both dma
+ buffer and some other data (written in cache, but not yet in main
+ memory), the other data can not hit memory due to invalidation. That
+ happen on rtl8187 where struct rtl8187_priv fields are located just
+ before and after small buffers that are passed to USB layer and DMA
+ is performed on them.
+
+ To fix the problem we align buffers and reserve space after them to make
+ them match cache line.
+
+ This patch does not resolve all possible MIPS problems entirely, for
+ that we have to assure that we always map cache aligned buffers for DMA,
+ what can be complex or even not possible. But patch fixes visible and
+ reproducible regression and seems other possible corruptions do not
+ happen in practice, since Yeeloong laptop works stable without rtl8187
+ driver.
+
+ Bug report:
+ https://bugzilla.kernel.org/show_bug.cgi?id=54391
+
+ Reported-by: Petr Pisar <petr.pisar@atlas.cz>
+ Bisected-by: Tom Li <biergaizi2009@gmail.com>
+ Reported-and-tested-by: Tom Li <biergaizi2009@gmail.com>
+ Cc: stable@vger.kernel.org
+ Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
+
+commit e2f141d67ad1e7fe10aaab61811e8a409dfb2442
+Author: Sujith Manoharan <c_manoha@qca.qualcomm.com>
+Date: Fri Feb 7 10:29:55 2014 +0530
+
+ ath9k: Calculate IQ-CAL median
+
+ This patch adds a routine to calculate the median IQ correction
+ values for AR955x, which is used for outlier detection.
+ The normal method which is used for all other chips is
+ bypassed for AR955x.
+
+ Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
+
+commit c52a6fce0820c8d0687443ab86058ae03b478c8f
+Author: Sujith Manoharan <c_manoha@qca.qualcomm.com>
+Date: Fri Feb 7 10:29:54 2014 +0530
+
+ ath9k: Expand the IQ coefficient array
+
+ This will be used for storing data for mutiple
+ IQ calibration runs, for AR955x.
+
+ Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
+
+commit 034969ff5c2b6431d10e07c1938f0b916da85cc3
+Author: Sujith Manoharan <c_manoha@qca.qualcomm.com>
+Date: Fri Feb 7 10:29:53 2014 +0530
+
+ ath9k: Modify IQ calibration for AR955x
+
+ IQ calibration post-processing for AR955x is different
+ from other chips - instead of just doing it as part
+ of AGC calibration once, it is triggered 3 times and
+ a median is determined. This patch adds initial support
+ for changing the calibration behavior for AR955x.
+
+ Also, to simplify things, a helper routine to issue/poll
+ AGC calibration is used.
+
+ For non-AR955x chips, the iqcal_idx (which will be used
+ in subsequent patches) is set to zero.
+
+ Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
+
+commit 9b1ed6454e6f3511f24266be99b4e403f243f6a8
+Author: Sujith Manoharan <c_manoha@qca.qualcomm.com>
+Date: Fri Feb 7 10:29:52 2014 +0530
+
+ ath9k: Fix magnitude/phase calculation
+
+ Incorrect values are programmed in the registers
+ containing the IQ correction coefficients by the IQ-CAL
+ post-processing code. Fix this.
+
+ Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
+
+commit 36f93484f96f79171dcecb67c5ef0c3de22531a6
+Author: Sujith Manoharan <c_manoha@qca.qualcomm.com>
+Date: Fri Feb 7 10:29:51 2014 +0530
+
+ ath9k: Rename ar9003_hw_tx_iqcal_load_avg_2_passes
+
+ Use ar9003_hw_tx_iq_cal_outlier_detection instead.
+
+ Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
+
+commit 3af09a7f5d21dd5fd15b973ce6a91a575da30417
+Author: Sujith Manoharan <c_manoha@qca.qualcomm.com>
+Date: Fri Feb 7 10:29:50 2014 +0530
+
+ ath9k: Check explicitly for IQ calibration
+
+ In chips like AR955x, the initvals contain the information
+ whether IQ calibration is to be done in the HW when an
+ AGC calibration is triggered. Check if IQ-CAL is enabled
+ in the initvals before flagging 'txiqcal_done' as true.
+
+ Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
+
+commit cb4969634b93c4643a32cc3fbd27d2b288b25771
+Author: Sujith Manoharan <c_manoha@qca.qualcomm.com>
+Date: Fri Feb 7 10:29:49 2014 +0530
+
+ ath9k: Fix IQ cal post processing for SoC
+
+ Calibration data is not reused for SoC chips, so
+ call ar9003_hw_tx_iq_cal_post_proc() with the correct
+ argument. The 'is_reusable' flag is currently used
+ only for PC-OEM chips, but it makes things clearer to
+ specify it explicity.
+
+ Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
+
+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
+ }