For 6GHz support and to remove channel number ambiguity use policy
manager APIs updated for frequency in other modules. This change
covers following APIs:
policy_mgr_is_chnl_in_diff_band
policy_mgr_check_for_session_conc
policy_mgr_handle_conc_multiport
policy_mgr_change_sap_channel_with_csa
policy_mgr_get_channel
policy_mgr_get_nondfs_preferred_channel
Change-Id: I4a6673db3a02b6e8d7fa94ae452338db618e3883
CRs-fixed: 2545099
Update policy manager to use regulatory module API to get valid
channel list instead of MLME config item.
Change-Id: I2fa24c73892746de68ece00e50fd55d6135b7753
CRs-fixed: 2545120
Update policy manager data structures and APIs to use frequency
instead of channels. This is done to address channel number
ambiguity with introduction of 6GHZ band. Fix all references of
channel and add temporary internal functions for frequency
usage as replacement for public APIs using channels. Also modify
the channel list handling to frequency list in associated modules.
Change-Id: I11dff14a5fbe6d49cf411f8fce6863994ffccd75
CRs-fixed: 2540000
Currently the value of force 1x1 exception is 2
which can lead to STA connection to a OUI AP in 1x1.
In a DBS configuration when AS is disabled, STA came
up in Single Mac mode in 2x2, and when a SAP came up
in DBS, then it sent out a SMPS to AP which lead to AP
crash. But very few APs have this behaviour, so it is
better to have a higher throughput than limit the
connection to 1x1.
Change-Id: I0ebd1ed2b764c3280151ca55117545349e474cbb
CRs-Fixed: 2538438
Currently if there are 3 connections in MCC on same
MAC, FW asserts.
If there are several bssid for same ssid and channel id from wpa
supplicant is 0, driver will sort candidate AP and try one by
one, vdev start channel isn't decided until candidate is
selected, need do concurrency allow check at that time, or lead
to 3 connections on the same MAC.
STA+STA MCC on same MAC has no benefit, total throughput is even
lower than single STA for channel switch frequently on same MAC.
so add check to disallow STA+STA MCC.
Change-Id: Id286096ea156915432807e42983c68cc83a8b42e
CRs-Fixed: 2545411
Update SAP data structures to use channel frequency values instead
of using the channel id values to support 6GHz channels in SAP.
Change-Id: I9ef5857e8dcf3f7d879495d3f3c3ead083fe0bf0
CRs-Fixed: 2513083
If radar event is indicated in station vdev, it may be dropped by
station vdev since station does not support DFS master.
Select first sap vdev started in dfs channel to handle radar event.
Change-Id: I74229eb02c6ae6d81042df6b736d231db26253b5
CRs-Fixed: 2512836
In function csr_check_concurrent_channel_overlap, local
variable intf_ch is defined as uint16_t, but its pointer
is casted to uint32_t * before invoking
policy_mgr_get_sap_mandatory_channel, which will do
32-bit memory write and causes a stack memory over-
writing.
Call Trace:
dump_stack+0x46/0x59
print_address_description+0x66/0x22b
kasan_report+0x21f/0x245
policy_mgr_get_sap_mandatory_channel+0x1fd/0x258 [wlan]
csr_check_concurrent_channel_overlap+0xf84/0x10d2 [wlan]
sme_check_concurrent_channel_overlap+0xaa/0xf0 [wlan]
wlansap_check_cc_intf+0x102/0x124 [wlan]
wlan_hdd_get_channel_for_sap_restart+0x506/0x8f8 [wlan]
policy_mgr_check_sta_ap_concurrent_ch_intf+0x35e/0x425[wlan]
process_one_work+0x2cc/0x53b
worker_thread+0x357/0x490
Change the type of the 2nd parameter to uint16_t within
function policy_mgr_get_sap_mandatory_channel, so only
16-bit memory writing will take place.
Change-Id: If514a394e65d005a1fe025c0e753bf7440dd5dde
CRs-Fixed: 2508798
1. Add g_enable_go_force_scc INI configuration
to enable force SCC on P2P GO interface.
This option only takes effect when
gWlanMccToSccSwitchMode INI enabled.
2. Add API policy_mgr_is_go_allow_force_scc to get
the above configuration value for GO.
Driver will apply "MCC to SCC" logic to P2P GO
interface based on STA active status and the configurated
INI values.
Change-Id: I1d16368b5f2d88984b91ef0a3e882148c20dcd23
CRs-Fixed: 2509555
In AP+STA case, if g_sta_sap_scc_on_lte_coex_chan != 0,
SAP is allowed SCC with STA on unsafe channel. And
if g_sta_sap_scc_on_dfs_chan != 0, SAP is allowed
SCC with STA on DFS channel.
But when the STA disconnected, standalone SAP is not allowed
on unsafe channel or DFS channel. We need to move
the SAP to safe channel or non DFS channel.
The original API -
policy_mgr_is_sap_restart_required_after_sta_disconnect
only handle AP+STA case. Change it to cover 3VIF
concurrency case - AP+AP+STA.
Change-Id: Iec4e750d8b3fda0cc52ac698ecaa9a274f935706
CRs-Fixed: 2509545
SAP1 chan6, SAP2 chan6, LTE channel avoidance event marks
chan6 unsafe, driver will do channel switch for SAP1 and SAP2 to
safe chan 1.
In the middle of channel switch of SAP1, policy_mgr_allow_concurrency
disallows the channel switch request because new SAP1 channel 1
will cause MCC with existing SAP2 (channel 6) and firmware
doesn't support MCC for dual-beacon entities on same band.
This change removes all the SAP entry on the old channel
before do concurrency check for SAP channel change request.
Change-Id: Ic2c828a3fec4cbe2f11d4bedf471211bee442e9e
CRs-Fixed: 2491265
Currently the driver checks whether the device
supports antenna sharing, and if the AP is added
in the OUI framework, then the driver modifies the
nss value to 1 to avoid sending SMPS to the peer AP.
Now suppose the device does not support Antenna sharing,
but supports DBS and is helium HW, then going to DBS HW
mode would result in peer sending a SMPS frame to the peer
as the helium HW only has two antennas, and one is needed
by each MAC now.
Fix is to add a third param in force 1x1 ini which would
decide the driver should consider the antenna sharing as
mandatory or not.
Change-Id: I3ae00fcbd642c7780952d66ccbf1208335fcb077
CRs-Fixed: 2496831
Enable following special 4 ports concurrency for HST:
(SAP+STA) (2.4G MAC SCC)+(SAP+STA) (5G MAC SCC).
1. Update pcl table for fourth connection
2. Increase max connection number to 4
3. Add concurrency allow check for 4 ports
Change-Id: Ib87bcfd845208f0ed8821c7e18b2f30833db22b7
CRs-Fixed: 2457713
On single MAC devices, when a SAP or P2P-GO is already operating
on a DFS channel, MCC mode is not allowed. It is currently
possible, even with a SAP on DFS channel, to connect to a 2.4G
AP using the command: iw interface connect SSID [AP freq]
Add additional checks in policy manager to prevent this
MCC situation.
Change-Id: I9adf063fbc1cb4c2d3f22f6b4d1bb00beb079007
CRs-Fixed: 2485436
Currently, there is no logging for channel switch reason.
Add csa_reason to know the reason for the channel switch.
Change-Id: Iec02d7fa2b1ec51acb97005da220db7de705d7e0
CRs-Fixed: 2483206
The SAP channel change can be called in scheduler thread and thus
waiting for hw mode change in scheduler thread will always lead to
timeout and thus channel switch failure.
Fix is to avoid wait and continue channel switch after hw mode
change is completed.
Change-Id: I951fab6c95ff2a84d6a619859295b830685fac4e
CRs-Fixed: 2484147
Add new g_sta_sap_scc_on_dfs_chan value 2 with below
enhancement:
a. Allow single SAP (GO) start on DFS channel.
b. Allow CAC process on DFS channel in single SAP (GO) mode
c. Allow DFS radar event process in single SAP (GO) mode
d. Disallow CAC and radar event process in SAP (GO) + STA mode.
Change-Id: I47fdccda3314681806fa999cb01ee62052434e50
CRs-Fixed: 2465644
The old change I7e5a21601642e0d6afef73beeecf80a3e0475909
is missing when new scan mgr introduced, re-design the
change.
If DFS AP present, station scan 5g chanlist should be
avoided if target doesn't support Agile DFS Scan in Single
MAC mode. And also if current hw mode is DBS, the 5g chan
scan is not allowed as well.
1) if agile & DFS scans are supported
2) if hardware is DBS capable
3) if current hw mode is non-dbs
If all above 3 conditions are true then don't skip any
channel from scan list.
Change-Id: I3773c1c63ea3f33db6f6ee2c31cb5d09d3c2ae71
CRs-Fixed: 2471542
Currently the driver checks that DBS for connection
is allowed or not, and on that basis rejects the scan,
but it may happen that FW supports DBS, and DBS for
scan is enabled in the ini, but the DBS for connection
is disabled.
In that case the diver opts for non-dbs scan.
Fix is to allow DBS scan in case of DBS scan enabled in ini.
Change-Id: I9feccdb434787f9ae1b87397b9c7a25cb2e40705
CRs-Fixed: 2473835
Update 2x2 dbs PCL table and DBS action tables
to support P2P GO + P2P GO + STA concurrency cases.
Change-Id: I87b77c64083f7e398fcec9f4efc60a887e18e7ef
CRs-Fixed: 2464109
If FW does not support WMI_SERVICE_DUAL_BEACON_ON_SINGLE_MAC_MCC_SUPPORT,
in AP+AP case start the second SAP on same band and
different channel will be failed.
For force mcc to scc switch enabled case, override the second AP's
chan to same chan of first AP instead of return failed in start AP.
Change-Id: I83ad3db3160cfc2dd66163bb1e1b2e19ae7c5fa3
CRs-Fixed: 2439440
Scenario of the issue is :-
1. Keep sta+sap_scc_dfs_ch as 0 to disable the dfs concurrency
2. Start a SAP on any 5ghz channel(NON-DFS).
3. Start a STA on a DFS channel.
Expectation: The SAP should not do MCC, SCC as the above
mentioned ini is 0, also MCC is not prefereed in a HW
solution where DFS is preferred, hence the SAP should go
to 2.4ghz and DBS should be the expectation.
Observation: The SAP does not do a DBS operation, and falls to
MCC here.
Reason: When the SAP gets a PCL in the path of SAP restart,
the PCL feels that a new SAP is going to come up, and hence
gives the best channel (first element of PCL ) as its own,
which leads to restart being rejected, as the SAP cannot start
on a channel which is the same as existing.
The final channel then selected is the STA channel, leading to
DFS SCC which is also not allowed. Hence the SAP is now stuck
in MCC(STA+SAP , one on DFS, and the other on NON-DFS channel).
Fix: The fix is to get an alternate channel for SAP restart, other
than the channel on which the SAP is already up, to lead to DBS,
if the STA channel is not suitable for SCC operaion.
Change-Id: Iab3ad22b2f970ca26ce3e6bc7a9b5ee34bc7e7ba
CRs-Fixed: 2443718
When SAP works in ACS mode, it needs to restart with a safe channel
if current channel is unsafe. Sometimes no channel is selected from
pcl channels. SAP can't just pick up one safe channel because the
channel may be DFS channel while SAP may disable DFS master capability.
SAP should select one valid channel for LTE COEX.
Change-Id: I303165f82b5c2a8d06447df4ba23fdcba5b1083c
CRs-Fixed: 2415007
Add policy manager support to avoid simultaneous connections on
STA plus STA concurrent interfaces when
WMI_SERVICE_STA_PLUS_STA_SUPPORT is not set.
Change-Id: I73e65c56a98908128d56af2f4fba8ced5210fff1
CRs-Fixed: 2427828
Add policy manager changes for NAN discovery interface and SAP
mode concurrency setup related constraints. This handles NAN enable,
disable, SAP bringup and PCL related configuration for NAN+SAP
concurrency.
Change-Id: I04564e80e62189e2e6c0f810856b961b61ef70b4
CRs-fixed: 2431539
In case of STA+SAP, if STA connect to new channel, driver check
if SAP channel switch is required. Before this it wait if channel
switch is already in progress, if not it continue and check if
channel change is required. While waiting in case where event was
set and channel switch was not in progress, the even gets reset
after waiting.
So if event is not set again, i.e in case SAP channel change is not
required. Any subsequent wait on the event will result in timeout.
Also while changing channel this event is reset and then the
concurrency checks are made and if checks fails the channel change
may not happen leaving event in reset state.
So wait for event only if channel switch is already in progress.
Also reset the event once all concurrency checks have passed and
channel change is started.
Change-Id: Iffcd8b2bf9dc7cbbd7d939983601cc395ef4c515
CRs-Fixed: 2425145
During LFR2 roaming, after the preauth with new AP
and disassociation with current AP are successful,
proper HW mode should be set based on the
existing concurrency scenario.
Change-Id: I312ed10bc844712b3dba36680457198a19f1e85c
CRs-Fixed: 2367224
If DBS 2x2 mode is supported, to operate in 2.4Ghz the driver needs to
be in DBS mode before vdev start/restart is sent on 2.4Ghz channel.
If STA is connected to a 5Ghz channel and the PEER AP switch from 5Ghz
to 2.4Ghz channel, it sends vdev restart without sending the HW mode
change to firmware.
Fix is to set HW mode before the initiating vdev restart if new channel
is 2.4Ghz and 2x2 DBS is supported and current HW mode is not DBS
Change-Id: I6dc57f37e155f0e29b17840e4e246de773f42b3e
CRs-Fixed: 2419642
Current ACS logic sometimes selects MCC channel based on its
algo for SAP / GO which results in SAP / GO bring-up failures.
This issue is seen in below concurrency combinations:
1. SAP + SAP
2. SAP + P2P-GO
3. SAP + SAP + SAP
4. SAP + SAP + P2P-GO
So with this change driver restricts ACS scan to intersection of
PCL and ACS channel list.
This implementation will take care of existing STA + SAP case as well,
as PCL will have channels according to 1st connection being STA.
Change-Id: Ic715fb29533c20b63cffda8a82b7317904f0d291
CRs-Fixed: 2407289
Policy manager is not aware of NAN Datapath Interface(NDI)
which is used to establish datapath with NAN peers. Define
and enumerate policy manager definitions and tables to
support NDI alongside NAN Discovery and Station interfaces.
Important thing to note is that NDI cannot be active without
presence of a NAN Discovery interface.
Define NAN Datapath related definitions in Policy Manager.
Change-Id: I6ecdf5a89a8161d9c5d671e4e718dd615f46019e
CRs-Fixed: 2407225
If DBS 2x2 mode is supported, to operate in 2.4Ghz the driver needs to
be in DBS mode before vdev start/restart is sent on 2.4Ghz channel.
In scenareo with gWlanMccToSccSwitchMode 4, when AP is in 5Ghz and
STA connect to any other channel in 5ghz, it force AP to switch to 2.4 Ghz
channel. Thus AP sends vdev restart without sending the HW mode change
to firmware.
Fix is to set HW mode before the AP start channel switch.
Change-Id: I2a1c176d5f3ed8cc2f62dc24c72959db1afbaae3
CRs-Fixed: 2414034
Add NAN Discovery specific modes, modules that manage NAN
Discovery interface. Add cases and exceptions that manage
concurrent operations alongside NAN Discovery.
Add policy manager changes to manage NAN Discovery.
Change-Id: Ib9a10be265c14adf8d1d5f2f2e2b65aa399d6636
CRs-Fixed: 2358183
If DBS is disabled from INI then driver just bails out
in wlan_hdd_update_dbs_scan_and_fw_mode_config() API and never report
it to FW. This creates a confusion when DBS is disable INI but our HW
is capable of doing DBS, i.e. driver thinks that DBS disabled
but FW thinks that DBS is enabled.
Provide a fix that driver should report exact INI setting to FW.
This issue got introduced as part of regression caused by:
Iec2ef7e77e91f332028904c319d24e1ed134306d
ROME platform doesn't support any DBS related commands in FW,
so if driver sends wmi command with dual_mac_config with all params
set to 0 then FW wouldn't respond back and driver would timeout on
waiting for response. This was the original issue for which
Iec2ef7e77e91f332028904c319d24e1ed134306d was added.
Make sure current solution doesn't break backward compatibility.
Add a check to make sure FW supports DBS to eliminate
ROME vs NON-ROME platform.
CRs-Fixed: 2361628
Change-Id: I8a3b795b20e82391ae5d5c86d1e7d814d103ce64
