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
As FW requires, send WMI_PDEV_DFS_PHYERR_OFFLOAD_DISABLE_CMDID when there
is no beaconing session in DFS channel for FW which supports dfs offload.
Change-Id: I73b86328be6eb132de70bd10406495fbaefcab67
CRs-Fixed: 2554083
When tgt_dfs_set_precac_state API is called, the dfs_precac_active
boolean is set to false for all pdevs. This results in preCAC
being stopped for all pdevs in DBS_SBS mode when one of the
pdev becomes inactive.
Reset dfs_precac_active flag only for the calling pdev and
set the global boolean 'precac_state_started' to false only
if all the individual pdev flags are inactive.
Change-Id: I73fcacb911a5eb9028b03aa1c86775a66f2a7fc9
CRs-Fixed: 2556734
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
Implement a frequency API based dispatcher function to retrieve
the precac channel state of a given channel frequency.
Change-Id: Iefd70c8b6e60a42f8dc95db5f8a2e8c66ae013ea
CRs-Fixed: 2526372
To avoid IEEE channel number space collision,
use freq in structure dfs_acs_info.
Change-Id: I48813d12819f03495f196e634e9fcb422105f304
CRs-Fixed: 2555897
To avoid "channel number" collision that was introduced after
6Ghz band was added to the driver, frequency based DFS callbacks are
registered with dfs_to_mlme structure.
Change-Id: Id937059329e4df25a49397c1c01251f81afc1fe6
CRs-Fixed: 2526372
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
To avoid "channel number" space collision with the introduction of
6GHZ frequency band, add frequency based APIs in DFS dispatcher.
Change-Id: I349093e134b04ee31d046eb4da108522bc74a51a
CRs-Fixed: 2526372
Due to channel number ambiguity with introduction of 6Ghz operation
policy manager APIs are updated to use frequency values instead
of channel number. Update corresponding caller functions to
adapt for frequency usage.
Change-Id: Icf76480cdd0fbd98d9b5f559d9bfdc5d5a35dc7b
CRs-fixed: 2550098
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
Remove channel_map_old and and remove the instances of
CONFIG_LEGACY_CHAN_ENUM in the dfs and regulatory component.
Change-Id: I3e30dba72c28c9c356648595ad96720ab0cd789a
CRs-Fixed: 2463009
Bring up a Hawkeye AP in ETSI domain in HT80_80 mode and enable preCAC
(preCACEn). When preCAC timer is running, if radar gets detected in the
secondary segment (which is DFS), dfs_get_bonding_channels() gets invoked
to find the radar affected channels's IEEE. The radar-found channel's IEEE
gets computed from "dfs_precac_secondary_freq" variable which does not get
populated for Lithium chipsets as "dfs_precac_secondary_freq" is specific
to legacy preCAC.
Since the secondary 80 channel's IEEE gets assigned as 0, radar-found
frequency gets computed wrongly and channels are not added to NOL.
Ensure that "dfs_precac_secondary_freq" is used for secondary frequency
computation only for legacy chips. For chips that have a separate agile
radar detector engine, use "dfs_ch_vhtop_ch_freq_seg2" variable to
compute the secondary frequency.
CRs-Fixed: 2521686
Change-Id: I50e1c496ce81d532408d61d21bac568c8d755b2c
In dfs_check_for_cac_start API, the following checks (in addition
to few more unchanged ones) are done:
1. If CAC timer is running, is the current channel a subset of the
CAC started channel (dfs_cac_started_chan).
2. If CAC timer is not running, is the current channel a subset of the
last CAC started channel and was the last CAC not aborted.
The variable dfs_cac_started_chan is filled when CAC timer is started. It
is then reset only if, after vdev response, if the new channel is non DFS
or when the next CAC timer is started (with new channel value).
With the above logic, the cases where CAC is not skipped for a DFS
channel (e.g. preCACed channel) is not taken care of.
Consider the following scenario:
1. The current channel is 100 and the preCAC is completed on all
channels.
2. When CAC is started on this channel (100), the dfs_cac_started_chan
becomes 100.
3. If radar is found on 100 and the new channel selected is one
of the preCACed DFS channels, CAC is skipped.
dfs_cac_started_chan still remains 100.
4. After NOL timeout, if the radio is switched back to 100, the last
CAC started channel is 100 and new channel is also 100, which results
in CAC being skipped.
Rewrite the dfs_check_for_cac_start logic by checking the following:
1. If CAC timer is running, check if the current channel is a
subset of dfs_cac_started_chan.
2. If CAC timer is not running, check if the current channel is a
subset of previous channel (input).
Clear the dfs_cac_started_chan when the CAC timer stops or expires.
Also, in the API "dfs_is_subset_channel", while checking if one channel
is a subset of another, the DFS subchannels are determined based on the
channel flags. This is handled for two cases:
1. If secondary channel alone is DFS.
2. If primary and secondary channels are DFS.
The case "If primary channel alone is DFS" is not handled.
In case of channel 116HT80_80 with secondary 80 being non DFS,
all subchannels are considered as DFS subchannels.
Add a new API "dfs_find_dfs_sub_channels" where all the above
mentioned cases of DFS channels are handled to find proper DFS
subchannels.
Change-Id: I893430ff010746c84ce340323b25c17af25bc45a
CRs-Fixed: 2504840
Add channel number along with their frequency information
to display channels affected by radar.
Change-Id: Iedc489c5f23d95f13e32affa2aa200b55a77e5eb
CRs-Fixed: 2482303
Bring up a Hawkeye AP in ETSI domain in HT80_80 mode and enable preCAC
(preCACEn). When preCAC timer is running, if radar gets detected in the
secondary segment (which is DFS), radar found frequency gets computed
from "dfs_precac_secondary_freq" variable which does not get populated
for Lithium chipsets as "dfs_precac_secondary_freq" is specific to
legacy preCAC.
Since the secondary frequency gets assigned as 0, radar found offset gets
computed wrongly and channels are not added to NOL.
Ensure that "dfs_precac_secondary_freq" is used for secondary frequency
computation only for legacy chips. For chips that have a separate agile
radar detector engine, use "dfs_ch_vhtop_ch_freq_seg2" variable to
compute the secondary frequency.
CRs-Fixed: 2515454
Change-Id: Id1ec0c1500bf4df02a0fe52b4960141122da4f16
Rename dfs_cac_attach to dfs_cac_timer_attach. This is to align with
other function names.
CRs-Fixed: 2519566
Change-Id: I9c66fa1688c1790bd72f6e7938e612e57035c876
Currently eWNI_SME_DFS_RADAR_FOUND is triggered for every vdev
attached to the pdev in which radar is found. It is incorrect
because when handling one eWNI_SME_DFS_RADAR_FOUND event, every
sap in the DFS channel processes the event.
Trigger eWNI_SME_DFS_RADAR_FOUND once for one radar detection.
Change-Id: I72f8a2a34b670bd86f07d0caabf2ee8f96c962be
CRs-Fixed: 2504793
Currently a single API(dfs_get_precac_enable) is used to get
dfs_precac_enable and dfs_agile_precac_enable. This API is
wrongly returning value for dfs_precac_enable since agile
capability is set even for Cascade.
Separate out the GET APIs for getting dfs_precac_enable and
dfs_agile_precac_enable so that getting these flags becomes
independent of each other.
Change-Id: I08b0cbcd29c320a345865e3e9456ce3e809e26a6
CRs-fixed: 2501266
As part of supporting different bandwidths for preCAC, the preCAC list
also maintained current channel CAC information independent
of preCAC being enabled.
Once the current channels are CACed, they are marked as CAC done in
the preCAC list irrespective of preCAC being enabled or not. If
radar is found on any of these channels, they are not marked as NOL
in precac list if preCAC is not enabled. Since the channels are still
marked as CAC done, after NOL timeout, switching to this channel does
not start CAC.
Mark the preCAC list as NOL during radar, irrespective of preCAC
being enabled or disabled.
Change-Id: Ica24315c1e06fd603d7039e1233fcbd84bfeb594
CRs-Fixed: 2496747
During radar detection, with subchannel marking enabled, when the mode
is HT160, the secondary segment center frequency is determined by
adding +40 offset to the 160 band center frequency.
Consider the case where AP comes in channel 116 HT160. In this case,
the secondary segment center frequency is 5530 which is -40 to the
160 band center frequency (5570).
Primary segment center frequency is 5610 (+40 offset).
Due to this wrong offset addition, the channels added as part of
radar detection are in the wrong segment.
Find proper secondary segment center frequency used for radar
detection.
Change-Id: Icb527fad4fd1317acf8c2b9c010a8ac6a765f985
CRs-Fixed: 2475720
Send proper minimum and maximum agile preCAC timeout values to the target
as part of starting agile DFS detector. Add a common agile preCAC
parameter structure with the timeout values, channel and width fields
which are to be sent as part of configuring agile detector.
Change-Id: If5f5b179aa12a6c549cb9a4402aa10e957129d78
CRs-Fixed: 2482929
For a 2.4 GHz pdev, dfs object is NULL and hence 'dfs is NULL' print is
in tgt_dfs_set_agile_precac_state().
To fix this, add non 5 GHz pdev check before dfs NULL check.
Change-Id: I32cf622d7b769ce841d30de538527639b87f459b
CRs-Fixed: 2490145
The EN302_502 radar pattern is applicable in a predefined list of
regulatory domains (defined in DFS component). During radar table attach,
the current regulatory domain is checked if it is one of the
applicable regulatory domains.
The predefined EN302_502 applicable domains are:
ETSI11_WORLD
ETSI12_WORLD
ETSI13_WORLD
ETSI14_WORLD
Predefining these regulatory domain pair values in DFS component will
affect future regulatory updates that modify/add regulatory domains
to this list. Also, as per regulatory update #27, ETSI13_WORLD is not
EN302_502 applicable and ETSI15_WORLD is EN302_502 applicable.
Introduce a regulatory API(is_regdmn_en302502_applicable()) that finds if
the current regulatory domain pair is one of the EN302_502
applicable domains.
Modify the EN302_502 applicable regulatory domains as follows:
ETSI11_WORLD
ETSI12_WORLD
ETSI14_WORLD
ETSI15_WORLD
CRs-Fixed: 2390875
Change-Id: I78839a796eeb53a6b06b9fe66e8cae58de8838fa
When radar is found on Agile detector, the channels are not added to
NOL list and are only added to preCAC NOL list.
Add the radar affected channels, in Agile detector, to NOL list and to
preCAC NOL list based on the detector ID of the radar event received.
For subchannel marking, use agile channel instead of current operating
channel to the NOL when radar is found on agile detector.
Change-Id: Ifa61feeddbaaa81fe405972aa5826994a1383c00
CRs-Fixed: 2464929
In the current Agile DFS design it is assumed that the agile detector's
bandwidth is always 80Mhz. However, the agile detector inherits the
bandwidth of the current operating channel with the following
mapping:
Current Chan BW --- > AGILE BW
20 20
40 40
80/80+80/160 80
Provide support for Agile DFS on 20/40/80MHz channels based on the
current channel's bandwidth. Maintain a Binary Search Forest,
with each Binary Search Tree (BSTree) rooted by an 80MHz channel
structure. These BSTrees are connected by the preCAC list.
The primary key (identifier) of each node in the BSTree is an IEEE
channel. Each level of the BSTree has a unique bandwidth.
Remove the three existing precac lists: precac_required_list,
precac_done_list, precac nol_list.
Maintain
1) regular CAC and preCAC
2) regular NOL and preCAC NOL
information in the same Binary Search Forest.
Modify the following APIs to support the new framework.
1. Pick a channel for preCAC / Agile CAC.
(dfs_get_chan_from_precac_list, dfs_find_chan_for_agile_precac)
2. Reset the preCAC lists. (dfs_reset_precaclists)
3. If preCAC is done on a channel. (dfs_is_precac_done_on_ht20_40_80_chan,
dfs_is_precac_done_on_ht8080_ht160_chan)
4. Mark the channel as preCAC done / NOL. (dfs_mark_precac_nol,
dfs_mark_precac_done)
CRs-Fixed: 2464929
Change-Id: I6029ed919bd2275f46c4712ce1637ede4995557f
During abrupt channel change (e.g. iwconfig), the vap is brought
down and then brought back up. Now if the Agile detector is running
during this period, the detector is turned off as part of vap down.
When the vap comes back up, as part of starting the Agile detector,
a status of OCAC_SUCCESS and frequency of dfs->dfs_agile_precac_freq
is sent to the API (dfs_start_agile_precac_timer). The
dfs_agile_precac_freq variable was meant to be 0 as part of starting
the timer but since it was never cleared, that freq was moved to
Agile CAC done state immediately.
Clear the dfs_agile_precac_freq as part of vap down in addition to
stopping the Agile precac timer.
Change-Id: Ife117277a5d85911ae310e19a406f88fb9a544f0
CRs-Fixed: 2467077
MCL needs the interface type to query policy mgr for PCL
when selecting random channel. The existing API
utils_dfs_get_random_channel doesn't provide the vdev
type. Add new utils_dfs_get_vdev_random_channel
with vdev parameter to support P2P GO random channel
selection.
Change-Id: I0c6841b1692baca92730a6be73653282c98f1682
CRs-Fixed: 2467871
Currently the driver uses i both in outer and inner loop
which would corrupt the value of i and the loop would
never end.
Fix is to use another varibale j for the loop.
Change-Id: I6f64fb45d1007621b03fe93cd29da7d4c827a23f
CRs-Fixed: 2476402
