Currently the driver calculates the best channel
amoung the given spectrum and uses logic to select
best frequency amoung the BW members, but the logic
to maximize the weight before selecting the min
weight is wrong, and must be done after the selection
of the minimum weight frequency.
Fix is to maximize the weight after the minimum weight
channel is selected.
Change-Id: Ie196462fbcc4215e6eb655168d07305110ff0ee7
CRs-Fixed: 2578582
Currently in stop adapter the driver checks the ACS bit
in progress and then waits for it to get complete
Now if in scheduler thread the sap scan cb comes then
it will check to get op protect which would not be
granted as it is a pdev operation, and already a vdev
transition is in progress, hence the bit for acs in progress
would not get cleared.
Fix is to remove the check of op protect as it is no longer
needed since the stop adapter takes care of acs in progress.
Change-Id: Ifebaed87e3a798126031d9971dc801d60fd34ea6
CRs-Fixed: 2567157
Fix indentation issue in sap channel select to
avoid compile failures in auto branch compilers
Change-Id: Ifa92dfaaa349833d5651b7cdb66d87f039f0df36
CRs-Fixed: 2568414
In ACS, driver uses frame parser to get the HT/VHT/HE IE to fill
bandwidth, center freq etc. These info are already available in
scan entry so use them.
Change-Id: I5148f8aa20174b4fa0fc64acd7b74825e10ede03
CRs-Fixed: 2568513
Change vht_seg0_center_ch and vht_seg1_center_ch in acs_cfg
struct to vht_seg0_center_ch_freq, vht_seg1_center_ch_freq
respectively.
Change-Id: Ie3378376e6f31c239157c8eaaf3ceb22d2e35073
CRs-Fixed: 2564065
Change acs->start_ch and acs->end_ch to acs->start_ch_freq
and acs->end_ch_freq respectively.
Change-Id: I105cd618970c739340df29d58f635d01a68754d2
CRs-Fixed: 2564018
Acs changes for 6ghz to change chan to frequency
in the spectral params structure.
Change-Id: Iffd348ac5c2457b313b702a92b340a258992e764
CRs-Fixed: 2564043
Convert primary, secondary channel for acs cfg to freq as part
of ACS 6Ghz changes.
Change-Id: I4f6220b39dae91df070b0764fa8b048cdc6ad00f
CRs-Fixed: 2555988
At the time of starting / stopping 2nd or 3rd connection,
Host sends WMI_PDEV_SET_HW_CMDID command to FW to change
HW mode to DBS / Single-Mac based on concurrency rule.
FW upon receiving this command turns off TXRX chainmask
which means that radar pulses might get missed for
20ms - 50ms during CAC period. To fix this, Host should
block new connection when existing SAP is performing CAC
on DFS channel.
Change-Id: I51eb117afa763a6ef54211808875419026c9075b
CRs-Fixed: 2533717
For 6GHz support and to remove channel number ambiguity use policy
manager APIs updated for frequency in other modules. This change
covers following APIs:
policy_mgr_get_pcl
policy_mgr_update_with_safe_channel_list
policy_mgr_get_valid_chans_from_range
policy_mgr_get_valid_chans
policy_mgr_set_sap_mandatory_channels
policy_mgr_get_pcl_for_existing_conn
policy_mgr_get_mode_specific_conn_info
Change-Id: Ia21829345be2746cd3fc1f2337cfc90abf0c53f4
CRs-fixed: 2550092
For 6GHz support and to remove channel number ambiguity use policy
manager APIs updated for frequency in other modules. This change
covers following APIs:
policy_mgr_get_chan_by_session_id
policy_mgr_get_mcc_operating_channel
policy_mgr_check_and_set_hw_mode_for_channel_switch
policy_mgr_is_chan_ok_for_dnbs
policy_mgr_is_safe_channel
policy_mgr_valid_sap_conc_channel_check
policy_mgr_disallow_mcc
policy_mgr_add_sap_mandatory_chan
policy_mgr_remove_sap_mandatory_chan
policy_mgr_is_hwmode_set_for_given_chnl
policy_mgr_is_valid_for_channel_switch
policy_mgr_update_user_config_sap_chan
policy_mgr_is_sap_restart_required_after_sta_disconnect
policy_mgr_is_sta_sap_scc
policy_mgr_nan_sap_scc_on_unsafe_ch_chk
Change-Id: I682f8380d9dc41fc015d73f06b6e055d1d04ef97
CRs-fixed: 2545110
For 6GHz support and to remove channel number ambiguity use policy
manager APIs updated for frequency in other modules. This change
covers following APIs:
policy_mgr_allow_concurrency
policy_mgr_nan_sap_pre_enable_conc_check
policy_mgr_allow_concurrency_csa
policy_mgr_current_connections_update
policy_mgr_incr_connection_count_utfw
policy_mgr_update_connection_info_utfw
policy_mgr_get_channel_from_scan_result
policy_mgr_update_and_wait_for_connection_update
policy_mgr_get_sap_mandatory_channel
policy_mgr_checkn_update_hw_mode_single_mac_mode
Change-Id: I162c2b90a58539194907c5ecd6915eafecc635cc
CRs-fixed: 2545099
Handle error condition of vdev not found (Logical delete
state), and scan req memory not allocated to prevent mem
leak for SAP ACS channel list.
Change-Id: I0ab00c0119f80299cc8d93236839e42c647b939f
CRs-Fixed: 2547058
As a part of 802.11ax amendment, 6GHz band operation is added.
Since the 6 GHz channel numbers are overlapping with existing 2.4GHz
and 5GHz channel numbers, use frequency to identify unique channel
operation instead of channel number. Channel frequency is unique across
bands.
As part of above requirement add logic to process rx mgmt
packets based on the frequencies instead of channel numbers.
Change-Id: Ib063070738ecdb4f83379eafe50629778a490aae
CRs-fixed: 2522693
To support 6Ghz channel, update channel number of struct
sap_StartBssCompleteEvent_s, hdd_ap_ctx and sap_ch_selected_s.
Change-Id: I19e6d7d03072135abed25e077e8573b5326ddba8
CRs-Fixed: 2519308
Use wlan_reg_set_channel_params_for_freq to update SAP channel
parameters. The "freq" version API can handle 6GHz channel properly.
Change-Id: I519de47d4ec1fa1351b120f2faa9f23de1064493
CRs-Fixed: 2536568
Normalize the weights of the frequencies for ACS scan
if the user has changed them in the ini.
This is done as legacy devices wont be able to scan
the newly added 6ghz frequencies, and thus wont
be able to associate with the SAP if it starts
on 6ghz channels.
Change-Id: I2dd2f706c248f5339bde06963540d0874d08b847
CRs-Fixed: 2543007
It has "ISO C90 forbids mixed declarations and code"
build issue on the LE.UM.4.1.1, so fix it.
Change-Id: I0bc918f55e9a7d3c540a455ed292977c15300456
CRs-Fixed: 2542657
Currently the driver uses a global safe channel
list, and also keeps another safe channel list in
policy mgr which results in duplicate copies
of the same thing.
Also there are many possible issues which are seen
if the global list implementation is used.
Issue 1:-
The global unsafe ch list is maintained for each
channel and is updated as part of ACS scan cb.
So if a user does ACS again and again ( SAP on off)
then the result of unsafe channels of the previous
ACS request would be updated as part of the ACS cb
of the new ACS scan request.
In the function of sap_get_freq_list, the driver
filters out the channels which are unsafe, and the
same channels are not chosen as the best channel for
SAP operation.
Now the filtration of the channels would happen
according to the previous ACS request, and the driver
would remove the channels from the ACS scan list.
But those channels were unsafe when the previous ACS
happened, and may not be unsafe now, and can be used
to turn on the SAP (can be chosen as the best channel)
Issue 2:-
If the channels are truly unsafe, then the driver
filters out the channel in the function sap_get_freq_list,
and do not chose them for the SAP.
It may happen that the channel list that the driver
preferred as part of do acs becomes unsafe, and the
channels that were unsafe at the time of do acs becomes
safe while the driver was scanning the ACS channels to
find other APs.
Now since the channels that were unsafe at the time of
ACS req are safe now, they could have been chosen as the
best channel but they were not scanned, so the ACS channel
weight of these channels would remain maximum, and they
would be sorted at last of the sorted list.
Also the channels that were as part of the ACS channels list
became unsafe, hence the driver would also assign maximum
weight to them, and they would too become unusable channels.
This would result in all channels having the same weight that
is maximum weight, and so the sorting algorithm does not have
to sort any channel now since all of the weights are same.
The first channel in the sorted list would be channel number
1 of 2.4Ghz, and would get chosen, but this may not be
correct if the HW mode is 5ghz only.
Fix:-
Safe and unsafe channels can be checked by using
policy mgr safe channel list too, so it is better
to keep just one unsafe channel list.
The driver would not filter out the unsafe channels
for ACS scan, and would filter out the unsafe channels
as part of the ACS scan done callback.
Change-Id: Ief236db9e73864e5cb2d290a8106799f9e80f82d
CRs-Fixed: 2530241
When vdev_mgr_start_send is introduced, the Dfs->dfs_curchan
will be filled from mlme "des_chan" by tgt_dfs_set_current_channel.
Set correct channel flags to des_chan so that dfs radar functions
can get correct channel information.
Change-Id: I643acadb97c3924261b45f598a50fa82d9a224e6
CRs-Fixed: 2529996
Enable configurable dfs_pri_multiplier. The ETSI typ2 type3 radar
detection ratio is lower than expected(>80%) while channel loading is
high(>30%). The host improvement for this are:
1. Add configurable dfs_pri_multiplier, controlled by
DFS_PRI_MULTIPLIER. Default value 2, min 1, max 10.
2. Lower adrastea ETSI type 2/3/4 radar filter rssi_threshold,
controlled by DFS_OVERRIDE_RF_THRESHOLD, dfs log shows that
QCS405 target report RSSI range [18, 45] while radar power
is 3 dbm. By using default rssi_threshold 24 will reject
many radar pulses, which leads to low detection ratio.
3. Calculate deltapri for each searchpri based on dfs_pri_multiplier
in dfs_count_the_other_delay_elements(), check deltapri
between [1, dfs_pri_multiplier] * refpri and searchpri, if
the primargin is desired, mark it as matched pulse.
4. Pick lowpri as refpri for the radar filter with
rf_ignore_pri_window equals to 0 while DFS_PRI_MULTIPLIER is
enabled. Observed original findref logic has some problems
which selects refpri is bigger than lowpri, which leads to
the lowpri pulses pri_match are set to 0, and in this case,
radar was not detected. Example for the issue, assume
rf->rf_pulseid 34 (ETSI type 2) has 7 pulses with pri:
1489, 2978, 2978, 2978, 1489, 2978, 1489 us in this case,
highscore is 4 (2978), scoreindex is 5, refpri is 2978, which
leads to: index 0, 4, 6 pulses with pri_match 0 in
dfs_count_the_other_delay_elements(). The fix is to select
lowpri as refpri(1489 in this case).
Change-Id: I1f3ca3298c9ab1f1e2651ad6b4a0a4810f83f8a1
CRs-Fixed: 2522506
Replace channel ID with frequency in struct hdd_channel_info
& oem_channel_info.
Change-Id: I1a14ab40da4824d2861a7ec862cc322a158f0cd1
CRs-Fixed: 2532299
Currently the SAP memory is not freed as part of stop
adapter as the sap ctx is mem zero in deinit ctx, hence
the addr to free in NULL
Fix is to extract the the sap config from adapter and
then free the sap ch list memory from it.
Change-Id: I8c0bf66765c34f0936d694d260ce1544791beecc
CRs-Fixed: 2530985
Update SAP data structures to use channel frequency values instead
of using the channel id values to support 6GHz channels in SAP.
Change-Id: I9ef5857e8dcf3f7d879495d3f3c3ead083fe0bf0
CRs-Fixed: 2513083
Currently the driver does undo acs which clears away
the acs cfg ch list, master ch list, and sap_ctx->ch_list
before the ACS is complete (race condition), which can
lead to pointer access after free.
Fix is to wait for ACS complete event, and then clear away
the above mentioned ch lists.
Change-Id: I55de1e94d1fc3ebb99891465131de11ea3204778
CRs-Fixed: 2519650
CONFIG_LEGACY_CHAN_ENUM has been removed. That macro needs channel number
based enumeration. Use channel frequency going forward. So change to
frequency based channel enumeration.
Change-Id: I234eb070a6dcfaf3325bbd523c19188d5b2bbd24
CRs-Fixed: 2513098
Currently the sap ctx's channel list is not freed
as part of undo acs, and hence can lead to mem leak
when the do acs and SSR is triggered in parallel.
Scenario:-
1. Turn on SAP
2. Do SSR in parallel
3. Unload WLAN
Fix is to clear the channel list as part of undo
acs.
Change-Id: Ie8dcace1d32aeec2621e785d793290d70c194f62
CRs-Fixed: 2511752
Copy the sap channel list that is obtained after filtering
the channel list from all the checks like SRD, DFS
to maintain the sync between the ACS module, and the sap
channel select logic.
Change-Id: I78a835f700ab34fa81b9b748e6ad28ca3b726650
CRs-Fixed: 2513628
In case of DBS, two AP can operate on different band together.
Current logic of resetting CAC state in sap_clear_global_dfs_param
function assumes that if two APs are up state then it must be SCC
scenario and resulting in dropping of tx packets if stop follwed by
start operation is performed on AP on DFS channel.
This change reset CAC state as part of stop AP if another AP is
operating on 2.4GHz in case of DBS operation.
Change-Id: I3f71606bf610d45184a0fa81d2b9d9a6c11f72e8
CRs-Fixed: 2509808
For runtime PM if the bus is suspended driver need to consider
extra 6 sec time for bus resume.
Thus add 6 sec extra in WMI timeouts if runtime PM is supported.
Change-Id: I5515cc889a0315382bac11a33ea6f901b7af1c46
CRs-Fixed: 2507029
Currently the driver selects channel 12, 13 as they are
free from BSS as their weights are minimum, which results
into IOT issues as legacy STAs do not support the same.
Fix is to avoid channel 12, 13 in SAP ACS process, and try
to start the SAP on channels from 1 - 11.
Change-Id: If735fade7d7b489b45a20f74c04bab5582343f79
CRs-Fixed: 2509791
1. Add g_enable_go_force_scc INI configuration
to enable force SCC on P2P GO interface.
This option only takes effect when
gWlanMccToSccSwitchMode INI enabled.
2. Add API policy_mgr_is_go_allow_force_scc to get
the above configuration value for GO.
Driver will apply "MCC to SCC" logic to P2P GO
interface based on STA active status and the configurated
INI values.
Change-Id: I1d16368b5f2d88984b91ef0a3e882148c20dcd23
CRs-Fixed: 2509555
Currently the driver calls the pre bss scan cb
which is used to calculate the weight to start
the SAP on best channel. This API depends upon
the SAP context pointer which is passed as a arg
to the scan module, which in turn returns the arg
as part of the scan cb. But it may happen that
the SAP was deleted before the scan cb was called.
In that case pre bss scan cb and weight calculation
does not matter to the driver as SAP in any case is
OFF. Here the sap context which was passed as an arg
to the ACS cb is used after free, and there is no way
currently to validate the pointer. But as part of scan
cb, the driver gets a vdev pointer, which would be in a
logically deleted state, if the stop adapter for SAP has
been done. Using this data, the driver can know the object
status, and then decide to continue with the weight calculation.
Fix is to try get vdev ref before the weight calculation algo
kicks in, and return if the reference cannot be taken to avoid
use after free for SAP-context.
Change-Id: Ib9c3bde4a36ee49efdadab3dc531991b8688f79e
CRs-Fixed: 2509249
SAP1 chan6, SAP2 chan6, LTE channel avoidance event marks
chan6 unsafe, driver will do channel switch for SAP1 and SAP2 to
safe chan 1.
In the middle of channel switch of SAP1, policy_mgr_allow_concurrency
disallows the channel switch request because new SAP1 channel 1
will cause MCC with existing SAP2 (channel 6) and firmware
doesn't support MCC for dual-beacon entities on same band.
This change removes all the SAP entry on the old channel
before do concurrency check for SAP channel change request.
Change-Id: Ic2c828a3fec4cbe2f11d4bedf471211bee442e9e
CRs-Fixed: 2491265
Currently the driver modifies the channel list
which came from hostapd in trim channel list API
in case of concurrency present.
This would in turn prevent SAP to change channel
to a safe channel whenever a LTE-COEX event comes
as the acs channel list would contain only one channel
that would be the SAP channel itself.
Fix is to retain the info of channels which came from
the hostapd, and use this info to restart he SAP.
Change-Id: I9d43930d78f1eaedb01139a9ddc319b610d21862
CRs-Fixed: 2501400
Currently if the driver does not find any scan results
in the ACS scan, it selects a best channel as the PCl
channel by filtering the PCl list based upon the start
and end channel, which may not be correct everytime
as start and end channel does not specify the channels
to be selected.
Fix is to select a default operating channel from the
acs list itself, if no scan results are present.
Change-Id: I9a76957087b9349da66545e0fcaede2355f732cd
CRs-Fixed: 2504796
Remove operationChannel from structure csr_roam_profile, remove
the code where value assigning to operationChannel take place.
Change-Id: If7cd64d4d7513000181f92faabd6c863341c71f9
CRs-Fixed: 2503043
After got restart channel rsp from fw, vdev state will change
as: ST-RESTART_PROG->ST-CONN_PROG.
In lim_send_sme_ap_channel_switch_resp, if channel is non-dfs,
vdev state will change to up; if dfs channel, later it will
change to DFS CAC when starting cac timer.
Current issue is if there is ap stop after restart channel rsp,
while processing WLAN_VDEV_SM_EV_DOWN, there is no hanler in
ST-CONN_PROG > ST-DISCONN_PROG.
From design perspective, In SAP, ST_CONN_PROG is a dummy state,
ideally, SAP state should change as below without preemption :
RESTART_PROGRESS->CONN_PROGRESS->UP
RESTART_PROGRESS->CONN_PROGRESS->DFS_CAC_WAIT
To fix issue, change vdev state to DFS_CAC_WAIT in
lim_send_sme_ap_channel_switch_resp; So WLAN_VDEV_SM_EV_DOWN will
be handled in DFS_CAC_WAIT state.
At the same time, set DFS_CAC_WAIT when starting SAP, and clear
sap_move_to_cac_wait_state in sap state machine.
Change-Id: Iee89521471e456a553f40577da6d1e69aef3b803
CRs-Fixed: 2501339
