When SAP start as pri freq: 5180, 160M, pri freq isn’t DFS freq, but
bonded freqs are DFS freq, so sap_dfs_wakelock is held.
After SAP restart as pri freq: 5180, 80M, pri freq and bonded freqs are
not DFS freq, so sap_dfs_wakelock isn’t released.
To fix it, add ch_params_before_ch_switch in sap_context, which includes
ch_width/ccfs0/ccfs1, can get all bonded sub channel info.
Add ch_params parameter in API hdd_hostapd_channel_allow_suspend and
hdd_hostapd_channel_prevent_suspend.
Call wlan_mlme_check_chan_param_has_dfs in them instead of
sap_chan_bond_dfs_sub_chan with
CRs-Fixed: 3777779
Change-Id: I7e32317b2ffab6f8de5990aeed68e7bd02527d6f
Currently, opmode is extracted from sap_ctx->vdev without
checking if it's NULL. Add a preventive NULL check
on sap_ctx->vdev.
Change-Id: I084d7ad441f84426d316d729136286a24fbeed26
CRs-Fixed: 3786993
Driver use uninitialized unsafe channel array in the function
"wlansap_select_chan_with_best_bandwidth"
So, to fix this, initialize the unsafe channel array with zero
value.
Change-Id: If63226da00187086f27e716424b29e30137a46b1
CRs-Fixed: 3772902
For non-DBS solutions, if STA is present on an indoor channel
with operating bandwidth less than 80 MHz, the sta+sap indoor
concurrency support allows SAP to operate only on that BW.
However, the SAP BW selection logic selects 80 MHz BW for the
concurrent indoor SAP. Since, the SAP operation in 80 MHz
hosts indoor channels as well, the kernel tears down the SAP.
For the indoor STA+SAP concurrency, choose the same BW of
STA for the SAP operation.
Change-Id: I564eebb260ff973d459603029705afbd380f2161
CRs-Fixed: 3756878
Currently vdev_id in mac_ctx->sap.sapCtxList[vdev_id] is check against
WLAN_UMAC_VDEV_ID_MAX(255), but sapCtxList[] array size is
SAP_MAX_NUM_SESSION(5), so change to check against max sap context
array size.
Change-Id: Id8370512194e6585c9e305b2c5a896e6d7bdbe0b
CRs-Fixed: 3671591
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
In ACS, SAP phymode is updated as per the ACS request, but actual
phymode is calculated during start bss, which check the IEs etc.
In pe session the ht/vht/he/eht capability flags are not updated
as per the new phymode/dot11mode and thus even if phymode is
11ac, he flag is set and send he caps to firmware.
So once SAP is started, don't allow phymode update from ACS.
Also update the ht/vht/he/eht capability as per the new dot11mode
so that there is no mismatch in dot11mode and
ht/vht/he/eht capability flag.
CRs-Fixed: 3696205
Change-Id: I73e5f8ed0fbdc17b423bcba6fd3cbf2acc221fc2
After CSA to 5180 (unsafe), the sap_fsm_validate_and_change_channel
will call wlansap_set_channel_change_with_csa API to do a new CSA
to safe channel. But wlansap_set_channel_change_with_csa will not
set ch_switch_in_progress flag. Instead, we should use parent API
hdd_softap_set_channel_change to trigger CSA, which will set
ch_switch_in_progress flag. The existing code will do
unsafe check after CSA done in hdd_hostapd_check_channel_post_csa,
so combine the sap_fsm_validate_and_change_channel work into it.
The ch_switch_in_progress missing during CSA will cause another CSA
request being executed while the first CSA is still in-progress. This
is not supported.
Change-Id: I17c9181a32ffc4f35f647db1f957a05b00306bee
CRs-Fixed: 3683289
In LA by default, the max supported SAP interface number -
QDF_MAX_NO_OF_SAP_MODE is 2. In third party framework or using
command line to add SAP interface, the active number of SAP
interface may exceed the number of QDF_MAX_NO_OF_SAP_MODE.
To avoid running into unexpected scenario, add check the active
SAP interface number with configuration of macro QDF_MAX_NO_OF_SAP_MODE
when adding virtual interface.
And in MDM we support 4 SAP, so make the QDF_MAX_NO_OF_SAP_MODE
configurable by Kbuild.
Change-Id: I7b64ae8f580d2b11ab5bd46c9346567f4ceabc39
CRs-Fixed: 3673518
Add separate APIs to validate SAP, P2PGO or LL_LT_SAP
channels according to LL_LT_SAP concurrency.
Change-Id: I180796df6b312f9bbb0a8e61085ca1517cd687b5
CRs-Fixed: 3647561
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
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
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
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
Input parameter of sap_chan_sel_init() update from mac handle to struct
mac context, update place where sap_chan_sel_init() being invoked when
AFC enable.
Change-Id: I2fb6af59f02c83f28bd2fad43d287552b662dfbe
CRs-Fixed: 3640939
The current host driver maintains a singular global mac session
for the timer. In situations where the SAP timer runs in one context
and P2P operates in another, the P2P GO context might unintentionally
halt the timer in global mac context for SAP.
Scenario:-
Initially host driver created SAP at index zero, After that it created
another P2P GO at index one before calling start bss api host driver
was trying to stop the interface and dfs timer offload was running for
SAP at index zero, As host driver never initialized cac offload for
P2P GO and dfc timer is running on global mac ctx and it was trying to
destroy the timer during hostapd deinit without even calling timer init.
This is due to absence of checks to validate whether P2P initiated
the timer.
This modification ensures that the timer initiates only when not running
in any session and halts only when the mac ctx and SAP context share the
same vdev id.
Change-Id: I77e14f660b946e8d1a815030f11ad36c14fc8bc4
CRs-Fixed: 3615156
ACS Scan requires reliable scan policy for valid results.
Set the flag to trigger reliable scan for ACS.
CRs-Fixed: 3627456
Change-Id: I269058f567f923396a67d7c36bdb839607d26c5c
As ETSI18 and ETSI20 also added to check SRD channels.
Rename the api of ETSI13 with ETSI.
Change-Id: Ib04e809ba53a55101a6254e0c1ef9f9b37b93fb8
CRs-Fixed: 3616398
Currently if ll_lt_sap needs restart, host driver selects
best bw for the restart channel, since ll_lt_sap always
needs to operate on 20 MHz bandwidth, host driver needs
to keep the bw as 20 MHz always when it selects the restart
channel.
In current scenario, ll_lt_sap is up and country change
happens, current operating channel of ll_lt_sap is invalid
according to new country regulatory which leads to restart
of the ll_lt_sap and during restart, ll_lt_sap is changing
the bw to 40 MHz.
To address above issue, add logic to keep the same bandwidth
for ll_lt_sap restart.
Along with the above change, below mentioned changes are
also taken care as part of this fix:
1. Filter 2.4 GHz channels when policy manager modifies
channel list for ll_lt_sap as there is a possibility
that this API gets invoked from different path other than
get_pcl, in current scenario this gets invoked when host
driver tries to get the restart channel and in that case
policy_mgr_pcl_modofication_for_ll_lt_sap gets invoked
with the policy_mgr psoc list which contains 2.4 GHz channels
as well.
2. Return current SAP frequency from wlansap_get_chan_band_restrict
API if SAP need not restart and add a check in the caller API
to not restart the SAP if the restart freq is same as the current
frequency. currently wlansap_get_chan_band_restrict API returns
0 if SAP need not restart or if it does not find any valid frequency.
If this API does not find any valid frequency for SAP restart and
if current SAP frequency is invalid (for ex: if country changes)
then this API returns 0 and the caller does not restart the SAP,
which results for the SAP to operate on invalid frequency.
With this change wlansap_get_chan_band_restrict API returns different
values if SAP need not restart and if SAP needs to restart and there
is no valid frequency.
Change-Id: I90378623265a9f5879e82cecb7c1cfcb9adc7a27
CRs-Fixed: 3617465
Currently if SAP channel switch fail, SAP will be stopped by function
wlansap_stop_bss(), but this function will not clear connection info
in policy manager, it lead to some concurrency check failure, and SAP
stopped event will not notify user space.
Add SAP channel change response status to SAP channel change response
event, and check if status fail schedule worker to stop SAP completely,
so that can notify policy manager and user space about this SAP stopped
event. And do not have to indicate new channel to kernel if channel
change failed. If CSA procedure interrupt by SAP stop, clear channel
switch in progress flag after SAP stopped.
Change-Id: I802404a4ed4948d072525d6e3676866c382eb442
CRs-Fixed: 3586579
Currently SET_DISABLE_CHANNEL_LIST command is used to disable
legacy channels only.
Update this command to accept frequency for all the bands along with
the channel numbers from legacy (2.4 GHz/5 GHz).
Change-Id: Id55493acfa115da059404af1cd3901e877e46632
CRs-Fixed: 3601196
If disconnection event is for link switch, do not trigger SAP
force SCC check. And if link switch is in progress, skip
the force SCC workqueue.
And if link is in middle of switching, do not run link force logic.
Change-Id: I4a8bf59ff16dca2caf560eb36e1bc58f7d6a919b
CRs-Fixed: 3590814
The API wlansap_get_valid_freq was used to get new SAP channel
when country code changed from world mode to non world mode.
In STA+SAP concurrency case, SAP may be force SCC to STA channel
or the other band's channel. And If STA is disconnected, normally
the SAP should move back to original channel frequency on 5 GHz or
6 GHz. But in current code the API wlansap_get_valid_freq will
still be invoked to get new SAP channel based on PCL after STA
is disconnected. It is not expected.
Fix by add new master_ch_list_updated flag to indicate
the master channel list has been changed from 2.4 GHz only to
2.4 GHz + 5/6 GHz and based on the flag to invoke
wlansap_get_valid_freq to get new SAP channel.
The move back to original channel has been handled by
policy_mgr_is_sap_restart_required_after_sta_disconnect.
Change-Id: I33b7a4cda3b45221b45e2aec85069477d0999d4e
CRs-Fixed: 3596546
Currently if CAC in progress, it prevent SAP restart happen, if there
is some event like set band command come during CAC wait time, it is
not possible to restart SAP even after CAC END.
Change I54663bdd887e3d591d7fd9ee7ce76572b1ef21f7 moved
check_concurrent_intf to SAP interface manager, which will not invoke
when CAC END, so add policy_mgr_check_concurrent_intf_and_restart_sap
in sap_cac_end_notify().
Change-Id: Ida370804d0c7145b750c9dad5c169b74f9c37cd6
CRs-Fixed: 3586509
There are two APIs wlan_get_opmode_vdev_id and
wlan_get_opmode_from_vdev_id present in the host driver for the
same task.
With this change, remove the duplicate API wlan_get_opmode_vdev_id
from the host driver code.
Change-Id: I7ff45610ff18da9c002e22c5be06f1414d3835bc
CRs-Fixed: 3593560
Currently PM_LL_LT_SAP_MODE is not handled in policy manager.
With this change add support for PM_LL_LT_SAP_MODE in the policy
manager.
Change-Id: Icfbb3a95dc65225fc7dad5df7dca9306a5029402
CRs-Fixed: 3536491
Move tSapChSelSpectInfo structure from sap component to mlme
component so that it can be use by LL_SAP as well
Change-Id: Ic3c2919054326aca3530071df27d425bb78a699a
CRs-Fixed: 3561182
Currently if SAP start on DFS channel and band restrict to 2 GHz, it
will move to 2 GHz channel and when band restore it can not move back
to original DFS channel, it may lead to concurrency fail in some 4 SAP
scenario.
Because wlan_reg_is_enable_in_secondary_list_for_freq() only check
channel ENABLE state and ignore DFS state, replace it to
!wlan_reg_is_disable_in_secondary_list_for_freq() so that original
DFS channel can be selected.
Change-Id: Ie39564c51a4a54e76a5df6e639961f82f30d9e16
CRs-Fixed: 3586421
Populate policy_mgr_restrict_sap_on_unsafe_chan() to check whether need
check coex unsafe channel when SAP start on fixed channel, only
restriction_mask from user space configure set SAP bit requires to check
unsafe channel when SAP start on fixed channel. If ACS enable, SAP should
check unsafe channel unless above restriction_mask from user space
configure not set SAP bit.
This change is to change back behavior which changed by Change-Id
I4ccf887655066da6d6b50715f631dde6edfda598, and adjust Change-Id
Ie3947058d8854823a718b833ec788c5c8a14b903 after this change.
Change-Id: If8d26fa7cfdd4ffa44dd2009b4d6939f3d4c49b2
CRs-Fixed: 3525515
Currently if STA+SAP SCC on a 6 GHz channel is present and
host received SET_FCC_CHANNEL 0 command then host disables
all 6 GHz channels except for STA connected channel. If
SAP's bandwidth is greater than 20 MHz then kernel sends
stop_ap as SAP bonded channels are disabled.
To address this issue, do CSA to a non 6 GHz frequency.
Change-Id: I89edf3c862c5b02f0eb5865428bdbb0d43d07f85
CRs-Fixed: 3563476
In the api wlan_hdd_add_vlan(), key index value check
is not present which can cause buffer overflow.
Add keyindex check in the api wlan_hdd_vlan_sap()
in order to prevent the buffer overflow.
Change-Id: I87c606eed6b4e169d6e059cd5d06342c2bc0adaf
CRs-Fixed: 3560531
Initially, if hotspot starts in world mode, it can come up in
2.4 GHz only. Later, the correct regulatory domain gets configured
in the host driver.
Even if this new reg domain supports higher bands and better channels,
the SAP will not be able to move since the ACS list configured
initially is for world mode(only 2.4 GHz channels).
To fix this, after the initial ACS userspace will configure the
ACS channels as per the band preference. Upon new country change,
the host driver will use this updated list to switch to a higher/
better band.
Change-Id: I60524e60798df656b86cbd883a31b00ccd210bc6
CRs-Fixed: 3453679
SAP FSM state is not moved to STARTING from STARTED for DFS freq,
thus CAC complete is not handled in STARTED state and VDEV does
not move to UP state.
Fix this by moving state to STARTING from STARTED for DFS Freq.
Also add vdev id in all FSM logs.
Change-Id: Id8f178d8d7838bdeacdeea50b41dbb19146108c2
CRs-Fixed: 3556248
If the all of valid channels in ACS (filtered by PCL) don’t support
320 MHz, sap_sort_chl_weight_320_mhz should return failure code and then
sap_sort_chl_weight_all will downgrade BW to lower one.
But current code doesn't update valid_chans based on channel "valid"
or not in sap_sort_chl_weight_320_mhz, which causes the API
return QDF_STATUS_SUCCESS if some channels (not "valid") support
320 MHz.
"valid" means the channel is in ACS list(filtered by PCL).
Fix by check channel "valid" or not before update valid_chans.
Change-Id: Ia634f28e09f5446a0ca53aebef8af5c003b38002
CRs-Fixed: 3552093
Currently only store and delete self SAP connection information when
get PCL for mode SAP, if there is other SAP doing SCC with it, the PCL
list may only have SCC channels, but if the SCC channel has unsafe
channel within bandwidth, it cannot move to other safe channel which
has bigger bandwidth.
For example, AP1+AP2 on channel 5240(BW 80 MHz) and AP3 is on channel
2462, COEX AVOID event come and both 5180 and 2462 become unsafe, when
AP1 is going to switch channel it will get PCL list only have 5240, so
it cannot move home channel but just shrink bandwidth to avoid unsafe
channels.
Fix it by also store and delete other SAP connection information SCC
with current SAP if get PCL from get safe SAP channel path:
wlansap_get_safe_channel_from_pcl_and_acs_range().
Change-Id: Ia52c6ac221293036f65173f38cf4b8436629492a
CRs-Fixed: 3534131
If SAP is configured with non 802.11 BE phymode, don't
return 320 MHz BW in wlansap_get_max_bw_by_phymode.
Otherwise, CSA will fail because of invalid BW.
Change-Id: I6fdda48f464bb40b0b88484da4e89f9f91f547e8
CRs-Fixed: 3545596
Currently, In case of SAP CSA, there is a race condition
driver handles the eSAP_DFS_CHANNEL_CAC_START event
from "SAP_INIT" state and move SAP state to "SAP_STARTING"
in schedular thread. Parallelly, if SAP state is used in
hostapd context to handle the event without being updated
which may lead to a assert.
To fix it, handles the eSAP_DFS_CHANNEL_CAC_START event in
"SAP_STARTING".
Change-Id: I01a535c6f86cdf0eff5bb91be870ab33604fb849
CRs-Fixed: 3541842
If "gDisableDFSChSwitch" ini is set, SAP do not change the
channel even if radar is detected. Instead, the SAP is
expected to do a CSA to the same channel. However, during
this CSA, the bandwidth is downgraded to 20 MHz.
To fix this, retain the current SAP operating channel width
in CSA similar to the channel.
Change-Id: I7fa65765ce5f5d249ec65904749af589679dfe3e
CRs-Fixed: 3538115
ACS will mark non ACS channel(filtered by PCL) to SAP_ACS_WEIGHT_MAX.
But the filtered channel still need a reasonable weight to
calculate the combined weight for ACS bw 40/80/160/320.
Assign weight value SAP_ACS_WEIGHT_ADJUSTABLE to such channels and
update it with reasonable after all channels weight are computed.
Change-Id: Iba6565a0f57cc3fe4997427733e922eefc917516
CRs-Fixed: 3537962
If precac interface is in the middle of CAC, do not
entertain any CSA request coming as part of userspace/
country change/unsafe channel handling. Processing the
Channel change request in middle of CAC leads to teardown
of the SAP as SAP is in SAP_STOPPED state.
This leads to pre-cac failure.
To fix this, prevent CSA while CAC and once CAC is finished,
check the sanity of the operating channel based on
unsafe/disable channel list and move it to a valid channel.
Change-Id: I2757753a2a13bdaef60f9b9a46fcd569ddb7306c
CRs-Fixed: 3505593
In api wlan_hdd_add_key_vdev(), for multipass
sap usecase data traffic is dropped during
transition between multiple password due to
group key mismatch for VLAN.
Introduce support to maintain vlan_id_map
in order to facilate the management of group
key for multipass SAP.
Change-Id: I196a02dad2b979bae10d179e15c3187420bbd19f
CRs-Fixed: 3539185
320 MHz channel has overlap between adjacent bonding, so the certer
frequency is not unique, it will check fail if check certer frequency
differ and may not included as a valid bonding.
Remove certer frequency check when doing ACS at 320 MHz.
Fix static analyze error in this file.
Change-Id: Icf500e92ebe64071737161ac1e5a0d22f2a0e08d
CRs-Fixed: 3509363
Set new puncture cap, clear old puncture cap.
For SAP with fixed freq instead of ACS mode, need support puncture too,
need use API sap_phymode_is_eht(sap_ctx->phyMode).
Change-Id: I4bbbd742c3c49111d1725137739557bce18588f9
CRs-Fixed: 3518498
Currently host disables 6 GHz band when set_fcc_channel cmd
is received hence existing STA/P2P client 6 GHz connections
get disabled.
Add changes to keep existing STA/P2P client 6 GHz connections
intact and also keep SAP up on 6 GHz if STA+SAP SCC on 6 GHz
channel was present before receiving this command. Disable all
other 6 GHz operations.
Change-Id: I95c094e1b344d430a288b6f613842efe6e576e25
CRs-Fixed: 3495006
