High CAC timeout is seen for weather and non-weather DFS channels.
This is due to the delay in 5.4 Kernel timers. There is 1 second delay
observed for every 60 seconds.
To fix this issue, replace qdf timers with HR timer for CAC timeout.
On CAC expiry, when VDEV UP is sent to FW, serialization timer is
cancelled. Since CAC expiry is processed in H/W interrupt context
(while using HR timers), no other timer cancellation is allowed.
Hence, process the CAC timer completion in work queue context to allow
other timer cancellations by the CAC thread.
Change-Id: I92c4662decbba27261448327abb16708d941d778
CRs-Fixed: 3142394
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
Enable the wmi_service to fetch the radar found cfreq from
wmi_service_radar_found_chan_freq_eq_center_freq.
Add changes in DFS random channel selection algorithm
(1) To find a channel of input width 320MHZ. Since 320MHZ in 5G
is 240MHZ (320 - 80 punctured), there are 12 valid 20MHZ subchannels
possible in 240MHZ. Validate the continuity of 240MHZ channel before
declaring the channel to be found.
(2) To find a fallback channel for the input channel
width of CH_WIDTH_320MHZ. The fallback channel of 320MHHZ is
160MHZ.
CRs-Fixed: 3149475
Change-Id: I03cac7f090de20efd912402b5e4df543b47aafed
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
In the 5.4 kernel, a kernel timer expiry is delayed at the rate of 1 sec
per minute (approx). This accrues to 30 seconds for NOL which is a
30 minutes timer
To avoid the delay use HR(High Resolution: "hrtimer_start") timer for NOL
Change-Id: Ia1072532120d909bbbb73d6acb74643956a66900
CRs-Fixed: 3043864
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
Use DFS curchan and prevchan to deliver DFS CAC Events.
When CAC is started, deliver WLAN_EV_CAC_STARTED on all the sub-channels
of the current channel. In order to reset the CAC_DONE state of the
previous channel, deliver the WLAN_EV_CAC_RESET event on all the
sub-channels of previous dfs channel. If the previous channel was non-dfs
channel the CAC_RESET event need not be delivered. Since in the case of
ETSI domains retain the CAC_DONE state CAC_RESET event need not be
delivered for this case too.
Change-Id: Ia1083828f9e2e269fd17969bc4f8d642e938990d
The bonding channel array is calculated by adding center frequency to
hardcoded offsets.
Since, they can be calculated by Artihmatic Progression, replace the
hardcode assignments.
Change-Id: I4f145ac05f8266a69a6787783cb627200f52563e
With the introduction of 240/320MHz channels with 11be, sub-channel
marking has to enhanced.
Find the sub-channels of the 240MHz/320MHz channel that got affected by
radar.
Change-Id: I0b0d057b533ad4e6c4d1627c878e3823d1c75979
With the introduction of 11BE, channel puncturing becomes possible.
Hence, the DFS channel structure should be updated with channel puncturing
information.
Change-Id: Ia1bccd55e7fadde2a49fb08bd30ff6b5b2cc6ba1
Add the following DFS channel flags for 11BE:
1) WLAN_CHAN_320MHZ
2) WLAN_CHAN_EHTCAP
3) WLAN_CHAN_EHT20
4) WLAN_CHAN_EHT40PLUS
5) WLAN_CHAN_EHT40MINUS
6) WLAN_CHAN_EHT80
7) WLAN_CHAN_EHT160
8) WLAN_CHAN_EHT320
Add the following checks for both 5G channels and 6G channels:
1) WLAN_IS_CHAN_11BE_EHT20
2) WLAN_IS_CHAN_11BE_EHT40
3) WLAN_IS_CHAN_11BE_EHT80
4) WLAN_IS_CHAN_11BE_EHT160
5) WLAN_IS_CHAN_11BE_EHT320
Update the WLAN_IS_CHAN_DFS check to include 11BE modes.
Change-Id: I2bd9e877aa0b4fca8f93bf2b72247f8fc29ae833
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
Following are the changes:
1. Add macros relevant to the addition of the 320 MHz root to the preCAC
tree.
2. Adding 320MHz bandwidth in switch case and separating
'case CH_WIDTH_320MHZ' using a compile time macro ( 11BE), forces us
to use the macro inside the function, which is not allowed by the
coding guideline.
Convert the "switch case" mapping (which is generally a binary search)
into a linear search of a mapping (BW -> bonded pair) array , thereby
using the macro WLAN_FEATURE_11BE to separate the 320MHz bandwidth
in the data structure space instead of doing the separation inside
the function space.
Change-Id: Iaab2328deef1cb7b2ff82bafe5d3cd2ea137e725
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
In dfs test mode, bandwidth detection test on dfs channel fails
with QCN7605 chip, reason is some pulses will be discarded due to
low rssi reported on some frequency channel, it's different halphy
design for QCN7605 chip, so need to define rp_rssithresh for QCN7605
chip to different value.
Fix is define rp_rssithresh for QCN7605 chip to different value for
FCC/ETSI/JP W56 table which are used for dfs certification.
Change-Id: I9132cf82e6d8d97f83ebb4cd8586f8d8ff48066e
CRs-Fixed: 2986947
During random channel selection after radar, channels 149 to 177 are
not considered as a potential random HT160 channel after the
introduction of the 5.9G channels. This is because, the last 80MHz
band (165, 169, 173, 177) are not added to the list of 80MHz band
list that is used to find the next random channel.
Update the 80MHz band list with 165-177 and update the band count.
Change-Id: Id881adaa07dab07400435d559940f4bdf837eb75
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
Avoid calling qdf_timer_mod after qdf_timer_stop as the
node is deleted after timer is stopped and qdf_timer_mod
dereferences the deleted node leading to data abort.
Replace 'qdf_timer_mod' by the sequence
'qdf_timer_sync_cancel, qdf_timer_start' to be SMP safe.
If a timer is being started for the first time, use only
'qdf_timer_start' and not the sequence
'qdf_timer_sync_cancel, qdf_timer_start'
Change-Id: Ida5440d4a54d49aa97f57fbda57ab1ef2cce16e6
CRs-Fixed: 3005699
Write two new functions to check if preCAC and RCAC are supported in the
current DFS domain.
Currently, the preCAC is supported in the following DFS domains:
1. ETSI Domain
Currently, the RCAC is supported in the following DFS domains:
1. FCC Domain
2. MKK Domain
3. MKKN Domain
Change-Id: I2996e4d5b26e1a57ebb00e415fa41108af997b21
CRs-Fixed: 3005416
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
New regdomain of MKKN added channel 144 to JP.
Add 144 (5720Mhz) to JP outdoor frequency.
Change-Id: Ic50dd3aeb4e192672b71c7173b9fd4b4072b0e0a
CRs-fixed: 2943076
On a partial offload chipset, when radar is detected on a DFS channel,
the host dfs wait timer (timeout of 200ms) is started, but there is a
delay in sending the avg_params to the FW. This delay happens for approx
330ms due to some high priority interrupt, due to this, the thread that
sends the avg_params to the FW seems to be suspended.
Host timer expiry is seen, and due to this there is a new target channel
chosen and multivdev restart is sent to the FW (the vdev is in restart
progress state). At this moment, the FW spoof timer (timeout is 300ms)
gets expired and a status code of 1 (indicating spoof failure) is sent
in the host dfs status WMI event. Due to this, the DFS channels are
blocked and the channel list is rebuilt with only non-DFS channels.
A non-DFS channel is chosen as the target channel. Since the vdev SM is
currently in restart progress state, when radar event is posted to the
vdev SM, assert is triggered and this leads to a crash.
The timeout value of the host timer is 200ms and the FW timer is 300ms.
The Host timer should be greater than the FW timer.
Therefore, increase the Host status timeout value from 200ms to 350ms.
Change-Id: I86858377fd5041922f232a1ac3d5ab781c7a63c1
CRs-Fixed: 2936809
In some platform the timer is not precise. NOL timer may take more
than expected. During this time When print nol is called, NOL left
time is negative.
Set NOL left time as 0 in print nol if it is negative.
Change-Id: Ic6aec5f7ee080625adb39ae75785a271ad782f6c
CRs-Fixed: 2926548
Replace below APIs used under CONFIG_CHAN_NUM_API
in DFS module with corresponding channel frequency
APIs as part of regulatory cleanup effort,
dfs_get_bonding_channels
dfs_is_en302_502_applicable
dfs_nol_timer_cleanup
dfs_remove_spoof_channel_from_nol
dfs_tlv_calc_freq_info
dfs_print_radar_found_freq
dfs_compute_radar_found_cfreq
Change-Id: I962449264fa76783ea83b271ca2e5fa67dfe478c
CRs-Fixed: 2916463
When the phyerrors get accumulated in the radar queue and matches a filter,
the radar queues is reset. But the phyerror reception is not disabled
immediately, instead only done after taking radar action. In this interval,
the radar queue still continues to accumulate pulses until phyerror
reception is disabled.
When radar action is completed, channel is changed and phyerror reception
is re-enabled, the existing pulses in the radar queue continue to exist
and cause false radar on the newly changed channel. This will potentially
add all the dfs channels to NOL.
In order to avoid such a scenario, reset all the delaylines, radar queues
and the associated stats variables after disabling the phyerror
reception.
CRs-Fixed: 2891715
Change-Id: I6ad202a6d99d313895b347119fcae0a2a2651ca1
