The macro QCA_SUPPORT_DFS_CHAN_POSTNOL is specific to WIN code.
Therefore remove the macro QCA_SUPPORT_DFS_CHAN_POSTNOL and
associated code from Common code and add it to component dev.
CRs-Fixed: 2829537
Change-Id: Ib49424c44817d6af5e485c87d6f7b08afee4fa11
Remove the following functions from Common dev to component-dev:
1) dfs_bangradar
2) dfs_start_host_based_bangradar
3) dfs_fill_emulate_bang_radar_test
4) dfs_check_bangradar_sanity
5) dfs_start_host_based_bangradar
CRs-Fixed: 2829438
Change-Id: I5d3564bcb89e60629ee7fddc9827e03e9d9da6a2
Add an enum to encode various DFS channel states.
The dfs channel states are represented using a per dfs array object rather
than maintaining a channel state field for each channel (since dfs channel
states are not required for 2G and 6G channels).
The size of the array is approximately 30 because
first_dfs_chan = 52
last_dfs_chan = 161(in case of ETSI EN302 502)
channel_spacing = difference between 2 consecutive 5G channels = 4
size_of_the_array = (last_dfs_chan - first_dfs_chan) / channel_spacing
= (161 - 52) / 4
= 27.25
~= 30;
The dfs channel array is indexed by hashing the frequency. The conversion
(hash function) is as follows:
given_chan_number = (given_chan_frequency - 5000) / 5;
where 5 is: 5Mhz = minimum IEEE chan bandwidth.
array_index = (given_chan_number - first_dfs_chan) / channel_spacing;
Add the following functionalities:
1) initialize the DFS channel state array.
2) update the channel state array.
3) read the channel state array.
4) convert the channel frequency to channel state array index.
5) convert the dfs channel event to dfs channel state.
Change-Id: I7921571fcc80b43a7ef7caf92c34b016fe396e45
CRs-Fixed: 2823529
The macro QCA_DFS_RCSA_SUPPORT is currently residing inside common
code. But this feature is not used by MCL, therefore in order to
reduce code approval process, this macro and associated code is moved
to WIN specific component-dev git repository.
CRs-Fixed: 2822626
Change-Id: I43a9e63ede5958f8641be1be45f7c5cd71820667
After clear nol channel, the number of nol channel is 0. We should update
this information to platform.
Change-Id: Ia39be9a2c53067629460ead6000c2661ead07f63
CRs-Fixed: 2818936
Currently the driver does not have a support to
filter out the 6ghz frequencies from the valid freq
list, and hence there is a high chance of selecting
the 6ghz freq as an operating freq for SAP, which
the legacy clients won't be able to scan.
Fix is to add a support for filtering out the 6ghz
frequencies from the valid freq list.
Change-Id: I8e3552a254e2b79cc1fc09da3e1e06ac378cbb07
CRs-Fixed: 2801414
While getting the bonded channels during radar, if preCAC timer
is running, we use the zeroCAC frequency as the secondary frequency.
Consider a device with agile DFS enabled and the home channel as
160MHz/80P80MHz. If radar is injected on the secondary segment of
the home channel, since agile preCAC is running, the zeroCAC frequency
is considered as the secondary center. This results in wrong
channels being added to NOL/failure (depending on the zeroCAC channels).
Use the zeroCAC frequency as secondary segment center during radar,
only if legacy preCAC is enabled.
Change-Id: I9a99b1c9968e622ffe55c662fd21586cfc587281
While checking for the radar source, the status of preCAC timer
is used to check if rolling CAC is active or not.
However, rolling CAC uses a different timer which results in
radar during rolling CAC to be treated as radar in home channel.
Check for preCAC timer only if agile preCAC is enabled.
CRs-Fixed: 2811313
Change-Id: I1f41e4fb83213abb8fd93531174063fad339f3b7
With bandwidth reduction enabled, when radar is detected during
80p80MHz operation, if the primary segment is unaffected, the
next expected BW for the device is 80MHz. However, the API
reg_set_channel_params has the following bw precedence list:
80P80 -> 160 -> 80 -> 40 -> 20 MHz.
This is valid in normal channel change cases but when used for
the bandwidth reduction feature, 80P80MHz should be considered
same as 160MHz and the next bandwidth (to be checked) should be
80MHz.
Update the channel width in the channel params to 80MHz if
the current channel is 80P80MHz and call the regulatory API
to check channel availability with the updated params.
CRs-Fixed: 2805939
Change-Id: I4337a3a797d1c4b0ef19e47d0933d4dd292733b5
For a 16-MB profile, while insmoding "umac.ko" unknown symbol error for
function "dfs_translate_radar_params_for_agile_chan" is seen.
The actual definition of function
"dfs_translate_radar_params_for_agile_chan" is present in the
dfs_zero_cac.c which is not compiled for a 16-MB profile. Therefore,
the unknown symbol error is seen.
Add ADFS compile-time macros
QCA_SUPPORT_AGILE_DFS and QCA_SUPPORT_ADFS_RCAC to the declaration of the
ADFS specific function dfs_translate_radar_params_for_agile_chan().
As the macros are not present in 16-MB profile, the function becomes an
empty function in the zero_cac.h and definition of
dfs_translate_radar_params_for_agile_chan() is present (though empty)
in the umac.ko.
Change-Id: I2e28090ef99a76dad9f814f739c207f5bf0f2320
CRs-Fixed: 2802734
In the current code the function that gets the bonded sub-channels
dfs_get_bonding_channels_for_freq() does not take into consideration of the
80P80MHz channel. Rather, it takes into account the restricted 80p80MHz
channel and adds all the sub-channels of the restricted 80p80MHz into the
list.
This is not desired because, when the current channel is 80p80MHz,
get bonded channels should also take the segment id into consideration and
should list only the sub-channels of the 80MHz indicated by the segment id.
Modify get bonding channel function, to list the sub-channels of a
80p80MHz channel in such a way that it lists only the sub-channels of
either primary segment or secondary based on the segment id.
Change-Id: Ia6bf001c976603345c15facfa9b23853b7cc185b
CRs-Fixed: 2795460
In the current code, dfs_radarevent_basic_sanity() function is used to
check A) if the current channel is a non-dfs channel B) if it is a non-dfs
channel, a few queues and variables related to dfs filtering are reset.
dfs_radarevent_basic_sanity() is called from two different places namely:
i)dfs_process_radar_ind()
ii)dfs_process_radarevent()
While is okay to perform (B) for (ii) there is no need to do the same for
(i), as (i) is for full-offload chips only and there is no filtering done
in the HOST and thus resetting variable related to dfs filtering is
meaningless.
Instead of calling, dfs_radarevent_basic_sanity() from both (i) and (ii)
define two new functions:
C)dfs_radar_pulse_event_basic_sanity (Call from dfs_process_radarevent)
D)dfs_radar_found_event_basic_sanity (Call from dfs_process_radar_ind)
While both (C) and (D) check if the current channel is a non-DFS channel,
only (C) resets the variables related to filtering.
CRs-Fixed: 2764060
Change-Id: I8466687e889e5f2b9a57c89ef775f14f13dd8066
The "radar on Agile detector" currently checks only if the detector
id in the radar found parameter is the same as the Agile detector id.
Increase the scope of the "radar on Agile detector" check by also
checking if the Agile PreCAC was enabled or if RCAC was enabled and
if PreCAC timer was running.
CRs-Fixed: 2770006
Change-Id: I064560f738bdcbbf4bcb45b37bae71a0829e4146
For the Pine true 160MHz, the Host radar action receives radar parameters
based on the 160MHz synthesizer. Host internally converts these parameters
into 80MHz synthesizer parameters. This conversion API
dfs_translate_radar_params(), does not take care of Agile channel and is
based on the current channel.
Introduce a radar parameter translation API for radar detection on
160/165MHz Agile channel.
Change-Id: I97043da5837545da072d5da3139bc2cc9888aebc
CRs-Fixed: 2784493
When a radar is detected by the Agile detector, the radar found center
frequency is same as the frequency configured to the Agile detector.
This is true for operation in 20/40/80MHz. When operating in 160MHz mode,
the Agile center frquency is the center frequency of the 160MHz channel
and when operating in restricted 80P80MHz channel the Agile detector is
configured with 5690MHz as center frequency 1 and 5775MHz as center
frequency 2. In these cases the radar found frequency should be based on
the segment id on which the radar is detected.
Modify the radar found found agile center frequency based on the
segment id.
While modifying the center frequency in the function to get the
bonding channels, it is to be noted that the API
dfs_get_bonding_channels_for_freq() is based on HK Agile DFS model.
That is, when the current channel is 80P80/160MHz mode, the agile
channel is 80MHz only. Whereas, for Pine, when the current channel
is 80P80MHz, the agile channel is 160MHz mode and when the current
channel is 160MHz, the agile channel might be 80P80MHz/165MHz channel or
160MHz channel.
Accommodate Pine ADFS considerations in
dfs_get_bonding_channels_for_freq().
Change-Id: I31710a73a79a52f29aa4229bc55e08b81311b8d6
CRs-Fixed: 2670679
Initialize postNOL width to CHWIDTH_INVALID instead of 0 which
is mapped to CHWIDTH_20MHZ to avoid channel changes to HT20 mode
after NOL.
Change-Id: I684f38ddb0dc76cccfede74bd6424162407b378f
DA_SUPPORT macro specific code changes are removed
in DFS source code. Also, remove DA_SUPPORT macro
reference in file wlan_global_lmac_if.c
Remove the compile time flag WLAN_DFS_DIRECT_ATTACH
and related souce code.
Other DA-specific code changes are also removed.
Change-Id: Id9fdf547efd0b0332173ac1349811171e4e6acec
Issue: log level for some frequent prints is set to info
those logs would be present in dmesg as well as driver logs
and System performance may get affected due to excessive
logging.
Fix: Avoid redundant logs which may affect system
performance and change default log level to debug.
Change-Id: I053e95806884eab26c37340823b818c9e3c81036
CRs-Fixed: 2771412
The function dfs_mlme_mark_dfs_for_freq was introduced as a counterpart of
dfs_mlme_mark_dfs but both implement same functionality. In order to remove
redundancy, remove dfs_mlme_mark_dfs_for_freq. Replace the references to
dfs_mlme_mark_dfs_for_freq with dfs_mlme_mark_dfs.
CRs-Fixed: 2738831
Change-Id: I567861e4491802d73549670dfd30113b1a773d07
The logging macros implicitly takes care of embedding function name
in the log, hence there is no need to include __func__ again.
Getting rid of redundant __func__ reduces driver memory footprint.
Change-Id: Ife4d1dbb9bfafa4381f1017e331ddef247c649c2
CRs-Fixed: 2774457
During DFS random channel selection, in the function
utils_dfs_get_channel_list, check if inter-band channel switch is
allowed before adding the inter-band channels in the channel list,
from which a random channel is selected as the target channel.
Change-Id: I3f6c88788819039c4b562b462a922edf1baafe12
CRs-Fixed: 2771640
Do not create a DFS object for a radio if the channel frequency range
advertised by the target is a 6G only range.
Change-Id: Ib672902ec3945d00b53ab6d4460584ca889ae387
CRs-Fixed: 2755652
In Dependent Repeater, if the Repeater STA is connected to a Root-AP
in a DFS channel, then the Repeater AP which is configured in ETSI
domain comes up in the DFS channel doing CAC.
In FCC domain, whenever Spoof radar pulse comes, we check if the Spoof
check is done and skip the CAC accordingly. In case of other domains,
Spoof events are not present. Therefore, Spoof test can be always
considered complete for non-FCC domains. Also the test can always be
considered complete if the target/FW does not support spoof test.
CRs-Fixed: 2756845
Change-Id: Icac4dee5f3f69a2578a0a34d7aea9456aab63ece
With the current implementation dfs->dfs_soc_object was initialized in
function dfs_agile_soc_obj_init under the macro QCA_SUPPORT_AGILE_DFS
and ATH_SUPPORT_ZERO_CAC_DFS both of which are disabled for the low
memory profiles. Hence the dfs->dfs_soc_obj was not initialized for these
profiles, this led to a crash when the following access was made in
dfs_is_true_160mhz_supported and dfs_is_restricted_80p80mhz_supported.
psoc = dfs->dfs_soc_obj->psoc
Fix this by unconditionally initializing the dfs->dfs_soc_obj in
wlan_dfs_pdev_obj_create_notification.
Change-Id: I3438464e8efedaf2d62a68bbcf1bda5ee0579deb
Add 6G support for DFS Random channel selection to move to a 6G target
channel in the event of a radar on a radio that supports both 5G and
6G channels.
Change-Id: I1ad65b36feba65b6bbc3affc243aae1beb12960c
CRs-Fixed: 2727958
Move the dfs current channel NULL check inside the routine that does the
sanity check(dfs_radarevent_basic_sanity()).
Since we have two completely different functions to handle radar from:
1) Home channel
2) Agile Channel
we do not need agile detector check in "radar from home channel" function.
Change-Id: Ie91f1d24c948e9d136f49d9ce8bc4cff29327862
CRs-Fixed: 2737944
The process radar found indication was generic radar action function that
caters to both radar on agile channel and current operating channel.
Since this API dfs_process_radar_ind() has been split into, one for
the radar on agile channel dfs_process_radar_ind_on_agile_chan() and
the other one dfs_process_radar_ind_on_cur_chan() for radar on current
channel, and the agile spefic functionalities have been defined in
dfs_process_radar_ind_on_agile_chan(), dfs_process_radar_ind_on_cur_chan()
need not have any agile specific part.
Remove the agile specific part in dfs_process_radar_ind_on_cur_chan().
Also changed the following: dfs_is_precac_timer_running function returns
true for both agilePrecac and legacy preCAC. Therefore replace
"dfs_is_precac_timer_running" by "dfs_is_legacy_precac_enabled" while
checking for the radarsource.
Change-Id: Id6921d0919a7a630d201ef7c1037510285b12d73
CRs-Fixed: 2737327
The process radar indication is huge making it difficult to read and debug.
It can be modularized into 3 high level functionalities based on whether
HW mode switch action is in progress or not, whether the radar found
detector id or segment id is the same as agile detector or segment and if
none of these conditions satisfy then the radar might be on the current
operating channel.
Classify DFS radar action based on HW mode switch status,
detector id and preCAC status into 3 sub-functions.
i) dfs_radar_action_when_hw_mode_switch_in_progress()
ii) dfs_process_radar_ind_on_agile_chan()
iii) dfs_process_radar_ind_on_cur_chan()
Change-Id: I7d862eb08d6373fabaedda4b77deb966466f6b1a
CRs-Fixed: 2737273
The 2 functions dfs_print_delayline and dfs_get_pri_margin are specific
to Partial Offload and Direct Attach. Bringing them under the macros in
order to resolve unknown symbol errors for 16M flash profile.
Change-Id: I0ca1514e37ba54083a9f614825dda4f31a95e7ea
With the current implementation, the chanwidth of the Agile channel
(for both PreCAC/RCAC) is the same as (or less than) as the chanwidth
of DFS curchan. The width of the DFS curchan is determined in the
function dfs_find_curchwidth_and_center_chan_for_freq which calls a
macro WLAN_IS_CHAN_11AXA_HE80 for 80 MHz which checks if the channel
is a 5G channel and 80 MHz. As a result, for wideband (i.e radio has
both 5 and 6Ghz channels), if the curchan is a 6GHz channel this check
fails which leads to invalid chanwidth and RCAC does not start.
Fix this by checking the chanwidth of the DFS curchan for both 5GHz and
6GHz in case of 11AX.
Change-Id: I9aef64cea1d442fc31b2314da08baba7769650f2
In Partial-Offload, when a repeater is associated with Root-AP in
DFS channel. The Repeater STA will get connected with Root-AP and then
Repeater-AP comes up in the DFS channel but it does not send beacons.
The reason is, when a STA vap is UP and in connected state, CAC is
skipped. So, for Repeater-AP we send VDEV_UP before Spoof radar
pulses event. FW rejects the VDEV_UP sent by host and therefore
Repeater-AP will be in UP state but it does not send any beacons.
The fix is, while checking the condition if STA vap is set to true, we
also check whether spoof radar event is completed. If the spoof radar
event is not completed, then we will not skip CAC and then VDEV UP
will be sent after the Spoof radar event.
CRs-Fixed: 2748740
Change-Id: If63f3118d3e40785b375a0bd59d46783c14fe433
Introduce APIs to perform postNOL channel switch to user
configured channel after the NOL expiry of said channel.
This channel change will involve regular CAC after vdev start.
Change-Id: I426b0c4b51c84789870841dd4c3af942be185f20
Following are a part of this change:-
1. Add an API to check if PreCAC/RCAC is enabled. This API is used before
delivering an external event to Agile SM.
2. Post an event to the Agile PreCAC SM if Radar is found on
agile channel. Radar on primary channel is taken care of by the
ensuing channel change.
3. Move all Agile PreCAC changes under macro QCA_SUPPORT_AGILE_DFS,
only RCAC specific changes remain under QCA_SUPPORT_ADFS_RCAC.
Change-Id: I45d4b9f826d36e9e4093879b394165a15a52f324
Both (ETSI) PreCAC and RCAC are going to use use the same state
machine. The state machine drives the Agile engine and not very specific
to RCAC or PreCAC, therefore let the state machine be called agile state
machine and change the names of all the associated variables accordingly.
In this preparatory change, modify names of all APIs, states and events
to make them common to Agile RCAC and Agile PreCAC
Change-Id: I67858839589145bf4377a7eafec7c21ca4823141
CRs-Fixed: 2711104
The radar affected sub channel are determined by the bangradar type,
whether sub-channel marking is enabled or not, the center frequency
of the band on which the radar was detected. This block of code is present
in processing radar indication function and can be modularized.
Move the logic to find radar affected sub-channels into a single function.
Change-Id: Ic0a37fdfa97cbc1bcd2b9a23fd6642f22b43a733
CRs-Fixed: 2737120
If HW mode switch is in progress when a radar is detected, the radar
found channel information is stored and the processing is deferred.
This piece of code is in processing radar indication routine and can
be put under a function.
Move HW mode switch related code under a function so that it is
modularized.
Change-Id: I989ec62a2badbc70734e658a423aa0b8d2eee42d
CRs-Fixed: 2737116
The radar found parameters processing API dfs_process_radar_ind() is
supposed to read-only the radar_found_info parameters and not modify
them. A block of code for PO platforms modify the radar_found_info
parameters.
The function dfs_process_radar_ind() should not modify the radar found
input parameters.
Since in this case the parameter modifications are specific to partial
offload, move the code that modifies the parameters out of the function
into a partial offload specific code.
NOTE:- The previous change I2c717219d0b0f9263734767bee6070f335032b04 also
does the same that is mentioned here but for modification of
full-offload parameters.
Change-Id: Ic438d70eaadb9ef91d28f6a0c22caf4926ed1df1
CRs-Fixed: 2737060
The routine 'dfs_translate_radar_params()' translates the radar found
offsets given by a 160MHz detector which ranges from -80MHz to +80MHz
to that of the offsets given by an 80MHz detector that ranges from
-40MHz to +40Mhz. The same function also translates the segment ID from a
single-detector(160MHz) model to a two-detector model(80Mhz). This routine
is unnecessarily called for partial-offload chipsets which do not support
True 160MHz.
Do not call the function 'dfs_translate_radar_params()' from
'dfs_process_radar_ind()' which is common for both partial-offload and
full-offload. Call it from the full-offload specific radar action
function 'tgt_dfs_process_radar_ind()'.
Change-Id: I2c717219d0b0f9263734767bee6070f335032b04
CRs-Fixed: 2718507
CONFIG_CHAN_NUM_API macro will be disabled. Remove all the references to
any function defined/declared under the macro. The function
reg_get_channel_list_with_power was placed under CHAN_NUM_API by mistake.
This API does not have any CHAN_FREQ_API counterpart. Therefore, move
this function out of CHAN_NUM_API macro.
The function dfs_send_radar_ind_for_freq is redundant as its counterpart
dfs_send_radar_ind has the same arguments and same functionality,
removing the function dfs_send_radar_ind_for_freq. The function
dfs_send_radar_ind is moved out of CHAN_NUM_API macro.
The function wlan_reg_chan_to_freq, wlan_reg_legacy_chan_to_freq is
moved out of CONFIG_CHAN_NUM_API macro. Since it is applicable for legacy
bands.
CRs-Fixed: 2711600
Change-Id: Ib29be638c17ce51f928c865e362ac5b2b8954b42
While selecting the next channel after radar, if RCAC is enabled,
RCAC frequency and ch params are chosen. But in case where no
RCAC frequency was found, ch params were filled with 0s which are
then used by the next channel selection logic (random channel)
to figure out the next channel.
Since the ch params were now 0s, the ch width is pointing to
20MHz (0 enum) which results in a 20MHz channel picked irrespective
of current mode.
Do not modify ch params if the RCAC frequency is NULL.
CRs-Fixed: 2729023
Change-Id: If542fb8584a767ad8d1fe6115af039e8bc2cb173
Use dfs channel structure to store autoswitch channel instead
of a single frequency value.
CRs-Fixed: 2726427
Change-Id: Ib592b75d4f87b4597510a1fc32717633b2b39e21
Add new scan type SCAN_FOR_CONNECT to support connection manager
infrastructure.
CRs-Fixed: 2713772
Change-Id: I631f3f0324e82ef6cd8b2befbed020649c80bc4c
The function "ucfg_dfs_is_hw_pulses_allowed" should return bool and has
a compilation error
"return' with no value, in function returning non-void".
Return the bool type "false" when the dfs is a NULL object.
CRs-Fixed: 2715235
Change-Id: I8717aaedd1ac8208ce6257721d5890b82ca13a8f
The OCAC completion event 'wmi_vdev_adfs_ocac_complete_event_fixed_param'
has been updated to include center frequencies of 2 segments in MHz for
165Mhz Agile mode.
Update the corresponding Host OCAC completion data structure
'vdev_adfs_complete_status' to include 2 center frequencies to support
165MHz Agile mode.
Also FW might send a delayed OCAC completion status after the Host has
configured a new agile channel. So all the OCAC completion events should be
validated if the status is received for the current agile channel.
Update the OCAC completion processing API to include 2 center frequencies
and chwidth so that, it is possible to check if the OCAC completion status
is received on current agile channel or an obsolete agile channel.
CRs-Fixed: 2705671
Change-Id: Iab8980f8d030120d107f068d890c9694d28ee98c
