eMLSR + NAN concurrency is not supported currently, so handle it
as mentioned below
1. eMLSR+NAN: If NAN is coming up when eMLSR is active, disable
one ML link so that eMLSR gets disabled.
2. NAN+eMLSR: If eMLSR is coming up when NAN is already enabled,
disable one link so that eMLSR doesn't get enabled.
Also, cleanup the APIs to carry a generic flag to indicate that
a concurrent connection is coming up instead of mode specific flag
as there is no dependency on modes to handle concurrency.
Change-Id: I625f8b18f9d7e991922d22af53f3e8743a3727bd
CRs-Fixed: 3443900
Rename policy_mgr_is_sap_allowed_on_indoor() to
policy_mgr_is_sap_go_interface_allowed_on_indoor() since
it is common between SAP and GO. Cleanup the API as well.
Change-Id: I8380bd81c5050e9f12c00fff830455f14135c2b4
CRs-Fixed: 3423703
Since for MLO there may be several link connections, for TDLS
using api policy_mgr_get_connection_count_with_mlo() to replace
with policy_mgr_get_connection_count() to follow the original
logic.
Change-Id: Ic13c89f2e834196c01ca6966329cbd0d1552f292
CRs-Fixed: 3436049
Existing check for 4 vif concurrency in policy_mgr_allow_4th_new_freq
is insufficient to handle the case: ML STA on 2412 MHz and
5805 MHz, GO on 5180 MHz, SAP on 5805 MHz. Then user trigger
SAP CSA to 5240 MHz. Driver should reject the CSA because
DBS or SBS both can't meet the requirement that 3 VIFs MCC is not
supported in same mac.
Fix by loop all the hw mode to check vif channel and mode
combination are supported or not. If no one support the combination,
reject the 4th connection.
Change-Id: I67709395f7734d1f636a1410ac112a837cb66e79
CRs-Fixed: 3446747
Rename session_id with vdev_id in
policy_mgr_check_for_session_conc() to avoid confusion.
Change-Id: I9449395043f3f8d4e632f38770405febb1e227ab
CRs-Fixed: 3439906
Disable TDLS offchannel on SAP start if concurrent STA with
TDLS exist.
Enable TDLS off channel after SAP start if SAP and
STA are not in MCC.
If TDLS is enabled, and off channel is required, update
TDLS off channel to be the SAP channel.
Change-Id: Ica508889acbae5e2dc4269d4d7518cf01d62714f
CRs-Fixed: 3444747
In STA + SAP / GO DFS SCC concurrency, switch SAP / GO's operating
channel before STA's switch upon received very first CSA on STA
interface from peer AP.
Once STA moves to new channel, enforce SCC with existing SAP / GO
if its in MCC. This is done to allow traffic on SAP / GO side
during CSA period.
Change-Id: Icb4a15ad21ae96faff1fe338985aa734a4398cd2
CRs-Fixed: 3431386
Add support for new TDLS off-channel mode type:
DISABLE_ACTIVE_CHANSWITCH. With this
off channel mode, the TDLS off-channel will be disabled
completely without passive disable mode.
DISABLE_CHANSWITCH -> Passive channel switch can be done i.e if
peer requests channel switch then firmware can do channel switch
DISABLE_ACTIVE_CHANSWITCH -> Disable all off-channel switches.
Add support to send peer channel lists based on concurrency
combination. Override the ini configured frequency to the
supported frequency based on the current concurrency.
Change-Id: Ie3210178eb8b57d6ab126a730ed91895b70edaa1
CRs-Fixed: 3416213
Currently, policy_mgr_is_ll_sap_present api is used to check if
ll sap is present or not but different operations may be required
for HT and LT LL AP policy example for LT policy i.e gaming/loss
less audio MCC is acceptable but for HT MCC is strictly prohibited.
So, wrapper functions are added to check HT, LT and any AP policy.
Change-Id: I93dbcd65b1a102d0f879366db26f3d2cf01e030e
CRs-Fixed: 3435203
Add variables and APIs in SAP and SME to change CSA count
for SAP / GO.
Currently the default CSA count is 10, this API allows
to reduce the CSA count if required as per the requirements
Change-Id: I17c101cd0c809f49d57d2aaf87fc37d90b92ea1f
CRs-Fixed: 3431384
In MLO STA 2.4 GHz + 5 GHz High band and SAP concurrency case,
5 GHz Low band SAP will move to MLO 5 GHz link's home channel for
SCC after MLO STA is up.
But GO starts on 5 GHz high band when SAP CSA is in process and
pass the policy mgr concurrency check because the SAP channel
is still 5 GHz low band.
Fix by defer GO BSS start if any CSA is in progress and also
check any AP start is pending for STA, SAP force SCC concurrency
handling.
Change-Id: I0fcd799017d5048f3574687f913a396ab4d7ade1
CRs-Fixed: 3418351
Do not pass mode as an argument in policy_mgr_is_vdev_ll_sap().
Use vde_id to get the mode for further condition check.
Change-Id: Ie12c31d4cf536ba6c80f0e28524b4c99c23600d1
CRs-Fixed: 3414277
Add a new ini "p2p_go_in_indoor_chan" to enable support
for p2p go operation on indoor channels.
Do not allow standalone SAP on indoor channels if the
SAP indoor channel support is not enabled.
Change-Id: I2e6220ebcefe09b4ad5de496c36879ef048cb5b8
CRs-Fixed: 3405597
Rename policy_mgr_is_ll_sap_present() into
policy_mgr_is_vdev_ll_sap(). As this api mainly checks
whether the given vdev is ll sap or not
Change-Id: I7f87aceeb0ed6ac5bb7014db1fd6213e62e6305e
CRs-Fixed: 3413644
Handle link removal for ML STA vdev:
Send force link command to target if MLO STA link number > 1.
Select other inactive link to active if possible.
Change-Id: I40567364ad240399caf6be6683b96d17f6a4aab0
CRs-Fixed: 3352849
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
