Add infra to support Dedicated Bluetooth Antenna Mode (DBAM)
feature. It is used to switch between dedicated antenna for
BT and shared antenna for WLAN and BT.
Change-Id: I21688093674ef9b63ee811df9168a31bd71c56b5
CRs-Fixed: 3239895
Add support for initiate pasn authentication using the vendor
command: QCA_NL80211_VENDOR_SUBCMD_PASN
Fill the below required attributes to initiate PASN:
QCA_WLAN_VENDOR_ATTR_PASN_ACTION
QCA_WLAN_VENDOR_ATTR_PASN_PEERS
QCA_WLAN_VENDOR_ATTR_PASN_PEER_MAC_ADDR
QCA_WLAN_VENDOR_ATTR_PASN_PEER_SRC_ADDR
Change-Id: If33f54eafe5986b4571cc21a80fb0b61578db116
CRs-Fixed: 3232261
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
In function reg_freq_width_to_chan_op_class_auto, global_tbl_lookup is set
to false for 2.4 GHz and 5 GHz without considering the global opclass set
by user command. This results in wrong opclass information in eCSA.
Add an api to check if global opclass is set and update global_tbl_lookup
accordingly in reg_freq_width_to_chan_op_class_auto.
Change-Id: I069131d6068fb546f2b59f1e752a3c8c50f15759
CRs-Fixed: 3168817
Fix compilation issue for adding AFC regulatory target
interface to support AFC device deployment
Change-Id: Ie9447873442e94614f44eb7468b76143b0f2dda3
CRs-Fixed: 3195809
Add AFC regulatory target interface to support AFC device
deployment indoor or outdoor type in init sequence between
FW and host
Change-Id: I3caed77e943fdcaa947cb7e514c88b68604f55a3
CRs-Fixed: 3190262
Add support to manage Wifi pos vdev private object. Add new peer
type in enum wlan_peer_type. Add rx_ops and register the rx_ops
for PASN peer create/peer delete request.
Register 11az PASN related WMI events in target if.
Change-Id: I2a5e4d8d7c9b9562d9ab02b287957e93ee6f4758
CRs-Fixed: 3154521
Validate the MLO HW link related info obtained from the global shared
memory arena of management Rx reorder feature.
CRs-Fixed: 3111549
Change-Id: I6fd7812dc49bfa8428b2ffbf66ae978592734bc0
Move the global shmem common APIs (init & deinit) from REO
component to MLO component.
CRs-Fixed: 3122203
Change-Id: Ib52490c0e9662d6297a52af365e1d87b60e0739d
Export objmgr APIs to be used by SON module to register
and unregister create/destroy handler.
Also add lmac_if API to register lmac_if ops from SON
module.
Change-Id: Id4c19807792b9f7b46387ae907f853151e4e28c6
CRs-Fixed: 3118986
Save quiet status of indicated link to sta contect of MLO mgr. Any link
should check quiet status of MLO connection, then decide whether it
can trigger inactivity to FW or not.
Change-Id: Ic294bbe6452030b6cae495ca0dd3e504416e2c9e
CRs-Fixed: 3117825
Wireless mode is of datatype uint64_t but in some places, it is used
as uint32_t.
In this change, replaced 'uint32_t wireless_modes' with
'uint64_t wireless_modes'.
Change-Id: I13b5781ddb14fc0131668e1710df19ae75eb1e34
CRs-Fixed: 3119562
Firmware sends the following reg rule to build 5G 240MHZ channels
240MHZ reg rule:
start: 5490, end: 5730, max_bw: 240.
However, 240MHZ is not one of the standard IEEE channel width.
Hence the channel finding APIs will fail to find a channel of 240MHZ BW.
240MHZ is considered as a punctured 320MHZ channel (320 - 80).
Hence convert the max bw of 240MHZ reg rule to 320MHZ within the host
so that channel can be built.
Also, change the 5G 240MHZ bonded pair's end freq to 5720. Since there is a
5MHZ bandwidth gap between channel 144 and 149, the bonded pair is
restricted to 5720MHZ on 5G.
Change-Id: Iee8dad0317f7ecb95843faa3d0779b854b8f48fa
CRs-Fixed: 3106866
Trigger MLO teardown and wait for response before proceeding with soc
power down.
Change-Id: Ie1d00408862459b0e5240ef3151a0d969ab65e80
CRs-Fixed: 3102143
As per the spec,
"A STA affiliated with a non-AP MLD, that operates on Link2, transmits a
(Re)Association Request frame to AP2 requesting Link1 as one of the links
for multi-link setup. Since the (Re)Association Response frame is
transmitted by AP2 after the last Beacon frame on the initial operating
class/channel on Link1 and before the first beacon on the initial
operating class/channel is transmitted, AP2 includes the Max Channel
Switch Time element in the per-STA profile corresponding to AP1 in the
(Re)Association Response frame it transmits. The value carried in Max
Channel Switch Time element provides an estimate of time until the first
TBTT on the new channel on Link1."
Hence, calculate the remaining max channel switch time using the below
steps.
When host receives the CSA complete event with the CSA count 1, calculate
the Max channel switch time for each vdev by adding the below values,
a) Host triggers the channel switch when CSA complete event is
received with the CSA count 0. The time difference between
CSA count 1 and CSA count 0 is one beacon interval. Hence, add
one beacon interval.
b) Add the channel change time. The total time required to receive
CSA event handler from FW with CSA count 0, plus, the time required
to process the CSA complete event, plus, the time required to send
multi-vdev restart request for all the vdevs in the new channel and
send updated beacon template (only for non-DFS channel) is
approximately 1 second (added a few milliseconds as delta and
considered 16 AP vaps here).
c) Add DFS CAC duration of the new channel if the new channel is DFS.
d) Add one beacon interval time (time required to send the beacon on
the new channel after VDEV up).
e) Store the sum of the above time values in max_chan_switch_time of
the vdev_mlme object.
f) Save the current time when host receives CSA complete event with CSA
count as 1 in the last_bcn_ts_ms of the vdev_mlme object.
Calculate the remaining channels switch time using the below formula.
- Remaining channel switch time is equal to the time when the last beacon
sent on the CSA triggered channel plus max channel switch time minus
current time.
Reset the max channel switch time and the last beacon sent time after
sending the VDEV UP command to FW.
Change-Id: I7c03bfae5e159419a6c9462591aeb2d6c5b4fb87
CRs-Fixed: 3076245
Currently, VDEV manager responses are using legacy path instead of
target_if, vdev_mgr and os_if components. As the driver implementation
is planned for converged model, legacy implementation will be moved to
the respective components.
To avoid rework, Use target_if, vdev_mgr and os_if components to process
the FW responses corresponding to the vdev manager.
Change-Id: I778f6de93481fc730383e8f8e1c604f173947d69
CRs-Fixed: 3093776
Add interface for sending mlo link set active cmd and
register the response handler.
Change-Id: Icd7cf3294cddec1aa4a417e29a22fcd6fbea0dfb
CRs-Fixed: 3036846
Currently, MAC address update is supported only when interface is down.
Because of this framework needs to issue interface down and interface
up to update the MAC address.
This is resulting in connection time increase when MAC address
randomization is enabled for every new connection.
To optimize the connection time, add support to update the MAC address
without bringing the interface to down state.
Change-Id: Ic3eff6a9571f885292021b2c178d26b0eace5042
CRs-Fixed: 3063475
Add support to extract the freq, cfreq1, cfreq2, PHY mode, Destination
macaddr, and channel BW values from the RTT measurement request buffer
received from the LOWI application. Pass these values to a registered
callback. Users can use these values to make some decisions on the RTT
scan.
Change-Id: Idb2232c07bbfa2946dc01e75908b9a6036597ecf
CRs-Fixed: 3060685
With the introduction of 11BE, channel puncturing becomes possible.
Hence, the DFS channel structure should be updated with channel puncturing
information.
Change-Id: Ia1bccd55e7fadde2a49fb08bd30ff6b5b2cc6ba1
The "wmi_pdev_dfs_radar_detection_event" has an unused field "chan_freq".
It currently holds the value of primary 20MHz channel. With the
introduction of 11BE chipsets, this field is changed to hold the value of
the center frequency of the channel width on which the radar is found.
This new change is indicated by a wmi service
"wmi_is_radar_found_chan_freq_eq_center_freq".
For the Chipsets that support this service, the radar found frequency
can be calculated by mere addition of the fields "chan_freq" and
"freq_offset" field.
Change-Id: I8d2ce0023e2feb6e749ca8d7d5f547fafc0fdf98
Expose the following APIs from MLO global shared memory handling
- APIs required by the REO logic
- APIs required to invoke the MLO global shared memory parsing
Change-Id: Ia2fb0b0fee5d3904bae8cd70ce3364360d5ea16e
CRs-Fixed: 3014343
Consider the management frames that are consumed/dropped in the FW and also
the frames that are received at the Host but dropped in lower layers.
The host has the MGMT Rx REO parameters about these frames via WMI events.
There could be frames waiting in the MGMT Rx REO list for the above-said
frames. If we update the waiting frames with the MGMT Rx REO parameters of
the above-said frames, the waiting frames could be released and sent for
processing. Add the logic for the same.
Change-Id: I6be4577d30c4aefe2e964aefbb56472749a90cb4
CRs-Fixed: 2987941
When a management Rx frame enters the MGMT TxRx component, route it to the
MGMT Rx REO module where the REO algorithm decides whether the frame needs
to be processed right away or need to wait for frames on other links.
Change-Id: Ib7ca911dfaeee131fd71d9a4345f5bc720326228
CRs-Fixed: 2987784
In dfs test mode, bandwidth detection test on dfs channel fails
with QCN7605 chip, reason is some pulses will be discarded due to
low rssi reported on some frequency channel, it's different halphy
design for QCN7605 chip, so need to define rp_rssithresh for QCN7605
chip to different value.
Fix is define rp_rssithresh for QCN7605 chip to different value for
FCC/ETSI/JP W56 table which are used for dfs certification.
Change-Id: I9132cf82e6d8d97f83ebb4cd8586f8d8ff48066e
CRs-Fixed: 2986947