Pine and Spruce supports 80P80 mode of operation in 5 GHz band
and hence opclass 130 is sent to the user application in
MESH_MAP_OPCLASS_FOR_CUR_HWMODE NL80211 command.
However, these chips support 80P80 mode of operation
only on CFI 138 and 155, but to the application all the 80 MHz
channels in the 5 GHz band are advertised as supported.
This causes the application's channel selection algorithm to fail.
The existing API reg_is_chan_supported() can determine if the input
frequency is 80P80 capable only if cfreq2 of the 80P80 channel is
provided and in reg_get_cfis_from_opclassmap_for_non6g() API, it is not
possible to determine all combinations of cfreq2 for the given primary
frequency. Hence, a call to is_freq_80p80_supported() is made to
determine if any 80P80 combination is possible for the given input
frequency.
Also, 6 GHz channels do not support 80P80 mode of operation.
reg_is_cfi_supported() does a lot of computation to find out that
80P80 is not supported. Hence, if the opclass entry
is 6 GHz 80P80, set 80p80_supported as false.
Hence, send only the supported 80P80 CFIs in the
supported channel list array in MESH_MAP_OPCLASS_FOR_CUR_HWMODE command.
CRs-Fixed: 3627501
Change-Id: Ib5d3e872b34b8df81b8466e877b10f2fd4e68e40
Modify return values in wlan_crypto_setkey to
reflect the exact error condition.
Change-Id: I21729bf999a6561d6282bb456451e1e1a0748609
CRs-Fixed: 3629285
Currently for any assoc failure the number of links part of the
association is reduced and retried with less number of partner links.
If the failure is due to PMKID retry to the same with the same number
of partner links instead of downgrading the links.
Change-Id: I65320d92b4b77d2ccfb20a05fbab2aa8377bb6fa
CRs-Fixed: 3653834
Host driver moves VDEV SM to IDLE_DUE_TO_LINK_SWITCH any link
switch failure to handle events such as DISCONNECT_REQ which
gets dropped if the VDEV is in INIT state.
Disconnect request on any ML VDEV initiates disconnect on partner
VDEVs as well if they are either in connected or connecting state
but not if in IDLE_DUE_TO_LINK_SWITCH state. This leaves the VDEV
in this new IDLE_DUE_TO_LINK_SWITCH state instead of in INIT state.
Include VDEVs which are in IDLE_DUE_TO_LINK_SWITCH during partner
VDEV disconnect so that VDEV SM moves to INIT.
Change-Id: I6e715c0bb94562be866e902009b3bfd7d2c60e8a
CRs-Fixed: 3659110
Currently 'reg_compute_pdev_current_chan_list' is called
twice as shown below, when 'wmi_reg_chan_list_cc_ext_event'
from FW is handled.
LIST_CC_EXT event:
reg_compute_pdev_current_chan_list() [ 1st call]
reg_send_scheduler_msg_nb()/reg_send_scheduler_msg_sb()
wlan_reg_decide_6g_ap_pwr_type()
reg_decide_6g_ap_pwr_type()
reg_set_ap_pwr_and_update_chan_list()
reg_compute_pdev_current_chan_list() [2nd call]
To solve this, do not call 'wlan_reg_decide_6g_ap_pwr_type'
from north bound or south bound callbacks.
However, the above fix creates another problem because the function
'reg_decide_6g_ap_pwr_type', in addition to calling
'reg_compute_pdev_current_chan_list', also sets the current 6 GHz
power type for the pdev. A proper place to set the 6 GHz
power type is in function 'reg_set_ap_pwr_type',
which currently does not set 6 GHz power type correctly.
Hence remove 'wlan_reg_decide_6g_ap_pwr_type' and
'reg_decide_6g_ap_pwr_type' functions and modify
'reg_set_ap_pwr_type' to set the best 6 GHz power type
based on the 6 GHz regulatory rules.
CRs-Fixed: 3609342
Change-Id: I1bdfd71245552a51fd5123931a7a6dcc16f2a942
Issue happens during following scenario:
1. Connecting to ML AP1 (with SSID1) and disconnect.
2. Connecting to ML AP2 (with SSID2), as part of that vdev
is destroyed and created but stored keys for AP1 are not reset.
3. Disconnect for ML AP2.
4. Connect to ML AP1.
Now host driver sends stored keys FW instead of the newly
generated keys sent by supplicant.
To fix this during ML dev initialization
clear the stored keys.
CRs-Fixed: 3649214
Change-Id: Ibffeb8b3108bf353e9140cbc901f99f08d9b0449
Provide support for bangradar with Frequency hopping radar type
as one of the parameters.
Add the parameter as part of the packed structure to be sent to FW.
Change-Id: I1c366c8f1c2033527bbd74f0ae6219225cafc4ed
CRs-Fixed: 3641574
If "override_ht20_40_24g" ini is set, the host driver disables
the HT40/HE40 caps for 2.4 GHz after connection via SET IE. The
firmware uses this for roam. However, if reassoc comes from userspace
with the HT40 cap different from the initial connect, then host
does not update the IEs based on new cap. This leads to mismatch
between user configuration and firmware roam.
To fix this, modify and send the HE40/HT40 caps via SET IE for
every connect request. Reset it after disconnection to the default
self cap.
Change-Id: I3de73d2ff2e5ebbbda530c29371edc0295ec608f
CRs-Fixed: 3655893
For MCC, dp_vdev_detach_wifi3->dp_vdev_id_map_tbl_remove
will happen before mlo dev ctxt detach from vdev destroy,
which will cause it access dp vdev with null pointer issue
(use-after-free).
So move the mlo dev context detach out from the function
wlan_objmgr_vdev_obj_destroy(), and will detach the mlo
dev context from hdd_vdev_destroy_event_wait for MCC and
meanwhile not impact win logic.
Change-Id: Id07db64a27cd7032ea45fb4661b54edb662010c7
CRs-Fixed: 3621883
Since sta don't send probe req to MBSSID AP, channel info in
link_info not update.
But station receive beacon and update info into scan_entry,
so when connect done, we can update link channel info from
scan_entry by bssid and freq.
Change-Id: Ie7058cf055847b709823a7ade89e074f718f03d6
CRs-Fixed: 3625825
Add initialization value for bss_mld_addr in function
cm_check_and_prepare_roam_req().
Change-Id: Ic9ac9fd6f94343ff1bab8b45bac81e889a9dfe1f
CRs-Fixed: 3643137
Currently host is directly acting on the link_id for which link switch
is requested, if the link is already active on the other vdev if the
link switch is not sanitized resulting in firmware ending up
in bad state.
Reject the link switch if the link is already active on different vdev.
CRs-Fixed: 3635416
Change-Id: Idf445dcc487540c4faac7cf98abf7c214512d750
In case of outdoor NULL response, currently the api
'reg_set_ap_pwr_and_update_chan_list' bypasses setting power
type when ap_pwr_type is REG_CURRENT_MAX_AP_TYPE
in order to update the current channel list to the upper layers.
Due to this, selecting best power mode
algorithm fails during the invalid case scenario (allowing
to operate in channel which is not in Outdoor SP channel list).
To fix this problem, remove check which bypasses setting power type in
the api reg_set_ap_pwr_and_update_chan_list.
This removal needs an additional change which will handle the updating of
current channel list, which is done in another change. Refer to
change Change-Id: I176a432a031af0170e8bc7dec9b417828595fd14
for more details.
Change-Id: I80e3a0d12afa175d30fa945fb83aa8b247bf3889
CRs-Fixed: 3641754
Currently, mlo_get_assoc_rsp provides assoc rsp pointer
every time even in case of reassociation where assoc rsp
is not valid which can cause issue in link_switch as assoc
rsp provided might be invalid.
Fix is to provide reassoc rsp if present in case assoc
rsp is not present.
Change-Id: I91715a39f77159b68eee5cc97dc291a09e21a897
CRs-Fixed: 3622768
New API, reg_get_next_higher_bandwidth added to
get next higher bandwdith for the given channel width.
Add boundary check for channel width in
API get_next_lower_bandwith.
Change-Id: Icd250d0c518eda9749b25778427b1bffac66ad56
CRs-Fixed: 3636188
Currently the ini "enable_responder_11az_support" is a boolean value
and applicable for enabling all the RSTA operations- 11az TB and NTB
ranging. Change the usage of existing ini "enable_responder_11az_support"
into a bitmap as below:
BIT 0 - 11az NTB
BIT 1 - 11az TB
Set the wiphy ext caps based on the bitmap values
this change to enable TB/NTB ranging as per user config
Change-Id: I97034677e6ed6840d8d9403b32b823c318a17634
CRs-Fixed: 3640571
In case of 2 link AP, partner link will be 1 instead of
2. As of now, driver set is_valid_link as false in
case of 2 partner link.
Fix is, set is_valid_link as false if partner link is 1.
CRs-Fixed: 3645066
Change-Id: Ib91baff1915b9b38a8144ad3f9c8cb113c450205
Add null check for RNR node in the scan API
scm_filter_rnr_flag_pno before accessing its parameters.
CRs-Fixed: 3645688
Change-Id: I8c18c75214128496d159425c923db1be1525e298
HE score is directly dependent on prorated_pcnt value.
With Change-Id: I812f5c322d36ba44f63d4e27b5ec65a2846b3265,
In "cm_calculate_bss_score", prorated_pcnt is initialized as zero but value
is never updated. This leads to HE score as zero always.
To fix this, retrieve the prorated_pcnt value from "cm_calculate_ml_scores"
before calculating HE score.
Change-Id: I64ff207d8935c5b2440d6fba07adc534c30891c0
CRs-Fixed: 3634652
Scenario: Turn on and off XPAN multiple times and in between
of this, bring all interface down.
When XPAN gets turned on, it will run ACS algorithm either on
new scan results or previous scan results which are having
last_scan_ageout_time less than 30sec to select the best
channel. If multiple times ACS request comes then driver should
select the same previous channel if it's scan time is less than
30sec. But in this case, driver was selecting different channel
when all channels were recently scanned.
This is because, in some scenario, the number of scan entries
was becoming 0 which causes ACS to select new channel even the
previous selected channel were recently scanned.
Reason for becoming number of scan entries as 0 is when all
interface goes down, stop modules will get call which results
to flush out the psoc. As part of psoc flush out, it will remove
all scan entries as well. But driver is not resetting the
last_scan_ageout_time when no scan entries are present. Hence,
it will not for new scan again and later all channels were having
same score after applying ACS logic. This led to select first
from scanned list.
As part of fix, reset the last_scan_ageout_time when no scan
entries are present.
Change-Id: I8e021ecf22047661076e11302998a42c029f8b37
CRs-Fixed: 3625075
Currently, scan on same mac channel is not allow where
LL_LT_SAP is present.
But as part of this change, allow scan on same mac channel
where LL_LT_SAP is present.
Change-Id: I0c781caa70bf5c95c0639218dd08a409ebeefbfc
CRs-Fixed: 3636119
For candidate entry which is given as bssid hint, the maximum
score CM_BEST_CANDIDATE_MAX_BSS_SCORE(20000) is given and no
other operations are performed. But for MLO connection
scenario, the best links should be chosen for association and
other links will go to standby.
This is not happening for candidate entry which is given as
bssid hint. So links with inferior score could be chosen as
partner links.
Sort the partner links based on score for candidate which is
given as BSSID hint also to choose partner links with better
score.
Change-Id: Iac50778b7e66c65727c788ace0885f5e88cb4159
CRs-Fixed: 3636673
When Mapping Switch Time(MST) or Expected Duration(ED) expires the
peer-to-peer level T2LM negotiation will be discarded. Hence, add a
callback to update the peer-to-peer level T2LM negotiation data
structures on MST and ED expiry.
Change-Id: I873e07918941ea16c90fb40445b5c032abe9676b
CRs-Fixed: 3640538
STA info length subfield of STA info field indicates the number of
octets in the STA Info field, including one octet for the STA Info
Length subfield.
In the current implementation, one extra byte is added to STA info
length subfield to access STA profile subfield. Due to this, unable
to extract CSA, ECSA and MCST IEs from the STA profile.
To fix this, don't add WLAN_ML_BV_LINFO_PERSTAPROF_STAINFO_LENGTH_SIZE
to offset field to access the STA profile subelement.
Change-Id: I99fb3c5d1bfb9b3bf414fc0b778d724e98a3c7ae
CRs-Fixed: 3640538
Currently host fills channel frequency in connect response
buffer either by frequency of selected candidate or
frequency present in connect request. Mostly upper layer
sends a connect request with frequency = 0. So in case if
connect request fails due to “no valid candidate found”
for connection and with reason "Unspec failure", host
sends frequency = 0 (present in connect req) to upper
layer via an event EVENT_CONNECTIVITY_LOG.
Fix is if frequency present in connect request use
frequency else use frequency hint present in connect
request to fill connect response buffer.
Change-Id: Ic6eaf6cd26587bd2051c4449038009f08b9e2fad
CRs-Fixed: 3638648
Add callback mlme_vdev_reconfig_notify_standby to cld code to
handle standby link removal.
For standby link, it is going to be removed by AP, so don't
start link removal timer for it. Force inactive it to avoid
link switch to it.
Change-Id: Iae8eebeb2263b0057026c0e80223ef5c6b68a41f
CRs-Fixed: 3640204
Currently in cm_get_cm_ctx_fl, if caller passes NULL vdev as an
argument, then it leads to crash in driver.
To avoid NULL access, add vdev null check.
Change-Id: I37e1d095829b84ee75cc89d8dcf5fbe312c25035
CRs-Fixed: 3632944
Add change to initialize all members of the struct, as one of the member
is not updated in the callee function.
Coverity issue fix.
Change-Id: Ic0c2d70fa540fd81ae9094e49c2240ebd9b691b5
CRs-Fixed: 3632788
If LL_LT_SAP is already present and if STA tries to
come up on same mac, then it may result in data loss
on LL_LT_SAP as STA will need ROC on the connection
channel for some time, to avoid these data loss during
STA connection, add logic to switch the bearer for LL_LT_SAP
data to non-wlan and once connection completes, switch back
the bearer to wlan.
Change-Id: Ic44cd77b9b5e569350d697c33260cf5cec3652e0
CRs-Fixed: 3627643
Add a cfg set API to configure scan mode for 6 GHz. This is
invoked in reset HE capability API.
Change-Id: If4891036dec3777d85f3584eef965ed65ececadd
CRs-Fixed: 3629445
AP sends chan center freq index via Bandwidth Indication OPIE
in channel load request.
Call reg_compute_6g_center_freq_from_cfi API to get corresponding
center freq for 6 GHz and 320 MHz case.
Change-Id: I14bbfe75016e40189388f32fd207d21197bc989b
CRs-Fixed: 3629129
Current SAP is unable to support multi-link MLO connection.
To unblock validation we simulate 2-link connection on SAP.
Changes are as follows:
- Add support for multi-link during assoc
- disable security check during assoc
Change-Id: I21b3de2298085d7e6676854a7be68608546ccc6c
CRs-Fixed: 3591638
Handle mlo_grp_id value for rx_reo_release_frames so it cant be
more than WLAN_MAX_MLO_GROUPS
Change-Id: Id6761f125d1ce04d8b10753f86e1d2c1cb30c65e
CRs-Fixed: 3620074
This change is to fix modpost issue due to mlo_mgr_get_ap_link_by_link_id
in 6.x compilation.
Change-Id: I2da64fd550f6dbafe87100ca80a280834f1f3f12
CRs-Fixed: 3603454
Currently, as part of wifi load, the wifi_pos psoc private object is only
allocated for the first PSOC (PSOCx) and this PSOCx can be accessed via
wifi_pos_get_psoc() to derive the wifi_pos psoc private object.
In the current code, when RTT is triggered on PSOCy, this psoc is used to
derive the wifi_pos psoc private object instead of PSOCx.
Since wifi_psoc psoc private object is not tied to PSOCy,
wifi_pos_get_psoc_priv_obj() returns NULL and this leads to RTT failure.
To fix this, check and replace ‘wifi_pos_get_psoc_priv_obj(psoc)’ with
‘wifi_pos_get_psoc_priv_obj(wifi_pos_get_psoc())’
Change-Id: I2acb91c4c80ad94df22390f3763e2d34c83b743d
CRs-Fixed: 3619836
