Currently, if there is a legacy connection and a new STA
connection comes up with EMLSR capability, Host does not
advertise EML caps in assoc request. But there is no support
to enable EMLSR mode if the legacy connection goes away.
Thus, add support to handle this concurrency scenario as
follows
1) Host should advertise EML support capability in assoc
request.
2) After association is complete, force disable one of the
EMLSR links.
3) Once the legacy connection goes down, re-enable the
disabled link.
Change-Id: I5d9f37827e2a9f0571fa9733b4779668bd987f92
CRs-Fixed: 3363115
Add support to force enable/disable MLO links in MLSR mode
based on link mac address. The input will be an array of
active link mac addresses. Force enable the links associated
with all the mentioned link addresses and force disable the
links associated with mac addresses that are not given in
the input.
Change-Id: I14660f14ba6381da04460b641f971734c03aa9a7
CRs-Fixed: 3391992
In STA+SAP / GO concurrency, SCC is enforced by moving SAP / GO
to STA's operating channel. STA side, if there is a CSA
then SCC will be enforced only after STA moves to new channel.
In usecase of STA + GO SCC on DFS channel, CSA is sent with no-TX
and STA's movement will only happen once CSA count becomes 0.
This will block data transmission till then, which will have bad
user experience in case of XR where, it needs to have periodic data
transmission in every 1 second with GO interface.
This new INI is added to handle this scenario where SAP / GO will
move first followed by STA.
Change-Id: Id642872da4f3403a5168a2fad58b4c971cd88288
CRs-Fixed: 3380861
Currently, unsafe channels are avoided when SAP restart happens.
If WMI_COEX_FIX_CHANNEL_CAPABILITIES is advertised by firmware
and if the SAP is started in a fixed channel, don't restart even
if the current operating channel is unsafe.
Change-Id: I5f7d632bcc00a1b5351dad64aca0ce16f1057537
CRs-Fixed: 3381394
Add channel tx max power factor to existing ACS channel weight logic,
so if AFC available can automatically select Standard Power channel
which has higher 6 GHz tx power and better performance.
Add SAP best channel selection callback when AFC triggered DCS,
DCS module will invoke this callback and dynamic switch to best
channel/bandwidth if possible.
Change-Id: I300057c2b11d0b818f4e20ba51d6ab9b82f6a3ff
CRs-Fixed: 3204199
Clean up code for sme_get_valid_channels() and
sme_get_roam_intra_band() apis and
replace it with ucfg api.
Change-Id: Ic2f07e2193186d1e1ac81f6e5909417c10ab9c89
CRs-Fixed: 3335898
When dual sta connected as SBS mode instead of dbs mode, driver didn't set
pcl per vdev, so dual sta had same PCL in firmware, MCC may happened after
roaming.
Fix:
1. Host pass roaming MCC disallow flag to F/W by checking primary vdev id.
2. For platform SBS supported, when doing dbs or sbs, send PCL from table
to F/W directly, allow SCC and SBS<->DBS roaming, don't limit to intra
band, only avoid mcc case if no primary vdev.
3. Use policy_mgr_concurrent_sta_on_different_mac to replace
policy_mgr_concurrent_sta_doing_dbs, add logic to consider SBS when set
PCL to F/W.
4. Change dual sta PCL table to remove mcc channels.
5. When STA channel switch, also update PCL to F/W.
6. For roaming case, do vdev level PCL update for all sta after connection
update in policy mgr, or wrong PCL is got.
Change-Id: I631c84c96da2bba4011b69e4c076db174205c874
CRs-Fixed: 3336768
While SAP doing CSA, NAN enabled, SAP tries to do CSA to force SCC with
NAN in scheduler thread, since last CSA in progress, scheduler thread is
blocked to wait last CSA finished, CSA timer can't be handled in scheduler
thread any more, last CSA can't finish, deadlock happens until timeout.
To fix it, let SAP force scc with NAN logic run in work thread instead of
scheduler thread.
Change-Id: Icb774ffcfc70f279ba3b18b3c5cd4a169180e99b
CRs-Fixed: 3344905
In current design of sta+sap scc on indoor channels, the NO_IR
flag of all the indoor channels are removed during init.
Then, based on the operations on the SAP interface, the
SAP concurrency will be decided in host driver.
However, some userspace p2p applications, do not query the
pcl list from driver, therefore standalone P2P GO are sometimes
brought up in indoor channels.
To fix this:
1. Upon STA connect: Remove the NO_IR flags only from the
indoor channels to which the STA is connected.
2. Upon STA disconnect: Add the NO_IR flag back to the
disconnected channel.
3. Upon STA roam/csa:
a) Add the NO_IR to the new channel if it is indoor.
b) Remove the NO_IR of the previously connected channel
once the SAP/GO(if present) moves out of the indoor channel.
4. The NO_IR flags should be removed for all the bonded channels
on which the STA is active.
5. In indoor concurrency cases, add logic in the SAP start to
limit the channel width with the STA interface bandwidth. Since,
only the bonded channels are active channels.
Change-Id: Ib0b30e1f17d0eb944c72b26bb679bf7447b9032f
CRs-Fixed: 3296208
Currently probe request is sent every 200ms during join timeout
this can lead to 16+ probe req, send during join time.
Change logic to send max 5 probe req during join time,
if candidate freq can lead to MCC concurrency scenario.
Change-Id: I7956771e2cf6724754f59c6db5b07fb45426ae41
CRs-Fixed: 3338329
Kernel doc mismatch in policy_mgr_are_sbs_chan(). Correct it
by adding proper argument.
Change-Id: Ic72659df96bac1f98323ec7a9d339d0a975434a0
CRs-Fixed: 3336165
In concurrency case: GO on 5180 MHz, SAP on 5765 MHz,
MLO STA vdev 0 5180 MHz, MLO STA vdev 1 2462 MHz.
When the MLO STA is up and driver does force SCC on
SAP, the get PCL is failed because the GO vdev,
MLO STA vdev 0 and vdev 1 are all non-SBS channels
between each other. Driver doesn't handle the case in
policy_mgr_get_index_for_ml_sta_sap_sbs if current
hw mode is SBS. This case can happen the mlo sta link
vdev is inactive after get connected.
To fix it add new API:
policy_mgr_get_index_for_ml_sta_sap_hwmode_sbs to
handle it. It will return the correct PCL index
to avoid 3 home channels on same mac.
Change-Id: Ia16f8a391b34fc15287a93590b2c119d58250e20
CRs-Fixed: 3326358
Currently CH_WIDTH_MAX is set as default BW when sap do restart,
then apply some checking rules to get the final BW. It's possible
the final BW is greater than sap original BW. But a greater BW
isn't expected in some use cases where greater BW may introduce
some unexpected issues.
Add INI to configure sap original BW as default BW when do sap
restart as required.
Change-Id: Ie274a3eea73c2af9424a8b9ce21bee34eeaaef2e
CRs-Fixed: 3315486
If there is existing interface STA/GC/SAP/GO/ML STA and
low latency SAP tries to come then allow only if below
condition satisfies
1. DBS hw_mode: Allow if existing interface is on 2.4 GHz
channel otherwise reject.
2. SBS hw_mode: Allow if existing interface channel and low
latency SAP channel are mutually exclusive.
Change-Id: I67a883b89f63fa581379cb303da6c11b43e65912
CRs-Fixed: 3296640
Add a support to check if low latency SAP is present on 5 GHz
channel then do not allow STA/GC to connect on 5 GHz for
both gaming and lossless audio profile.
Change-Id: I8e1c62dfea3c27306e338392448f5cc6eed912aa
CRs-Fixed: 3302763
Low latency SAP is supported on DBS and SBS hw and it can come
up on below two profile
a. Gaming
b. Lossless Audio
DBS: Allow only 2.4 GHz channel for both gaming and lossless
audio profile
SBS: Allow non low latency SAP 5 GHz channel which are mutually
exclusive for both gaming and lossless audio profile.
Check whether low latency sap is present or not. If it's present
then get the frequency to validate the concurrency with other
interface.
Change-Id: I39715a01e63de612448d4d0f230e6ccb71b76b15
CRs-Fixed: 3294596
Add below two enhancements for SAP
1. Spatial Reuse enabled in single MAC concurrency
2. Set bit HESIGA_Spatial_reuse_value15_allowed in SRP IE
Change-Id: Id2d3d04ae1b3b9a2e6d84f30749b577bc7b79061
CRs-Fixed: 3305447
Add API policy_mgr_is_mlo_sta_disconnected to check all STA
in mlo dev are disconnected. If any link is associated
the API will return false.
Change-Id: I2845e81b25b4dabe5cd52e80d230979ce44e9994
CRs-Fixed: 3302791
Two mlo sta link vdev (2+6(LPI)) are started but hw mode is SMM (one
link maybe inactive in fw).
When start SAP on 5 GHz low, driver doesn't select force SCC channel for
such case. It left the SAP channel not changed (5 GHz 5220).
Since the 6 GHz STA link is on LPI mode, SAP is not allowed on
6 GHz (policy_mgr_modify_sap_pcl_for_6G_channels). Driver needs to
consider the PCL as well to select force SCC channel. Add new API
policy_mgr_get_pref_force_scc_freq to fix it.
Change-Id: I824de7168a26955caeeaff955a232c80baa13345
CRs-Fixed: 3280704
Hw mode change in progress is set after the set_hw_mode
command is queued in serialization. Its not reset in below
cases:
Active command timeout case, serialization command
cancelled case.
Before connect request is queued, if hw mode change is in
progress, there is 6 secs wait and if there is no hw mode
change response, connection failure. This causes subsequent
connection failures and there is no recovery.
Reset the wait for hw mode change event in serialization
command failure cases.
Change-Id: I716982f06198e9c3495685ddb158044778c4b1ff
CRs-Fixed: 3256424
In SAP+GO concurrency, if move SAP to DFS channel (BW 160 MHz)
and cause MCC with GO, the target will do CAC on SAP, but target
doesn't support MCC with GO when SAP is CAC state.
Fix by checking correct BW of CSA target channel so that correct
DFS flag can be got and if target channel is DFS causing MCC
with other AP interface then reject CSA request.
Change-Id: Ic7821cf62d3b364e4d2ea052dc82d65d18054091
CRs-Fixed: 3275285
In GO+STA+SAP concurrency, if GO is MCC with STA, the new SAP
will not be allowed in same MAC. FW doesn't support MCC in same
MAC for 3 or more vdevs. Move GO to other band to avoid SAP
starting failed.
Change-Id: Ia19abd1b11f7416797af3e975ab8ffde9037c11f
CRs-Fixed: 3262185
If SAP+P2P GO SCC on 2.4 GHz, the new STA interface will be
allowed connect to AP on 2.4 GHz SCC channel of SAP/GO or
5/6 GHz band AP. And do same for 5 GHz band.
For 3rd SAP/P2P GO coming up, try to force SCC to
existing same band SAP/GO home channel if any, to avoid the
concurrency check failure.
Change-Id: I363e9c8307ac4cfa70d6d00bc0d01a545c3eca26
CRs-Fixed: 3249205
Based on the new requirement, add support to get requested
feature set info from different feature components.
Change-Id: I1bfc097c8ae8c4ab678d4dc07b7932cf3272d851
CRs-Fixed: 3262868
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
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
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
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
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
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
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
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
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 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
