The process radar indication is huge making it difficult to read and debug.
It can be modularized into 3 high level functionalities based on whether
HW mode switch action is in progress or not, whether the radar found
detector id or segment id is the same as agile detector or segment and if
none of these conditions satisfy then the radar might be on the current
operating channel.
Classify DFS radar action based on HW mode switch status,
detector id and preCAC status into 3 sub-functions.
i) dfs_radar_action_when_hw_mode_switch_in_progress()
ii) dfs_process_radar_ind_on_agile_chan()
iii) dfs_process_radar_ind_on_cur_chan()
Change-Id: I7d862eb08d6373fabaedda4b77deb966466f6b1a
CRs-Fixed: 2737273
The 2 functions dfs_print_delayline and dfs_get_pri_margin are specific
to Partial Offload and Direct Attach. Bringing them under the macros in
order to resolve unknown symbol errors for 16M flash profile.
Change-Id: I0ca1514e37ba54083a9f614825dda4f31a95e7ea
With the current implementation, the chanwidth of the Agile channel
(for both PreCAC/RCAC) is the same as (or less than) as the chanwidth
of DFS curchan. The width of the DFS curchan is determined in the
function dfs_find_curchwidth_and_center_chan_for_freq which calls a
macro WLAN_IS_CHAN_11AXA_HE80 for 80 MHz which checks if the channel
is a 5G channel and 80 MHz. As a result, for wideband (i.e radio has
both 5 and 6Ghz channels), if the curchan is a 6GHz channel this check
fails which leads to invalid chanwidth and RCAC does not start.
Fix this by checking the chanwidth of the DFS curchan for both 5GHz and
6GHz in case of 11AX.
Change-Id: I9aef64cea1d442fc31b2314da08baba7769650f2
In Partial-Offload, when a repeater is associated with Root-AP in
DFS channel. The Repeater STA will get connected with Root-AP and then
Repeater-AP comes up in the DFS channel but it does not send beacons.
The reason is, when a STA vap is UP and in connected state, CAC is
skipped. So, for Repeater-AP we send VDEV_UP before Spoof radar
pulses event. FW rejects the VDEV_UP sent by host and therefore
Repeater-AP will be in UP state but it does not send any beacons.
The fix is, while checking the condition if STA vap is set to true, we
also check whether spoof radar event is completed. If the spoof radar
event is not completed, then we will not skip CAC and then VDEV UP
will be sent after the Spoof radar event.
CRs-Fixed: 2748740
Change-Id: If63f3118d3e40785b375a0bd59d46783c14fe433
Introduce APIs to perform postNOL channel switch to user
configured channel after the NOL expiry of said channel.
This channel change will involve regular CAC after vdev start.
Change-Id: I426b0c4b51c84789870841dd4c3af942be185f20
Enable burst scan for GO+STA case and set the burst
duration as 1 active dwell time.
Burst scan provides higher priority and can ensure
the scan request granted, since P2P GO requests larger
duration for its high priority channel request.
But this value will limit the off-channel time to give
more bandwidth for P2P home channel.
Also, change minimum rest time from 50 to max rest time
i.e. 100 for MCC case for all concurrency combinations.
50ms min reset time only grants 1 home channel in MCC,
when there is only 1 home channel and has heavy traffic,
it can be scheduled firstly as scan BSS channel, and if
activity check found not much traffic for the 1st 50ms,
it decides to go foreign channel directly, the 2nd home
channel with heavy traffic will not get chance to schedule.
Change-Id: I2cd73750709a964bd23896fe10f754caa28c2789
CRs-Fixed: 2716111
Add connect functions to convert kernel specific connect
request to connection manager specific connection request
for connection manager infrastructure.
Along with the above functions, add the file structure for
connect, disconnect and roam functions for connection
manager infrastructure.
Change-Id: Id4e389d06cea6e39327faef0c119275741574785
CRs-Fixed: 2739318
Currently driver sets the NOL state of the channels to false
on every regulatory updated, which indicates the channel is
not in NOL. Which may lead to some issues where the channel
is actually in NOL but host treats it as non-NOL channel.
Ideally NOL list should be maintained throughout the driver
lifetime and across the regulatory changes.
To address this issue add a logic to not update the NOL state
of the channels whenever the regulatory update is received.
Change-Id: I7487a24a349f5f6e06a058b4d07799c8e5ac2d40
CRs-Fixed: 2735137
In 6GHz only 11AX onwards phymode is supported. Update default
phymode sent to FW in wide band scan request as 11AX HE20.
Change-Id: I56849adc8a37bf12e510c3c435a00a80952d42e3
CRs-Fixed: 2746701
Implement the filter to reject the candidate with the channel in
the NOL list(i.e FS hit channel).
Change-Id: I8e39cd9e13a17816f7f96354c9880b11af9c06c8
CRs-Fixed: 2746157
Add change to move the existing filter params bool datatypes
into bitfields and also add new filter type to filter candidate
with channel marked as DFS hit.
Change-Id: I4aa5d7342cf7880da20c35eebd99fc72a71b58be
CRs-Fixed: 2746157
Add APIs wlan_reg_is_5ghz_op_class and wlan_reg_is_2ghz_op_class,
to check if an input opclass is a 5ghz, and 2ghz opclass respectively.
Change-Id: I677b5e927ac9060f65b71eee838073348d06d4b2
CRs-Fixed: 2732373
Following are a part of this change:-
1. Add an API to check if PreCAC/RCAC is enabled. This API is used before
delivering an external event to Agile SM.
2. Post an event to the Agile PreCAC SM if Radar is found on
agile channel. Radar on primary channel is taken care of by the
ensuing channel change.
3. Move all Agile PreCAC changes under macro QCA_SUPPORT_AGILE_DFS,
only RCAC specific changes remain under QCA_SUPPORT_ADFS_RCAC.
Change-Id: I45d4b9f826d36e9e4093879b394165a15a52f324
In the 5G radio, if the current regulatory domain does not support
4.9Ghz channels, and if 4.9Ghz IEEE channel number 1 to 11 are given as
an input to reg_compute_chan_to_freq, instead of returning 0,
it returns the corresponding center frequency of the 4.9 Ghz IEEE
channel number.
This is because the channel state and chan_flags of the 4.9Ghz channel
are not checked, that is why it returns the valid channel frequency.
To fix this issue, check the channel state and chan_flags of the
4.9Ghz channel before returning the non-zero channel frequency.
Change-Id: Icedd74422b4194ac4f1affed7e9f131fb8426986
CRs-Fixed: 2738248
Both (ETSI) PreCAC and RCAC are going to use use the same state
machine. The state machine drives the Agile engine and not very specific
to RCAC or PreCAC, therefore let the state machine be called agile state
machine and change the names of all the associated variables accordingly.
In this preparatory change, modify names of all APIs, states and events
to make them common to Agile RCAC and Agile PreCAC
Change-Id: I67858839589145bf4377a7eafec7c21ca4823141
CRs-Fixed: 2711104
When dcs happened for three times in five minutes, then do
restart(start/stop) SAP operation, when SAP is started again,
dcs may happen again quickly, if total four times dcs happened
in five minutes, dcs_disable_timer will be started due to dcs
happened frequency control policy, it will disable wlan
interference detection for 30 minutes and dcs interference
detection won't work for 30 minutes, it's unreasonable. After
SAP restart, dcs happened times should be calculated from zero.
Add ucfg API to reset im stats and freq ctrl params.
Change-Id: I4ad8234349d24f044dff700d90e1bec859eaa397
CRs-Fixed: 2739299
The radar affected sub channel are determined by the bangradar type,
whether sub-channel marking is enabled or not, the center frequency
of the band on which the radar was detected. This block of code is present
in processing radar indication function and can be modularized.
Move the logic to find radar affected sub-channels into a single function.
Change-Id: Ic0a37fdfa97cbc1bcd2b9a23fd6642f22b43a733
CRs-Fixed: 2737120
Add a new API wlan_reg_is_6g_freq_indoor, to check if a 6G channel
frequency is indoor.
Change-Id: I2ccdcc2760b6aeade0409346a315b004014525c7
CRs-Fixed: 2731637
Send RRM scan type indication in scan control flags to FW to scan
the channel for given duration after the FILS is detected.
Change-Id: I2057ef9794e3b05b7296679bb0220425ff64e6ae
CRs-Fixed: 2743155
Support a new capture_interval_mode: capture_count, where after
capture_count+1 number of frames, MAC stops channel capture and
waits for capture_interval duration before enabling again.
Add nob(capture_intervalmode_sel) to switch to capture_count or
capture_duration mode in wlanconfig application, where
capture_intervalmode_sel=0 indicates the old capture_durarion
mode where MAC stops channel capture after capture_duration
instead of capture_count. capture_intervalmode_sel=1 indicates
the capture_count mode.
Support MO marking: Current ENH CFR uses the existing MD/MO,
type/subtype filters to filterin the packets with programmed
type/subtype as either MD/MO. But for m_TARA it is also required
to consider the bw/nss/ta/ra setting. Therefore, it is possible
that not all the filtered-in PPDUs have channel capture and lead
to processing of packets which does not have captured data.
To overcome this issue, from QCN9000 onwards, MAC has MO marking
feature added for M_TARA filter mode, where MAC will consider
all TARA group configuration as filterin criteria & provides
an option to HOST to choose either filterin mode as FP or MO.
en_ta_ra_filter_in_as_fp is added to support MO marking.
Based on the discussion between HOST, FW & MAC teams, 0 is the
recommended & default setting for en_ta_ra_filter_in_as_fp.
Add nob to configure en_ta_ra_filter_in_as_fp but do not expose
to user.
Change-Id: I75cd3218fa4308afad21052e4535ef9b8e5a5869
If HW mode switch is in progress when a radar is detected, the radar
found channel information is stored and the processing is deferred.
This piece of code is in processing radar indication routine and can
be put under a function.
Move HW mode switch related code under a function so that it is
modularized.
Change-Id: I989ec62a2badbc70734e658a423aa0b8d2eee42d
CRs-Fixed: 2737116
The radar found parameters processing API dfs_process_radar_ind() is
supposed to read-only the radar_found_info parameters and not modify
them. A block of code for PO platforms modify the radar_found_info
parameters.
The function dfs_process_radar_ind() should not modify the radar found
input parameters.
Since in this case the parameter modifications are specific to partial
offload, move the code that modifies the parameters out of the function
into a partial offload specific code.
NOTE:- The previous change I2c717219d0b0f9263734767bee6070f335032b04 also
does the same that is mentioned here but for modification of
full-offload parameters.
Change-Id: Ic438d70eaadb9ef91d28f6a0c22caf4926ed1df1
CRs-Fixed: 2737060
The routine 'dfs_translate_radar_params()' translates the radar found
offsets given by a 160MHz detector which ranges from -80MHz to +80MHz
to that of the offsets given by an 80MHz detector that ranges from
-40MHz to +40Mhz. The same function also translates the segment ID from a
single-detector(160MHz) model to a two-detector model(80Mhz). This routine
is unnecessarily called for partial-offload chipsets which do not support
True 160MHz.
Do not call the function 'dfs_translate_radar_params()' from
'dfs_process_radar_ind()' which is common for both partial-offload and
full-offload. Call it from the full-offload specific radar action
function 'tgt_dfs_process_radar_ind()'.
Change-Id: I2c717219d0b0f9263734767bee6070f335032b04
CRs-Fixed: 2718507
Do not age out the scan entries of non-tx bss of connected AP
as the non-tx bss entries are updated based on connected AP
beacon.
Change-Id: Ib7276ff919f4c9a843c018caca1a90fd31168eac
CRs-Fixed: 2714982
Currently, vendor scan request is enqueued in the scan queue first and
then posted into the scheduler queue. Now if there is an SSR in between,
then scan request will be freed twice. Once in SSR context and again
in the caller context because scan scheduling fails due to user disabled
the scan.
To resolve this, post the scan request in scheduler queue first. Once
scan request scheduling is success, then enqueue the scan request in
scan queue. This approach can lead to a race condition like after
scheduling scan request, host may get scan response from firmware even
before the scan request is queued. To avoid this race, scan request
scheduling and enqueue should be protected by scan_req_q_lock.
Change-Id: Ic26da0181fb9a902a8a4abb8f68d9fc668f1b3f2
CRs-Fixed: 2714495
It starts spectral scan without vdev object, and uses the first vdev
as current vdev. which cause vdev mismatch in some platforms. So pass
vdev object or id when finding current vdev.
Change-Id: Iab55afbe2c98906021a008918f186d3d2dce5871
CRS-Fixed: 2716460
CONFIG_CHAN_NUM_API macro will be disabled. Remove all the references to
any function defined/declared under the macro. The function
reg_get_channel_list_with_power was placed under CHAN_NUM_API by mistake.
This API does not have any CHAN_FREQ_API counterpart. Therefore, move
this function out of CHAN_NUM_API macro.
The function dfs_send_radar_ind_for_freq is redundant as its counterpart
dfs_send_radar_ind has the same arguments and same functionality,
removing the function dfs_send_radar_ind_for_freq. The function
dfs_send_radar_ind is moved out of CHAN_NUM_API macro.
The function wlan_reg_chan_to_freq, wlan_reg_legacy_chan_to_freq is
moved out of CONFIG_CHAN_NUM_API macro. Since it is applicable for legacy
bands.
CRs-Fixed: 2711600
Change-Id: Ib29be638c17ce51f928c865e362ac5b2b8954b42
Update reg domain rules to support three new
channels in 5.9 GHz for US.
New channels are 169, 173 and 177 with freq
5845, 5865 and 5885 MHz respectively.
These new channels will be controlled by an
ini fcc_5dot9_ghz_chan_in_master_mode and
a service bit WMI_SERVICE_5_DOT_9GHZ_SUPPORT.
If the service bit is not set we disable the
new channels, and if service bit is set but not
the ini, we make the channels passive. If both
are set, they will be enabled.
Change-Id: I575b02ad387cbda00b015f7075d80c907463bdef
CRs-Fixed: 2683702
Add new channel bonding pairs as well as frequency
pairs for 40, 80 and 160 MHz with the support of
three new 5.9 GHz channels 169, 173 and 177.
Add new API reg_modify_chan_list_for_5dot9_ghz_channels
to enable/disable these new channels based on
INI value and service bit.
Change-Id: I8598e705ba4047e96e7167661ba70d4236cde251
CRs-Fixed: 2696211
When a one-shot capture is triggered with CFR, the state is not
reset to DISABLED after capture has completed. This affects HW mode
switch behavior because if CFR capture is ongoing (ENABLED), mode
switch is not allowed. This change checks for period to return DISABLED
or ENABLED. Period is 0 in case of one-shot capture.
Change-Id: Iae8727959a1becd3b5f4da166e868c1592910b84
CRs-Fixed: 2735166
Move few scoring params to uint8 from uint32 to save memory.
Also move the req and resp related IE to req and resp structures
instead of global structure.
Change-Id: I67f8dd3f381642083fc5f288ebd9055d2919faad
CRs-Fixed: 2737146
In the TBTT info of RNR, one byte is added for power
spectral density. Add logic to get the PSD limit.
Change-Id: I7ce44a762c47d0d0526157fcb41a80ad3ef3c08e
CRs-Fixed: 2731433
In I3c82e2eb98cdaf0ff8754bd990529a1833276304, KW error is reported in
the function, reg_compute_chan_to_freq.
This is because min_chan_range and max_chan_range can be assigned values,
that can cause array out of bounds issue.
To fix the issue, add explicit range checks against min_chan_range and
max_chang_range before iterating through master_chan_list to
avoid out of bound access.
Change-Id: Id5cd032fb899475720080b29012a6de1b5d4a916
CRs-Fixed: 2727082
Currently we invoke scm_11d_handle_country_info() on every
beacon/probe-rsp receiving, it is not fair if not checking duplicated
beacon/probe-rsp, like if station connected it will dwell more time on
home channel and receive more duplicated beacon/probe-rsp, and caused
elect unexpected country.
Because scan entry will be updated without duplication, so after scan
complete we do 11d country vote by iterating whole scan entry db.
Change-Id: If7669c5529dd51e193e4a58d0090c0b2a1f25425
CRs-Fixed: 2706837
For adrastea targets, enhanced CFR is not supported. When only
CONFIG_WLAN_CFR_ENABLE is set, some compilation errors are
observed as CONFIG_WLAN_ENH_CFR_ENABLE is not set true.
Fix these compilation errors when only CONFIG_WLAN_CFR_ENABLE
is set for targets which do not support enhanced CFR.
Change-Id: I96a769d8f10144033e48e123bb68d48a54cdf8ab
CRs-Fixed: 2706904
LOWI application provides the interface name as part of lowi message to
host driver. Add support in the driver code to get the corresponding
pdev_id and pdev from interface name using dev_get_by_name().
Change-Id: I267b95c843a9bb1dd0c58ff45767f31999500b1c
CRs-Fixed: 2711423
While BSS are scored apply blacklist logic to remove
blacklist AP or move the avoid AP at the end.
Change-Id: I3071b63732dba6763e2f48d0613b36e86bd780d9
CRs-Fixed: 2725143
While selecting the next channel after radar, if RCAC is enabled,
RCAC frequency and ch params are chosen. But in case where no
RCAC frequency was found, ch params were filled with 0s which are
then used by the next channel selection logic (random channel)
to figure out the next channel.
Since the ch params were now 0s, the ch width is pointing to
20MHz (0 enum) which results in a 20MHz channel picked irrespective
of current mode.
Do not modify ch params if the RCAC frequency is NULL.
CRs-Fixed: 2729023
Change-Id: If542fb8584a767ad8d1fe6115af039e8bc2cb173
Setband changes require support for 6G band. Using a bitmap
better supports the addition of new bands. Changes to support
this include:
1. Update band_capability in regulatory pdev priv obj
to be a bitmap.
2. Add API to convert between the bitmap and
enum band_info.
3. Update channel list modifying function to include
case for 6G band.
4. Update the get and set APIs to use uint32_t instead
of band_info.
Change-Id: Iff38fdd7cc540a0e471647de349d7fa57b3a8467
CRs-fixed: 2726285
