This change is to check for station count with maximum
number of concurrent connections.
Change-Id: I539ae0b78deadf5e514f00d57542b4dd871e0e4e
CRs-Fixed: 3776536
Add support override the NSS capability with HW NSS capability
during TDLS setup.
Change-Id: I916193969d5aafe042ee1bea2adc29668c9109ee
CRs-Fixed: 3792456
When SAP CSA is started, host driver starts sending CSA IE
with beacon count. Host driver sends VDEV_RESTART to firmware
only when the beacon count reaches to 0(e.g. from 10 to 0).
But if CSA has to be aborted due to some reason(e.g. concurrent
SAP got disconnected), host driver stops the CSA by posting
EV_CHAN_SWITCH_DISABLED where it stops sending the CSA IE and
restores the VDEV state to UP-UP-ACTIVE. It updates the
templates and doesn't send VDEV_RESTART to firmware.
Currently, host driver sends VDEV_UP to firmware as part of
SAP state machine restoration. But firmware might not expect
this VDEV_UP as vdev is in UP state. Host has to avoid
sending VDEV_UP to firmware when the VDEV state is UP-ACTIVE.
Also, SAP CSA abort might result in other race conditions.
So, let the CSA continue if it's already started and SAP channel
gets evaluated once SAP is UP anyway.
Change-Id: Ic8ff8b0c58dd656b4e7ae2a2f9c46c3584a33165
CRs-Fixed: 3734991
When ML STA links are on MCC, TDLS action frames try to
set the link mode to force active. To avoid this
reject the TDLS mgmt request when ML STA links are on MCC.
Also enhance few debug prints for TDLS.
CRs-Fixed: 3717831
Change-Id: I69a942d80f5fac0ff25cfb47229e5dde6a693f97
Some targets may prefer to keep SAP on same channel even when the
channel is marked as unsafe due to coex operations.
Check the corresponding device capability and avoid chan switch
when the SAP is fixed channel(non-ACS) SAP.
Change-Id: I8d003359a587c5308899e0956b0414074bd748b0
CRs-Fixed: 3776847
Currently, firmware-reported unsafe channels are ignored
and userspace configured channels are honored when
coex_unsafe_chan_nb_user_prefer ini is set. This is supported for
SAP mode only.
But some platforms may want driver to ignore the firmware-
reported coex channels for P2P-GO also.
Enhance the ini to allow user to configure mode specific
bit as mentioned below,
BIT 0: Don't honor fw coex/unsafe channel info for SAP mode
BIT 1: Don't honor fw coex/unsafe channel info for P2P-GO mode
Change-Id: I91a2c6b2da9aba411d081f6ae3b23d374fe53159
CRs-Fixed: 3766393
Currently, Host driver is rejecting force scc on non DBS
solution when QDF_MCC_TO_SCC_WITH_PREFERRED_BAND is set.
This change is to allow STA + SAP concurrency on non DBS solution.
CRs-Fixed: 3716279
Change-Id: Ief73a57d23f627764eca00254acf4cf7e9acd963
The SAP is not moved to the 6 GHz user configured
frequency in the following cases:
1. STA disconnected, SAP is standalone in 2.4 GHz
2. STA is VLP/PSC channel, but SAP is currently in
2.4 GHz(due to STA(DFS) + SAP)
Allow the SAP to restart in 6 GHz channels for the
above scenarios if the following criteria are met:
1. For standalone: The SAP user configured band is
superior than the current operating band.
2. For SCC: The 6 GHz STA should operate in PSC and
the channel should support VLP in DUT regdomain.
Change-Id: Iea292c94e579ccead2300f6e9b994c4b8e9a0a87
CRs-Fixed: 3713247
Add more validation for vendor command force active link bitmap:
1.If force inactive num is present due to MCC link(DBS RD) or
concurrency with legacy intf, don't allow force active if
left inactive link number doesn't meet concurrency requirement.
2.If force inactive bitmap is present due to link removal or
concurrency with legacy intf, don't allow force active if
it is conflict with existing concurrency requirement.
Change-Id: Ic7507c1797189c079f0032a39819e15467bd6bf3
CRs-Fixed: 3701323
Currently, SAP gets moved to STA channel when SAP causes MCC
upon STA connection. Same is true for ML-STA where SAP is in
same band as one of the ML-STA links, even if the ML-STA is
in DFS channel.
But STA may receive disconnect request from userspace just
after connect completion. If SAP-CSA is started before receiving
disconnect request, CSA is supposed to be aborted as the STA
would be gone out of the DFS channel.
If SAP-CSA is not aborted, host driver may send VDEV_RESTART on
the STA DFS channel without cac timer and firmware allows SAP to
proceed with VDEV_UP. Host driver doesn't send VDEV_UP as the SAP
channel is not valid anymore. Firmware waits for SAP VDEV_UP and
may cause inconsistency in firmware state machine as host doesn't
send VDEV_UP at all.
So, abort SAP restart if any of the STA/ML-STA links/P2P client
are in disconnecting to avoid this.
Change-Id: I8d229686d9dae685ed680592396bb7cf389f6011
CRs-Fixed: 3667305
In DBS rd, SAP on 2.4 GHz, and ML STA on 5 GHz + 6 GHz. Driver
will force inactive one of link to inactive, for example 6 GHz link.
When user sets the 6 GHz link to active, current driver rejects.
Consider the SAP is on 2.4 GHz, MLSR can be switched between on 5 GHz
and 6 GHz, to allow such user request.
Change-Id: I32440d0c079b9a4bb9551087ecd959b3f9fc25c4
CRs-Fixed: 3675217
Currently, gWlanMccToSccSwitchMode has the below documentation,
gWlanMccToSccSwitchMode = 0: disabled.
gWlanMccToSccSwitchMode = 1: Enable switch.
gWlanMccToSccSwitchMode = 2: Force switch with SAP restart.
gWlanMccToSccSwitchMode = 3: Force switch without SAP restart.
...
But values 1 and 2 are not used and all platforms are adapted
to value 3. Usage of values 1/2 leads to the case where
connections are stuck in MCC.
Deprecate the same and overwrite it to 3 in host driver.
Change-Id: I036985c6cf33b975a726a3eee6d6562a869bbc60
CRs-Fixed: 3668491
Add new data structure to save the external/internal set link
request. The different source of request has different priority.
In some situations, a certain request may not be honored if
it conflicts with higher priority request.
Change-Id: Ib95d0c688f92dcfc294702e7deb2e3b7da13f76c
CRs-Fixed: 3650630
Currently, PCL carries the supported frequencies for SAP
restart as part of MCC to SCC switch. Policy mgr checks
if any frequencies from this list have to be filtered out,
i.e to avoid unsafe/dfs/6 GHz etc channels.
This works fine if the PCL carries only one frequency(non
multi-link STA case). But if STA is connected to an MLO AP in
multi link mode, the PCL carries two(could be more) frequencies.
First channel from PCL is picked for evaluation in
policy_mgr_get_sap_mandatory_channel(), which might be different
from the chosen frequency for chan_switch. Then it returns
different frequency than the chosen frequency(i.e. carried
through intf_ch_freq) by the caller. So, the caller thinks that
the filter API rejected the chosen channel and aborts channel
switch.
The expectation is to pick the preferred channel from caller
data(i.e. intf_ch_freq) if it's present in PCL. If intf_ch_freq
doesn't carry any valid frequency from PCL, first frequency can
be picked as per current logic.
Change-Id: Ib087b27b7149ff8cfe06e2ad7aa75099bba5085c
CRs-Fixed: 3668526
In the roaming to eMLSR AP, fw may move the link to inactive
because concurrency not support eMLSR mode, the eMLSR cap in vdev
may not be properly set in one vdev in the middle of roaming.
Check inactive vdev as well for the eMLSR flag, if anyone vdev
have eMLSR return true for API policy_mgr_is_mlo_in_mode_emlsr.
Change-Id: Ia05200e16aae701c24e9d9c3a70c8139825db833
CRs-Fixed: 3647141
After 3-link association is complete, Host sends force
inactive num command between 5 GHz and 6 GHz links to
firmware. Later, if user wants to force enable 1 or 2
links, the current checks prevent it from taking effect
as a previous force active num is in place and a NO
FORCE command cannot be sent as it is a DBS RD.
So add new API in policy manager to check if the new
force active num command is valid and process accordingly.
All new force active num commands except for 5 GHz +
6 GHz links should be allowed while honoring the prior
force inactive bitmap as well.
CRs-Fixed: 3656412
Change-Id: Iecfca57d9b47acd31d191cca2632a6d1baf62174
Currently, host driver sends only 2 port interface combinations to
userspace based for non-DBS targets. But 1x1 DBS also does not
support 3 port concurrencies.
So, to fix this, disable the 3 port concurrencies for
1X1 DBS target also.
Change-Id: Ia70937a7875d11d3f852ca498c4f7d9415a6783b
CRs-Fixed: 3654683
Currently LL_LT_SAP does not support 4th port concurrency,
add a check in policy manager to reject 4th port concurrency
if LL_LT_SAP is present.
Change-Id: I57ed78c937935396f9001b867652cb7ee146c487
CRs-Fixed: 3658476
Currently, SAP bw gets downgraded(from 320 MHz to 160 MHz) when
link connect starts on a channel which causes DBS/SBS.
But SAP is not aware of the link that can cause DBS/SBS if it is
inactive as corresponding entry is not present in driver policy
mgr table. When link switch is triggered to a channel which
causes SMM to DBS/SBS hw_mode, SAP bw update algo gets triggered
as there is a new connect which causes split-phy mode. SAP bw
update algorithm need not be triggered upon link switch start and
can be triggered post link switch to avoid interrupting link
switch.
Currently, it doesn't differentiate between user connect request
and link switch connect request. Add a check and avoid SAP bw
update trigger link switch cases. Evaluate the links posts
connection and trigger bw update if needed.
Change-Id: I90f836c04d096dffb5b82c53166b18d2ba27a584
CRs-Fixed: 3649268
Add separate APIs to validate SAP, P2PGO or LL_LT_SAP
channels according to LL_LT_SAP concurrency.
Change-Id: I180796df6b312f9bbb0a8e61085ca1517cd687b5
CRs-Fixed: 3647561
Currently wlan_reg_decide_6g_ap_pwr_type is
getting invoked from south bound and north bound
callback path, because of this pdev channel
is computed unnecessarily two times and
the AP power type obtained is not used in
reg_populate_secondary_cur_chan_list.
To address these issues, set AP power type
while propagating master channel list to pdev and
use this power type value to populate secondary
channel list.
CRs-Fixed: 3609366
Change-Id: I5bdc69d42cd09c0d875b8fb55d14f6ee10a175b2
If LL_LT_SAP start is in progress and at the same time if any
concurrent interface comes up in SCC with LL_LT_SAP, then add
changes to check presence of concurrent interface once LL_LT_SAP
start completes.
Change-Id: Ia8b72549ac98a7e60a1b55e4f7120b24596088c4
CRs-Fixed: 3647186
LL_LT_SAP and SAP can not be present on same MAC, if SAP is
present on 5 GHz for DBS RDs and if LL_LT_SAP tries to come
up, then move LL_LT_SAP to 2.4 GHz frequency so that LL_LT_SAP
can come up on 5 GHz.
This change handles this scenario and move the SAP to 2.4 GHz
frequency when host driver receives acs request for LL_LT_SAP,
when LL_LT_SAP start completes.
When LL_LT_SAP goes down, host driver restores the original
user configured channel.
Change-Id: Ia4ed29d86a595321ee8be57420cc6a03c84f190b
CRs-Fixed: 3647076
For LL_LT_SAP, give preference to 5 GHz low frequency to select
channel during ACS.
In case of SBS, it's better to bring up LL_LT_SAP on 5 GHz low
as there will be less number of passive channels on 5 GHz low
band compared to 5 GHz high band.
Change-Id: I1d7f7c08c315394315df3b360c9c632d17a4b39a
CRs-Fixed: 3648218
LL_LT_SAP does not support SCC, so to avoid this, reject initial
STA connection and CSA on LL_LT_SAP frequency if STA receives CSA
on LL_LT_SAP frequency.
Change-Id: Iaa4546bbbc242aa8fc9580d1a8a2728b197457d0
CRs-Fixed: 3654643
When SCC_MCC switch mode is configured as:
QDF_MCC_TO_SCC_SWITCH_WITH_FAVORITE_CHANNEL, then when
concurrent STA is disconnected, don't move SAP to user
configured frequency even if the SAP is currently on
different band as the user configured frequency band.
Change-Id: I287fdf51bba2ca98bf6048694c03fafc114340da
CRs-Fixed: 3645514
Fix API to check if freq will lead to SBS/DBS, also use
vdev id to avoid the decision making using the self vdev during
vdev restart.
Change-Id: I4c6920883031a8e926b224841cfea710b6d82da7
CRs-Fixed: 3653755
To avoid race between CSA and set BW, check if BW upgrade is
still required after set bandwidth command become active.
If any connection is in progress, restart the timer again.
Change-Id: I049dbcbc1d30fba8f38250b05f5f62e8c230234c
CRs-Fixed: 3652085
Based on new requirement update policy manager PCL tables for
below LL_LT_SAP concurrencies:
1. LL_LT_SAP + STA + SAP
2. LL_LT_SAP + SAP + SAP
3. LL_LT_SAP + STA + P2P GO
4. LL_LT_SAP + P2P GO + SAP
5. LL_LT_SAP + P2P GO + P2P GO
6. LL_LT_SAP + STA + P2P CLIENT
7. LL_LT_SAP + P2P GO + P2P CLIENT
8. LL_LT_SAP + STA + STA
9. LL_LT_SAP + P2P_CLIENT + SAP
Change-Id: I8a01b88fc89dc18d1740ccf5fe0f8751e2980535
CRs-Fixed: 3647137
When STA is connected with some AP and that AP has send
RRM request to connected STA. The connected STA will start
RRM scan. During RRM scan, STA may miss beacon while doing
scan as it goes to foreign channel for scan and then comes
back to home channel. Now if LL_LT_SAP is present, it will
do scan in TWT interval. It will be overhead to handle
LL_LT_SAP + STA + Scan in firmware.
For now, reject rrm request if LL_LT_SAP is present.
Enable back later if required
Change-Id: I010b2b3289d80bfd9b0b6340fc6dda17044b06b0
CRs-Fixed: 3647800
Add NULL check for pm_ctx pointer to avoid NULL pointer deference
in function policy_mgr_pcl_modification_for_sap().
Change-Id: Ibc32e5dace8eddd1b88775af6ce76ae62fc76a1e
CRs-Fixed: 3626754
The SNS test may input QCA_WLAN_VENDOR_ATTR_CONFIG_EMLSR_MODE_SWITCH
vendor command randomly. The force active/inactive bitmap may
be conflict with existing force bitmap state. And eMLSR can only
enter with no concurrent connection present.
Add validation to avoid entering eMLSR in concurrent connection
present and bitmap confliction.
Change-Id: Ia1ca46faeca8ae1e32e5e8f585affff2870c5bf8
CRs-Fixed: 3644746
SAP restart happens when a concurrent STA comes up in the
same band. Currently, the new bw is calculated based on channel
supported max bw. If SAP moves from one 6 GHz channel to another
6 GHz channel, the new bw would be calculated as 320 MHz even if
the current SAP operating bw is 160 MHz. But SAP bw should be
limited to current operating bw as it might have got downgraded
to 160 MHz as part of sap_bw_update algo.
Considered current operating bw when SAP restart happens as part
of sap_bw_update.
Change-Id: If310b0ad9f914b438ae3c1968ca8f1ee26d57589
CRs-Fixed: 3637263
Customer framework may set active num 2 to driver for ML STA.
If the two enabled links are MCC, don't not force active 2
links.
If current enabled links are < 2 and there are concurrent
connections present, force active 2 links, which may be
conflict with concurrent rules, reject it.
Change-Id: Ifd37b7a3fb66e77954b26dad13f3f4244d114dea
CRs-Fixed: 3644404
Currently, if standalone SAP is operating in 6 GHz
and SET_FCC_CHANNEL 0/2 command is issued, as a result
complete 6 GHz band gets disabled and host triggers
SAP CSA to a new 2.4 GHz frequency.
In this path CSA is getting triggered for the second
time and as SAP is operating in a 2.4 GHz frequency
host does CSA to a new 5 GHz channel.
To address the issues,
1) Add logic to do SAP CSA to best valid channel if current
channel is disabled.
2) Invoke wlan_reg_recompute_current_chan_list from
policy_mgr_update_connection_info only for STA
and P2P client.
Change-Id: I3dd2b4075d8cd9e73735317ac3a5f7fb08635548
CRs-Fixed: 3603739
LL_LT_SAP supports MCC with sta interface and does not
support SCC with any interface. Add a logic to force
MCC if any STA comes up in SCC with the LL_LT_SAP interface.
This change adds below logic to force MCC on LL_LT_SAP:
1. If STA is present and LL_LT_SAP comes up, select MCC
channel in ACS and make sure to bring LL_LT_SAP on MCC channel.
2. If LL_LT_SAP starts without ACS in SCC channel, then
overwrite this SCC channel with MCC channel.
3. If LL_LT_SAP is present and STA comes up in SCC with
LL_LT_SAP, move LL_LT_SAP to an MCC channel or on different
MAC channel.
4. If LL_LT_SAP and STA are present in MCC and STA receives
CSA on LL_LT_SAP frequency resulting in SCC then move
LL_LT_SAP to MCC frequency.
5. If LL_LT_SAP and STA are present in MCC and STA roams
to LL_LT_SAP frequency resulting in SCC then move
LL_LT_SAP to MCC frequency.
Preference to lower 5 GHz will be given followed by
standalone MAC frequency then MCC frequency.
Change-Id: I7f4380ed7d726112bbc2aa94a50ffbb5d8b6036d
CRs-Fixed: 3640669
For mcc to scc switch config QDF_MCC_TO_SCC_SWITCH_WITH_FAVORITE_CHANNEL,
if GO is on 5/6 GHz, SAP is not allowed to active on 5/6 GHz, SAP should
move to 2.4 GHz, If GO is not present on 5/6 GHz, SAP needs to move to
5/6 GHz user configured frequency.
Change-Id: I4ba99460fe5656440c6010afcb0ebbc9c0f4de76
CRs-Fixed: 3624311
Rename policy_mgr_get_lt_ll_sap_freq to
policy_mgr_get_ll_lt_sap_freq and policy_mgr_get_ht_ll_sap_freq()
to policy_mgr_get_ll_ht_sap_freq()
Change-Id: I740d6dfc75008b36861c8e90d6e365ebc6d8a054
CRs-Fixed: 3637126
At present, the tdls_handle_link_unforce may be invoked multiple
times even though the link is unforced previously. That causes
sending set link command unnecessarily.
Fix by checking the current link force state to avoid setting link
again.
Change-Id: I1e75fb713b17e6efd8143ebbc5ce59aed0409061
CRs-Fixed: 3640207
Add callback mlme_vdev_reconfig_notify_standby to cld code to
handle standby link removal.
For standby link, it is going to be removed by AP, so don't
start link removal timer for it. Force inactive it to avoid
link switch to it.
Change-Id: Ib28e6b043f582e0fff2f4702e32ff222fc3428d3
CRs-Fixed: 3629633
Currently, SAP+STA and STA+SAP concurrencies are considered for
320 MHz SAP bandwidth downgrade to 160 MHz/upgrade to 320 MHz
from 160 MHz.
But during MLO link switch, a link gets disconnected and a new
link connection is started. The new link might be of 6 GHz, which
makes the sap_bw_update algo thinks that new connection/candidate
is 6 GHz and it can coexist with 320 MHz with SAP. This drives the
sap_bw_update algo to upgrade to 320 MHz, which starts policy mgr
opportunistic timer. This blocks the link switch(new link
connect operation). But this is not correct as a link is already
present and new link gets added.
Add a condition to check current bandwidth of the SAP and go for
downgrade only if the current bw is 320 MHz.
Also, cleanup the code which restarts policy mgr opportunistic
timer explicitly as timer is anyway started post
connect/disconnect completion. Introduce a new reason
POLICY_MGR_UPDATE_REASON_TIMER_START for this purpose.
Change-Id: Id49632b385cd3554b67be11e02e4e45ce094f0b4
CRs-Fixed: 3632270
Add changes to handle audio transport switch events in different
states of the bearer switch state machine.
Change-Id: I07568b3c3ccc5877d1e6f46ae5bf12afd3af3ec2
CRs-Fixed: 3626950
When FW includes new eMLSR hardware modes in
service ready indication host should be able to
store and update capability information.
Add support in policy manager to handle new HW modes
for eMLSR.
CRs-Fixed: 3618543
Change-Id: I575b93c85940e4d6469fbd038ce90123750729ff
When host handles hw_mode, host rejects NAN if CAC is in progress
as NAN always expect hw_mode DBS and set_hw_mode can't be done
while DFS CAC is going on.
But in hw_mode offloaded solutions, host doesn't have control
on set_hw_mode. Host can expect firmware to take care of
NAN+CAC scenario but that causes some out of sync issues.
So, reject NAN if DFS CAC is running. Framework/application
may retry later.
Change-Id: Icf4367c9185511e732379df2a32bf7889b9b101b
CRs-Fixed: 3614017
