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: I2c14a43982eb6e7cb5965253633ac00b357314e1
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
External applications require header files that are shared between
driver and application. So moving command enums and set/get
vendor command structures to a separate file.
Change-Id: I1171ae12f5ab8522253bde93fd15d41456f717f8
For qcn9000 in case of monitor mode, reap monitor destination
ring first and status ring later to avoid backpressure
on monitor destination ring
Change-Id: If107d40471a4d01ce8d42054ed844b98217e60cf
CRs-Fixed: 2670656
Support synchronization of Tbtt in multi SoC case.
Add WMI to send vdev details of one soc to another.
Info includes beacon interval, bssid and tbtt calculated
in host wrt to other Soc.
Change-Id: I79c5813e6294f4852bd373d32723a98c05bd5871
a. ppdu desc in pending ppdu queue is dropped on queue length exceeds
threshold which is 32.
b. configuring ring map for soc only once.
Change-Id: I7398a478ce9e4d974d9ecc2a06d30821f151a1b5
Feature Description:
FCC/JP domains do not support PreCAC. However, we can always start
beaconing in a channel if we have completed CAC in that channel for more
than or equal to the CAC period of that channel.
If an Agile engine is available and the next channel is known, we can
start CAC in the next channel using agile, while continuing the Tx/Rx
in the current channel. And when we want to start beaconing in the
next channel after a radar detection (or after/for a user request) we can
do so without any new CAC. This allows us to jump to the new channel
without having to disrupt any ongoing data traffic. This type of
continuous CAC in the next channel while operating in the current channel
is known as Rolling CAC.
Following functionalities are implemented:
1. APIs to enable/disable Rolling CAC feature.
2. APIs to set/get user configured Rolling CAC frequency.
3. Rolling CAC timer init, deinit and timeout functions.
4. API to determine if Rolling CAC feature is supported or not.
5. API to prepare a Rolling CAC channel and start RCAC host timer.
6. API to verify if user configured RCAC frequency is valid or not.
7. API to invoke random channel selection algorithm to determine a
RCAC chan.
CRs-Fixed: 2659363
Change-Id: Idd233268530a743dee5f0d939168573f1ba10ad8
