Hopping radar happens on whole band, hope all DFS sub channels are put to
NOL, but F/W only reports single radar event on special freq to host.
When DFS puncture enabled, sub channel marking is enabled, host only put
single affected 20M sub channel to NOL instead of all current bonded sub
channel, AP still stays on current freq for valid puncture bitmap
instead of leave DFS freq.
If the radar is a frequency hopping radar that truly hops over entire DFS
band, then the AP and clients are best served by moving out of the DFS
band. But it could well be that only part of the band is used. It is
difficult to find product specifications with info on the total bandwidth.
Mostly military systems use frequency hopping to avoid jamming. So a middle
ground would be to put full bandwidth of current AP to NOL for FCC type 6
frequency hopping radar.
When frequency hopping radar happens, F/W set flag that full bandwidth need
put to NOL in new added tlv radar_flags of event
WMI_PDEV_DFS_RADAR_DETECTION_EVENT, When find the flag is set, host will
put full bandwidth of current AP to NOL even sub channel marking is
enabled.
To avoid compatibility issue between old/new F/W and new/old host, add a
F/W service bit wmi_service_radar_flags_support and host service flag
is_full_bw_nol_supported.
If the wmi_service WMI_SERVICE_RADAR_FLAGS_SUPPORT is enabled by FW, host
shall set/unset a bit in the host service flag is_full_bw_nol_supported
based on host capabilities. This host service flag is then sent to FW via
WMI_INIT_CMDID.
Change-Id: I6e280ca4ab00dce97c5aec90c7a4b4fc7c4a440a
CRs-Fixed: 3595476
Modify the DFS debug print level to reduce the prints during bootup
as per customer's requirement.
Change-Id: I9e2c07373ffe036d4dfa7599d49d589eefee5cff
CRs-Fixed: 3568927
In Pebble (11BE qcn6432 chip), the radar-found frequency is
incorrectly computed in the current implementation as
dfs_translate_radar_params is executed.
The translation function (dfs_translate_radar_params) which
alters the frequency offset is needed for pre-11BE chipsets.
For 11BE chips where
wmi_service_radar_found_chan_freq_eq_center_freq
service is advertised by HALPHY, the frequency translation is not
needed as the offset sent by FW in wmi_dfs_radar_detection_event_id
can be directly used.
CRs-Fixed: 3562464
Change-Id: I824b94ca764d6bd62a67feb38ba3ccc966999e90
Currently policy mgr api policy_mgr_convert_device_mode_to_qdf_type
accepts only QDF_OPMODE as an argument and converts it to
policy_mgr_con_mode. Also, name of this api does not reflect
the task this is doing.
With the new SAP mode for low latency low throughput SAP,
to convert the QDF_OPMODE to policy_mgr_con_mode, host driver
needs to know if it is ll_lt_sap or normal sap. To get this
information, update policy_mgr_convert_device_mode_to_qdf_type
api to accept the psoc and vdev id as parameters. Also, rename
this api to reflect the task this apiis doing.
Change-Id: Ib182d8091305fd9c4f35b424d7b4a751a61730ad
CRs-Fixed: 3525427
The change 'I4acd2f70707386f731e9b8fa2ef90a37868cbe23'
makes modifications in MLME and DP (Data Path) to optimize
the check for radar in per packet transmission path to
reduce CPU processing overheads. This new check is based on
a VAP variable that indicates whether radar is detected
or not.
Upon radar detection, send an indication to MLME through the
registered callbacks to update the status of the flag.
Change-Id: Id0582b5d79be672949f150907eb9ee64fa17d4f7
CRs-Fixed: 3528956
Add API utils_dfs_get_radar_bitmap_from_nolie() to fetch the puncture
bitmap from NOL IE. Also, move dfs_convert_wlan_phymode_to_chwidth()
from oss to common code. Also, add a 11BE version of
utils_dfs_convert_wlan_phymode_to_chwidth() API.
CRs-Fixed: 3538818
Change-Id: I258452e122d259c7b16655b760f217073b8e2e9b
When AP is moving to down state, stop the puncture SM.
If we do not stop the SM, the corresponding puncturing
slots will not be available for new radar puncturing.
Introduce a new member dfs_is_unpunctured in dfs_punc_obj
structure. The dfs_is_unpunctured holds the information
whether SM object is unpunctured at that moment. Since
both un-puncturing and puncturing are done through vdev
channel change, current code cannot differentiate between
if the channel change is for puncturing or it is for
un-puncturing.This variable will help us identify whether
an event should be for puncturing, or it is for
un-puncturing.
Handle the radar puncturing after the usenol check,
otherwise the usenol case will not get executed.
The internal_radar_pattern is not needed as the
information can be fetched from DFS puncture SM object.
CRs-Fixed: 3540171
Change-Id: If889348056ad82e7cbbe6ca954af7ddfa99e6865
Currently, OCAC status in DFS SOC object is defined as a boolean type,
whereas, individual OCAC status types are defined as macros. Hence, it
becomes difficult to differentiate between various status values.
To solve this issue, enumerate OCAC status types together and change
the OCAC status in the DFS SOC object from boolean to the enumerated
type.
Also, create a new object 'adfs_completion_params' to store the Off
channel CAC completion parameters within the wlan_dfs structure.
Create a new api 'dfs_agile_cleanup_rcac' to clear the agile RCAC
parameters.
Change-Id: Id95014f4f81b4a2137092a5dd107c570d70058b6
CRs-Fixed: 3501679
When we bring up AP on channel 100 HT320 with dfs puncturing
feature enabled and inject radar using bangradar at an offset of 70,
channel 144 gets added to the NOL. AP comes up on 100 HT320 with a
puncture pattern of 0xC0. AP's channel is changed to 149 HT80 and then
channel is changed again to 100 HT320 with 0xC0 puncture bitmap using
doth_ch_chwidth command.
Since 100 HT320 0xC0 is a DFS channel, AP does CAC and at the end of the
CAC expiry dfs_is_radar_on_punc_chan() API is invoked. This API checks
if radar infected channels are punctured by the user puncture bitmap
(dfs_ch_punc_pattern) and if so does not mark the CAC done chan as radar.
However, since 100 HT320 has a user puncture pattern of 0xFC00 and the
NOL infected bitmap is 0xC0, it considers radar is found on CAC
completed channel and tries to mark the channel as a radar as
dfs_ch_punc_pattern is equated to radar_bitmap in
dfs_is_radar_on_punc_chan(). This results in a cpu stall.
In dfs_is_radar_on_punc_chan(), if the radar bitmap is a subset of user
puncture bitmap, it implies that radar channels are punctured by the
user and hence there is no need of another radar detection at the CAC
expiry.
CRs-Fixed: 3519985
Change-Id: Ia8383500e89e2ac734d124e047bdbb94822bff3d
Add an API dfs_is_radar_on_punc_chan() which determines if
radar is found on a punctured channel and if so, does not mark
the channel as radar.
CRs-Fixed: 3504792
Change-Id: I5b38499baa794138f94898a24918eedc91f314e9
When the dfs_puncture feature is enabled and if the punctured subchannels
are not part of the current channel, dfs_punc_sm_stop() is invoked
from dfs_handle_dfs_puncture_unpuncture() API.
dfs_punc_sm_stop() does a hrtimer_cancel of dfs_punc_cac_timer though
hrtimer_init of dfs_punc_cac_timer is not done.
This causes kernel panic.
hrtimer_init() is done only when punctured channels are a subset of the
current channel.
Do a hrtimer_init() during dfs_attach to avoid the crash.
Change-Id: Ib9214ffe0b9605850885ca09c8d638dccecc7f00
CRs-Fixed: 3491078
Add device Id and target type checks for qcn6432 target
compilation
Add CFR and spectral support for QCN6432
Change-Id: Ic908fa768aa1be7cfc40be7fcc7f9ca6aa85aaa6
CRs-Fixed: 3351747
Implement the data structures for DFS puncturing and
un-puncturing state machines. For details of state
machine implementation refer to the change id
I5accbf2866a830447bd776b989c31909060c45ca.
CRs-Fixed: 3462277
Change-Id: I026228fb72302408f2992325099a31a60e986e3c
Following sequence of events results in a deadlock.
1.When channel change is in progress on channel 100.
In mlme_ext_vap_start_response_event_handler(),
wlan_vdev_mlme_sm_deliver_evt takes a mlme_vdev_sm_spin_lock
while posting WLAN_VDEV_SM_EV_RESTART_RESP event.
2.This mlme_vdev_sm_spin_lock is released only after
the RESTART RESPONSE action is completed. Restart response action
calls mlme_vdev_start_continue_cb() where
iv_enable_radar_table() is invoked. [[SM SPIN LOCK ACQUIRED]]
3.iv_enable_radar_table() = ol_ath_enable_radar_table.
This invokes ol_ath_init_and_enable_radar_table() where
dfs_get_radars() is invoked. This calls dfs_get_po_radars()
where WLAN_DFS_DATA_STRUCT_LOCK() is tried to be acquired.
4.However, acquisition of WLAN_DFS_DATA_STRUCT_LOCK() fails in (3)
because the lock is held by another thread mentioned in (5).
[[WAITING FOR DFS LOCK AS DFS TASK HAS ALREADY ACQUIRED]]
5.While AP is in START Response action detailed in (2),
there is a radar event received and dfs_task acquires
WLAN_DFS_DATA_STRUCT_LOCK. This lock is held till
VDEV RESTART is posted. [[DFS LOCK ACQUIRED]]
a. Dfs_task
b. dfs_process_radarevent
c. dfs_radar_found_action
d. dfs_radarfound_action_generic
e. dfs_process_radar_ind
f. dfs_process_radar_ind_on_home_chan
g. mlme_dfs_mark_dfs
h. ieee80211_mark_dfs
i. ieee80211_dfs_action
j. wlan_pdev_mlme_vdev_sm_notify_radar_ind
k. mlme_vdev_sm_radar_notify
l. wlan_vdev_mlme_sm_deliver_evt()
[[WAITING FOR SM SPIN LOCK WHICH IS ALREADY ACQUIRED IN (2)]]
Fix: To acquire WLAN_DFS_DATA_STRUCT_LOCK lock only around
dfs_process_each_radarevent() where the radar filter tables
/ radar queues/ delay lines are manipulated and release once
dfs_process_each_radarevent() is completed.
dfs_radar_found_action() which changes channel after radar
need not be protected by the DFS_DATA_STRUCT_LOCK.
Change-Id: I308f96d77c4e2e28f2ba1ec55f363202a8c25fe8
CRs-Fixed: 3403824
In Linux kernel 5.5, commit 43756e347f21 ("scripts/kernel-doc: Add
support for named variable macro arguments") improved how named
variable macro arguments are handled, and changed how they are
documented in kerneldoc comments from "@param...", to "@param",
deprecating the old syntax.
In Linux kernel 6.3, commit 3bdd9f075f54 ("scripts: kernel-doc: Remove
workaround for @param... syntax") removed support for the old syntax.
Currently the dfs_log() documentation uses the old syntax, so update
the documentation to use the new syntax.
Change-Id: I1aa44cd36ffacb0b26ee279496fc5a99b8de371d
CRs-Fixed: 3451492
Add APIs to fetch the DFS channel parameters such as CAC, NOL and the
channel state to the user application.
struct dfs_cacelem is defined to store all the CAC related information
such as cac start time, cac completed time and the cac timeout.
dfs_cacelems is stored for NUM_5GHZ_CHANS in the dfs pdev object.
dfs_handle_cac_events() API is used to handle CAC related events such
as WLAN_EV_CAC_COMPLETED, WLAN_EV_CAC_RESET and radar during CAC.
CRs-Fixed: 3428828
Change-Id: I82f7aafeb20222d9722bed5a1a8c10b5703ac975
dfs_disable_radar_and_flush_pulses() is defined under
HOST_DFS_SPOOF_TEST compiler macro and this macro is disabled for
a few config profiles. Hence when dfs_disable_radar_and_flush_pulses()
is invoked from dfs_process_radar_ind_on_home_chan() API, it causes
unknown symbol error.
Define dfs_disable_radar_and_flush_pulses() API outside
HOST_DFS_SPOOF_TEST macro as it is independent of spoof test feature.
CRs-Fixed: 3411429
Change-Id: I939c0154bc79c63b878c23447fc370a924c52049
1. Enable sub chan DFS type if QCA_DFS_BW_PUNCTURE defined, or all bonded
operation freq will be affected and disabled for nol, puncture can't work,
always need to switch freq.
2. Find nearest puncture pattern for a bitmap.
For example, SAP started with channel width 320 MHz, if only 20 MHz freq
affected by radar, 320 + 20 puncture pattern is invalid, but puncture
pattern 320 + 40 can be used.
3. Fix build issue when QCA_DFS_BW_PUNCTURE defined as following.
error: incompatible pointer types passing 'qdf_freq_t[16]' (aka
'unsigned int[16]') to parameter of type 'uint16_t *' (aka 'unsigned
short *')
Change-Id: I374ed76c6a13ef5fac1a78073f1b8974b0a9bb30
CRs-Fixed: 3386020
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
80+80 MHz support HE capability as well. To make it generic,
change the function name from dfs_is_precac_done_on_ht8080_chan
to dfs_is_precac_done_on_80p80_chan.
The function dfs_is_precac_done_on_ht20_40_80_160_165_chan_for_freq
checks for 320 MHz channel width also. To make it generic, this function
has been renamed as dfs_is_precac_done_on_non_80p80_chan_for_freq.
Change-Id: I942e27b85f4f9e2ccc1786072b044deb0b4a6e45
CRs-Fixed: 3317795
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
Spoof DFS check happens when AP is brought up in a DFS channel in
FCC domain. These spoof pulses are sent by FW in several bursts
via wmi_phyerr_event_id. Once host receives the first set of pulses
and if radar is detected by the host, host sends the radar found params
to FW. However, host does not disable the radar detection. Hence, host
continues to receive the next burst of spoof pulses and detects radar
again. This second set of radar found params when sent to FW is treated
as "real radar" pulses and FW sends a DFS status code of 2. Hence
host does a channel change to a new channel.
Hence the spill-over spoof pulses are treated as "real radar" and causes
frequent channel change on the DUT.
Once the first set of spoof pulses are detected as radar and radar found
params are sent to FW, disable DFS radar detection until the DFS status
check is received from FW. Once FW responds with a DFS status check,
re-enable the radar detection.
Change-Id: I57018776a449203c6467bb384120d4319bc04805
CRs-Fixed: 3305592
The NOL and CAC timeout callback function is divided into two parts:
HardIRQ and workqueue. If NOL/CAC expires, the callback function runs in a
HardIRQ context and the rest of the task runs in a workqueue to avoid
deadlock issues.
Issue: Workqueue tasks run in a low-level context. The task's execution
might have been delayed.
To fix this, run the "NOL" and "CAC" timer in softirq context.
Use QDF_CONTEXT_TASKLET instead of QDF_CONTEXT_HARDWARE as a argument in
qdf_hrtimer_init. If it is a "QDF_CONTEXT_TASKLET," the HR timer
initialises with softIRQ mode(HRTIMER_MODE_SOFT) and runs in softRQ
context when timer expires.
Change-Id: I9e23a9dff1a9c4669bb85342b3ffd91bc46ebe95
CRs-Fixed: 3239417
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
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
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
