Currently, all roam params are updated to firmware whenever
a new param(e.g. preferred channels) is configured by the
userspace. This may overwrite the firmware learned data with
fresh config which is not intended.
Isolate the configured param update to firmware to avoid
tampering other params.
As there are multiple roam params, isolate ROAM CHAN configuration
for now. Incremental changes can be added to make other params
adapt to this.
Change-Id: Ib8c01e42263a0d77b5747f71591ac282909ed7d3
CRs-Fixed: 3856863
Host updates the configured RSSI threshold from INI
"gNeighborLookupThreshold RoamRSSI_Trigger" over the
GETROAMTRIGGER command. But this RSSI threshold is reduced
by firmware in steps for reasons like candidate not found
during roam scan. So, the expectation is to print the next
RSSI threshold at which the roam scan will be triggered.
This value is received from firmware via the
WMI_ROAM_SCAN_STATS_EVENTID.
Fix is to store “next RSSI threshold” value in vdev mlme
and update same when GETROAMTRIGGER is queried.
Change-Id: I9b5dc80724d13f7cfe082f1214197d1c016e1a94
CRs-Fixed: 3827747
Sending deauth on one of the links in MLO connection will result
in removing anchor link in FW and driver shall silently remove the
next link without initiating another deauth. For this reason the
status of MLO peer is set to DISCONN_INITIATED on sending first
deauth frame so that subsequent links do not send again.
The MLO peer context holds the list of all object manager peers for
that MLD connection and failure to add to the context shall result
in termination of connection. Currently the failures are not handled
and the object manager peer is not having any MLO peer context and
this results in sending deauth frame on both the links.
Handle the error of peer create and MLO peer attach on roaming
to abort the roam sync.
Change-Id: I4d5a766b673b36edb44d19065237aa35ff7d5f1d
CRs-Fixed: 3837890
When roam happened in F/W and send roam stats to host driver,
host driver send these roam stats info to user space by event
without cache them.
Change-Id: I772c0a5035896715204f6eee277090ed1f33e97c
CRs-Fixed: 3790270
Currently if Host receives ROAM SYNC event in
RSO STOPPED state, Host drops ROAM_SYNC event and
fails to send ROAM COMPLETE response to FW. This
results assert in fw with reason ROAM COMPLETE
response timeout.
If ROAM SYNC come to host in below scenario:
1. HOST sends RSO stop command with scan mode 4,
in order to process supplicant disabled roaming
request
2. FW already queued the roam sync event before
RSO STOP command receive from host
In this case host should send RSO STOP with
scan mode = 0 to FW. So that FW can stop roam sync
timer and change roam state to RSO STOP state
along with other internal cleanup in FW.
Change-Id: I8b25be98b30d7f8185d5f8dcd67a4b52f502fd37
CRs-Fixed: 3810436
Currently while processing roam synch legacy case
is not handled properly for self-roaming case and
host is sending roam as it finds peer is
already attached to a vdev.
To address this issue don't send roam stop if peer
is attached to same vdev.
Change-Id: I75bbeb23e2b94458e0709b8b27178549c7104ea1
CRs-Fixed: 3690348
Add chipset stats for deauth event when roam
is trgiggered due to deauth frame from AP
Change-Id: I21125d1fde5805a3893ff8d0f9ec2be49082f994
CRs-Fixed: 3804975
Below is the sequence of events causing RSO init command to
be sent to firmware while disconnect is happening:
1. Roam Start received from firmware in scheduler thread.
2. Connect request for reassoc received in supplicant thread.
3. This connect request triggers disconnect, but before RSO stop
& deinit is sent to firmware, roam synch event is received. This
roam synch is getting processed in the scheduler thread. But RSO
stop & deinit are sent in wpa_supplicant thread.
4. As part of roam synch host is posting RSO_ENABLE to RSO state
machine which triggers roam init to firmware.
5. Since disconnect sequence is already in progress, the RSO is
in init state before vdev stop. Disconnect sequence got executed
cleanly except for the RSO sequence.
This results in abnormal firmware behavior.
Check if the vdev is in connected state before sending roam init
to firmware.
CRs-Fixed: 3769766
Change-Id: I709c165bd9b11b323666e0e27cece76e6a4641dd
Currently, when Rx monitor mode interface is coming up, STA is
not disconnected causing RXDMA ring to be used as both error ring
and destination ring. This is causing backpressure in RXDMA ring.
To fix this, issue disconnect for STA when Rx monitor mode is
being added.
Change-Id: I95e73edd80472a8aae9092ebdbce5e514b1cd531
CRs-Fixed: 3799325
During roaming tests, if an AP gets kicked out due to move away,
the driver adds the BSSID to an avoid list.
However, this approach has a drawback. If the AP later moves nearby
again, it won’t be picked up because it’s still on the avoid list.
To address this, the driver checks the RSSI value before adding the
BSSID to the avoid list for kickout roam reasons.
If the RSSI value is above -70 dBm (from INI good_rssi_threshold)
and get kickout, which means AP may have functionality issue, then
the BSSID can be added to the avoid list. Otherwise, if the signal
strength is bad below -70 dBm, the BSSID should not be avoid list
because the AP may move away, let roam logic to pick up or not based
on score value of the BSS.
Change-Id: I4ace2733cfe270667d14095f1d4dc2c5abb9f0d5
CRs-Fixed: 3788290
If CSR roam synch callback fails then the status is not updated
with error status code and this causes the caller to consider
roam synch indication is successful and RSO stop is not sent
to firmware leading to roam synch completion timeout at firmware
Send correct status to the caller of the api:
cm_roam_sync_event_handler_cb() if CSR roam synch processing
fails
CRs-Fixed: 3800617
Change-Id: I29214c04976498fd81cb5266738e341928af3af7
When roaming happens with full SAE for FT-SAE AKMs host doesn't
update the PMK received from firmware into its global cache.
This causes stale PMK to be sent to firmware when full SAE
happens when roaming to below AKM's:
WLAN_CRYPTO_KEY_MGMT_FT_SAE
WLAN_CRYPTO_KEY_MGMT_FT_SAE_EXT_KEY
So update the PMK sent from firmware for above AKM's when
auth status is connected (full SAE happens at host).
CRs-Fixed: 3807689
Change-Id: I25d1a253de37481952c41f54697521285a0ccf92
If host founds below all conditions are true:
1. Connected AP sends CCX IE in beacon/probe response
2. single PMK feature enabled via ini
"sae_single_pmk_feature_enabled"
3. And current connection is SAE with AKM type
WLAN_CRYPTO_KEY_MGMT_SAE_EXT_KEY or
WLAN_CRYPTO_KEY_MGMT_SAE
Then host should mark connected AP supports
"single PMK feature" and update same to FW via RSO
command.
Change-Id: I831cfefb60271b03e5c5cbdfde0bd5277ee116e0
CRs-Fixed: 3795133
After roaming to 11BE 320 MHz EHT AP, the channel width is wrongly
updated as 40 MHz in newly created pe_session. This causes wrong
channel info to be sent to kernel in the get sta channel request
and could result in disconnection. In lim_fill_ft_session(),
the chan_width is updated from VHT OP or Vendor VHT OP IE only
currently. But in 6 GHz EHT 320 mode, the VHT OP IE will not be
present and default 40 MHz is assigned.
So extract the channel info from EHT OP IE and use that to fill
the ft pe session created after roaming
Change-Id: I81b52391e69dfe87b103ca1ee90dd9658f02273a
CRs-Fixed: 3746276
Currently, ROAM_SYNC is aborted on the corresponding vdev when
the vdev is not in CONNECTED state. This abort operation sends
an RSO_STOP to fw but the status is not notified to the caller.
This results in a race condition in the below scenario,
1. Firmware roamed to a 2-link ML AP and sent Roam sync ind
to host
2. Host posted ROAM_SYNC on vdev-0 in scheduler thread context
as the vdev-0 state is CONNECTED
3. Got a DISCONNECT request from userspace in user thread and
the states moved to DISCONNECTING.
4. Host tried to post ROAM_SYNC to vdev-1 but aborted as the
state is not CONNECTED and tries to send RSO_STOP to fw.
This RSO_STOP won’t be sent as it’s a link vdev and the
RSO_STOP should go from assoc vdev later.
But this status is not indicated to the caller which
proceeds with vdev-0 ROAM_SYNC.
5. As vdev-0 ROAM_SYNC doesn't check for the connection state
once processing is started, ROAM_SYNC would be completed
on vdev-0.
6. This causes out of sync and vdev-1 doesn't get cleaned-up.
7. As part of the disconnect, host tries to cleanup the old
peer on vdev-1. But firmware ignores this as that peer is
already cleaned up in fw.
This results in peer map-unmap issue later as the new Roamed
peer on vdev-1 will never get cleaned-up in host but the same
got cleaned up in fw. FW is free to use that peer_id to
another peer mac later and when it does, host DP complains.
So, indicate ROAM_SYNC abort status to the caller to abort
the complete Roaming.
Change-Id: Ic65149ddf28f01ca5d7a0f6d3137a38e64e6c6ae
CRs-Fixed: 3786671
Host driver doesn't disable RSO before restarting the vdev
for fw-initiated as well host-initiated CSA or BW change for
link vdev. Therefore, if the FW is in middle of roam(for host
initiated CSA) cases, this restart leads to race condition in FW.
Add a new reason code for VDEV restarts triggered due to CSA,
enable/disable the RSO SM based on this new reason code for
assoc as well as partner links.
Change-Id: I48925d76df62bb1c60f212048b95c434af18042f
CRs-Fixed: 3770973
Firmware timestamp values are not printed for BTM_QUERY &
BTM_REQ events and wrong value for BTM_RSP. This is because
the timestamp values is read from wrong structures.
Read the firmware timestamp values from correct wmi structure
to fill the connectivity diag event
Change-Id: I568e87ee3e4bb66d3f73d353df794ced92b418c1
CRs-Fixed: 3788350
In cm_is_peer_preset_on_other_sta, wma_context is
fetched from gp_cds_context and used without any
validation checks. This may lead in NULL pointer
dereference.
To address this issue add null check before
accessing.
Change-Id: I78656303855efb2369afcf47d1aabe3b916498c4
CRs-Fixed: 3712317
Currently, the driver doesn't consider the force 20 MHz in
2.4 GHz configuration while calculating the channel width
for the session during roam. Therefore, fw and host will be
out-of-sync wrt the channel width of the connection.
Consider the force override 20 MHz in 2.4 GHz config which is
based on the ht40 cap of connect request for the channel width
computation.
Change-Id: Id616dd1ceefd5b2c2130be1b88067a92121e0fa1
CRs-Fixed: 3768406
When roaming happens from 3 Link AP to Legacy or 1 link AP after
a link switch, and the assoc vdev when connected to 3 Link AP is
disconnected during roaming, it causes the DP default link mapping
not to be updated. This resutls in data stall and ultimately
NUD failure is triggered resulting in disconnection.
After roaming to Multilink AP, then update the DP with
the new deflink as the assoc vdev.
CRs-Fixed: 3681911
Change-Id: I114a9858c3cbe58ef59743ad251a2b3af2543d3d
Host has to issue RSO_STOP to firmware before performing any
vdev operations(start/stop/down/up,..). Otherwise firmware may
face memory corruptions if it tries to access the same
vdev while host is modifying it.
Currently, RSO_STOP is sent to firmware only if all vdevs are
UP. But in OWE/EAPOL offloaded roaming cases, assoc vdev
would be UP and partner vdev would be down till EAPOL is
done and keys are received from userspace. Connect is started
on partner vdev once the keys are received. Host driver is going
to do a vdev start as part of this connect. So, RSO_STOP is
supposed to be sent to firmware before performing any connect
operations on partner vdev.
So, send RSO_STOP to firmware right after sending
ROAM_SYNC_COMPLETE even if the link vdev is no UP.
Change-Id: Idaa15c7b0cedff5fd6f276626047f349c500a5b8
CRs-Fixed: 3769038
If the scan entries for a non-tx profile MBSSID partner links
are not present at the time of candidate selection, then
host driver generates the scan entry for the missing partner
link from the assoc response.
The assoc response from the AP has PMKID in the RSN(some APs
do not include RSN IE in assoc resp).In this case, the RSN
along with PMKID gets inherited into the scan cache of the
missing partner and this leads to mismatch between M3 and
scan entry RSN causing disconnection.
To fix this, mark all the MBSSID partners without scan entries
as invalid links at the time of candidate shortlisting. Score
and connect to only non-tx candidates with valid scan entries.
Remove the probe response generation from assoc response logic.
Change-Id: I3b90ca1f1d81f2de7cc629576714c72975b11ae9
CRs-Fixed: 3738606
Add new APIs to save number of links to which FW roamed
and add new API to retrieve this saved info.
Change-Id: Idfd8727855bd5da97a3808c78e89a505ef06c249
CRs-Fixed: 3755754
HW is non-DBS. SAP is UP in 6 GHz. Now, when a STA connection is
attempted, the pcl for the second connection would have SAP SCC
channel with highest priority, all the 5 GHz channels with 2nd
highest priority and the 6 GHz channels with least priority.
Therefore, even if there is a strong 6 GHz candidate for STA, the
5 GHz candidate would be chosen and the SAP moves to SCC in 5 GHz.
To fix this, ignore the pcl scoring for the non-DBS concurrency
cases as the SAP can move to the channel of the best STA interface.
If the SAP is in legacy band, and if still a 6 GHz STA is chosen,
then the legacy SAP would be torn down. So, give STA the best
possible in non-DBS case.
Change-Id: If268b61c61e77db96b499437cdbc95188240fba8
CRs-Fixed: 3749399
As per new requirement, If DUT associates with an AP does
not support BTM then when host receives BTM req frame
from FW. Instead of forwarding the BTM req frame to
supplicant, host should drop it.
Change-Id: Ie6b6c27c01b072fac19dc039327cb9a86370b535
CRs-Fixed: 3746758
User/wpa_supplicant disable roaming flag is only effective for current
connection, it will be cleared during new connection.
APP/wpa_supplicant can uses QCA_NL80211_VENDOR_SUBCMD_ROAMING to change
roaming behavior for current connection.
Change-Id: If9f439f51e25e3d67f5db5557c0d8f468b071596
CRs-Fixed: 3737996
On receiving QCA_WLAN_VENDOR_ATTR_CONFIG_BTM_SUPPORT vendor
command, do below action in host:
1. Disable btm_offload_config in FW via RSO command.
2. If btm_offload_config disabled in FW at step #1,
FW forwards BTM frame to Host, Host needs to drop frame.
3. Disable btm ext capability (p_ext_cap->bss_transition)
bit in assoc request and unicast probe request to AP.
4. On disconnection, restore BTM configuration.
Change-Id: I228bafe243c43bc055f19d472c2f2d986225f577
CRs-Fixed: 3742276
Add support to process newly added vendor command
QCA_WLAN_VENDOR_ATTR_CONFIG_BTM_SUPPORT.
User space use this vendor command to disable/enable
BTM roaming for STA interface.
If host receives this vendor command in connected
state, host should return failure to user space.
Change-Id: Iafadc2fab2ee30a0eb2e8e7ebb7178c1d36fe1c9
CRs-Fixed: 3715920
Add support to send roam cancel diag event in instances with
below reasons:
IDLE ROAM scan cancelled due to screen ON
scan cancelled due to other high priority roam scan
Add new diag structure & reason code enum for this diag
event
CRs-Fixed: 3708863
Change-Id: I1f7a819d766735f7d89eda3945e7ed92d22919ae
Some solutions may not have HS-2.0 certification and there is
no need to forward the BTM frame to wpa_supplicant in such
solutions. Let firmware handle the frame in such cases by
enabling btm_offload so that it doesn't wakeup the host.
Firmware may roam to another AP upon BTM reception.
To enable/disable BTM offload add hs20_btm_offload_disable INI.
If this INI is enable BTM offload will be disable and if INI
is disable BTM offload will be enabled.
Change-Id: Id6e18404cc3a12a23b213c0f858c943715285932
CRs-Fixed: 3718776
Currently, HS_20_AP param of cm_ext_obj->rso_config is set
to true when STA connects to a HS-2.0 AP. This is to disable
btm_offload as per HS-2.0 cert requirements.
But this flag is not cleared even when STA disconnects from
that AP and this disables btm_offload for next connections
as well even for non-HS-2.0 APs.
So, reset the flag as part of connect start to avoid this.
Change-Id: I3763544ecca0e4628b0c78633364fe70fd9b3094
CRs-Fixed: 3712758
Host tried to associate to AP, 6 GHz link is selected as
the assoc link and in the RNR there are two partner links 5 GHz, 2.4 GHz.
Only 6 GHz/2.4 GHz are beaconing and 5 GHz is not beaconing.
STA sent the ML-Probe request on 6 GHz link requesting the full profile
for the 5 GHz and 2.4 GHz links but AP responded with only one partner
link 2.4 GHz, from this we generated 2.4 GHz and added to scan cache,
AP didn't respond with 5 GHz link in per-sta.
STA sent the assoc request over 3-links and AP accepted the assoc,
and association is successful over 3-link and the same is intimated
to the firmware that 3link association is successful.
But while sending the connection information to the kernel 5 GHz link
is not found resulting in HDD/Kernel not being aware of the 5 GHz link.
Fix :- Use assoc response from the ML AP to generate ML probe resp
for the partner links to add to scan DB so that partner link
VDEV will have candidate to start connection.
Change-Id: I30176e58d9b02e7ed275b1c926cd1e119b66f8f3
CRs-Fixed: 3686809
Currently on HO failure host posts disconnect with priority
set in serialization queue before dequeuing the dummy roam
command from serialization, as a result for 2 link ML STA
case when HO failure is received, assoc VDEV disconnect gets
priority over partner link VDEV in the serialization
queue. When assoc VDEV disconnect is complete, host updates this
info to userspace and userspace issues dynamic mac address
update command. While processing this command the DP assoc VDEV
is first detached then re attached. There is possibility of
race where link VDEV disconnect starts in parallel, as DP link
VDEV has the reference of DP assoc VDEV, in order to release the
reference it looks up for the DP assoc VDEV , but as part of mac
address update if DP assoc VDEV is detached and reattachment is
pending then the DP link VDEV doesn't get the DP assoc VDEV and
reference release fails.
To address this issue don't prioritize disconnect for
HO Fail case.
Change-Id: I74c7bce851423226d3aac2750fddd5e6c7e34fd1
CRs-Fixed: 3697528
Add more validation for vendor command force active link bitmap:
1.If force inactive num is present due to MCC link(DBS RD) or
concurrency with legacy intf, don't allow force active if
left inactive link number doesn't meet concurrency requirement.
2.If force inactive bitmap is present due to link removal or
concurrency with legacy intf, don't allow force active if
it is conflict with existing concurrency requirement.
Change-Id: Ic7507c1797189c079f0032a39819e15467bd6bf3
CRs-Fixed: 3701323
Few non-TxMBSSID APs may not respond to ML probe req and driver
can't add latest scan entry for the partner links from ML probe
resp and if beacons from partner links are not received for a
duration enough to flush out the scan entry of that link then
connection of partner VDEV will fail with no candidates found.
Use assoc response from the MBSSID AP to generate ML probe resp
for the partner links to add to scan DB so that partner link
VDEV will have candidate to start connection.
Following are the conditions for this logic:
- Candidate is a non-TxBSSID in an MBSSID set
- Connection is for more than single link (MLSR/MLMR)
- Scan entry for partner link is not found in scan DB
Change-Id: If97475878d61d986988a6e97e693b194518dc192
CRs-Fixed: 3679519
Currently, driver drops BTM frames in unsupported cases,
e.g. connected to MBO AP without PMF capability, concurrent P2P
session present which doesn't allow STA roaming.
Add connectivity log support and indicate the reason for BTM
drop/block.
Define interface for userspace as below,
New subtype: WLAN_CONN_DIAG_BTM_BLOCK_EVENT
New enum to fill sub_reason for BTM_BLOCK_EVENT type
Change-Id: I87115da57d275a94c5ae69252ec09bcad698e47c
CRs-Fixed: 3699042
Firmware sends WMI_ROAM_SYNCH_KEY_EVENTID after roaming
to 3 Link ML AP. Host allocates memory for every crypto
keys and populates data from the fw event.
This memory is not freed if the addition to crypto
module fails and results in memleak.
Fix is to free the crypto key entry when addition fails.
CRs-Fixed: 3678765
Change-Id: Ife70261b697ec016f50d4e0730c3fa4fc0ec06ab
In the api cm_roam_btm_req_event(), BTM request and
BTM Candidate Connectivity logs are printed for both
partial and full scan when disassoc_imminent is set for BTM
roam trigger. But actually, over the air frame was received
only once on the device.
So to avoid BTM frame logs duplication,
ignore the BTM request frame TLV & btm candidate TLV received from
firmware after BTM roam trigger with disassoc imminent set.
Change-Id: I7d8cf4a4f0c7e2ee7958ae3fc309f14890c2fd33
CRs-Fixed: 3675909
After roaming to 2+5 MLO AP, MLD high RSSI roaming trigger is
getting disabled if assoc link is on 5 GHz.
To fix it, if self MLD roaming is supported, then don't enable
high rssi roaming trigger for 2.4 GHz link and disable it for 5
GHz link after roaming is competed.
Change-Id: I4c02cb2c946d97884fbc0d6cc513c585c21b9548
CRs-Fixed: 3670241
In api cm_roam_scan_info_event(), band_mask is updated
for ROAM_STATS_SCAN_TYPE_HIGHER_BAND_6GHZ and
ROAM_STATS_SCAN_TYPE_HIGHER_BAND_5GHZ_6GHZ. But
the band mask is truncated for ROAM_STATS_SCAN_TYPE_FULL.
add check in api cm_roam_scan_info_event() to update
band mask only for scan type
ROAM_STATS_SCAN_TYPE_HIGHER_BAND_6GHZ and
ROAM_STATS_SCAN_TYPE_HIGHER_BAND_5GHZ_6GHZ in order
to prevent the band mask from truncating for
ROAM_STATS_SCAN_TYPE_FULL.
Change-Id: I3e85c87e3e304d0c4d4ae311c7be1939e73d05df
CRs-Fixed: 3666578
Currently, host disables btm_offload feature if the connected AP
supports MBO/OCE but not PMF. Firmware doesn't process the btm
requests received from AP in such cases and forwards the same
to host. Host forwards them to userspace. But userspace may not
expect these frames as roaming is offloaded to firmware.
Drop the BTM request frames in driver for LFR3 cases when the
connected AP supports MBO without PMF.
Change-Id: I35800ff31f8a48d12eb57cdd36856fdef2b53b8e
CRs-Fixed: 3687371
Currently for STA + STA case, consider the below scenario:
1. Roam start received on vdev 2 & vdev 0. Vdev 2 roam
serialization command becomes active and vdev 0 roam
command is on the pending queue.
2. HO failure with AP0 received on vdev 2. This dequeues
the vdev2 roam serialization command. Vdev0 roam command
becomes active.
3. Roam synch indication received on vdev0 with peer AP as
AP0 (which is the peer on vdev 2). So duplicate detection
logic prevents same peer creation, so roam synch fails but
its not indicated properly to firmware. This leads to
disconnection of both the STAs.
To address the issue, first enqueue disconnect with high
priority set before removing roam command from serialization
so disconnect gets activated if roam was active for the
vdev.
Also while processing roam synch indication, check if peer is
found on different STA and send roam stop to fw so fw also
cleans up and initiates HO failure.
Change-Id: Iddeddcde782b936dc2ea4b8f32fd0be3c0ced591
CRs-Fixed: 3686114
Currently, RSO_STOP is sent to firmware if ROAM_SYNC is aborted
due to some reason. Host doesn't check for the current state of
RSO state machine and may send the RSO_STOP twice. Firmware
responds with SUCCESS for the second request and driver
continue to cleanup peer/vdev assuming that it's a normal
RSO_STOP response. This results inconsistency in firmware
as it might be in the middle of peer/vdev cleanup and
leads to ASSERTION.
Check for the RSO state machine status and avoid sending
RSO_STOP twice.
Change-Id: I87cdb4a682095772070a839bbb86e56a9450b299
CRs-Fixed: 3677172
Link beacon in roam sync frame event may be not for actual link when
roamed to 2+ link AP, then get right link beacon from scan cache, but
beacon size may be larger, if malloc buffer with link beacon size in roam
sync frame event to save beacon IE got from scan cache, OOB will happen.
To fix it, when malloc buf to save beacon IE during roaming, use max
mgmt mpdu size.
Change-Id: I08fc52ce26edc1f02365837a1ed7a632ed7c6706
CRs-Fixed: 3667410
Implement a locking mechanism for retrieving and
storing crypto keys. Currently, due to race condition,
Host driver is fetching information in one thread while
simultaneously writing key information in another thread,
resulting in synchronization issues.
This change is to add lock mechanism while reading and writing
crypto keys.
Change-Id: I156b619cf7c3c052ad3122a6f808d732fb5e4f51
CRs-Fixed: 3672330
Calculate valid number of roam scan channel count in case of
idle roam scan of type ROAM_STATS_SCAN_TYPE_HIGHER_BAND_6GHZ
or ROAM_STATS_SCAN_TYPE_HIGHER_BAND_5GHZ_6GHZ and send same
to upper layer via SCAN_DONE logging event.
Change-Id: If59c732c7efad78ef6e4b6b0ada48054f1d0252c
CRs-Fixed: 3652329
