Currently PM_STA_SAP_24_STA_5_DBS is not added in fourth connection
pcl table, due to which pcl is becoming 0 in case of P2P on 2 GHZ doing
MCC/SCC with one STA 2 GHZ link and one STA link on 5 GHZ in DBS.
Fix is to make PM_STA_SAP_24_STA_5_DBS same as PM_24_SCC_MCC_PLUS_5_DBS,
so that next/fourth connection can come up on PM_SCC_ON_5_CH_5G.
Change-Id: I4b4c346a998c24ab090307982f1ef6da90bb507c
CRs-Fixed: 3225380
When MLO SAP is started with two different bands, the 2.4 GHz
link follows the 5GHz and restarts on the same channel
as 5 GHz link.
The user configured frequency for the SAP is cached on the
psoc, therefore during the concurrency check after bringing
up the second connection, 2.4 GHz link considers the new
user configured frequency of 5GHz link and moves to the same
channel.
Save the user configured frequency per vdev to prevent
cross-utilization.
Change-Id: I62f883bf818332bb7d0c838e6ed629a8f2d2f21b
CRs-Fixed: 3209394
Currently, vdev in link set active request is added
without any check whether it is ml sta vdev or not
due to which may cause issue of empty event for that
particular vdev when sap/p2p vdev is added instead of
ml sta vdev in request.
Fix is to add ml sta vdev in link set request to avoid
mismatch with fw link down and expected vdev down from
host to avoid empty event failure
Change-Id: If99b305c267f094913b8d9ce96a330eed47d0214
CRs-Fixed: 3221818
Link gets disabled when a secondary STA is connected and if it's
causing MCC with one of the links. Once the secondary STA is
disconnected, this link can be re-enabled.
Change-Id: I5b5f885c103d5fb5611c32422c26112b336c97ec
CRs-Fixed: 3219632
When an ML STA connection exists with more than one link and if
secondary STA connection happened, check if it's causing MCC.
Disable the link that is causing MCC with the new station.
Change-Id: If85da9dd778791c1a5d1a658b97942c5277c5429
CRs-Fixed: 3219631
Add handling to disable second vdev of mac if miracast
is set for one vdev. In case high throughput or low latency
is required for particular vdev then another vdev on same
mac should be disabled, if present in MCC.
Change-Id: I36cc19f442130b098c4a02ec0ebcf69b89dd2a3c
CRs-Fixed: 3219512
Add support to handle 2 sap and 1 ml sta link.
Currently, get pcl fails for fourth connection when
2 sap link and 1 ml sta link is present due to which
fourth connection is not allowed as pcl len is becoming 0.
Fix is to add handling for fourth connection when existing
concurrency is P2P/SAP + P2P+SAP + 1 ML STA link.
Change-Id: Ief969018da14096f758fea4bd06d17e7e8d039b7
CRs-Fixed: 3219328
Add support to dump concurrency for four
vdevs with mode, vdev id , hw mode and
mac details on which vdevs are in MCC/SCC.
Change-Id: If4c1622770b0e787f5f3de54a3ca92b35a0e1873
CRs-Fixed: 3218170
New PCL PCL PM_SBS_CH_2G,PM_SCC_ON_5G_LOW_5G_LOW,
PM_SCC_ON_5G_HIGH_5G_HIGH do not allow 3 home channel
scenario. Remove it from API
policy_mgr_is_3rd_conn_on_same_band_allowed.
Add PCL string print support for new type:
PM_SCC_ON_5G_LOW_5G_LOW, PM_SCC_ON_5G_HIGH_5G_HIGH.
Change-Id: Ie6dbb042f5ecb04cb999a7949ced8e7c7ab4ad5a
CRs-Fixed: 3215568
Add eMLSR HW mode support for ML STA. eMLSR mode
(Enhanced Multi-link Single-Radio) is a new HW mode within 802.11be
op mode. This change consists of the following
1) Handle the new eMLSR HW mode. FW sends this capability to host via
extended service ready event.
2) If FW supports this mode, then update the eMLSR capability sub-fields
in the Basic-variant MLO IE under the assoc request frame.
3) Provide peer info like eMLSR capability, transition timeout, and link
IDs to FW through WMI_PEER_ASSOC_CMDID.
Change-Id: Idc00f5f780b5617e513f307952b58277669dee85
CRs-Fixed: 3184708
Currently, deleted connections are not restored if current connection count
is geater than or equal to max no of allowed connection - no of deleted
connection which may cause issue when there are 4 connections and 2 ML sta
link got deleted temporarily for getting pcl list. As max no of connection
allowed are 4, deleted sta links should be restored. In check to restore
the deleted link comparison is done with < max no connection, so deleted
connections are not restored.
Fix is to add a check that current connection count + deleted connection
count should be less than or equal to MAX_NUMBER_OF_CONC_CONNECTIONS.
Change-Id: Ia21235ffb4d5ecc3500001f215bab5a3c48de90a
CRs-Fixed: 3216952
This is about SAP+SAP+STA case. Restart third SAP failed after start
up and then 5/6 GHz disabled. This change allows SAP+SAP+STA SCC on
same mac and avoid third SAP restart fail.
Change-Id: I691b2e03132acfb8f724fc2f75b3816d17eb4d17
CRs-Fixed: 3198977
Currently locally generated vdev_id is passed to update
concurrency like to re-enable disabled sta link on one
p2p/sap down or handle concurrency on one ml sta link
down. This locally generated vdev id will be invalid/255
in case mode is non-sta, so hanlding will be done for non-sta
link down only.
Fix is to change vdev_id to session_id, so that session which
is deceremented due to session down can be provided and concurrency
handling can be done based on that.
Change-Id: Iaca9a339abbab3f5dab01e2224c3acd87df5bc0a
CRs-Fixed: 3212661
Currently if SCC frequencies are added in pcl list and
rest 5GHz frequencies are required to be added with lesser
weightage then all 5GHz/6GHz frequencies are added including
SCC channels. so in pcl duplicate entries are found for SCC
frequencies with different weightage.
Fix is not to add SCC frequencies during addition of 5GHz/6GHz
frequencies if SCC frequencies are already present in pcl.
Change-Id: I03123e4bf8caee62b0fcd0c3ae78d6cd7187c7de
CRs-Fixed: 3209858
The dynamic GRO enable/disable based on ingress filters
should currently is restricted only to standalone STA.
This was done to address issue where ingress filters are
added on STA interface whenever SAP is up disabling GRO
unnecessarily.
Fix is to allow dynamic GRO to work on all interfaces
and concurrency scenarios based on the priority of
the ingress filter configured to avoid unnecessary
GRO disable in STA+SAP.
Change-Id: I1742f4539353939e3a40ff4096b3f833f2029b12
CRs-Fixed: 3206815
Currently if SAP is operating on 5GHz channel and if country change
happens to a world mode where SAP is not allowed on 5GHz channels so
SAP moves to a 2.4GHz channel and saves the current operating 5GHz
channel, now when again country change happens then SAP tries to
move to previous 5GHz channels, if SAP is not allowed on this 5GHz
channel in new country, SAP comes up on 2.4GHz channel.
Ideally SAP should come up on some other valid 5GHz channel instead
of 2.4GHz channel.
This scenario is possible for 6GHz channel as well.
To address above issue, add a fix to get first valid same band channel
if previous same band channel is not valid channel.
Change-Id: I39dc297846c838731a70cd01d696bcbd8a054970
CRs-Fixed: 3175740
SAP is allowed to come up on SCC with a STA operating
in 6GHz only if the STA is on a PSC channel in VLP mode.
Therefore, filter out all 6GHz channels from the PCL if
the STA operates on any non-VLP mode. Also, in case of
VLP mode, filter out non-PSC channels.
Change-Id: I37d9a510db3647fc07858af99eb614ebe824cc78
CRs-Fixed: 3206471
Sta is not allowed to connect/roam in 6 GHz frequency or indoor
frequency in non-DBS target if SAP is active.
But STA roams to 6 GHz AP when SAP is active since the PCL allows
6 GHz frequency.
While populating PCL to firmware, check if 6 GHz and indoor
frequencies are allowed for non-dbs target and set the
weight appropriately if the channels are not allowed
Change-Id: I0e5fdc5b3c4177283d91cdfc58359336cc11910d
CRs-Fixed: 3205494
When STA is connected to non-dfs, non-indoor channel and
SAP starts second with mandatory channel list enabled,
then SAP is moving to 2.4Ghz. But SAP should follow sta
and move to non-indoor, non-dfs channel.
Also when STA is connected on DFS channel and when SAP
is coming up with g_enable_sta_sap_scc_on_dfs_chan,
then SAP also should move to DFS channel
So when PCL channels are filtered based on mandatory
channel list, then allow dfs/indoor channels based on
concurrent STA frequency.
Change-Id: I2bcb81a8b014108b07db36a31d03d0a16fe49eb9
CRs-Fixed: 3207750
Add log to check which mode, vdev and freq is
added as disabled ml link and dump disabled
links after moving vdev from connection table
to disabled link table and decrement session
count only if provided vdev entry is present
in connection table.
Change-Id: I19cd9323b7b66b29366f2ac930798da8ef91a709
CRs-Fixed: 3205975
In SAP+GO concurrency, if GO is started on 2.4 GHz and SAP is
doing ACS with 2.4 GHz preferred channel list, then we will
move GO to 5 GHz band. The purpose is to have more choice
in SAP ACS instead of starting on GO home channel for SCC.
Add API hdd_handle_acs_2g_preferred_sap_conc for such
purpose.
Change-Id: I6f2b4bab526c7e1c9163b8437c40350d3bf10bab
CRs-Fixed: 3181419
When SAP and GO home channels are in MCC in same band,
implement below requirement to avoid MCC:
1. SAP starts at first and GO starts later, then SAP will
force SCC to GO's home channel after GO starts up.
2. GO starts at first and SAP starts later, then SAP will
force SCC to GO's home channel during starting up.
3. SAP and GO SCC in same band, SAP changes channel to
the other channel in same band, GO will follow SAP and
move to SAP home channel.
4. SAP and GO SCC in same band, GO changes channel to the
other channel in same band, SAP will follow GO and move
to GO home channel.
And all the force SCC cases, if the target channel of force
SCC is not supported by the SAP or GO, then driver will
select other band's channel for the interface.
Change-Id: I7b24f3a972a401fd144a0c81dc19bd48ba224d85
CRs-Fixed: 3176087
Currently in case of SBS, if two connections are on one mac and
one connection is on another mac new connection can come up only
on 5 GHZ Low/5 GHZ high based on the mac that can support new connection.
But weightage of all 5 GHZ low/high channel is marked same instead of
prioritizing SCC channel.
Fix is to provide more weightage to 5 GHZ low/high SCC channel than
rest 5 GHZ low/high channels.
Also Optimize few logs.
Change-Id: I4153b209e6a74fe79081116baecaae78be5b632b
CRs-Fixed: 3204041
Add API policy_mgr_check_force_scc_three_connection
to select force SCC channel for 3 vifs existing case in
policy_mgr_check_scc_sbs_channel.
Change-Id: Ie092c15164939306a8723038f6418ab722314f7c
CRs-Fixed: 3178588
Add logic to disable a link vdev if concurrency doesn't allow it.
Send mlo_force_link_inactive in peer assoc for this and add
it in deleted table on connection complete.
Also disable the link if roam sync indication indicate
that link is disabled.
Change-Id: Ib0615308a669a5fd9d2b8ef6f8ab3f50953f658d
CRs-Fixed: 3192728
Call enable/disable link APIs from connect/disconnect/roam etc.
Cleanup policy_mgr_handle_sap_mlo_sta_concurrency and
policy_mgr_handle_sap_plus_ml_sta_connect API as
policy_mgr_handle_sap_cli_go_ml_sta_up_csa and
policy_mgr_re_enable_ml_sta_on_p2p_sap_down will take care of
ML STA + SAP/P2P cases.
Also optimize policy_mgr_handle_ml_sta_link_concurrency to consider
only ML STA+STA cases and called from connect/disconnect/roam etc.
Change-Id: Ib8b9b2a490832ea5cbe1d86e58009e1437b331b9
CRs-Fixed: 3189685
Add logic to enable and disable number of STA ML link, on vdev UP
and DOWN, if any link is causing MCC with exiting
SAP/P2P and SAP/P2P with traffic type as low latency or high tput.
Change-Id: Id599acf5a07042328917b5e15f077d2decc0ad5f
CRs-Fixed: 3189304
Add disabled links table and APIs to move and remove
vdevs from disabled links table.
Change-Id: I610bbd10e387a4bcd3a5d5c88c3dba5698878441
CRs-Fixed: 3181474
Add PCL handling for ML STA + P2P + P2P concurrencies,
based on current hw mode (SBS/DBS/SMM).
Change-Id: I337b12a0c03ab89968572056f27f47a6b9392803
CRs-Fixed: 3177305
To make the active connections number configurable, based on
host configuration of INI gMaxConcurrentActiveSessions
host sets the num_max_active_vdevs in WMI init command to notify
the FW the number of active connections host expects to support.
FW will report the actual supported number in wmi ready event.
Policy mgr will record the FW supported number if FW number is
smaller than host requested.
Change-Id: I454c0cdde6be1e8a627f8fff08b6c7b2141b00f6
CRs-Fixed: 3183006
Keep SCC channels in the PCL list, if SCC is allowed on those
frequencies.Do not remove these frequencies, if the
mandatory channel list doesn't have the SCC frequencies.
Also, whenever the user configured frequency of the SAP is
different following a STA disconnect, switch it back to the
home channel.
Change-Id: Ia5fe8943136791084de02a2d3a8ff250008978be
CRs-Fixed: 3196278
During full scan only 2.4Ghz channels are printed.
Along with 2.4Ghz channels print 5Ghz channels.
so, use policy_mgr_get_connected_roaming_vdev_band_mask()
instead of policy_mgr_get_connected_vdev_band_mask()
After Roam result candidate or currently connected
AP bssid is not printed. so, printed candidate or
currently connected AP bssid by changing logic
Change-Id: I800ebdc033480b93150bdeb00a900c373ba333dc
CRs-Fixed: 3185092
Currently STA can scan and come up on 6Ghz or 5Ghz indoor channel
if hardware is non-dbs and SAP is present
As part of this change, do not allow STA to connect on 6Ghz and
5Ghz indoor channel for non-dbs hardware if SAP is present
Change-Id: I48ed8483225e35d8b898b0325eee398f74e41c97
CRs-Fixed: 3196247
QCN7605 HW DBS mode have two index. If DBS freq range fill two
index info, function policy_mgr_are_2_freq_on_same_mac will
not return correctly. So only fill DBS freq range when no freq
info are filled.
Change-Id: I4a8b6dbd470db3f3ecc40746abbb02d81272c74b
CRs-Fixed: 3161847
Based on the ini "sta_sap_scc_on_indoor_chan" the behavior of
STA+SAP in scc is as follows:
1. STA is on 2.4 GHz & SAP is on 2.4 GHz and SAP user configured
initial channel was on 5 GHz, then move SAP to 5 GHz initially
started channel
2. When STA + SAP are doing SCC on indoor only channel and
a) STA moves to 2.4 GHz -> then SAP moves to initialy started
channel
b) STA moves to another indoor only channel -> SAP follows
STA channel
c) STA moves to non-indoor, non-dfs channel -> SAP follows
STA channel.
d) STA moves to DFS channel -> SAP moves to 2.4 GHz channel
e) STA disconnects -> Move SAP to initially started channel
3. STA is on 2.4 GHz & SAP is on 5 GHz non-indoor, non-dfs channel
and STA moves to 5 GHz channel, then SAP should follow STA to 5 GHz
if SAP was initially started on 5 GHz channel. Else SAP restart
is not required and SAP will remain on the 2.4 GHz channel
Change-Id: I655dffff026d8147e13599dddc024980ba157be5
CRs-Fixed: 3186965
Refine the logic in API policy_mgr_valid_sap_conc_channel_check
to support 3 or 4 Vif concurrency case.
If the force SCC result is not suitable for the SAP to start up
for some reason, the API will select an alternate channel for
the SAP. The limitations includes LTE unsafe limitation, 6 GHz
non-support limitation, DFS STA AP concurrency limitation.
Change-Id: Ifd9cbecce697a885ba502b91340502d3e10c2d88
CRs-Fixed: 3176126
With MLO sta change, when WLAN_FEATURE_11BE_MLO is undefined, non mlo sta
index array is got wrongly, sta+sta dbs check based on it is wrong too,
and policy_mgr_concurrent_sta_doing_dbs always return false, then
2nd STA RSO is failed to enable, vdev level pcl isn't configured too, 1st
STA can roam to all band.
Change-Id: Iaa728222ab4835099899b463285be4fe2de58ea2
CRs-Fixed: 3192971
Add new ini for STA-SAP scc on 5 GHz indoor only channel -
"sta_sap_scc_on_indoor_chan"
When this ini is enabled, SAP moves to the STA channel
when STA is connected on indoor only 5 GHz channel with the
AP. When this ini is disabled, SAP moves to any 2.4 GHz
channel.
When gindoor_channel_support=1, this ini will not be considered and
SAP can come up on indoor channel.
Change-Id: Ia3ebc6d7fc2e6e569cde8e8a8b38ca76036b8fda
CRs-Fixed: 3186938
SAE authentication logging events are sent from host
driver during connection as well as during roaming.
But the other roaming frame related stats are printed
as part of the WMI_ROAM_STATS_EVENTID handling.
Since this roam stats event is received after preauth
frame related logs are queued to userspace, the order
of the logs are not correct.
Cache the SAE preauth logs in mlme and print them
upon receiving ROAM stats event. Read the firmware
service capability to decide if new caching needs
to be used or legacy behavior needs to be followed
Change-Id: I76381b9deef222f1481325974e2b5d9730eb2b67
CRs-Fixed: 3154147
If there are 3 or more 5/6Ghz SCC freq, avoid filling SBS freq in
PCL as due to 3 home freq limitation, 3rd freq will always be
leading to SBS.
So add SBS freqs in PCL, only if number of SCC are 1 OR 2 with 5Ghz
MCC/SCC.
Change-Id: Ib97589df50bbacafa56766dd4b8af6d9f5d1419b
CRs-Fixed: 3178339
Update doc for SBS related pcl_channel_order to make
it more clear and add doc for new pcl types.
Change-Id: I3635cc664f9a004a07956d88d7d95b02e14947a3
CRs-Fixed: 3178476
Before enabling FW features via wext or vendor command, first
sanity check if the feature is supported or not.
Change-Id: I2bb1c61a717be39185aee580085952adcc70ef8f
CRs-Fixed: 3171698
In GO+SAP Case, SAP starts firstly, GO starts on same band
but different channel. SAP forces SCC check is done in
hdd_hostapd_sap_event_cb in the event handle of eSAP_START_BSS_EVENT.
But at the time the GO's connection entry is not added to
policy mgr list. It is added after WLAN_IF_MGR_EV_AP_START_BSS_COMPLETE
is received by SAP interface manager. SAP can't find the same
band GO's channel at this time.
Fix by move the SAP forces SCC check in SAP interface manager
after WLAN_IF_MGR_EV_AP_START_BSS_COMPLETE event is received.
Change-Id: I54663bdd887e3d591d7fd9ee7ce76572b1ef21f7
CRs-Fixed: 3176076
Allow SAP and P2P GO mode MCC in same band if
wmi_service_dual_beacon_on_single_mac_mcc_support is
supported.
Change-Id: I228916df7166c9eddb829e423222da7803e3c7d2
CRs-Fixed: 3176081
Add Support for four port concurrency support for ML
sta + p2p + p2p. PCL will be same for SAP, P2P GO and
P2P CLI, so only SAP is considered in naming convention
to avoid repetitive handling.
Change-Id: Ie66407fd79f4e7b51271da8146c681dbf303810e
CRs-Fixed: 3177300
PCL for next connection is same in case of existing
concuurency is 3 port with 2 connections (one sta & sap)on
5G MCC or SCC and another STA on 2G. similarly pcl will
be same for 2 connections (one sta & sap)on
2.4G MCC or SCC and another STA on 5G.So, PM_STA_SAP_SCC_5_STA_24_DBS
can be renamed to PM_STA_SAP_24_STA_5_DBS and PM_STA_SAP_SCC_24_STA_5_DBS
to PM_STA_SAP_24_STA_5_DBS to avoid separate handling for SCC/MCC.
Change-Id: I5eeb809d49586b936f214c87defe6c0790d9829c
CRs-Fixed: 3170092
Add PM_SCC_ON_5_CH_5G pcl type to give priority
to SCC 5G followed by rest 5G channels for next
connection.
Change-Id: Ibff48dcd145368d967fb9f39c0118f94897a72a4
CRs-Fixed: 3170031
