Add a dispatcher API ucfg_dfs_is_agile_rcac_enabled() to determine
if RCAC is supported for the given pdev.
Change the prototype of dfs_get_rcac_enable() to store rcac
config in a bool datatype.
Also, do a structure copy of ch_params of RCAC channel in
utils_dfs_get_rcac_channel().
CRs-Fixed: 2679975
Change-Id: I4b033463fc8111144bfffd3bb7e7d2bef6568c46
Trigger Rolling CAC SM events from
- NOL expiry (EV_RCAC_START) to trigger RCAC START with a
new channel if possible and not already running.
- Agile radar (EV_ADFS_RADAR_FOUND) to restart RCAC with a
new random channel.
- vdev restart (EV_RCAC_STOP) to stop the running RCAC when
the primary channel changes. Start will be based on the
availability of the new channel.
In case of the rolling CAC feature, a channel is programmed to
the agile detector on which CAC is running continuously.
Introduce an API that finds an RCAC completed channel and return
the channel params which will be used for the next channel
change.
Also add a boolean argument in dfs_set_current_channel api to
indicate if the dfs current channel is updated in the API
"dfs_set_current_channel".
CRs-Fixed: 2674621
Change-Id: Ica54a57f131cd54e47138f1cbeef2dd0023390ed
So far the DFS algorithm detected only a train of single pulses and the
diff ts(PRI) which is the difference in time stamps between 2 consecutive
pulses, should be greater than a threshold DFS_INVALID_PRI_LIMIT of 100us.
When the diff ts is less than 100us, the radar queue gets reset. With the
updated w53 DFS specification for Japan country, new sets of duplets have
been introduced and the time interval between the 2 pulses in a single
duplet can be as low as 20us. Since, the diff ts threshold
DFS_INVALID_PRI_LIMIT is 100us, the duplets with a time interval less than
100us is not be detected.
Reduce the diff ts threshold DFS_INVALID_PRI_LIMIT to 15us for MKKN
DFS domain.
CRs-Fixed: 2656660
Change-Id: I67b8ebab80155a5bcefcaa33f5a8d75c30d2ef40
The old Japan radars that are detected in MKK4 DFS domain should also be
detected by MKKN domain.
The WARs specific to MKK4 are also applicable for MKKN.
Enable MKK4 specifi WARs for MKKN as well.
CRs-Fixed: 2673921
Change-Id: If514f7f35d7ca4fe086cc4392abdfc270eb55c4d
An extension of preCAC feature is Rolling CAC. The distinct difference
between these features is that the FW runs the off channel CAC
timer for a "finite" time for preCAC and runs the timer for "infinite"
time on an off channel. Hence the infrastructure built for
preCAC feature is being modified to accommodate RCAC feature as well.
Following are the modifications done:
1. Add an enum to represent various off-channel CAC modes.
2. Remove the 'static' declaration of few APIS so as to re-use them.
3. Add 'dfs_rcac_ch_params' to DFS PDEV object to store the RCAC
channel params so as to use the channel params after radar detect.
4. Rename DFS APIs to match its functionality.
CRs-Fixed: 2670419
Change-Id: I0bf0d33955706941cffb4e9cf6fcebfb465a6c74
'jiffies' does not include the device sleep time.
Use qdf_get_monotonic_boottime to monitor lapse of time for nol.
Change-Id: I6e00e003b8ee3d456ac4ec62b23fdaa02d577672
CRs-Fixed: 2652692
As part of the Rolling CAC State Machine, introduce three state
enums (INIT, RUNNING and COMPLETE) and the corresponding state
events.
Introduce generic APIs such as dfs_rcac_sm_create,
dfs_rcac_sm_destroy and dfs_rcac_sm_deliver_evt for rolling
CAC State machine operations.
CRs-Fixed: 2659666
Change-Id: I528db71aa7d21dced7e47ff4f9cccfbfe94c8c21
Feature Description:
FCC/JP domains do not support PreCAC. However, we can always start
beaconning in a channel if we have completed CAC in that channel for more
than or equal to the CAC period of that channel.
If an Agile engine is available and the next channel is known, we can
start CAC in the next channel using agile, while continuing the Tx/Rx
in the current channel. And when we want to start beaconning in the
next channel after a radar detection (or after/for a user request) we can
do so without any new CAC. This allows us to jump to the new channel
without having to disrupt any ongoing data traffic. This type of
continuous CAC in the next channel while operating in the current channel
is known as Rolling CAC.
Following changes are implemented:
I)Per DFS PDEV:
1) 'dfs_agile_rcac_freq' to store agile RCAC frequency.
2) 'dfs_agile_rcac_ucfg' to enable/disable RCAC feature.
II)Per DFS PSOC:
1) 'dfs_rcac_timer' is the only RCAC timer for the device/Psoc. This will
be shared by pdev level dfs objects.
2) 'dfs_rcac_timer_running' to indicate if RCAC is running or not.
III) New APIs:
1. A dispatcher API 'ucfg_dfs_set_rcac_enable' to set rcac config.
2. A dispatcher API 'ucfg_dfs_get_rcac_enable' to get rcac_config.
3. A dispatcher API 'ucfg_dfs_set_rcac_freq' to set user configured
rcac freq.
4. A dispatcher API 'ucfg_dfs_get_rcac_freq' to get the user configured
rcac freq.
5. Rolling CAC timer init/deinit APIs.
CRs-Fixed: 2659666
Change-Id: Iae002b2ab77964fca4faf237b0d0a4e2f2afe4c2
utils_dfs_reg_update_nol_history_ch is invoked with an argument of
(void *)chan_list. However, the usage of
utils_dfs_reg_update_nol_history_ch() assumes (void *)chan_list to be a
uint8_t *ch_ieee but (void *)chan_list is a (void *) pointer of struct
dfs_channel. Similarly, the equivalent freq API
utils_dfs_reg_update_nol_history_chan_for_freq() also has a mismatch in its
usage of (void *)chan_list.
Modify the arguments of utils_dfs_reg_update_nol_history_ch() and
utils_dfs_reg_update_nol_history_chan_for_freq() API to match its usage.
Change-Id: Ic0b88606ea81bde1f7065c16dfac008b737b705c
CRs-Fixed: 2484771
Problem:
1) When operating in 36VHT160 for example, if radar is hit without
bandwidth reduction dfs_radar_add_channel_list_to_nol_for_freq will add
only DFS channels (52,56,60,64) to NOL and disable them corresponding in
regulatory channel.
2)dfs_mark_precac_nol_for_freq will add all channel non-DFS(36,40,44,48)
and DFS (52,56,60,64) to preCAC nol. 3) after NOL expiry
non-DFS(36,40,44,48) will not be removed from the preCAC tree and
therefore cannot used (as part of the full 160Mhz channel) in future to
perform agile.
While processing RADAR the dfs_process_radar_ind() prepares the
list of frequencies (freq_list) to be added to NOL. This list
also contains the non-DFS channels.
Only DFS channels will be added to the NOL in
dfs_radar_add_channel_list_to_nol_for_freq() based on the channel state.
On adding to NOL, the channel state is also changed to disabled.
The subsequent APIs that will need to process
NOL(dfs_mark_precac_nol_for_freq() for instance) will have only the
freq_list. Since the channel state is also changed for DFS channels in
freq_list, these APIs cannot differentiate a NOL channel and nonDFS
channel (as channel state is not DFS for both). Thus not adding
NOL channels to PreCAC NOL list.
Solution:
Use the NOL frequency list (nol_freq_list) that is the output
of dfs_radar_add_channel_list_to_nol_for_freq() to process NOL.
CRs-Fixed: 2655016
Change-Id: If3608405a5e8e63d93157914080dde4c01c1e0bb
Since the precac tree now supports until 165MHz, the APIs to check
if the channel has done precac or not,
dfs_is_precac_done_on_ht20_40_80_chan_for_freq() and
dfs_is_precac_done_on_ht8080_ht160_chan() needs to be updated.
Change dfs_is_precac_done_on_ht20_40_80_chan_for_freq() to
dfs_is_precac_done_on_ht20_40_80_160_165_chan_for_freq() which can
check if precac is done on a 20/40/80/160/165MHz channel.
Change dfs_is_precac_done_on_ht8080_ht160_chan() to
dfs_is_precac_done_on_ht8080_chan() which can check if precac is done
on a given 80P80MHz channel other than the restricted 80P80MHz
(165MHz) channel.
Change-Id: I90312f968547d16b2d93783138c0f870439c6c26
CRs-Fixed: 2653171
When QCA_SUPPORT_AGILE_DFS is not defined, dfs->dfs_agile_detector_id
will not be set and it will be 0, which is also a meaningful detector id.
Currently, if radar_found->detector_id is not set, or set as 0, the
detector ID is recognized as a valid agile detector which is incorrect.
Return invalid agile detector id if agile dfs is not supported.
Change-Id: I259fa6f3f9fbcb4a76567090a8f084e15ee6af93
CRs-Fixed: 2646946
MKKN domain should detect the bin5 radars of MKK4 DFS domain.
Add the bin5 radars to the MKKN domain's bin5 radar table.
Change-Id: I0d0fbe91e56f4a290a675832fe4b9974f9afbf0d
CRs-Fixed: 2645168
Instead of channel number, use channel frequency for restricted 80+80MHz
boundary check.
Change-Id: I2fa65c3b1d102acd6b64b4c6e1583d2bc29484d1
CRs-Fixed: 2645155
Currently QDF_MAX_NUM_CHAN and NUM_CHANNELS aren't aligned, this unalignment
may cause many potential OOB access. So replace QDF_MAX_NUM_CHAN with
NUM_CHANNELS to keep unified.
Change-Id: I7bf7829d776f7caf5b2afbd2c9fd0c20d608e630
CRs-Fixed: 2644073
Introduce constants for building the 160MHz precac tree.
Add support to insert the 165MHz channel into the precac tree.
The precac entry is not restricted to be 80MHz bandwidth, it can be
20/40/80/160/165MHz, therefore introduce a new variable bw to
accommodate different bandwidths.
Change-Id: I57d1e2173712b54238f89079783f27ef591921d1
CRs-Fixed: 2647246
Provide support for bangradar with detector ID as one of the parameters.
Add the parameter as part of the packed arguments to be sent to FW.
Also add APIs for basic sanity check of bangradar params and packing
bangradar params inside an 32 bit unsigned integer.
CRs-Fixed: 2646549
Change-Id: Ie781bc9421b7ac0d407eb01814c9242c7f988884
In chipsets that support true 160MHz (single synthesizer),
the radar parameters received from target are different from Hawkeye
based chipsets in which two synthesizers, each 80Mhz,
produce 160Mhz signal.
The segment ID received in true 160MHz chipsets is always 0 and the
frequency offset is with respect to the center of 160MHz; unlike in
Hawkeye where segment IDs can be 0 (primary) or 1 (secondary) and
the frequency offset received is with respect to the corresponding
frequency centers (of the segment ID received).
Hence, to be able to use the same radar found algorithm as used in
Hawkeye, add a translation/mapping API that will translate new
parameters to old equivalents.
CRs-Fixed: 2633062
Change-Id: I37ad1db4ca71231119cf547abb9a8a70577cc6a4
In a future product, 160MHz mode of operation is acheived through
a single detector, unlike Hawkeye and its variants where 160MHz mode
is acheived using two 80MHz detectors.
Because of this change, the maximum segment ID is 0 in the new chipset,
whereas 1 in Hawkeye and its variants. Also the Agile detector ID
is 1 in the new chipset, 2 in Hawkeye and its variants.
In light of these changes, to identify the true 160MHz capability,
add a new API that checks the target type and returns true 160MHz
capability based on the target type. Also introduce a new dfs
variable that maintains the agile detector ID (based on the
true 160MHz capability).
In the future product, there is a support of restricted-80p80MHz
(a.k.a 165Mhz) where channels 132,136,140,144,149,153,157,161 are
available for operation as an 80p80Mhz channel.
Add a DFS API to check if this support is enabled.
CRs-Fixed: 2623964
Change-Id: If813e9d6fc649ce99c7780c04fbcb61acbd1af86
Current NOL conversion for dynamic mode switch is in such a way
that the NOL data is copied to the pdev ID entry for the targeted
mode. That is, the NOL data is split/merged before mode switch and
copied to a temporary structure before mode switch command is
sent to FW.
At this point, the target pdev's frequency range are still the old
values because of which, certain entries of the NOL data are missed.
Also in case of FW failures, the NOL entry cannot be added back
because they have been merged/split already.
To avoid the above, rearchitecture deinit and reinit NOL for
mode switch in such a way that the NOL data, as-it-is, is copied
before mode switch and is only split/merged after the frequency range
of the pdevs are properly mapped and the FW response is a success.
Change-Id: I4a073d1327ba182c40ced6089aa46d8f5f241d33
CRs-Fixed: 2632582
Per requirement, if STA+SAP is working on same 5G DFS
channel and INI g_sta_sap_scc_on_dfs_chan = 2, the
SAP DFS master is temporarily disabled to skip radar event,
and it will follow STA's channel movement. So, skip the
radar event processing based on STA+SAP concurrency policy,
otherwise the SAP would be stopped by kernel because the
current home channel is marked "disabled" by regulatory
during processing of radar event.
Change-Id: I3f851fe694c0e127665732894306e20f5d1c93f4
CRs-Fixed: 2636200
So far, only MKK4 and FCC DFS domains supported Chirp RADAR. But with new
Japan regulation, JP country which is mapped to MKKN DFS domain should
also detect the MKK4 DFS domain's Chirp RADAR.
Add Chirp RADAR detection support for MKKN DFS domain.
Change-Id: Iafd952d70726c9a9b85e73607d4a23c5022b8a46
CRs-Fixed: 2630894
When radar is detected on a channel and the radar parameters are sent to
FW, the Host Wait Timer expires even though the action status is
received from FW. At this point, the VAP state machine sends a
multivdev restart on the target channel, and is in restart progress
substate.
Since the Host Timer expires due to some reason, radar detect event is
posted to vdev state machine, that is currently in restart progress
state and, this causes a target assert and leads to kernel panic.
This issue is solved by the following 2 ways:
1) Start the host wait timer first, and then send the radar found
params to the target.
2) Check if dfs_is_host_wait_running is true, in the Host Wait Timer's
timeout, and only then call the radar_found_action_generic API.
Change-Id: I9b93c7c1822966f7d6bc00c00229849fdb5627d9
CRs-Fixed: 2604173
Currently the conversion APIs used doesn't take into account
the overloading of channel numbers between 6GHz, 5GHz and 2.4GHz
bands.
Add support to obtain the correct channel number (and auxiliary
information like band and frequency) through the new APIs that
support all three bands.
Change-Id: Ief417f14620bc2fc02d76fea3642b6fbb9615916
CRs-Fixed: 2610378
Query the external radar source and if external radars are
available use the external radars in addition to the internal
radars.
Change-Id: I9fe42ecaaf949f8e504c35ecb8cffb3e9e809fd0
CRs-Fixed: 2615278
Supported dynamic HW mode switches:
DBS (full band 5G and 2G) <-> DBS_SBS (low band 5G, high band 5G and 2G)
Description of the changes:
1. NOL conversion:
a. Introduce a temporary NOL list copy structure in DFS psoc obj.
b. When mode switch is triggered:
i. Stop the NOL timers and clear the data, to avoid processing NOL
expiry during mode switch.
ii. Allocate the psoc NOL copy for the target num_radios.
iii. Store the NOL data of each radio to the target pdev ID
(pdev ID after mode switch) in the psoc NOL copy,
using a unified mux/demux API.
c. After mode switch is completed:
i. Resume NOL by re-initializing the list from the temporary psoc
copy.
ii. Free the psoc copy after mode switch is complete.
iii. Note: changes are made to support pause and resume of NOL,
increasing NOL timeout by a few milliseconds.
2. PreCAC list conversion:
a. When mode switch is triggered:
i. Stop the existing preCAC timer and send ADFS abort command to FW.
b. When mode switch is completed:
i. Unify/separate the preCAC list if the target mode is DBS/DBS_SBS
respectively, using a single API.
ii. Start ADFS again.
3. Radar detection lock:
a. While detecting radar, acquire a lock to avoid handling user triggered
mode_switch during this process. Release the lock once radar
processing is completed and CSA start is triggered.
4. Radar detection/CAC completion defer during mode switch:
a. While detecting radar or CAC completion, check if mode switch is
in progress. If yes, defer the processing and wait for mode switch to
complete before handling the events.
b. Note: Precedence is Radar over CAC, i.e., if CAC processing is waiting
and radar is received, CAC completion is no longer handled.
CRs-Fixed: 2580403
Change-Id: I506f3b569bad2e351c6f336e50f203cf5fa8b223
When FCC type 4 radar is injected at +/-30MHz separation from center
frequency in VHT 80MHz mode, incorrect pulse duration is reported in the
radar summary reports and lead to decreased radar probablity detection.
Fix the issue by capturing pulses with such characteristics and
modify them to fit within the valid phyerror pulse duration range.
Change-Id: Ic6314a372d6909448fbe4eb694c41736d1719712
CRs-Fixed: 2573339
The w53 updated pulses should be detected by the DFS algorithm.
- Add new DFS filters to MKKN filter table.
- Introduce duration margin check in confirm radar routine.
Change-Id: Icf3fecb5c6027ba827cac05dbd43a1a55463209b
CRs-Fixed: 2582300
Introduce a new DFS domain MKKN that supports new w53 Japan RADAR
pattern only.
Initialize a new empty RADAR table dfs_mkkn_radars for MKKN DFS domain.
Map The 5G regdamain MKK17 to the new DFS domain MKKN to make sure that
the new w53 Radar pulses should be detected only by JP country or
MKK17 5G regdomain.
Change-Id: Ib0f6a7e98353c9930e90703ead2342b932e491e3
CRs-Fixed: 2575347
Before mode switch command is sent to firmware, the NOL channels are
reset. But the regulatory channel structure for these corresponding
channels are still disabled. After mode switch response, when
the new umac channel list is built, these channels are still marked
as disabled in regulatory, which results in the umac channel list
not having these channels at all.
Re-enable the NOL channels in the regulatory channel list after
NOL reset.
Change-Id: Ifad8ec7a5be53e061045c068f9a6bfc313d4985c
CRs-Fixed: 2580403
Pine supports restricted 80+80 MHz only on cfreq=5690 and cfreq=5775. If AP
detects RADAR in this channel, it chooses new 80+80 MHz random channel
which is not supported by Pine because, notion of 80+80 is not present in
current channel in regulatory component. Hence, as a temporary fix we
change the invalid 80+80 MHz channel to 160 MHz or lower.
Change-Id: I749607236a1dd7b9c7aa93ff889b65adcbb4191c
CRs-Fixed: 2570057
To fix 'error: ‘num_channels’ may be used uninitialized in this
function' error, initialize num_channels to zero.
Change-Id: Ic35b606a6e075dd309844c5fca793f970a701f5e
CRs-Fixed: 2570055
Remove dummy function dfs_remove_cur_ch_from_list(). This logic is already
implemented in dfs_apply_rules().
In dfs_apply_rules()/dfs_apply_rules_for_freq(), skip all the HT20 channels
of the curent channel when DFS_RANDOM_CH_FLAG_NO_CURR_OPE_CH flag is set.
In dfs_prepare_random_channel_for_freq(), allocate correct size of memory
for leakage_adjusted_lst array.
Use DFS_80_NUM_SUB_CHANNEL macro instead of DFS_80_NUM_SUB_CHANNEL_FREQ to
choose correct 80MHz channel.
Change-Id: Ie318d667ff1b0caef3032b7aa57f0ddfb7e1f1a7
CRs-Fixed: 2570055
With the introduction of 6GHZ and replacement of IEEE channel numbers
by frequency in DFS, "leakage_adjusted_lst" is now a pointer of type
uint16_t. Change the allocation size to take care of size of the new type.
CRS-Fixed: 2569329
Change-Id: I595bc77970a2758fd6ca66e53de6c0dbfe8843bc
There may be 3 different kinds of pris in staggered pulses. If one
of them is selected as reference pri, the other two pris fail the
pre pri check, then *prev_good_timestamp can't be updated at this
time. Even the next search pri has correct pri, it can't pass the
check of dfs_check_pulses_for_delta_variance because of previous
good timestamp.
Ignore pre pri check for staggered pulses, update *prev_good_timestamp
correctly.
Change-Id: I5ce95c6c1f899f29e6b4d0d83e8171d22c31fc5c
CRs-Fixed: 2556581
Currently MCL and WIN both have there separate queue.h
files with the same declarations and definitions.
As part of cleanup create single queue.h in common
code and update the usage of existing queue.h to this
newly added queue.h.
Change-Id: Ie381c3553d6361cf7f8c97f14a91ed24e332b51a
CRs-fixed: 2505617
To avoid IEEE channel number space collision,
use freq in structure dfs_acs_info.
Change-Id: I48813d12819f03495f196e634e9fcb422105f304
CRs-Fixed: 2555897
There is no defined variable "dfs_nol_channel" in function
"dfs_mark_leaking_chan_for_freq".
Change-Id: I4258a9d322bfd98dc644678d48ba3146f966b367
CRs-Fixed: 2554628
To avoid "channel number" collision with the introduction of
6GHZ frequency band, add frequency-based APIs to DFS Core.
Also, do not remove the old IEEE channel-number-based APIs that are still
referenced.
The DFS APIs of Target-IF layer and DFS UTILS in DFS dispatcher layer are
included as a part of this change as they invoke DFS Core APIs and are
dependent.
CRs-Fixed: 2526372
Change-Id: I7a00ca5796e9c81527438c326c2d41de1147ffee
The decision to do CAC when a vap is coming up should be taken based on
the previous channel and current channel. Introduce previous channel
in DFS structure and update it when the current channel is updated.
Use the previous channel and current channel in DFS structure to
decide whether the CAC should be done or not when the vap is coming
up.
Change-Id: Ia359025d5029713c32696dacee5b89618a1c9707
CRs-Fixed: 2538653
As part of the ETSI preCAC feature, every 20MHz channel that is CACed
and not in NOL is maintained in a list which is then checked during every
channel switch for CAC reuse (avoiding CAC).
With the introduction of preCAC list(Binary Search Forest) for
20, 40 and 80MHz channels which also includes the current channel CAC
information, the ETSI preCAC list has become redundant.
Remove all APIs and changes that support the redundant ETSI preCAC list.
Change-Id: Ie71e2fda3f6f62ec6ea312c3bf0bdfc53a7df003
CRs-Fixed: 2484864
With the change I7d4d4fdf4a6defac8fc436b63495b51c272669af the CAC is
restarted for both VAP down-up case and VAP restart case in the same
channel. For the VAP restart in the same channel CAC should not be
restarted.
Restarting CAC for VAP down-up is handled in
I456bbee34a722f3d18c781cbcc87585cbeee5d54.
Revert I7d4d4fdf4a6defac8fc436b63495b51c272669af without merge
conflicts.
Change-Id: Icbde60be9515a7a31e06ba74158ca2126f58520c
CRs-Fixed: 2539623
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: 2531811
Agile DFS support depends on the Firmware's aDFS support. This
information is propagated to the HOST in the WMI ready event as a flag.
This flag was not used by HOST before enabling agile DFS which resulted
in preCAC being enabled for the FW that does not support them.
Also, for certain chainmask configurations, aDFS should be enabled
only if the current pdev is operating in non 160 BW.
Introduce two new flags in the DFS object:
1. dfs_fw_adfs_support_160
2. dfs_fw_adfs_support_non_160
which specify FW support for ADFS for pdevs in 160 BW and non 160 BW
respectively. Make appropriate changes in is_agile_precac_enabled
check that includes fw support for the current operating bandwidth.
Also rename "dfs_agile_precac_enable" to "dfs_agile_precac_ucfg" and
"dfs_precac_enable" to dfs_legacy_precac_ucfg" in the dfs structure
to properly indicate what those booleans represent.
Change-Id: I202ead8ef109c707bfbda488064ecaa72a3f737f
CRs-Fixed: 2521654
Add new DFS filters to ETSI RADAR table to detect ETSI EN302502
Type 3 and Type 4 RADAR pulses.
The filters have been added per ETSI EN302502 spec
https://www.etsi.org/deliver/etsi_en/302500_302599
/302502/01.02.01_60/en_302502v010201p.pdf
Table D.3.1: DFS Test Signals simulating fixed frequency radars.
Change-Id: I4b9e93dc5069d57992c468cd4c00cb5ff77d3753
CRs-Fixed: 2505394
While checking if ETSI preCAC is already done on a given channel
in the API "dfs_is_etsi_precac_done", dfs_curchan is always used as
the channel to be checked. Since the API "dfs_is_cac_required" maybe
called without updating the dfs_curchan, using dfs_curchan in
function "dfs_is_etsi_precac_done" is not correct.
Use the current channel provided to the API "dfs_is_cac_required"
as input while checking for ETSI preCAC.
Change-Id: Id2bc59281e17afaa3ba7572f5a2d7bd4718a7639
CRs-Fixed: 2528023
When the radio is in HT20 mode, the duration of Korea Type 3 RADAR is
reported by the HW as 3us although the duration is only 1us. The minimum
and maximum duration for the corresponding filter(FilterID 42) is 0us
and 2us respectively. So host will neglect the pulses with a duration of
3us. This will result in Host failing to detect the Korea Type 3 RADAR
pulses in HT20 mode.
Increase the maximum duration of the filter(FilterID 42) to 3us.
Change-Id: I45f337ec31e017c4a0c19f1afea3fc7a08af9888
CRs-Fixed: 2503942
