TWT is allowed only in DBS/Standalone case and not in SCC/MCC.
Handle TWT if any session request comes in SCC/MCC or DBS case
as per below:
1. If TWT session request comes on standalone SAP then peer
client will initiate the session and not from userspace
(SAP DUT)
a. Send twt responder enable command and
b. Send twt requestor disable command to firmware
2. If session request comes on standalone STA then
a. Send twt requestor enable command and
b. Send twt responder disable command to firmware
3. If two vdevs are up and SCC/MCC exist
a. Send beacon template with twt responder disable command to
SAP vdev
b. Send twt requestor disable command to STA vdev
4. If two vdevs are up in case of DBS
a. Send requestor enable command for STA vdev
b. Send beacon template with responder enable command for SAP
vdev
5. If 3 port concurrency comes then
a. Send requestor disable command to STA vdev and
b. Send beacon template with responder disable command to SAP
vdev
Change-Id: I65994702bb72d5006bd66b2ef57a0704a67410f7
CRs-Fixed: 2938961
In any start BSS or ACS related function, change the calls to regulatory
to access the secondary channel list instead. This list will hold the
VLP channels specifically for any beaconing modes. This allows a client
and an AP to operate simultaneously on different power modes.
Change-Id: Ic06b408ebcc78292d84f1f035c00bf39a23de3ca
CRs-fixed: 2944484
At present LTE unsafe channel switch and DCS is using
hdd_switch_sap_channel to switch channel of SAP.
hdd_switch_sap_channel has no bw setting parameters and just
use the original bw of SAP - ch_width_orig. The ch_width_orig
(80Mhz) may not be applicable if SAP is channel switching from
5G 80Mhz to 2G. Use the new API wlan_get_ap_prefer_conc_ch_params
to override the bw to appropriate value for the new channel.
Change-Id: I9ab6c92a0534517c524bd56b0c3087d7f75f6368
CRs-Fixed: 2939654
Merge the bandwidth selection of the two API
wlansap_get_csa_chanwidth_from_phymode &
wlan_sap_get_concurrent.
Update 5G Force SCC target Max BW selection for dbs hw:
1. Max BW 80Mhz if sta_sap_scc_on_dfs_chan = 1 and Single SAP
2. Max BW 80Mhz if sta_sap_scc_on_dfs_chan = 0 and STA+SAP SCC
3. other case use User configured BW
The above Max BW value will be limited by SAP user configured
BW at the end.
Change-Id: I1b165d1411288ca6845f90103adbf8bbfc34f67d
CRs-Fixed: 2925750
As part of 320MHz bandwidth support for 11BE, add 320MHz
bandwidth conversion used internally in policy manager.
Change-Id: I25cf3e171249ae6c45988d3d9cdd5225a2000178
CRs-Fixed: 2934783
When starting SAP, the AP power type is decided based on certain
conditions. After turning off the SAP, the power type is no longer
valid, so reset it back to default.
Change-Id: I472da2e02b58017dab4855fc83cd4e15b24b7b08
CRs-fixed: 2934622
In case of STA + STA or STA + P2P CLIENT concurrency
in MCC, no need to update the beacon interval while
processing connection on the second interface.
Currently, the driver only bypass beacon interval
validation for P2P CLIENT connection in case of
STA + P2P CLIENT concurrency in MCC.
Fix is to bypass beacon interval validation for the
second sta connection so that connection can happen
in MCC for STA + STA.
Change-Id: I4c3f8b1ed0b22f809a291eb88dfd95255cebe5e2
CRs-Fixed: 2934503
If there is more than one STA iface concurrently active
and one of them is marked as a primary iface. The host
received CONCURRENT_DUAL_STA_POLICY vendor command with
policy PREFER_PRIMARY. Then Don’t consider PCL weightage
for an STA connection. Due to this host/fw allows a new
connection either in DBS, SCC or in MCC.
Change-Id: I400165f8dd3ab7b94b2cb808f8b34b34d6d42fee
CRs-Fixed: 2929015
In the validate beacon interval logic, there are a few calls to get the
vdev MLME object from the interface manager component. However,
the component does not have a vdev object, so get it from the MLME
component instead.
Change-Id: I7333edeb6f1f0d5669605fe9e3d4fb10745d1fa4
CRs-fixed: 2928798
When starting SAP, If 11be IE is configured from userspace,
driver need check concurrency, update phymode as 11be and notify mlo mgr.
Change-Id: I22fdec5d978c91a8fc292af49462f045922254ae
CRs-Fixed: 2908938
Add support to reject TWT setup request if received when the below
mentioned concurrency scenario exists.
STA + SAP: SCC or MCC: Reject TWT setup
STA + P2P: SCC or MCC: Reject TWT setup
Change-Id: I5c4c2bcc032276a0b83b7a46a44dbf7933cda29f
CRs-Fixed: 2923726
Previously, the hw mode changing is not allowed when SAP is CAC
state in old target which supports 1x1 dbs. The reason is
some action frame would be sent out when chainmask changes in
those target. But for 2x2 dbs target, chainmask is not changed
and hence not action frame will be sent out.
Allow the hw mode change for 2x2 dbs target when SAP is CAC.
Change-Id: I2d123a7f0065a562048584f56d5dd7640aaaf975
CRs-Fixed: 2892813
Currently, P2P mode is not supported in 6GHz mode
Add P2P mode in policy_mgr_is_6ghz_conc_mode_supported
API to support P2P mode in 6GHz mode as fix this.
Change-Id: I2e160641c1784dbbd592b237da6b38929f33abbe
CRs-Fixed: 2896291
If DFS master capability disabled, STA+SAP SCC on DFS is not allowed,
so reset g_sta_sap_scc_on_dfs_chan to 0.
Change-Id: I90b0ec6947f5bc24c9854062f443de0d1f6dc452
CRs-Fixed: 2897719
Currently, vdev_id 0 is chosen as default vdev_id in
opportunistic_timer_handler when none of the vdevs are started.
The same is used to send set_hw_mode command. But vdev_id 0 might
not be valid all the time and set_hw_mode command fails in
serialization module in such cases.
Below is one possible scenario,
1. Load the driver. p2p0 gets vdev_id 0 and wlan0 gets vdev_id 1
2. Enable NAN and create two NDIs. p2p0 interface(vdev_id-0) will
be deleted by userspace as part of this.
3. Disable NAN and remove the NDIs. It triggers opportunistic_timer
but hw_mode won't be set to SMM as the vdev corresponds to
vdev_id-0 doesn't exist.
So, choose a valid vdev_id(mostly belong to STA/NAN) as default
vdev_id.
Change-Id: I19bd00a07cb2c818af9ed5021b0ae0aca8c49f2f
CRs-Fixed: 2889404
Remove g_prefer_5g_scc_to_dbs, and update PCL table
pm_second_connection_pcl_dbs_2x2_table.
For STA + GO concurrency if the second connection is GO,
perfer SCC to DBS, which makes GO get high throughput.
Change-Id: I0bf68662fc363a66c778904f9c12714407cd738a
CRs-Fixed: 2881383
Currently the preferred channel list is not updated to have indoor only
channels removed. Add functionality to remove the indoor channels from
the PCL.
Change-Id: I31df737a3688f6c64c2eb5fa5ab0cea1d36869e5
CRs-fixed: 2874092
Move the beacon interval validation logic from the CSR module to the
interface manager module.
Add a path to send events to the SAP event handler from the MLME
module.
Change-Id: Ia86f219b3f209b53e7818a80f95b2c0555550736
CRs-fixed: 2796676
SAP stops working when it comes first and then sta connection
happens in non dbs HW mode
Allow SAP on non dbs HW even if the channel is safe or
lte-coex enabled.
Change-Id: I3e80b423ccb30fdb5e53a6d2aff961162b316e1c
CRs-Fixed: 2873957
This reverts change:I9408713fcf828d24688ecc45290d8c90a8d54c22
as it's not needed anymore as the actual issue(commands waiting
in active queue for response when the vdev is deleted) is fixed
with change:Ie31936132a389685ff4ff55b43ccbb4102e65830.
This wait-for-response causes a delay of around 200ms in
vdev_create as it's a blocking call.
As vdev_create happens after finding the peer device in case of
p2p, overall connection is delayed and connection time has
increased from 350ms to 600ms. This effects the
uses cases like WFD where applications have strict timing
constraints after finding the device.
Change-Id: I45c223a8d157892d8ec64b04f68cfbf39d732833
CRs-Fixed: 2870774
According to new requirement, when SAP manadatory channel list
enabled (gWlanMccToSccSwitchMode = 4,
gEnableSAPManadatoryChanList=1), the SAP will only be started on
PSC and VLP channels on 6Ghz band. Add all 6GHz PSC & VLP channels
to SAP mandatory list.
Change-Id: I00514c0af9c1cc07460120c928ced652aa2e8d4e
CRs-Fixed: 2870590
When SAP operated in channel 36 with 160Mhz, the primary channel
36 is non-dfs and existing checking dfs will drop the radar event
if the radar detected on channel 52. Change policy mgr API to
check the dfs flags instead of primary channel state.
Change-Id: Ie2f242182b8df30e5d1875e278c5ebffa2e7cafd
CRs-Fixed: 2865173
Use wlan_reg_get_channel_state_for_freq to get channel state
instead of wlan_reg_get_channel_state.
Change-Id: I0ab0465458801747cc97bf03b3aee4ec255beb57
CRs-Fixed: 2859852
Currently, host driver rejects any concurrent session with other
security modes(e.g. NAN) when WAPI is present. This is due to a
limitation on older platforms. But newer platforms(e.g. Lithium
architecture) support WAPI+other security modes concurrently.
Firmware advertises service capability WAPI_CONCURRENCY_SUPPORTED if it
supports other security modes when WAPI is active. Get the capability
and accept/reject concurrent sessions.
Change-Id: I0e004e1220afd9c42869589364606c9f729798f7
CRs-Fixed: 2844799
cm id is not passed to policy manager in case of DBS donwgrade
when NSS is modified, pass the cm id to fix it.
Change-Id: Ie038b30929c2fcddb6828f1f89765d3004ff3285
CRs-Fixed: 2860061
When a new connection is about to come up, host checks if current
concurrency combination including the new connection is allowed or
not based on the HW capability.
Firmware manages NAN + NDI by dividing up slots. Connection on NDI
is re-negotiable and therefore a 3rd connection with the same MAC
is possible.
Change-Id: I63e39c5cd4945cd308e475c1e03f676336c4e7c1
CRs-Fixed: 2841457
Currently host checks mac number to indicate
MCC or DBS which may not be correct. Host
may print DBS in case of MCC.
Check DBS support and print concurrency
based on hw mode if hw mode is dbs capable
then print DBS else MCC.
Change-Id: I1578e6a7a6b73b5b6c409653b4dc276954f51c3d
CRs-Fixed: 2845634
Acquire connection list lock in policy mgr before update the
entry. The "conn_index" maybe changed for a connection entry
if other connection is up or down.
Fix by acquire connection to protect the whole "update" operation.
Change-Id: I91e82e74884ef32e83e0c4105e88bafe8d99db3d
CRs-Fixed: 2848209
In the customer platform, the chain0 for 2.4G is disabled,
it just only support 1x1 2.4G + 2x2 5G for hasting. With
such kind of configuration, 2.4G SAP start failure due to
policy_mgr_is_hw_dbs_required_for_band return false with
following config, which block switching hw mode from single
mac(single mac just only support 5G) to dual mac and then
make start 2.4G SAP failure on single mac configuration
[0]-MAC0: tx_ss:2 rx_ss:2 bw_idx:5 band_cap:2
[0]-MAC1: tx_ss:0 rx_ss:0 bw_idx:0
[0] DBS:0 SBS:0 hw_mode_id:0
[1]-MAC0: tx_ss:2 rx_ss:2 bw_idx:5 band_cap:2
[1]-MAC1: tx_ss:1 rx_ss:1 bw_idx:4
[1] DBS:1 SBS:0 hw_mode_id:1
Change-Id: If9e76fb47743c32c313eacf150146ba8fa60eb2d
CRs-Fixed: 2833620
Currently, STA reconnect (e.g. reconnect to same BSSID) is handled
as STA+STA as part of NAN concurrency checks. This results in NAN
disable when reconnect is issued.
Check if the current incoming connection is on same vdev as
previous sta connection instance and disable NAN only if it's
different.
Handle NAN+SAP reenable in similar way.
Also, remove the redundant usage of NDI cleanup API
ucfg_nan_check_and_disable_unsupported_ndi in
if_mgr_connect_start.
Change-Id: Ia063a69bb2efdf1d51c6988b8905ceac0f454dab
CRs-Fixed: 2821352
Previously, if force SCC is enabled and Standalone SAP starts
on non-DFS channel, it starts with master mode Disable. If it
is switched to DFS channel it will switch without CAC.
As a fix, if SAP is started on non-DFS channel with force SCC,
don't allow it to switch to DFS channel if master mode is disabled.
Change-Id: I1822f67a5480d6c16fa980c9c6b262341af7c2de
CRs-Fixed: 2827237
At present when user trigger SAP move to unsafe channel,
driver doesn't reject the request since "strict = false"
and unsafe checking is skipped.
Fix by check SAP channel switch target channel safe or
unsafe with API policy_mgr_is_sap_freq_allowed before
perform channel switch.
Change-Id: I2950fb31346df8705c8fc608fd79e1a44f4d4947
CRs-Fixed: 2826619
Stop/Reject SAP connection if STA is/comes up
on a 6ghz freq and SAP is not capable of 6ghz
freq to avoid MCC situation in a non-DBS capable
HW.
Fix is to stop/reject the SAP startup in above
mentioned case.
Change-Id: I451c95929f378cd0790bd5fc647235fc2dd0071a
CRs-Fixed: 2818030
Currently the driver uses the API
policy_mgr_is_dbs_enable to check
whether the DBS is enable or not which
does not check the service capability of
DBS, and thus would return true if ini
and FW HW modes contain DBS. In this case
if STA is on 5ghz and SAP comes on 2.4ghz
then force SCC would not happen as the
driver would consider the HW to be DBS
capable which actually is not, and thus
the overall concurrency would be MCC which
is not favourable.
Fix is to use policy_mgr_is_hw_dbs_capable
API instead of DBS enable API which checks
for the service bit also, so that the driver
forces SAP to STA's channel.
Change-Id: I9319293ecfb54fe3e1ad0eaff15542c671514bf4
CRs-Fixed: 2820377
Currently the driver checks whether hw is
already in DBS in the function
policy_mgr_check_and_set_hw_mode_for_channel_switch
and it does not set hw mode if it is already
in DBS mode. It can happen that SMM is already
requested and is present in serialization and it
would change the HW mode from DBS->SMM and if
driver starts any vdev on 2.4ghz in HST/HSP
which requires the DBS mode for 2.4ghz , the FW
would send a vdev start failure.
Fix is to remove the check of current hw mode and
let DBS be posted to serialization. If hw mode is
already in DBS it would return from serialization
with E_ALREADY but would ensure that HW mode is
always in DBS for a 2.4ghz connection.
Change-Id: Ica660058175cb1edc2931dd2d28ee6cdd9bab2f4
CRs-Fixed: 2823238
Add a check for passive channels when checking the restricted
bands on SAP. This change blocks SAP from restarting on a passive
channel.
Implement the function to filter out passive channels from the PCL.
Change-Id: I80a4b78c1af77f5bfa68be3163f9e9a78cc6425a
CRs-fixed: 2817589
Modify connect start code in interface manager by
moving disable roam and tdls link teardown notify
APIs from HDD to if mgr. Alongside, move tdls link
teardown notify API from HDD to if mgr in start bss API.
Also, move the tdls link teardown API to TDLS module from
HDD module as TDLS should manage the wait logic.
Change-Id: I09fa31878563a3daaa7c5fde46327475829317b3
CRs-Fixed: 2811807
Add new ini "monitor_mode_concurrency" to support this feature
and introduce policy manager api's for concurrency checks.
Change-Id: I35ee1fece0a6f9ae8fe340b0598c4a3e20b17e82
CRs-Fixed: 2814523
Check the factors as below to decide whether the channel is
allowed or not:
* If the channel is in LTE coex channel avoidance list;
* If it's STA+SAP SCC;
* If STA+SAP SCC on LTE coex channel is allowed.
Replace policy_mgr_is_safe_channel() with this new function
for sap channel selection and acs channel filtering, to allow
unsafe channels when it's STA+SAP SCC and STA+SAP SCC on LTE
coex channel is allowed.
CRs-Fixed: 2743042
Change-Id: Ic5a84b2628200fe9decf6972f00706f190f04722
Add check in function 'policy_mgr_get_sbs_channels' to restrict the
array index out of bounds.
Change-Id: I387b666095107faf284e35f073dfe856d38323d3
CRs-Fixed: 2776966
Previously, if STA is connected to DFS channel and SAP starts on
Non-DBS HW, then it is forced to start on DFS channel with BW 160 Mhz
irrespective of BW on which STA is connected without CAC.
Even after STA disconnects, SAP remains on DFS channel with BW 160Mhz.
So, scan will be disabled and STA cannot be connected on any channel
other than DFS channel.
If STA is connected on non-DFS channel on 5 GHz and SAP starts, it
will start on non-DFS channel as primary channel with BW 160 Mhz
without CAC. Also, scanning was also allowed when SAP is started with
BW 160 Mhz. This might violate regulatory in case radar comes up while
scanning.
Standalone SAP on DFS channel was not allowed.
To fix this, Force set SCC for non-dbs HW, this way standalone SAP
can come on DFS channel but scan will be disabled in such case and
STA cannot be connected other than DFS channel.
In case STA gets connected to dfs channel in non-dbs HW, then sap
starts only on STA channel with force SCC with BW
MIN(sta_chan_width, CH_WIDTH_80MHZ).
Afterwards, if STA disconnects, restart the AP with BW CH_WIDTH_80MHZ
on safe channel. Scan will be allowed as the DFS master capability is
offloaded to AP with which STA is connected on DFS channel.
Also, if standalone sap starts, then STA connects to DFS channel then
SAP will restart with STA channel frequency and Channel width
MIN(sta_chan_width, 80MHZ).
If standalone SAP starts and then STA connects to non-dfs AP or SAP
starts when STA is already connected to non-DFS AP, then ch_width is
MAX(sta_chan_width, 80MHZ) (5 Ghz) or 20 Mhz (2.4 Ghz).
If STA disconnects during SAP+STA on non-DFS, SAP won't restart unless
the STA was connected on BW 160 Mhz.
Change-Id: I1cebfc79f170c1e4e2710ed747ec804df3d8b441
CRs-Fixed: 2809255
In DBS mode, gDualMacFeatureDisable can be 0, also can be
6: enable DBS for connection but disable simultaneous scan.
Change-Id: Ia3d46dbd2e67644e84436b90f40c203bc939eda7
CRs-Fixed: 2807010
In Interface manager, legacy roaming api's were used as roaming testing
was ongoing.Now testing is done so use converged roaming api's.
This will also resolve the KW warnings.
Change-Id: I9ef101e6ec02bb18c6f2f9a9fbdaa81dbe81f9a0
CRs-Fixed: 2798601
Currently, If hadware is not dbs capable opportunistic timer
can not be started. In function if_mgr_connect_complete
policy_mgr_check_n_start_opportunistic_timer fails to start
opportunistic timer in case of non-dbs hw and sap restart
doesn't happen.
Fix is not to validate status returned by
policy_mgr_check_n_start_opportunistic_timer to restart sap
in case of non-dbs hardware.
Change-Id: I3308a5c10341950d51419907cc767c09f967b7b1
CRs-Fixed: 2792764
