The macro QCA_DFS_BW_PUNCTURE depends on the macro
WLAN_FEATURE_11BE. This creates compilation issue and fix
is introduced in this patch.
CRs-Fixed: 3283332
Change-Id: Ie00f7384142b39c309845408c6268ae6346f4734
The macro QCA_DFS_BW_PUNCTURE depends on the macro
WLAN_FEATURE_11BE. This creates compilation issue and fix
is introduced in this patch.
CRs-Fixed: 3282072
Change-Id: I680670e58bd57d104bc69f2b4e7a56010b7584a5
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
When radar is found on any DFS channel, generate a
bitmap which represents the channels that are
radar infected. For example, if the current channel
is 100 HT160 and radar is found in chan 104, then the
bitmap generated have the value B0000_0010. The bit 1
represents radar infected channels.
The radar bitmap calculation also checks for any existing
punctured patterns. If already punctured patterns are
available then it includes the existing pattern and
also current pattern in the bitmap calculation.
CRs-Fixed: 3273737
Change-Id: Icfc5d4e22980d3d2375152c12d244c7a8f5e318d
Add the global dispatcher function pointers to enable/disable
the DFS puncturing feature.
Add a new dfs member "dfs_use_puncture" to remember if the
feature is enabled or disabled.
CRs-Fixed: 3272765
Change-Id: I1f45a9f44ede7f8606f770365220c5f7508847cf
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
If radar is injected on the non-dfs segment of a DFS channel
(e.g. Operating channel is 36 HT160, center freq is 5250, freq_offset is
-20, radarfound_freq = center freq + freq = 5230 (IEEE 46) which is a
non-dfs segment) using bangradar command, radar detect event on
non-dfs channel is sent to user space.
To ensure that radar found event is indicated only for DFS channel,
send radarfound event only if the final status of the API
dfs_process_radar_ind_on_home_chan() is a success. If the API returns a
failure (eg: radar on non-dfs segment), do not send radar detect event
to user space.
CRs-Fixed: 3254309
Change-Id: Iefc277348569e1494401f0ec215bb786e4153268
The parameter of callback of kernel struct hrtimer is itself, not
qdf_hrtimer_data_t. CFI failure happens if the function pointers
does not have the same type as the function that's called.
Add a new API __qdf_hrtimer_cb and assign it to hrtimer->function.
Change-Id: I9cf753272dd37635e82defac6cf7258c7a70425d
CRs-Fixed: 3245385
Issue: mode was set to HT20 and marksubchannel was enabled. We injected
radar into the HT20 primary channel. The primary channel is not being added
to NOL when marksubchannel is enabled because the current subchannel
frequency list(freq_offset->freq[i]) is not being filled.
To fix this, Even if it is an HT20 mode, fill the subchannel frequency
list(freq_offset->freq[i]) based on offset.
Change-Id: I571ba60c755e7701a21db89f917c953ffa9716a6
CRs-Fixed: 3244971
In case of RCAC, check if CAC is completed only on the RCAC
channel and do not check the CAC info on current operating
channel.
After RCAC complete is sent to FW, the RCAC tree info is
cleared. In case of RCAC, check the CAC done info only
on RCAC channel.
CRs-Fixed: 3231140
Change-Id: I976b2b5e29ebdf2dc4fb2e5df1f2feb700c972af
In case of BW Expand is enabled, Check if the user
configured channel is available. If it is available,
STOP the AGILE SM and Restart the AGILE SM. This will
clear any old preCAC/RCAC chan information.
CRs-Fixed: 3231108
Change-Id: I0d45204c8525ad7439a3b11cb4f8f8e7f20105d3
Add function declaration for the following APIs
1) dfs_bwexpand_find_usr_cnf_chan
2) dfs_bwexpand_try_jumping_to_target_subchan
3) dfs_is_rcac_cac_done
4) dfs_get_configured_bwexpand_dfs_chan
The mentioned APIs are used for BW Expand feature.
CRs-Fixed: 3230855
Change-Id: I17a4549a804a92f2ad3fbc8050a979a44796a152
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
The BW Expansion feature requires Agile SM to run on User
Configured Channel. The User configured Frequency and Phymode
should be stored in DFS structure.
Introduce the following new DFS structure members:
User configured Frequency - dfs_bw_expand_target_freq
User configured mode - dfs_bw_expand_des_mode
The API dfs_is_subset_channel_for_freq is changed from static to
non-static. The API dfs_is_subset_channel_for_freq is needed for
finding the channel to run Agile when Bandwidth Expansion feature
is enabled.
CRs-Fixed: 3221545
Change-Id: If98ab9b3cc2c50fa5acc8e29bd5374830d1adf52
The HR timer runs in hardIRQ context and tries to acquire a bh_spinlock
held by a SoftIRQ context, which leads to deadlock.
To fix this, create a workque and let the workque execute the timer
callback function.
CRs-Fixed: 3200600
Change-Id: I6e702acade6d4e1d75470339ead0e591e7b8e4d8
The radar found frequency offsets to find various 20MHz sub-channel
frequencies is hardcoded for different channel widths. These frequency
offsets can be calculated reducing repeatitive code.
Calculate frequency offsets from channel widths and center frequencies
to determine the radar found frequencies.
Change-Id: I146fa6dd06473ff90cad4bb5dd8ba4ce13ab7c7c
CRs-Fixed: 3182067
In 5 GHz band, a 320 MHz band channel cannot be formed without
puncturing. Hence the contiguous available BW is 240MHZ which has
twelve 20MHZ channels from 5500 - 5720. Send CAC start/CAC
complete/radar detect information only for the channels which are
not punctured.
CRs-Fixed: 3200931
Change-Id: I5c2bc3314df6d1d61500e7fb24eef4a096ba4bb5
Replace qdf timers with HR timer for pre CAC timeout and process
the preCAC completion work in workqueuecontext.
Since preCAC expiry is processed in H/W interrupt context
(while using HR timers), no other timer cancellation is allowed
('qdf_hrtimer_cancel' function will wait for the handler finish)
But if we process the preCAC timer completion work in H/W context,
other timer cancellation will take time. To fix this, process the
preCAC completion work in workqueue context to allow other timer
cancellation.
CRs-Fixed: 3185213
Change-Id: Iaa24055e0d485f613e16d6110d22002fecf10821
When AP moves from DFS to NON-DFS channel, dfs chan state is
not updated and have state DFS_CAC_STARTED. Similarly, if the VAP
operating in a DFS channel goes down, the dfs chan state needs
to change to DFS_CAC_REQUIRED but the dfs chan state remains in
DFS_CAC_STARTED.
During CAC STOP, send the DFS event CAC RESET to change the dfs
chan state.
Change-Id: I21831e2c79da67375f8e340964f899ebd169fd85
CRs-Fixed: 3160346
Replace slave for target, and replace
master for initiator which pair of slave.
Change-Id: I51ee0ce1ce0d0dc30281388a270bda1edfac2903
CRs-Fixed: 3169180
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
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
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
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
