onSubsystemRestart should be triggered by wifi HAL
when subsystem restart happened.
Add log to debug why this callback function was not trigger at
unexpected corner case.
Bug: 201330066
Test: Manual test
Change-Id: I160adc6006d078fcc72c1768927e87e378fd675e
Merged-In: I160adc6006d078fcc72c1768927e87e378fd675e
In order to trigger subsystem restart to reload wlan firmware,
this change adds an API for framework and vendor HAL.
Meanwhile, create new callback function for subsystem restart instead of
general callback "onFailure()".
Bug: 178126071
Test: vendor HAL can received API call
subsystem restart will callback "onSubsystemRestart()"
Change-Id: If3dc84049a9171677ad281c9bcc67a44dc722bdb
setMacAddress may fail in some scenarios like SSR inprogress. In such
case framework is not bringing up the iface again if it was brought down
to set random MAC address. Due to this subsequent operations like scans
are failing with "Network Down" error and Wi-Fi can't recover until
Wi-Fi restarts. To avoid this bring up the iface irrespective of
setMacAddress status.
Modified the original CL to move the WifiIfaceUtil creation to inside
Wifi object since that is where the legacy HAL instance is created for
the corresponding chip. This helps keeping the setMacAddress logic still
inside WifiIfaceUtil. Modified the iface_util lifetime - no longer a
singleton, one instance created per wifi chip instance.
Bug: 174183763
Test: Wifi can be enabled when back-to-back SSR and wifi on
Change-Id: I926b59f5da126aba222e05d1e570c0c19de739ed
The WIFI HAL API has support for multiple WIFI chips
(IWifiChip instances) however the implementation
is hard-coded to support only a single WIFI chip.
This change reworks the implementation so multiple
WIFI chips will be supported.
Support for multiple chips is based on the concept
that each chip is represented by its own vendor HAL
library.
The implementation will look for descriptor
files for vendor HAL libraries under
/vendor/etc/wifi/vendor_hals. It will parse
descriptors, dynamically load vendor HAL libraries
and create WifiLegacyHal and WifiChip objects for
each loaded vendor HAL library.
One of the descriptors should be marked with "primary"
flag. The implementation will create the first WifiChip
object for this library. Typically it is the one
providing the best WIFI functionality, which was
previously used as the only WIFI chip.
Additional support is added inside WifiChip and
WifiLegacyHal for getting available chip modes
and concurrency combinations from the vendor HAL
if available, and allowing the chip to override
network interface name when creating interfaces.
The mechanism for getting chip capabilities is
improved to allow getting chip-global capabilities,
which are independent of any created interfaces.
For example, if the framework needs to start
a SoftAP on the 60GHz band, it needs to find a
chip which supports this band, but before creating
any interface on the chip. The new mechanism allows
this.
Bug: 146922967
Test: atest VtsHalWifiV1_0TargetTest VtsHalWifiNanV1_0TargetTest VtsHalWifiApV1_0TargetTest \
VtsHalWifiV1_1TargetTest \
VtsHalWifiV1_2TargetTest VtsHalWifiNanV1_2TargetTest \
VtsHalWifiV1_3TargetTest \
VtsHalWifiApV1_4TargetTest VtsHalWifiNanV1_4TargetTest VtsHalWifiRttV1_4TargetTest
Change-Id: Ibdff93ea56aff186d4b5361ac77f6f448a0dfd45
