diff options
| author | Ye Jiao <ye.jiao@mediatek.com> | 2020-11-20 10:51:19 +0800 |
|---|---|---|
| committer | Roshan Pius <rpius@google.com> | 2020-12-02 17:44:49 +0000 |
| commit | bf8f310071d900dec038d517a136d94e94dbe42a (patch) | |
| tree | 998589d015f9b2ce2b26a1d0afe6b79690c6e483 /OWNERS | |
| parent | d47c62b62af53ddbd1f70e520162d843e0e43356 (diff) | |
| download | platform_hardware_interfaces-bf8f310071d900dec038d517a136d94e94dbe42a.tar.gz platform_hardware_interfaces-bf8f310071d900dec038d517a136d94e94dbe42a.tar.bz2 platform_hardware_interfaces-bf8f310071d900dec038d517a136d94e94dbe42a.zip | |
DO NOT MERGE: Tune up kMaxStopCompleteWaitMs to fix NE
On a low-end device which does not support STA-SAP concurrency, if STA
is currently enabled and user/app tries to enable SAP, then Wi-Fi needs
to reconfigure and stop Wi-Fi HAL first. Among other stopping actions,
HAL needs to set global_handle_ to nullptr and send "Exit" to
wifi_event_loop then waits no more than kMaxStopCompleteWaitMs. If the
wait times out, then reconfiguration fails and causes Wi-Fi controller
returns to STA mode and creates new STA iface indirectly. In this
process, HAL needs to access global_handle_, but since it was cleared,
we can only get a Native Exception.
Because there is no proper error recovery for UNKNOWN errors, I suggest
to simply set kMaxStopCompleteWaitMs to a higher value to circumvent
this timing issue.
Bug: 173760638
Change-Id: I1b5a0a7a554409704c017ffaf52a767b9424c61e
Diffstat (limited to 'OWNERS')
0 files changed, 0 insertions, 0 deletions