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
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
Use dfs channel structure to store autoswitch channel instead
of a single frequency value.
CRs-Fixed: 2726427
Change-Id: Ib592b75d4f87b4597510a1fc32717633b2b39e21
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
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
