From a3e5e0b538c290e6315b956341b3024c05cd74fe Mon Sep 17 00:00:00 2001 From: Kiran Kumar Lokere Date: Tue, 3 Nov 2015 14:17:26 -0800 Subject: [PATCH] qcacld-3.0: do not process HT IE change if RoC is in progress qcacld-2.0 to qcacld-3.0 propagation. Ignore HT IE change if RoC is in progress because as part of HT IE change we will try to change the channel parameters which use the same callback as RoC. So if we try to change the channel parameters if RoC is in progress we will overwrite the callback causing problems in the upper layers which are expecting a notification. Change-Id: I6bace6dd2bd40728ece94e3efe59f3e7038a4e6a CRs-Fixed: 710027 --- core/mac/src/pe/lim/lim_utils.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/core/mac/src/pe/lim/lim_utils.c b/core/mac/src/pe/lim/lim_utils.c index 4952804d9d2a..f11b3873c2a9 100644 --- a/core/mac/src/pe/lim/lim_utils.c +++ b/core/mac/src/pe/lim/lim_utils.c @@ -4918,6 +4918,20 @@ void lim_update_sta_run_time_ht_switch_chnl_params(tpAniSirGlobal pMac, return; } + /* + * Do not try to switch channel if RoC is in progress. RoC code path + * uses pMac->lim.gpLimRemainOnChanReq to notify the upper layers that + * the device has started listening on the channel requested as part of + * RoC, if we set pMac->lim.gpLimRemainOnChanReq to NULL as we do below + * then the upper layers will think that the channel change is not + * successful and the RoC from the upper layer perspective will never + * end... + */ + if (pMac->lim.gpLimRemainOnChanReq) { + lim_log(pMac, LOGE, FL("RoC is in progress")); + return; + } + if (psessionEntry->htSecondaryChannelOffset != (uint8_t) pHTInfo->secondaryChannelOffset || psessionEntry->htRecommendedTxWidthSet !=