From ec4bf277c7fb199c5acb8d8ee8791a7a51d099b2 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 !=