As function is defined under compile time macro, also
export the symbol under the same macro.
Change-Id: Id2eba221dcb9c6d8cd7503e9d473199a50508309
CRs-Fixed: 3357183
The kernel-doc script identified some documentation errors in the
umac/dfs folder, so fix them.
Change-Id: Ia86989a39fe502480e2d2358a6f23759f78707e0
CRs-Fixed: 3382430
A new capability bit from FW is introduced that provides
ADFS 320 MHz support information. supports_adfs_320 signifies
chainmask capability service bit if FW supports ADFS on 320 MHz
channel width. Add this capability bit(supports_adfs_320) in host.
Change-Id: I09c689658ef495d8a8707425ecc9ba922fce4d41
CRs-Fixed: 3317795
When radar is found in any DFS channel, a radar bitmap is
generated based on the radar infected channels. For example,
if operating channel is 100 HT160 and radar found in 112,
then the generated bitmap is B0000_0010. This proposed bitmap
is compared with the valid puncturing patterns. In this case,
the proposed bitmap is valid puncturing pattern.
In case of a valid puncturing pattern, send the final
bitmap to DFS module and the module updates the DFS channel
puncturing pattern. If an invalid puncturing pattern is
found, return value zero and do not update DFS channel
puncturing pattern.
CRs-Fixed: 3273800
Change-Id: Iee23ac267bfea1b4815a72c2728555f96bed6466
Issue: The offset parameter in bangradar unit test parameter is only one
byte long. Whereas radar offsets has a range of [-160, 80] MHz if host
supports 320 MHz bandwidth. but with bangradar unit test command only till
-128 MHz is possible
To fix this, Add frequnecy offset sign bit(13th bit) if hosts supports
320 MHz bandwidth. Firmware will identify max range of [-160,80] with
sign bit.
Change-Id: I33ea8e9185f8d25b81cad7a18dcca6d2d6f42669
CRs-Fixed: 3270525
Set dfs object parameter if host and fw supports 320 MHz bandwidth.
i.e. dfs->dfs_is_bangradar_320_enabled. Set to true if the host and
firmware support the bandwidth is 320 MHz. If there is no support, set
false.
Change-Id: I210823c448450f89dc65937201b4839168369d18
CRs-Fixed: 3270525
When BW Expansion feature is enabled using UCI or cfg80211tool
command, the utility function to set/get the BW Expand feature
is introduced inside DFS module.
A new dfs member dfs_use_bw_expand is used to store the status
of BW Expansion feature.
CRs-Fixed: 3229250
Change-Id: If01e080f8e60e883fbeb2d7dfd599b91584bc293
When SAP off and psoc idle shutdown happens before NOL timeout,
DFS pdev obj is destroyed, NOL timer is cleared, NOL channel
is failed to clear for regulatory pdev obj is freed already.
To fix it, let NOL timer and NOL be cleared in dispatcher_pdev_close,
before pdev destroy and regulatory pdev obj destroyed.
Change-Id: I5818f8a0284a6c45e8a435ac59269df73507deeb
CRs-Fixed: 3151099
Use CONFIG_REG_ 6G_PWR_MODE for the new API.
Use "_for_pwrmode" as suffix for the new functions.
Change-Id: I9b84944a59062277b76bc48877c47ea5afada0ec
CRs-Fixed: 3133023
The consumers of the current channel list may want to search through 6G
channels that are not part of current channel list and belong to channel
list of different power mode.
Therefore, replace the regulatory current channel list with that of 6G
power based channel list.
Change-Id: Ie2ff8bbfb50a5f95f584b134b18246cb28b1c406
CRs-Fixed: 3110987
The sub-channel array size was maximum of 8 sub-channels corresponding
to a maximum channel width of 160MHz. But with the introduction of 11be
higher channel width of 320MHz is possible.
Expand the size of sub-channel array to 16 to accommodate the sub-channels
of 320MHz in case of 11be chipsets.
Change-Id: I7ffd1a7c0f05085edff74b92e47ab5a0dab42ef0
CRs-Fixed: 3068405
With the introduction of 11BE, channel puncturing becomes possible.
Hence, the DFS channel structure should be updated with channel puncturing
information.
Change-Id: Ia1bccd55e7fadde2a49fb08bd30ff6b5b2cc6ba1
The "wmi_pdev_dfs_radar_detection_event" has an unused field "chan_freq".
It currently holds the value of primary 20MHz channel. With the
introduction of 11BE chipsets, this field is changed to hold the value of
the center frequency of the channel width on which the radar is found.
This new change is indicated by a wmi service
"wmi_is_radar_found_chan_freq_eq_center_freq".
For the Chipsets that support this service, the radar found frequency
can be calculated by mere addition of the fields "chan_freq" and
"freq_offset" field.
Change-Id: I8d2ce0023e2feb6e749ca8d7d5f547fafc0fdf98
Currently, "agile_precac_active" is set only after receiving the start
event in the init state. "agile_precac_active" indicates whether adfs is
supported in the radio or not. This has to be set based on the agile precac
enabled check when the vap is brought up and when the event
DFS_AGILE_SM_EV_AGILE_START is sent to DFS Agile State Machine.
Change-Id: I2084d6d413ee11fa9f77026326dab79aafcd64fb
When operating in 20/40MHz modes in channels 52/56/60/64, spur
is found on adjacent channels (40, 44, 48) if we switch to those
channels after radar. To avoid this issue, add a SW WAR to ignore
selecting the adjacent channels if radar is found on the UNII-2
channels (52-64).
Change-Id: I4d02c53bf57171b9e5e5704d36552d0d5c6423b9
When DFS_RANDOM_CH_FLAG_NO_DFS_CH set, the random channel
selection will pick non-dfs channel. But currently the
MCL API utils_dfs_get_channel_list doesn't populate
the DFS flags "WLAN_CHAN_DFS" for dfs channel.
That causes the dfs_prepare_random_channel_for_freq API
can't identify DFS channel.
Fix by set WLAN_CHAN_DFS for dfs channel
Change-Id: I7ead760ddc77c198a630d12960e775961840796c
CRs-Fixed: 3016746
While checking if the pdev is 5G for DFS APIs, only 11A mode
support is checked which is also present for 6G radios which do not
have DFS. Check if the radio is only 6G in addition to the 11A check,
and if it's only 6G supported, return false.
Change-Id: I80008de610a93eeac326da36da43a747bafad2d9
In dfs test mode, 18 pulses are injected in a single burst, the host
driver reports the radar found event two or three times to
upper layer. For a single burst of radar pulses, radar found event
should be reported only once.
Fix the multiple radar founds for a single burst by disabling radar
detection and flushing the existing radar pulses from all queues
while processing the current radar found indication event in dfs test
mode (usenol=0).
Change-Id: I70c7c15147a5cde038773fd97735c113ca385932
CRs-Fixed: 2981217
Spur or leakage transmissions is observed in Spruce HW in
frequencies from 5260MHz to 5320MHz when one of the following
conditions is true,
i) The AP is transmitting in 52/56/60/64 in 80MHz mode and then the AP
moves to the adjacent channel 36/44/48 in 80MHz mode and starts
transmitting.
ii) The AP is transmitting in 36/44/48/52/56/60/64 in 160MHz mode and then
the AP moves to the adjacent channel 36/44/48 in 80MHz mode and starts
transmitting.
In order to prevent random channel selection to cause spur restrict the
above given channel movements for Spruce target alone.
Change-Id: I27b558ec5544076430f66c84b056ab65f9e43c8c
CRs-Fixed: 2975473
As part of regulatory cleanup, remove
dfs_find_target_channel_in_channel_matrix()
Use dfs_find_target_channel_in_channel_matrix_for_freq() instead
of dfs_find_target_channel_in_channel_matrix()
Change-Id: I8750b95d5cf4a4fa3d738c2209edf1328794d486
CRs-Fixed: 2959916
With the current implementation, dfs->wlan_dfs_stats.num_radar_detects
is incremented for radar detections in partial offload alone. For FO,
this stat was not incremented. As a result, when the number of times
radar has been detected is queried with radartool, the stat always
returns 0.
Fix this by incrementing this stat for FO chipsets as well.
CRs-Fixed: 2967882
Change-Id: Ibf5ea3f9f358476a2b21eeae782c44e0d53ada52
As part of regulatory cleanup, Cleanup code under
CONFIG_CHAN_NUM_API feature flag.
Change-Id: I3add81605ea939b3631396154ed3f07f59493f24
CRs-Fixed: 2953646
Find out if a VAP is going through restart transition and skip CAC.
All other cases, do not skip CAC based on subset logic.
Also, if the channel is non-DFS, do not do CAC.
CRs-Fixed: 2945741
Change-Id: I5a9de47a879eb8d294dfed126a77970c52b2b546
Bring up a 5GHZ AP on HKV2 board and enable agile spectral scan
using "athssd -i wifi0 -j ath0 -a -f 5180" cmd. Agile spectral
scan fails to begin.
Agile spectral scan must not begin if RCAC is enabled as both cannot
run simultaneously. All the pdevs of the current PSOC are passed as an
input to 'target_if_is_aspectral_prohibited_by_adfs' to validate if
rcac is enabled on any of them. In case of HKV2, both 2G/5G PDEVs belong
to the same PSOC, when 2G PDEV is given as input, ucfg_dfs_get_rcac_enable
returns a failure as DFS is NULL.
Hence target_if_is_aspectral_prohibited_by_adfs returns a failure and
agile scan does not begin.
RCAC feature is only for 5GHZ channels and need not be validated for
2G PDEV. Hence do not block aspectral scan if DFS is NULL for 2G PDEV.
CRs-Fixed: 2947887
Change-Id: Icce2300f7ca2a4caf7d46cc23fe055f07f90266c
- 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
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
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
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
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
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
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
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
