This change is to add support for 320 MHz bandwidth based on
EHT Operation element defind in 11be draft 1.5.
Change-Id: Ie2e165493538991c331a856fea26d3ca518f04ad
CRs-Fixed: 3202962
Per 11BE Spec, only 320 MHz support in 6 GHz is defined in EHT
PHY capabilities. Therefore when deciding max target supported
EHT bandwidth, 320 MHz support is first checked using target
advertised EHT phy caps. If 320 MHz is not supported, fall back
to VHT channel width supported, which includes 160 MHz and 80 MHz.
Change-Id: I26ddfa250db66d72ca55a3c9f966d71740cb0414
CRs-Fixed: 3190474
SAP is allowed to come up on SCC with a STA operating
in 6GHz only if the STA is on a PSC channel in VLP mode.
Therefore, filter out all 6GHz channels from the PCL if
the STA operates on any non-VLP mode. Also, in case of
VLP mode, filter out non-PSC channels.
Change-Id: I37d9a510db3647fc07858af99eb614ebe824cc78
CRs-Fixed: 3206471
Sta is not allowed to connect/roam in 6 GHz frequency or indoor
frequency in non-DBS target if SAP is active.
But STA roams to 6 GHz AP when SAP is active since the PCL allows
6 GHz frequency.
While populating PCL to firmware, check if 6 GHz and indoor
frequencies are allowed for non-dbs target and set the
weight appropriately if the channels are not allowed
Change-Id: I0e5fdc5b3c4177283d91cdfc58359336cc11910d
CRs-Fixed: 3205494
When STA is connected to non-dfs, non-indoor channel and
SAP starts second with mandatory channel list enabled,
then SAP is moving to 2.4Ghz. But SAP should follow sta
and move to non-indoor, non-dfs channel.
Also when STA is connected on DFS channel and when SAP
is coming up with g_enable_sta_sap_scc_on_dfs_chan,
then SAP also should move to DFS channel
So when PCL channels are filtered based on mandatory
channel list, then allow dfs/indoor channels based on
concurrent STA frequency.
Change-Id: I2bcb81a8b014108b07db36a31d03d0a16fe49eb9
CRs-Fixed: 3207750
Current code calls wlan_hdd_select_queue(dev, nbuf)
inside the netif_tx_lock(dev). But the logic does
not need to hold this lock.
Move the function call outside of the lock,
to optimize the critical section.
Change-Id: Id3b86ec82e9583e8d91b0a0f28f951ea192c3f06
CRs-Fixed: 3207147
The max IE length in the frame is 255, and the payload of Multi-Link
element is becoming more than 255 and fragmented. Add logic to defragment
the ML IE when parsing the rx frames.
Change-Id: I438972143b457072edcd3e5b13b7c043a445457f
CRs-Fixed: 3202402
For KIWI platform FST reside in CMEM. CMEM address is known at the
init time from platform driver. Use 16K of CMEM address for FST.
Increase MAX FISA FST entry size to 256, which is allowed max size with
16K of CMEM allocation for FISA FST.
Change-Id: I395ab884b9cc761ed3c4438434475d6f9908a62b
CRs-Fixed: 3199251
If macro WLAN_FEATURE_11BE_MLO is enable, get_station_stats_cb for
TYPE_STATION_STATS is called only if last_req->ml_vdev_info.ml_vdev_count
none zero when WMI_UPDATE_STATS_EVENTID event comes back.
This causes timeout and fail to get station stats for legacy device or for
MLO device which does not set last_req->ml_vdev_info.ml_vdev_count.
To resolve this issue, add sanity check legacy device before invoking the
callback and set last_req->ml_vdev_info.ml_vdev_count if it is MLO device.
Change-Id: I8ca325482fc32de87cbedcba7d4af17d3876cbbc
CRs-Fixed: 3202588
Add log to check which mode, vdev and freq is
added as disabled ml link and dump disabled
links after moving vdev from connection table
to disabled link table and decrement session
count only if provided vdev entry is present
in connection table.
Change-Id: I19cd9323b7b66b29366f2ac930798da8ef91a709
CRs-Fixed: 3205975
When disconnected request started for an MLO connection,
link vdev gets disconnected first and then assoc vdev. So active
disconnect request is queued for link vdev first. As part of
RSO stop request-response handshake, the disconnect request is
cached and RSO stop request is sent to firmware. Disconnect is
supposed to resume for link vdev after getting the RSO stop
response . But currently, first MLO vdev gets checked if it
has active disconnect. This may fail to fetch the active
disconnect request if the first vdev in the list is assoc vdev
as it doesn't have active disconnect but link vdev has.
Check if it's a link vdev to resolve this and fetch active
disconnect req always.
Also, if there is only one link present(e.g. single link
connection or failed to connect the secondary link, etc.. ) in the
vdev_list, current release of vdev refs at the end of the API
wlan_cm_mlo_update_disconnecting_vdev_id() is not valid as it's
trying to release all links. Release only the links for which
reference is taken.
Change-Id: Idcb8a979dbdadafd4690e51a7301c4a7dfe82f73
CRs-Fixed: 3203969
Add API ucfg_mlme_set_vdev_traffic_high_throughput &
ucfg_mlme_set_vdev_traffic_low_latency to configure the
high throughput and low latency to vdev. In MLO STA concurrency
cases, the host or target may disable a certain link
based on the flags.
Change-Id: Iaae7cfdeb55e0086572b071d83520278aa3425ea
CRs-Fixed: 3191501
In SAP+GO concurrency, if GO is started on 2.4 GHz and SAP is
doing ACS with 2.4 GHz preferred channel list, then we will
move GO to 5 GHz band. The purpose is to have more choice
in SAP ACS instead of starting on GO home channel for SCC.
Add API hdd_handle_acs_2g_preferred_sap_conc for such
purpose.
Change-Id: I6f2b4bab526c7e1c9163b8437c40350d3bf10bab
CRs-Fixed: 3181419
When SAP and GO home channels are in MCC in same band,
implement below requirement to avoid MCC:
1. SAP starts at first and GO starts later, then SAP will
force SCC to GO's home channel after GO starts up.
2. GO starts at first and SAP starts later, then SAP will
force SCC to GO's home channel during starting up.
3. SAP and GO SCC in same band, SAP changes channel to
the other channel in same band, GO will follow SAP and
move to SAP home channel.
4. SAP and GO SCC in same band, GO changes channel to the
other channel in same band, SAP will follow GO and move
to GO home channel.
And all the force SCC cases, if the target channel of force
SCC is not supported by the SAP or GO, then driver will
select other band's channel for the interface.
Change-Id: I7b24f3a972a401fd144a0c81dc19bd48ba224d85
CRs-Fixed: 3176087
Currently, wakelock is only taken during initial connection if
pairwise key installation is pending and not during roaming. This
may lead to EAPOL delay/timeout during roaming as runtime pm and
suspend is allowed during roaming. To fix this issue, acquire
wakelock if key installation is pending during roaming.
This change also refactors the code and release the wakelock in
wma_remove_peer if EAPOL fails during initial connection or roaming.
Change-Id: Id4cac30b3c383ca3d3e963571846f8a30eaa1006
CRs-Fixed: 3189799
In case if HW doesn't support 160 Mhz BW, driver
doesn't update 160 Mhz capability in WIPHY and
even in such case if Userspace configures ACS
BW as 160 Mhz in hostapd, Driver selects this
bw for acs without checking whether HW support
this BW. This leads to mismatch between ACS BW
and supported Wiphy BW and ultimately leading
to SAP start failure for 160 Mhz for 5 ghz and
6 ghz band.
So, Update ACS BW with HW Supported BW such
that if hw doesn't support 160 Mhz bw then acs
bw 160 Mhz shouldn't be selected.
As in wiphy we won't enable 160 Mhz capability.
Change-Id: I195b0e6bd0ce7640f136077ed9042c6e15088143
CRs-Fixed: 3170528
EAPOL TX message enters the driver via NL and not
through the ndo_select_queue. Hence skb->queue_mapping
value is not set.
This fix will set the correct value to queue_mapping
for EAPOL packets. The EAPOL TX packets will hence be
marked correctly in the wlan_hdd_mark_critical_pkt()
and then logged.
Change-Id: I97018c4e8b44c55f9924c1465b41fcfdbc50406c
CRs-Fixed: 3190128
6 GHz STA profile contains HT and VHT capabilties in association
request when STA tries to associate 2.4 GHz + 6Ghz MLO connection.
Removed HT and VHT capability population from MLO IE preparation
when MLO connection is 2.4 GHz + 6 GHz.
Change-Id: Ie21723fb1f9c81404015a7de4f787447acbf9e90
CRs-Fixed: 3200099
EasyMesh agent fails to update the phymode requested by controller.
EasyMesh controller sends the channel selection request package to notify
EasyMesh agent to change phymode and channel. EasyMesh agent should change
them accordingly.
Update the phymode of the SAP, then restart the SAP.
Change-Id: Iab881b0bfbd1764072b48d426610adc8967111cd
CRs-Fixed: 3181195
Previous linkspeed only enabled for P2P mode,
and here extend for STA/SAP mode per request.
Change-Id: I0976ee2e4b064b74cc2532a310f20e0ef1b0e7f6
CRs-Fixed: 3205568
There is only 1 global var to save EHT cap in psoc cfg for both 2 GHz and
5 GHz band, it is propagated to vdev/pe session/frames without revising by
band, so EHT cap of 2 GHz and 5 GHz are same, EHT cap of assoc link and
partner link are same, so no EHT cap in ML-Link Info(per STA Profile) in
assoc request while connecting to EHT MLO AP.
To fix it, revise EHT cap when band is selected, get EHT cap by band when
assemble assoc req MLO link per sta profile, get correct 2 GHz cap by
checking supported bands when get MAC/PHY cap from firmware, copy supported
MCS set from firmware to EHT cap of 2 GHz and 5 GHz too.
Change-Id: Ie97e71ee141f023248fb49f9977e7345e21003f6
CRs-Fixed: 3200199
When verifying WNM BSS transition function, it's possible to
ask peer STA to transition across multiple band. Some vendor
BTM implementation is needed to check country IE to get all
supported band channel info. Without full channel list in
country IE, it cannot make a transition across multiple band.
To solve the interop issue, let country IE take all supported
band channel info when the specific vendor OUI is detected in
association request.
Change-Id: I78dd4b88937277b54a7da4d72d8a94706965e9a6
CRs-Fixed: 3196957
This reverts commit I9701830d. Host needs to honor the ll stats
command in disconnected state also.
CRs-Fixed: 3197453
Change-Id: I32db288cf070bba21023536c0d9e933835f26c53
Currently driver checks TX flag only for authentication
frames. This causes wrong tag for the frames.
Check TX flag for Deauth/Disassoc & authentication frames
also.
Change-Id: Id499bc1978ee72bac2435be165b31d0db49ce9d8
CRs-Fixed: 3203858
