Fix compilation errors when QCA_SUPPORT_AGILE_DFS macro is disabled
by adding the macros in certain APIs that were wrongly placed
outside the ADFS macro.
CRs-Fixed: 2689702
Change-Id: I89a4e43926625743b9f41ae142c6a45272b0c1a2
While determining the preCAC entry in which a channel falls
under, the range of the entry is calculated from the center frequency
and the hardcoded offset of +- 75 (for 160 MHz).
In certain RDPs which supports only a maximum of 80MHz, the
entries have a range of +- 40MHz from the center, but since this value
is always hardcoded to +- 75MHz, certain channels are wrongly
misinterpreted to fall in a preCAC entry even though the entries
do not have that channel.
To avoid such anamolies, use the precac entry's BW value to
determine the range of the entry instead of hardcoding it to
+- 75MHz (offset for 160MHz/165MHz).
CRs-Fixed: 2684927
Change-Id: I412cd433d50bad82e45af1d9f34bcd566381eccf
In case of low memory, it could be difficult to allocate luts at
once. So, allocate lut based on number of DBR entry and
split memory allocation.
Change-Id: Ib9d3940147f2adc2a22d0cc7a82210e29c9cd7d7
Before adding a ppdu to the retry queue, check if the
sched_cmdid matches that of the first ppdu in the queue.
If it does not, then the retry queue should be freed as
the received ppdu is not a retry of the ppdu in the queue.
Change-Id: I96a097f57d86539c8395af28f6fd57c13f4cad49
While finding the CAC status of a channel, the tree root's
subchannel count is hardcoded to 8 (subchannel count for 160MHz
channel) after the Pine ADFS changes.
In certain RDPs, the maximum bandwidth of a channel is only 80MHz
and in those cases, the preCAC tree roots are 80MHz channels. Now
while checking if a channel is CAC done, the number of CAC done
subchannels should be equal to the number of subchannels in the
corresponding tree node. But since the tree root's subchannel count
is not calculated but is hardcoded to 160MHz, it fails in these
RDPs (with 80MHz channels) and a channel is never considered CAC
done.
To avoid this issue, use the tree root's n_valid_subchs value
as the number of subchannels instead of hardcoding it to 8.
CRs-Fixed: 2684954
Change-Id: I85e5ea6e4bb71dc9b1ba951b8e227f487e3d11f6
Remove dependency of wlan_lmac_if_def headerfile from
wlan_objmgr_psoc_obj.h in component_dev
Change-Id: I5aa8f43845538e65d25c14776ec4ec9db174f0a8
CRs-Fixed: 2643301
This change implements the multi-link WiFi repeater functionality
using the Linux bridge Layer 2 forwarding table.
Change-Id: Ifa862a139f618f6bffde5613fd8d8d2e08d4f106
Adds support to OCE related config params to set
tx power,subnet id and ee report element.
Change-Id: I3909cdb032440bfdd7ae8b3024c2e3139d826551
CRs-Fixed: 2658248
Add change to define restart bitmap using the generalized bitmap
declaration. Also use generalized function to check if any of the
bits are set in the bitmap.
Change-Id: Ice0682ed7a59de962e9e46cf598643139c7c2313
delete redefinition of mcs from rx_user_status and keep mcs
derived from preamble which came from rts.
Change-Id: I5323d7944abd474a82d34b812caac1290168ea94
command to set next frequency for radar:
cfg80211tool wifix setNxtRadarFreq <freq_value>
command to get next frequency for radar:
cfg80211tool wifix getNxtRadarFreq
Before every radar detection, user has to set this frequency
or else AP will choose existing way to select channel.
This command is applicable for both RootAP and Repeater.
Change-Id: I12063dadeb28c5b3792bfd4b30c859de8e6eb2f2
CRs-Fixed: 2679009
In MBSS IE feature, non-tx VAPs can inherit parameters from tx VAP unless
a non-inheritance IE is added to the VAP's profile. Currently, only
security parameters can be added to this IE. Add commands to control this
feature.
If it's 1, security IEs from tx VAP are not inherited and non-inheritance
IE is added.
If it's 0, security can be inherited. In EMA case, Tx VAP security can't be
inherited if it's WPA/WPS. Only WPA2/WPA3 can be inherited.
Change-Id: Idb8df981371bd6c23afa0f3bb655668d0e094438
Add debug prints for Rolling CAC feature under the DFS debug level
"WLAN_DEBUG_DFS_RCAC". Enable it by setting the following commands:
1. iwpriv athx qdf_cv_lvl 0x27000a
2. radartool -i wifix dfsdebug 0x00400000
Change the prototype of dfs_get_rcac_enable() to store 'rcac_en'
value in a bool data type.
CRs-Fixed: 2679108
Change-Id: I124f23bb92f4464ef2c49ba2d8978c3ab4e05169
Add support
a. Drop msdu on queue exceed threshold of 4096
b. Add support to print consolidated peer tid queue.
Change-Id: I2b91b151531c839657716ac52987cf5e4a62e7cc
preamble value for mubar case is stored in phy_mode variable. this needs
to get carried over to preamble variable in mpdu_info so its used
correctly in radiotap setup.
Change-Id: If149f7b58a3d8b788bab706f8943d66f95e8517c
If status ring and destination ring ppdu id mismatches,
a. If If status ring ppdu > destination ring ppdu,
drop destiantion ring ppdu untill it matches status ring.
a. If If status ring ppdu < destination ring ppdu,
drop status ring ppdu untill it matches status ring
CRs-Fixed: 2677655
Change-Id: I80638245a09c3ed5846c0e71c8ad94e1c22c9014
There is a new vendor sub command added for configuring Spatial reuse.
All spatial reuse commands will be added under that vendor sub command.
Hence, remove the existing Spatial reuse commands from Wi-Fi params.
CRs-Fixed: 2631806
Change-Id: I13c218d7809c220b52d16dadaa8f628546afe0b4
When CFR feature is disabled through INI, skip handling of HTT
event indicating the DMA completion of CFR data.
Change-Id: Ia1aafc57866eb11a952cedfbe3a00fec201e0ee0
For BRP frame ppdu, frame control is not valid in all user
completion tlv, which is causing to drop ppdu as wrong ctrl mgmt
queue checked for payload.
To fix this, updated frame control based on ppdu frame type
Change-Id: Ia5eb67da14647cccfe2ade7c0626a97171454446
CRs-Fixed: 2677252
Update the event handlers of the states (INIT, RUNNING, COMPLETE)
of the rolling CAC state machine with appropriate response
to various events.
INIT:
- EV_RCAC_START:
Check if RCAC is running and if not, prepare an RCAC channel.
If channel is found, update RCAC index and transition to RUNNING.
RUNNING and COMPLETE:
- EV_RCAC_STOP:
Abort existing RCAC (cancel host timer and send RCAC abort to FW).
Introduce the following APIs:
- dfs_abort_agile_rcac: To abort RCAC in HOST and FW and reset RCAC
index.
- dfs_find_subchannels_for_center_freq: Given the center frequencies,
find the subchannels.
Also modify the channel selection logic of RCAC to clear the saved
RCAC channel parameters if no channel is found and return a valid
channel only if the agile width and the new RCAC channel width match.
CRs-Fixed: 2675221
Change-Id: I6b5565c089a7a0c3584a9e86fb81ad938d24a207
all probe responses and disassoc from bss peer will be accepted and
later filtered by
mac. Additionally retry queue is having a treshold for this new
mechanism to be able to flush queue in case it gets filled up.
this is meant to work for every control frame that has reached such a
state in its retry q.
Change-Id: Ie49d00d9b9422f02f5d9512a891ceb546cdd432d
As part of preCAC forest building in pine, 160MHz root nodes
were introduced to support 160 ADFS.
To support different BW root nodes in the preCAC forest,
an API (dfs_fill_max_bw_info_for_chan) was introduced to find
every cluster of channels. i.e, every unique 160, 80,
40, 20MHz channels available in the regdomain.
This API loops through different BWs for a given primary channel
and updates the maximum BW for the primary channel and it's
corresponding center frequency. The API then skips all
the primary channels within this range (primary frequency + BW)
and goes to the next primary channel that is not in the range
and start finding the maximum BW of this channel.
After all these operations, a set of center frequencies and it's
maximum BW will be found. This data will be used to build the
preCAC forest.
While looping through different channels with the same primary,
the BW value was updated only if it's greater than the existing
maximum, but the center was always updated.
Consider a case where, for primary channel 36, the current
center is 5250MHz and it's BW is 160MHz. Now, if a new channel
structure with 36 as primary and mode as 80+80MHz, the center
is updated as 5210MHz but BW is not updated, since the new BW
(80MHz) is less than the existing BW (160MHz).
Now the center is 5210MHz but the BW is 160MHz which results in
a faulty preCAC forest.
Update the center frequency only if the maximum BW value
is changed. Also, update the index of the frequency and BW
list (dfs_max_bw_info) to start from 0 instead of starting from 1. Hence,
num_precac_roots will reduce by 1 as the index is starting from 0.
Change-Id: I50503d0cd7ebe18890216952e2193e611f7f209a
CRs-Fixed: 2674087