At present, 6 GHz allow check is not applicable to P2P GO interface
type in API hdd_get_ap_6 GHz_capable, thus start GO on 6 GHz failed.
Fix by call policy_mgr_is_6ghz_conc_mode_supported API to check
interface type support 6 GHz or not.
Change-Id: I96bda834e65d0e1fe7301ef695234df9088f50a6
CRs-Fixed: 3253893
For multiple concurrency on dual mac, connection
dump is not added if a single vdev is present on
one mac. For example if 2 connections are on MCC 5 GHz
and one connection is on 2 GHz in DBS system then in
connection dump only MCC/SCC vdevs will be present.
Fix is to include single vdev in connection dump and
cleanup dump_dual_mac_concurrency as concurrency can
be checked with in loop instead of separarte mac share
check for each vdev.
Change-Id: I09ab964915cd3b132c3bd3cba096e40cba238eed
CRs-Fixed: 3254806
Currently if SAP is up on 5 GHz DFS/non-DFS channel and country
change happens to world mode where SAP is not allowed on 5 GHz
channels then it moves to a 2.4 GHz channel and saves current
operating frequency band information, now again if a country
change happens SAP tries to move back to any allowed 5 GHz
DFS/non-DFS channel.
Sap should come to non-DFS channel first. If not available then
it should come on DFS channel
To address this issue, add a fix to check for first valid 5 GHz
non-DFS channel and first valid 5 GHz DFS channel. Move to
valid 5 GHz non-DFS channel if present.
Change-Id: I0cf3841e35e22efc0f518ce15b4cab40996cc645
CRs-Fixed: 3247522
Add following host fixes related to EMLSR association.
1) Use phy cap get macro to extract EMLSR hw mode id.
2) Add logic to send EMLSR cap flag during vdev start.
3) Add logic to copy EML caps from assoc link common
info subfield to MLO peer assoc struct in order to
share EML caps to FW on both links via peer assoc.
4) Add checks to update EMLSR cap flag only if both
STA and AP support and advertise EMLSR mode.
5) Send EMLMR support flag along with EMLSR support
flag to FW as part of vdev set IE cmd for roaming
scenarios. Also, update common info length when EML
caps are present.
Change-Id: Ied2570d498a43adadd93899d4fdbe023d320676b
CRs-Fixed: 3235059
When SAP tries to come on 2.4 GHz channel with 40 MHz bandwidth
then it should start on same bandwidth if no other interface is
up. But currently SAP is getting switch from 40 MHz to 20 MHz
even in standalone case.
As a part of fix, check any other vdev is present on same mac or
not. If it's not present then start SAP on given bandwidth
Change-Id: Id9625a3dfaec34480f86b7ca1459ea33c32299fe
CRs-Fixed: 3226558
sbs_num contains the sbs_freqs array size. Do not clear it
to 0 before call get_sbs_chlist API. Otherwise the size_of_sbs
will be 0 and can't add sbs freq to list.
Change-Id: I318edd12978f73e9f75ab5298c36ceec57c5df6d
CRs-Fixed: 3243780
Allow the policy manager to select an alternate channel
on the same band if the SAP has no concurrent interfaces.
Change-Id: Ibd358018b0e9d631dbf61b42069a117870b5af44
CRs-Fixed: 3230881
Create radio combination matrix list from target mac phy information.
Return the supported radio matrix to apps by vendor command
QCA_NL80211_VENDOR_SUBCMD_GET_RADIO_COMBINATION_MATRIX.
Change-Id: I9732eadf10e8634336dbdac21e10f60e81cbaca6
CRs-Fixed: 3214050
From Auto P2P GO DFS requirement, if GO force SCC strict
enable and sta_sap_scc_on_dfs_chan ini enabled, allow
Autonomous GO starts on DFS.
Fix it by allow GO on DFS such configuration.
Change-Id: Ia4c5b1c7889f5c3115e4e05ac7f051673bbb2b81
CRs-Fixed: 3228456
Add checks to see if STA supports eMLSR mode and also
vendor command selection. If both support eMLSR, then set
eMLSR support bit. This value is shared with FW via
wmi_vdev_set_ie.
Change-Id: I9ea3bebfcaf90bb83d8811924afd8805530e40dc
CRs-Fixed: 3220949
Handle the following the eMLSR STA concurrency scenarios
1) eMLSR STA + SAP/P2P GO/NAN - Send a force disable link request to
FW on any one of the eMLSR links. FW will decide which link to disable.
2) eMLSR STA + STA/P2P Client - Send a force disable link request to
FW on any one of the eMLSR links. FW will decide which link to disable.
This action happens before vdev start of the new connection request.
3) eMLSR STA + TDLS - TDLS connection is not allowed since eMLSR STA is
given higher priority.
4) If there is already an existing connection, then eMLSR is not allowed.
Once the other connection goes down, the disabled eMLSR link is restored.
The concurrency handling API is invoked from corresponding interface
manager APIs.
Change-Id: Ib7d5da5dcb8eb3ea16c6e50c8fcadc20972d7d05
CRs-Fixed: 3185078
In dynamic SBS if 2.4 GHz is sharing mac with 5 GHz low, it can be
dynamically be moved have mac sharing with 5 GHz high.
So if one of the freq is 2.4 GHz in existing 3 connection, the
4th connection can be brought up on any 5 GHz freq (low/high) and
the 2.4 GHz vdev will be moved with other mac.
Similarly for all 3 connection be on 5 GHz and SBS, in case of the
dynamic SBS along with the low/high 5 GHz freq, 2.4 GHz freq can be
included in PCL, as 2.4 GHz can share mac with any of high/low 5 GHz.
e.g
if current concurrency is:
=> STA (2.4 GHz) + SAP (5 GHz low) on mac 0 and STA (5 GHz high)
on mac 1 (LOW mac share with 2.4 GHz)
currently only 5 GHz high is present in PCL thus making:
=> STA (2.4 GHz) + SAP (5 GHz low) on mac 0 and STA (5 GHz high) +
SAP (5 GHz high) on mac 1 (LOW mac shared with 2.4 GHz)
but 5 GHz low (i.e. all 5 GHz) can be provided in PCL to make it as below:
=> STA (2.4 GHz) + SAP (5 GHz high) on mac 0 and STA (5 GHz low) +
SAP (5 GHz low) on mac 1 (HIGH mac shared with 2.4 GHz)
Also for below 5 GHz high and 2.4 GHz can be provided in PCL
=> STA (5 GHz low) + SAP (5 GHz low) on mac 0 and STA (5 GHz high)
on mac 1
If it select 5GHz high:
=> STA (5 GHz low) + SAP (5 GHz low) on mac 0 and STA (5 GHz high) +
SAP (5 GHz high) on mac 1
if it select 2.4 GHz:
=> STA (5 GHz high) + SAP (2 GHz) on mac 0 and STA (5 GHz low) +
SAP (5 GHz low) on mac 1 (HIGH mac shared with 2.4 GHz)
Thus increasing the range of PCL for dynamic SBS.
Change-Id: I3fc555f137050fd49b5ce5eaf12f57f19ee9d903
CRs-Fixed: 3227280
When STA receives a connect req (C1) and it requires hw mode
change. Now the hw mode change resp will take the SME global
lock and call connection manager API, which will try to
acquire CM lock.
But if before that one more connect req (C2) is received in
another thread which has acquired CM lock before C1 can
acquire it, and this connect req C2 will also flush the C1
from CM queue. Now if C2 also require hw mode change, which
also require to acquire SME global lock.
So both connect will wait for each other to complete, leading
to deadlock.
To fix this, from hw mode change response, break the context
(by posting to scheduler thread) so that sme global lock is
released and C2 is processed.
As C1 is already flushed by C2, on scheduler thread execution
once it get CM lock it will be dropped silently, and C2 will
proceed with connect.
Change-Id: I14efb0f21442edcae90a4abea20cb0b9e06a0758
CRs-Fixed: 3223786
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
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
