Patch "ath10k: fix fetching channel during potential radar detection" has been added to the 4.9-stable tree

This is a note to let you know that I've just added the patch titled

ath10k: fix fetching channel during potential radar detection

to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
ath10k-fix-fetching-channel-during-potential-radar-detection.patch
and it can be found in the queue-4.9 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

From: Mohammed Shafi Shajakhan <[email protected]>
Date: Wed, 8 Mar 2017 18:03:32 +0530
Subject: ath10k: fix fetching channel during potential radar detection

From: Mohammed Shafi Shajakhan <[email protected]>

[ Upstream commit a28f6f27a88f047f03f04b9246ca260ebc91455e ]

Fetch target operating channel during potential radar detection when the interface is just brought up, but no channel is assigned from userspace. In this scenario rx_channel may not be having a valid pointer hence fetch the target operating channel to avoid warnings as below which can be triggered by the commands with DFS testing over longer run

comamnds:
iw wlan1 set type mesh
ifconfig wlan1 up (valid tgt_oper_chan only)
iw wlan1 cac trigger freq 5260 HT20 (valid rx_channel, tgt_oper_chan) iw wlan1 cac trigger freq 5280 HT20
iw wlan1 cac trigger freq 5300 HT20

Once the CAC expires, current channel context will be removed and we are only left with the fallback option of using 'target operating channel'

Firmware and driver log:
ath: phy1: DFS: radar found on freq=5300: id=1, pri=1125, count=5, count_false=4
ath: phy1: DFS: radar found on freq=5260: id=5, pri=3151, count=6, count_false=11
ath: phy1: DFS: radar found on freq=5280: id=1, pri=1351, count=6, count_false=4
ath: phy1: DFS: radar found on freq=5300: id=1, pri=1125, count=5, count_false=4
ath10k_pci 0001:01:00.0: failed to derive channel for radar pulse, treating as radar
ath10k_pci 0001:01:00.0: failed to derive channel for radar pulse, treating as radar

Call trace:

WARNING: CPU: 1 PID: 2145 at
backports-20161201-3.14.77-9ab3068/net/wireless/chan.c:265
cfg80211_set_dfs_state+0x3c/0x88 [cfg80211]()

 Workqueue: phy1 ieee80211_dfs_radar_detected_work

[mac80211]
[<c0320770>] (warn_slowpath_null) from [<bf79b90c>] (cfg80211_set_dfs_state+0x3c/0x88 [cfg80211])
[<bf79b90c>] (cfg80211_set_dfs_state [cfg80211]) from [<bf79697c>] (cfg80211_radar_event+0xc4/0x140 [cfg80211]) [<bf79697c>] (cfg80211_radar_event [cfg80211]) from [<bf83c058>] (ieee80211_dfs_radar_detected_work+0xa8/0xb4 [mac80211]) [<bf83c058>] (ieee80211_dfs_radar_detected_work [mac80211]) from [<c0339518>] (process_one_work+0x298/0x4a4)

---
 drivers/net/wireless/ath/ath10k/wmi.c |    5 +++++
 1 file changed, 5 insertions(+)

@@ -3638,6 +3638,11 @@ static void ath10k_dfs_radar_report(stru
 
 	spin_lock_bh(&ar->data_lock);
 	ch = ar->rx_channel;
+
+	/* fetch target operating channel during channel change */
+	if (!ch)
+		ch = ar->tgt_oper_chan;
+
 	spin_unlock_bh(&ar->data_lock);
 
 	if (!ch) {

Patches currently in stable-queue which might be from [email protected] are

queue-4.9/ath10k-fix-fetching-channel-during-potential-radar-detection.patch queue-4.9/ath10k-fix-compile-time-sanity-check-for-ce4-buffer-size.patch queue-4.9/ath10k-fix-a-warning-during-channel-switch-with-multiple-vaps.patch queue-4.9/ath10k-disallow-dfs-simulation-if-dfs-channel-is-not-enabled.patch