- Remove wlan_reg_set_channel_params and the callers
associated code.
- Clean up part of CONFIG_CHAN_NUM_API functions.
Change-Id: If9583e674752d6f47de8d7d6bc946909509957b5
CRs-Fixed: 2883773
A huge number of prints come under dfs_err. Enabling all of these
unnecessarily floods the console and some of these prints show up for
expected behavior such as the dfs object being null for a 6GHz radio.
Only memory specific prints could be enabled specifically later.
CRs-Fixed: 2887966
Change-Id: I27091924450d1cc3d4e3df38e49f1a537e080bc6
dfs_set_nol function is also required by MCC DFS function, Change-Id
I6c74dd13a16acb2a67bb3b477b13bc0e4ee165ce move implementation from
common code to WIN, add back it.
Change-Id: I46c16eec82024c3af4b4cee02ff19edb0023d3b6
CRs-Fixed: 2875061
During wifi load and unload, multiple memory allocations and deallocations
are done in the path of dfs_deinit_precac_list, and at a particular
instance there is a crash seen due to an invalid paging request.
The QDF_TRACE_LEVEL_ERROR logs are not enabled by default. These prints
can be useful in debugging the issue when it occurs the next time.
Hence, the dfs_err prints are enabled by default.
When a crash occurs with the dfs_precac list functionality, debugging the
crash with dumps in T32 is difficult. During wifi unload, the api
wlan_dfs_pdev_obj_destroy_notification is called. On first step, the pdev
component is detached making the pdev component as NULL and after that
dfs component is detached. So when crash happens at this point, pdev
component is already NULL and analysing dumps with T32 is useless at this
stage.
Therefore, modify the order of dfs detach in
wlan_dfs_pdev_obj_destroy_notification. First detach the dfs component and
then detach the pdev component.
CRs-Fixed: 2872097
Change-Id: I157c6e6272bf4dd3676588b7ee6889fdb2efa5dc
After NOL expiry of the radar hit channel, the scan channel list
of the FW is updated to include 'NOL expired' channel as well
so that FW can initiate subsequent scan on this channel.
Only those channels which are not marked as NOL in regulatory
are updated in the scan channel list.
However, in the current flow of events, the scan channel list is
first updated via dfs_nol_update() API and then channel is
unmarked as NOL in utils_dfs_reg_update_nol_chan_for_freq() API.
Hence the NOL expired channel is not updated to FW and subsequent
scanning does not happen on this channel.
Ensured that the channel is cleared of NOL flag before updating
the scan channel list.
CRs-Fixed: 2877337
Change-Id: I7331bcc12c1dd6a26407c0753f28481cee1ce628
Add function declaration for dfs_restart_rcac_on_nol_expiry()
API. This API helps to restart RCAC on NOL expired channel
with interCAC and RCAC feature enabled.
CRs-Fixed: 2860727
Change-Id: Ifc06ed938ebc7cc6ccbe68989158939d6f399c46
Add function declaration for mlme_proc_spoof_success API and its
corresponding function pointers. This API is used to process spoof
completion status from FW.
Change-Id: Ia25ffd01619a0c9d1e5a1bc4c20623b75ee8d75e
During DFS_SPOOF_FAILURE Check, the reason for failure is unknown.
So for debugging analysis purposes, add debug prints to print the
average params that are sent to FW.
CRs-Fixed: 2847047
Change-Id: If1e20352f62f4286396a9f93f49c528bbf38f95e
Remove utils_dfs_bw_reduced_channel as this
function is not used by MCL or WIN.
Change-Id: I042578fea76cd845b90f240fa3e814e50f2eaf5b
CRs-Fixed: 2859799
The sm engine header files are required only for ADFS sm handling.
Move the header file to the ADFS sm source file.
Change-Id: Icc77a889d6bf28d8c0b20a12944f9be78d1a8c27
CRs-Fixed: 2853428
DFS component's pdev private object allocation is skipped in
few scenarios. In this case return agile precac enable as false.
CRs-Fixed: 2853435
Change-Id: I7725e9bcbd05b2c9f1b1ee217cc8eb8a2df8144a
If STA DFS is enabled before vdev creation through etc/config/wireless
then VDEV START is sent to F/W as a part of the normal flow to bring
the VAP up. However, if STA DFS is enabled/disabled on the fly for a
running VAP then do a VDEV STOP, followed by a VDEV START of the STA
VAP and set/unset WMI_CHAN_FLAG_STA_DFS flag in VDEV start.
Change-Id: I032ffa53d89eaafcb43c648670af3b3f2134561f
CRs-Fixed: 2843248
There is compilation issue since dfs macros only defined with
WLAN_COMP_CHAN_MODE. So adds related definitions for the case without
WLAN_COMP_CHAN_MODE.
Change-Id: I4b9f16b5000304157067be565864cc79c510770f
CRs-Fixed: 2848979
Reorder channel mode macros to have macros in logical
order, and to optimize the channel modes to use
bit specific enums instead of single bit to reduce
the usage of number of bits. The changes are specific
to host
Example for Channel mode: IEEE80211_CHAN_HE20
Channel modes represents only the information regarding
to channel such as band, width, passive, DFS, blocked
40MHz_intolerant and so. It doesn't have information
regarding hwmode like 11ac,11ax.
CRs-Fixed: 2846331
Change-Id: I197de032a4d677a27b46028fa090a6eabe0c6086
In DFS, to check if a channel is radar, we use the flags that
are filled from UMAC to check for radar. Since the channel list
in UMAC are dynamically calculated, the dynamic flags will not be
consistent over multiple channel pointers.
Use the radar information in regulatory for individual subchannels
to check for radar in a given channel. Define these new APIs
under a feature specific macro.
Change-Id: I7f86560c3d29d2366c6506ccf63204263cbc0ef1
CRs-Fixed: 2841168
Move the WIN only DFS features from common code to WIN specific
Component dev. The following features are moved.
1. WIN Hardware mode switch.
2. StaDFS
3. dfs_set_nol
4. nol_history
CRs-Fixed: 2834311
Change-Id: I6c74dd13a16acb2a67bb3b477b13bc0e4ee165ce
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
