Currently, vdev_id 0 is chosen as default vdev_id in
opportunistic_timer_handler when none of the vdevs are started.
The same is used to send set_hw_mode command. But vdev_id 0 might
not be valid all the time and set_hw_mode command fails in
serialization module in such cases.
Below is one possible scenario,
1. Load the driver. p2p0 gets vdev_id 0 and wlan0 gets vdev_id 1
2. Enable NAN and create two NDIs. p2p0 interface(vdev_id-0) will
be deleted by userspace as part of this.
3. Disable NAN and remove the NDIs. It triggers opportunistic_timer
but hw_mode won't be set to SMM as the vdev corresponds to
vdev_id-0 doesn't exist.
So, choose a valid vdev_id(mostly belong to STA/NAN) as default
vdev_id.
Change-Id: I19bd00a07cb2c818af9ed5021b0ae0aca8c49f2f
CRs-Fixed: 2889404
Remove g_prefer_5g_scc_to_dbs, and update PCL table
pm_second_connection_pcl_dbs_2x2_table.
For STA + GO concurrency if the second connection is GO,
perfer SCC to DBS, which makes GO get high throughput.
Change-Id: I0bf68662fc363a66c778904f9c12714407cd738a
CRs-Fixed: 2881383
Currently the preferred channel list is not updated to have indoor only
channels removed. Add functionality to remove the indoor channels from
the PCL.
Change-Id: I31df737a3688f6c64c2eb5fa5ab0cea1d36869e5
CRs-fixed: 2874092
Move the beacon interval validation logic from the CSR module to the
interface manager module.
Add a path to send events to the SAP event handler from the MLME
module.
Change-Id: Ia86f219b3f209b53e7818a80f95b2c0555550736
CRs-fixed: 2796676
SAP stops working when it comes first and then sta connection
happens in non dbs HW mode
Allow SAP on non dbs HW even if the channel is safe or
lte-coex enabled.
Change-Id: I3e80b423ccb30fdb5e53a6d2aff961162b316e1c
CRs-Fixed: 2873957
This reverts change:I9408713fcf828d24688ecc45290d8c90a8d54c22
as it's not needed anymore as the actual issue(commands waiting
in active queue for response when the vdev is deleted) is fixed
with change:Ie31936132a389685ff4ff55b43ccbb4102e65830.
This wait-for-response causes a delay of around 200ms in
vdev_create as it's a blocking call.
As vdev_create happens after finding the peer device in case of
p2p, overall connection is delayed and connection time has
increased from 350ms to 600ms. This effects the
uses cases like WFD where applications have strict timing
constraints after finding the device.
Change-Id: I45c223a8d157892d8ec64b04f68cfbf39d732833
CRs-Fixed: 2870774
According to new requirement, when SAP manadatory channel list
enabled (gWlanMccToSccSwitchMode = 4,
gEnableSAPManadatoryChanList=1), the SAP will only be started on
PSC and VLP channels on 6Ghz band. Add all 6GHz PSC & VLP channels
to SAP mandatory list.
Change-Id: I00514c0af9c1cc07460120c928ced652aa2e8d4e
CRs-Fixed: 2870590
When SAP operated in channel 36 with 160Mhz, the primary channel
36 is non-dfs and existing checking dfs will drop the radar event
if the radar detected on channel 52. Change policy mgr API to
check the dfs flags instead of primary channel state.
Change-Id: Ie2f242182b8df30e5d1875e278c5ebffa2e7cafd
CRs-Fixed: 2865173
Use wlan_reg_get_channel_state_for_freq to get channel state
instead of wlan_reg_get_channel_state.
Change-Id: I0ab0465458801747cc97bf03b3aee4ec255beb57
CRs-Fixed: 2859852
Currently, host driver rejects any concurrent session with other
security modes(e.g. NAN) when WAPI is present. This is due to a
limitation on older platforms. But newer platforms(e.g. Lithium
architecture) support WAPI+other security modes concurrently.
Firmware advertises service capability WAPI_CONCURRENCY_SUPPORTED if it
supports other security modes when WAPI is active. Get the capability
and accept/reject concurrent sessions.
Change-Id: I0e004e1220afd9c42869589364606c9f729798f7
CRs-Fixed: 2844799
cm id is not passed to policy manager in case of DBS donwgrade
when NSS is modified, pass the cm id to fix it.
Change-Id: Ie038b30929c2fcddb6828f1f89765d3004ff3285
CRs-Fixed: 2860061
When a new connection is about to come up, host checks if current
concurrency combination including the new connection is allowed or
not based on the HW capability.
Firmware manages NAN + NDI by dividing up slots. Connection on NDI
is re-negotiable and therefore a 3rd connection with the same MAC
is possible.
Change-Id: I63e39c5cd4945cd308e475c1e03f676336c4e7c1
CRs-Fixed: 2841457
Currently host checks mac number to indicate
MCC or DBS which may not be correct. Host
may print DBS in case of MCC.
Check DBS support and print concurrency
based on hw mode if hw mode is dbs capable
then print DBS else MCC.
Change-Id: I1578e6a7a6b73b5b6c409653b4dc276954f51c3d
CRs-Fixed: 2845634
Acquire connection list lock in policy mgr before update the
entry. The "conn_index" maybe changed for a connection entry
if other connection is up or down.
Fix by acquire connection to protect the whole "update" operation.
Change-Id: I91e82e74884ef32e83e0c4105e88bafe8d99db3d
CRs-Fixed: 2848209
In the customer platform, the chain0 for 2.4G is disabled,
it just only support 1x1 2.4G + 2x2 5G for hasting. With
such kind of configuration, 2.4G SAP start failure due to
policy_mgr_is_hw_dbs_required_for_band return false with
following config, which block switching hw mode from single
mac(single mac just only support 5G) to dual mac and then
make start 2.4G SAP failure on single mac configuration
[0]-MAC0: tx_ss:2 rx_ss:2 bw_idx:5 band_cap:2
[0]-MAC1: tx_ss:0 rx_ss:0 bw_idx:0
[0] DBS:0 SBS:0 hw_mode_id:0
[1]-MAC0: tx_ss:2 rx_ss:2 bw_idx:5 band_cap:2
[1]-MAC1: tx_ss:1 rx_ss:1 bw_idx:4
[1] DBS:1 SBS:0 hw_mode_id:1
Change-Id: If9e76fb47743c32c313eacf150146ba8fa60eb2d
CRs-Fixed: 2833620
Currently, STA reconnect (e.g. reconnect to same BSSID) is handled
as STA+STA as part of NAN concurrency checks. This results in NAN
disable when reconnect is issued.
Check if the current incoming connection is on same vdev as
previous sta connection instance and disable NAN only if it's
different.
Handle NAN+SAP reenable in similar way.
Also, remove the redundant usage of NDI cleanup API
ucfg_nan_check_and_disable_unsupported_ndi in
if_mgr_connect_start.
Change-Id: Ia063a69bb2efdf1d51c6988b8905ceac0f454dab
CRs-Fixed: 2821352
Previously, if force SCC is enabled and Standalone SAP starts
on non-DFS channel, it starts with master mode Disable. If it
is switched to DFS channel it will switch without CAC.
As a fix, if SAP is started on non-DFS channel with force SCC,
don't allow it to switch to DFS channel if master mode is disabled.
Change-Id: I1822f67a5480d6c16fa980c9c6b262341af7c2de
CRs-Fixed: 2827237
At present when user trigger SAP move to unsafe channel,
driver doesn't reject the request since "strict = false"
and unsafe checking is skipped.
Fix by check SAP channel switch target channel safe or
unsafe with API policy_mgr_is_sap_freq_allowed before
perform channel switch.
Change-Id: I2950fb31346df8705c8fc608fd79e1a44f4d4947
CRs-Fixed: 2826619
Stop/Reject SAP connection if STA is/comes up
on a 6ghz freq and SAP is not capable of 6ghz
freq to avoid MCC situation in a non-DBS capable
HW.
Fix is to stop/reject the SAP startup in above
mentioned case.
Change-Id: I451c95929f378cd0790bd5fc647235fc2dd0071a
CRs-Fixed: 2818030
Currently the driver uses the API
policy_mgr_is_dbs_enable to check
whether the DBS is enable or not which
does not check the service capability of
DBS, and thus would return true if ini
and FW HW modes contain DBS. In this case
if STA is on 5ghz and SAP comes on 2.4ghz
then force SCC would not happen as the
driver would consider the HW to be DBS
capable which actually is not, and thus
the overall concurrency would be MCC which
is not favourable.
Fix is to use policy_mgr_is_hw_dbs_capable
API instead of DBS enable API which checks
for the service bit also, so that the driver
forces SAP to STA's channel.
Change-Id: I9319293ecfb54fe3e1ad0eaff15542c671514bf4
CRs-Fixed: 2820377
Currently the driver checks whether hw is
already in DBS in the function
policy_mgr_check_and_set_hw_mode_for_channel_switch
and it does not set hw mode if it is already
in DBS mode. It can happen that SMM is already
requested and is present in serialization and it
would change the HW mode from DBS->SMM and if
driver starts any vdev on 2.4ghz in HST/HSP
which requires the DBS mode for 2.4ghz , the FW
would send a vdev start failure.
Fix is to remove the check of current hw mode and
let DBS be posted to serialization. If hw mode is
already in DBS it would return from serialization
with E_ALREADY but would ensure that HW mode is
always in DBS for a 2.4ghz connection.
Change-Id: Ica660058175cb1edc2931dd2d28ee6cdd9bab2f4
CRs-Fixed: 2823238
Add a check for passive channels when checking the restricted
bands on SAP. This change blocks SAP from restarting on a passive
channel.
Implement the function to filter out passive channels from the PCL.
Change-Id: I80a4b78c1af77f5bfa68be3163f9e9a78cc6425a
CRs-fixed: 2817589
Modify connect start code in interface manager by
moving disable roam and tdls link teardown notify
APIs from HDD to if mgr. Alongside, move tdls link
teardown notify API from HDD to if mgr in start bss API.
Also, move the tdls link teardown API to TDLS module from
HDD module as TDLS should manage the wait logic.
Change-Id: I09fa31878563a3daaa7c5fde46327475829317b3
CRs-Fixed: 2811807
Add new ini "monitor_mode_concurrency" to support this feature
and introduce policy manager api's for concurrency checks.
Change-Id: I35ee1fece0a6f9ae8fe340b0598c4a3e20b17e82
CRs-Fixed: 2814523
Check the factors as below to decide whether the channel is
allowed or not:
* If the channel is in LTE coex channel avoidance list;
* If it's STA+SAP SCC;
* If STA+SAP SCC on LTE coex channel is allowed.
Replace policy_mgr_is_safe_channel() with this new function
for sap channel selection and acs channel filtering, to allow
unsafe channels when it's STA+SAP SCC and STA+SAP SCC on LTE
coex channel is allowed.
CRs-Fixed: 2743042
Change-Id: Ic5a84b2628200fe9decf6972f00706f190f04722
Add check in function 'policy_mgr_get_sbs_channels' to restrict the
array index out of bounds.
Change-Id: I387b666095107faf284e35f073dfe856d38323d3
CRs-Fixed: 2776966
Previously, if STA is connected to DFS channel and SAP starts on
Non-DBS HW, then it is forced to start on DFS channel with BW 160 Mhz
irrespective of BW on which STA is connected without CAC.
Even after STA disconnects, SAP remains on DFS channel with BW 160Mhz.
So, scan will be disabled and STA cannot be connected on any channel
other than DFS channel.
If STA is connected on non-DFS channel on 5 GHz and SAP starts, it
will start on non-DFS channel as primary channel with BW 160 Mhz
without CAC. Also, scanning was also allowed when SAP is started with
BW 160 Mhz. This might violate regulatory in case radar comes up while
scanning.
Standalone SAP on DFS channel was not allowed.
To fix this, Force set SCC for non-dbs HW, this way standalone SAP
can come on DFS channel but scan will be disabled in such case and
STA cannot be connected other than DFS channel.
In case STA gets connected to dfs channel in non-dbs HW, then sap
starts only on STA channel with force SCC with BW
MIN(sta_chan_width, CH_WIDTH_80MHZ).
Afterwards, if STA disconnects, restart the AP with BW CH_WIDTH_80MHZ
on safe channel. Scan will be allowed as the DFS master capability is
offloaded to AP with which STA is connected on DFS channel.
Also, if standalone sap starts, then STA connects to DFS channel then
SAP will restart with STA channel frequency and Channel width
MIN(sta_chan_width, 80MHZ).
If standalone SAP starts and then STA connects to non-dfs AP or SAP
starts when STA is already connected to non-DFS AP, then ch_width is
MAX(sta_chan_width, 80MHZ) (5 Ghz) or 20 Mhz (2.4 Ghz).
If STA disconnects during SAP+STA on non-DFS, SAP won't restart unless
the STA was connected on BW 160 Mhz.
Change-Id: I1cebfc79f170c1e4e2710ed747ec804df3d8b441
CRs-Fixed: 2809255
In DBS mode, gDualMacFeatureDisable can be 0, also can be
6: enable DBS for connection but disable simultaneous scan.
Change-Id: Ia3d46dbd2e67644e84436b90f40c203bc939eda7
CRs-Fixed: 2807010
In Interface manager, legacy roaming api's were used as roaming testing
was ongoing.Now testing is done so use converged roaming api's.
This will also resolve the KW warnings.
Change-Id: I9ef101e6ec02bb18c6f2f9a9fbdaa81dbe81f9a0
CRs-Fixed: 2798601
Currently, If hadware is not dbs capable opportunistic timer
can not be started. In function if_mgr_connect_complete
policy_mgr_check_n_start_opportunistic_timer fails to start
opportunistic timer in case of non-dbs hw and sap restart
doesn't happen.
Fix is not to validate status returned by
policy_mgr_check_n_start_opportunistic_timer to restart sap
in case of non-dbs hardware.
Change-Id: I3308a5c10341950d51419907cc767c09f967b7b1
CRs-Fixed: 2792764
Steps to reproduce:
1. AP_AP mode setup, AP1 occupy channel 1, AP2 occupy channel 44.
2. Set channel1~channel11 as unsafe channel, which cause AP1 try to
switch to 5G band.
Observed Results:
AP1 select channel 36, and channel switch fail.
Expected Results:
AP1 select channel 44 same as AP2, and channel switch pass.
Root cause: in Dual AP concurrency case, when get PCL for one AP, need
find the AP from connection list by vdev id and remove it temporarily,
can't just remove 1st vdev from connection list.
Change-Id: I763bbc89bacdad4389084588ee68c3a1e2f17b7b
CRs-Fixed: 2774570
At present, WAPI security mode STA is not allowed to run in
concurerncy with any other vdev.
So, whenever a new vdev is created, policy_mgr_check_privacy_for_new_conn
is called to check the security concurrency of new connection by checking
security of exisitng vdevs and if a STA vdev with WAPI security exists
then the concurrency is not allowed and the api will return false.
In case, while performing this check, the adaptor associated with
the existing vdev is destroyed, there might be a crash as
hdd_wapi_security_sta_exist is still trying to access the security
of that vdev.
To solve this, use wlan_objmgr_pdev_iterate_obj_list with crypto info
to iterate across all the existing vdev and check the security. If
Wapi security STA exists, it will return an argument with value as true
which will be used in policy_mgr_check_privacy_for_new_conn and it will
return false as concurrency is not allowed
Change-Id: Iff811d2406f1c74cec26d457a2a682dd992710b8
CRs-Fixed: 2784406
qdf_mem_malloc() function already takes care of logging the
caller function name and line number in case of any allocation error.
Hence there is no need to add the error log again.
Getting rid of these unnecessary logs reduces driver memory footprint.
Change-Id: If0b9425f82f9ed793c7639c0ed09eb1f868b6d5c
CRs-Fixed: 2781932
The peer objmgr pointer in the if_mgr_roam module may be NULL if
there is no peer connected. Add check to see if pointer is NULL
before dereferencing it. Also modify logic to only check if the
vdev is in STA or P2P_CLI mode.
Change-Id: I7370ca5b9c74bd81f6e958cf740b6ee426f4faad
CRs-fixed: 2779831
When band mask for connected STA is 7(connected in 6GHz), the weight
of 2.4Ghz channels is sent as 1(weight of non-pcl channels). This
allows firmware to roam to 2.4Ghz AP with dual sta roaming enabled.
For 6Ghz connection, set 2.4Ghz channels weight to 0 to disallow fw
roaming.
Change-Id: I9581c51a827e6fa6ac186b531639ce4835ba0faa
CRs-Fixed: 2775276
- Use sme roaming api's instead of converged
roaming api's.
- Add debug logs in if mgr api's.
- Fix typo in Kbuild file.
- Fix compilation errors.
- Fix comments for readability.
- Update disconnect functions so parameter type matches.
Change-Id: Ia0adf6f79036e9348bf4ebb6237a5e25ef813a21
CRs-Fixed: 2774509
Add the API to validate the BSS before roaming to it. This API will check
if other vdevs are already connected to the BSS, if concurrency is allowed,
and if channel is allowed for the current HW mode.
Keep the new changes under the interface_mgr feature flag.
Change-Id: I280e95b0a30c08fe4037295330628b79d22acf5f
CRs-fixed: 2774543
Currently, the APIs related to setting the preferred channel list is
in the SME module. Move these APIs to the policy manager so they can
be accessed from non-legacy modules.
Change-Id: Icc487dd2a0014e59db9c2df729b875f58e3e975e
CRs-fixed: 2766863
Add disconnect start and disconnect complete event handlers to
the interface manager.
Add disable roaming, enable roaming on connnected STA, and
enable roaming after P2P disconnect APIs.
This change is part of the connection manager effort.
Change-Id: Ib68b9ef9ff5b6541d7393bfbe6332a68b17bd587
CRs-fixed: 2760090
If STA is on 5G channel, starting P2P GO on a different 5G DFS channel
should be rejected, but it's not, due to it didn't check the P2P GO
specific configurations, but only check the one for SAP.
To fix it, use P2P GO specific API to check the force scc status
for P2P GO mode.
CRs-Fixed: 2769182
Change-Id: Ibb3bb5e6e7f8a64e4483bdef863ce1f4294da9eb
The logging macros implicitly takes care of embedding function name
in the log, hence there is no need to include __func__ again.
Getting rid of redundant __func__ reduces driver memory footprint.
Change-Id: Idf4685539991f65205f19b27551cef699230c82e
CRs-Fixed: 2768575
Currently the driver goes for SCC when STA is
present on 2.4Ghz and the GO comes up.
In case the user wants throughput then
GO should go for VHT80 in 5ghz even in
case of STA present on 2.4ghz so that
it leads to better throughput.
Change-Id: I211858b42d3de407f6047609f966f95720644109
CRs-Fixed: 2763812
Currently the driver enables the SRD channels
support for both P2P_GO and SAP if the SRD master
mode is enabled.
Have individual ini values to enable/disable
the SRD channel for each op-mode as required.
Change-Id: If6e66996ed19dacbde7f71a6702f378a7e9a273c
CRs-Fixed: 2748446
