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
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
Rolling CAC is a feature that uses the agile detector to
continuously perform CAC on a channel other than the primary
operating channel.
When the primary channel is changed to this Rolling CAC channel,
CAC is not required given that there was no radar in this rolling
CAC channel for a minimum duration (1 min in general).
Introduce a state machine that holds three basic states,
1. RCAC_INIT - No channel in Agile detector.
2. RCAC_RUNNING - Channel in Agile detector for < minimum duration.
3. RCAC_COMPLETE - Channel in Agile detector for > minimum duration.
Events that will be handled by the state machine:
1. RCAC_START - Trigger RCAC configuration in Agile detector.
2. NOL_EXPIRY - Retry picking new RCAC channel if not running/complete.
3. RCAC_STOP - Reset agile detector and stop host timer.
4. RCAC_DONE - Move SM to completed state if running.
5. ADFS_RADAR - Reset Agile detector with new channel if available
for RCAC.
Each states have entry, exit and event handlers with basic
implementations.
Few state transitions are as follows:
INIT -- RCAC_START --> RUNNING
RUNNING -- RCAC_DONE --> COMPLETE
COMPLETE -- ADFS_RADAR --> INIT (new chan) -- RCAC_START --> RUNNING
RUNNING -- RCAC_START --> INIT (new chan) -- RCAC_START --> RUNNING
COMPLETE -- RCAC_START --> INIT (new chan) -- RCAC_START --> RUNNING
RUNNING -- ADFS_RADAR --> INIT (new chan) -- RCAC_START --> RUNNING
CRs-Fixed: 2659363
Change-Id: I48a459d67d14973920c5a615bcd7c9d756b05293
For packets from exception ring will have extra HTT header, that
is adjusted to avoid wrong LLC header
Change-Id: I36adaa6ab0c3ba96a5eec9bf05747576e3938028
CRs-Fixed: 2661034
Monitor mode is not supported in 256M profile. Therefore set monitor buffer
size as 2K.
Change-Id: I914ede679363d67566537c1abb9f9f1b599b4d20
CRs-Fixed: 2668071
The current implementation of the TX Capture
feature assumes a non QoS 3 address frame for
each frame. If a frame is a QoS frame, the extra
fields are manually added, but if the frame is a
4 address frame, there is no handling. Add QoS,
4 address and 4 address QoS frame types to the
TX Capture feature and update accordingly.
Change-Id: Idd7f8f55a5543718f52bc38be396d671b87b54bd
CRs-Fixed: 2636684
filter pass seems to not be working for control frames
so we are using mac check address comparison for non-bss freames
when tx_monitor is set
Change-Id: I3a003636381f73191081e821dbe8cf00a67cb042
If tx capture, sniffer are not enabled, mgmt nbuf is freed.
It is causing use-after-free in bpr enabled case
Added change to free only when bpr is disabled
CRs-Fixed: 2662214
Change-Id: I0d889f371cf47047200f70563b589fac99733c49
streamfs/relayfs is needed by MCL and WIN. It is being moved to
QDF layer(Change-Id: I1401112ece290e6d0560623cf10faaf498ebb1b7).
Cleanup QAL streamfs files to avoid duplicity.
Change-Id: I06f2f07ca347e12b262620a780b38f40f565712a
Agile DFS can be disabled by disabling macro QCA_SUPPORT_AGILE_DFS.
Fix compilation errors on disabling Agile DFS.
Change-Id: I144a261f5e0db37bea9a0a6b372bcf1e13205bb6
Hold the ast lock while fetching and using the ast
entry from ast table without unlocking in between
to make sure that the ast entry is not freed
in between.
Change-Id: I887b94441e7c19d6ce0bf7175f61a1dc9055a0fc
PreCAC NOL is unmarked based on the 80MHz center frequency. This is
wrong as the PreCAC tree, with the avilablity of full 160MHz Agile engine,
can have a root as high as 160MHz. This will lead to channel not picked
for PreCAC after NOL timeout.
PreCAC NOL should be unmarked based on the center frequency of
the root node's bandwidth.
CRs-Fixed: 2654993
Change-Id: Ie054d725c1b7a2fed47c9f294f3d71c4dd9e8ecb
Streamfs implementation is moved to cmn_dev since both WIN/MCL
need it for CFR. In QAL layer, parent directory was NULL,
whereas in qdf layer, parent directory is "qdf".
This change modifies the streamfs directory path used by CFR
userspace app.
Change-Id: I5d235dab66344e3baa8d9fac7ad2f12e2b9f13ea
The API to check if precac is done on a given channel is based on
the 80MHz precac tree(dfs_is_precac_done_on_ht20_40_80_chan_for_freq()).
So a separate API was needed to check if precac was done on a 80P80MHz or
160MHz channel(dfs_is_precac_done_on_ht8080_ht160_chan()).
Now that the precac tree is updated to include the 160MHz and 165MHz
channel, the API(dfs_is_precac_done_on_ht20_40_80_chan_for_freq()) can
also be updated to include the 160MHz and the 165MHz channel and
the API(dfs_is_precac_done_on_ht8080_ht160_chan()) can check only the
80P80MHz channel.
Change the API dfs_is_precac_done_on_ht20_40_80_chan_for_freq() to
dfs_is_precac_done_on_ht20_40_80_160_165_chan_for_freq() to also check the
160MHz and the 165MHz channel.
Update the API dfs_is_precac_done_on_ht8080_ht160_chan() to
dfs_is_precac_done_on_ht8080_chan() that checks precac done only on a
80P80 channel other than the restricted 80P80 channel(the 165MHz channel).
Change-Id: Id747e3a88fc3d74c40702fc250af9e1b825b4e78
CRs-Fixed: 2653172
The API dfs_is_pcac_on_weather_channel_for_freq() which checks
whether PreCAC is being done on a weather radar channel or not does not
consider the case of an input 160MHz channel.
Add a case to check if the 160MHz channel includes weather radar channels
or not.
Also take care of the 165MHz channel which will be treated as 80P80MHz
channel.
CRs-Fixed: 2651161
Change-Id: I7285c9095a184947b1c33c11d6bb3b2370b31401
