Currently in case of LTE-coex event, the driver restarts
the SAP to a new channel if the current SAP operating
channel is unsafe.
In the current logic the driver gets the PCL apply the
logic to remove unsafe channels, NOL channels etc.
and then chose a final channel for the SAP.
Now for the case of standlaone SAP the PCL would contain
only 5ghz channels, and it may be the case that ACS
channel list contains only 2.4ghz channels because
the SAP was initially started on 2.4ghz band.
Now with the intersection of 2.4ghz and 5ghz, the driver
would not get anything left to restart the SAP and the SAP
restart would eventually fail.
Fix is to directly check the number of connections as 1,
that would mean only SAP is present, and if it is the
case, just restart the SAP on any other channel from the
ACS channel list rather than intersection with PCL.
Change-Id: If3a77ca877b2bf5e83ca64930e716936f680940f
CRs-Fixed: 2556054
Currently the driver in case of force SCC picks up
2.4ghz SCC channel if any other STA/AP is already
up on that channel, so in the process of shifting
in the API sap_validate_channel it picks up 2.4ghz
and calls a reg API to set the freq related params
to it. Now since the frequency for 2.4ghz is 40 mhz
capable the max BW supported for 2.4ghz becomes 40 and
the driver starts the SAP on 40mhz.
Now since the OBSS scan is offloaded to the hostpad
and now since it was driver which started the SAP
on 40mhz there is no mechanism to start OBSS scan
from driver, which leads to channel blockage if
any legacy 11g, 11b lient is operating on the channel.
Fix is to lower down the BW to 20Mhz if the SAP does a
force SCC in 2.4ghz.
Change-Id: I0d85dfb5e9e8332957d853173063e77d18ea600c
CRs-Fixed: 2581495
Currently the driver does not set weight calculated flag
in the spectrum channel structure for each channel as
true in 40, 80, 160 sorting case.
Now in the next iteration the weight calculation done
comes as false, and the weight is set as maximum
which leads to wrong channel and BW selection and the
last while running channel selection logic.
Fix is to set weight calculation done as true for all
the channels which come under the particular BW, and
skip the channels for which the weights are already
calculated.
Change-Id: Ib355dd5cf7c3aeeb5534bfa295785bdfc30eed86
CRs-Fixed: 2583538
1. Convert channel to frequency and use frequency
Regulatory API to check DFS status.
2. Skip dfs check for 6G channels.
Change-Id: I54b6d6a3ad25c192af4eec4e7f43932bada728b5
CRs-Fixed: 2580568
For SAP/P2P GO on 5G, when receive cmd to disable 5G band when
modem n79 band used, will move to 2G band via CSA.
1. If no active connection on 2G, select ch by safe list, or
channel 6.
2. If there is STA on 2G, force scc with it.
3. If there is SAP/GO on 2G, force scc with it.
4. Handle one race condition that if candidate is already
selected & FW has gone ahead with roaming or about to go ahead
when set_band comes, it will be complicated for FW to stop the
current roaming. Instead, host will check roam sync to make sure
the new AP is on 2G, or disconnect the AP.
5. If 2 SAP on 5G, move both to 2G and keep scc.
When Set band to enable 5G band again, restored all 5G SAP/Go..
Change-Id: I9b2b1ead3b4502022aeefc08359037457bb051f9
CRs-Fixed: 2580204
Currently if the first channel if seen in the normalize
acs weight array is found, the driver does not set the
freq present as false back, which leads to further
disabling all frequencies for SAP which should not be
the expectation.
Fix is to set the freq present as false again for the
next frequency.
Change-Id: Iabeb40179a0ef02cb51441b1148eea79b82d0ebf
CRs-Fixed: 2578551
Currently the driver does not fill the seg1 frequency
in case of 160 mhz which is used for SAP startup.
Fix is to Fill seg1 for 160 mhz BW in ACS result
Change-Id: Iffc61581290adf97d83e10b6a717c50afb750687
CRs-Fixed: 2575631
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
