summaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/sctop.py
diff options
context:
space:
mode:
authorSujith Manoharan <c_manoha@qca.qualcomm.com>2014-09-05 08:03:11 +0530
committerJohn W. Linville <linville@tuxdriver.com>2014-09-09 15:27:20 -0400
commit9bf30ff93dae035bb60ea2f3812e44ac79b31478 (patch)
treef0aba21c66818cbcc9f4c799aa73f02a95b41a0a /tools/perf/scripts/python/sctop.py
parent602607b6e7413e4f5b194bf28deb7195b0395486 (diff)
ath9k: Fix panic when adding an AP interface
If a station interface is already assigned to a context and is active and a second interface of type AP is added, then beaconing on the new interface has to be begin only after the BSS_CHANGED_BEACON_ENABLED flag is sent by mac80211 to the driver. But, since we issue ATH_CHANCTX_EVENT_ENABLE_MULTICHANNEL as soon as a new channel context is added, a switch occurs almost immediately before BSS_CHANGED_BEACON_ENABLED is received. When a HW reset is done for the new context, beacons are enabled for the interface since "enable_beacon" in the BSS config maintained in mac80211 is true - but the driver hasn't been notified yet. This causes a panic, since the beacon interval is zero for this interface and ath9k_cmn_beacon_config_ap() doesn't have a safety check. Fix this panic by checking if the beacon params has been cached for this context and use the "enable_beacon" flag maintained locally in the driver. Also, recalculate the summary data after the beacon params have been cached when BSS_CHANGED_BEACON_ENABLED is received. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Diffstat (limited to 'tools/perf/scripts/python/sctop.py')
0 files changed, 0 insertions, 0 deletions