| Date | Comment | Version |
|---|---|---|
| 08/16/22 | Initial Release | 0.1.0 |
HAL- Hardware Abstraction Layer, may include some common componentsHAL.h- Abstracted defined API to control the hardwareHAL.c- Implementation wrapper layer created by theOEMorSoCVendorRDK- Reference Design Kit for All DevicesRDK-B- Reference Design Kit for Broadband DevicesWi-Fi- Wireless Radio NetworkingHATS- HAL Automated Testing SystemOEM- Original Equipment ManufacturerSoC- System on a Chip
The Hardware Abstraction Layer (HAL) is to abstract the RDK Wi-Fi requirements at a general level to allow platform independent control.
The picture below shows the relationship between the HAL, Kernel and the WiFi Driver.
The following components are optional and its upto vendors discretion.
-
hostapd(host access point daemon) is a user space daemon software enabling a network interface card to act as an access point and authentication server -
nl80211/cfg80211nl80211 is the interface between user space software (iw etc.) and the kernel (cfg80211 and mac80211 kernel modules, and specific drivers)
It should be statically loadable library. There should one HAL interface for the system.
The lifetime of which shall exists throughout the lifetime of process.
Failure to meet these requirements will likely result in undefined and unexpected behaviour.
Initialize the Wifi HAL using wifi_init() before making any other calls.
The kernel boot sequence is expected to start all the dependencies for the WiFi HAL.
HAL is expected to be thread safe.
There is no restriction on the vendor to create any number of threads to meet the operational requirements.
A single instance is expected to exist. And only one instance will be initialised.
Where HAL creates any memory, then HAL will be expected to own it.
Where client creates memory, then client is expected to own it.
Exceptions to these rules can be specified in the API documentation.
There is no requirement for the component to participate in power management.
There are number of asynchronous callback registration functions these are defined by xxx_callback_register()
and marked in the doxygen comments with token @execution callback
As a few examples of this are:-
- For asynchronous management frames transmission -
wifi_mgmt_frame_callbacks_register() - For asynchronous notification on client connection -
wifi_newApAssociatedDevice_callback_register() - For asynchronous notification on client deauthentication -
wifi_apDeAuthEvent_callback_register() - For asynchronous notification on client dissocciation -
wifi_apDisassociatedDevice_callback_register() - For asynchronous notification on client connection status -
wifi_staConnectionStatus_callback_register() - For asynchronous notification on client scan results -
wifi_scanResults_callback_register()
During callbacks the client is responsible for create a copy of data, unless otherwise specified in the API documentation.
None of the calls in the interface should block.
All the APIs define a list of return codes, each API must be capable of returning all of the codes defined, the UT if possible, will create cases
for the error codes to be exercised.
HAL is responsible to handle system errors (e.g., failure of memory allocation, array boundary out of memory, return code check), and returning
only the fixed returned codes as defined in the API specification.
Wifi HAL configuration will be maintained by upper layer.
Following non-functional requirement should be supported by the component.
The component should log all the error and critical informative messages. This helps to debug/triage the issues and understand the functional flow of the system.
The logging should be consistance across all HAL components.
If the vendor is going to log then it has to be logged in wifi_vendor_hal.log file name.
Logging should be defined with log levels as per Linux standard logging.
During idle and Standby, memory and CPU utilization will be a minimal footprint.
Refer to product specification for guidance on maximum CPU load average and memory requirements.
The vendor should endeavour to:-
- Run a static analysis tool like Coverity etc
- Have a zero-warning policy with regards to compiling. All warnings should be enabled by default in the makefiles.
- Use of memory analysis tools like Valgrind are encouraged, to identify leaks/corruptions.
HALTests will endeavour to create worst case scenarios to assist investigations
Licensed under the Apache License, Version 2.0 (the "License"). you may not use this file except in compliance with the License.
The source code should be built under Linux environment using cmake, make, gcc, etc. as required, and would normally be delivered as a library and source code.
Ideally the source code should be delivered into git repositories and tagged based on the requirements for the project.
Compile time flags config flags can control compilation:-
Example of this would be:-
config flags are encouraged, so this can be defined at the top-level compile time
#ifdef CONFIG_WIFI_V6
.. do wifi v6
#else
.. no v6
#enidf
The interface will maintain getCapabilities() functionality, and the upper layers will use this to determine available features.
The interface is documented by Doxygen and will be included with this release.
Covered as per "Description" sections in the API documentation.
sequenceDiagram
participant coreThread
participant Wifi_HAL
participant Wifi_Driver
participant Linux_System
coreThread->>Wifi_HAL: wifi_init()
Wifi_HAL->>Linux_System: init wifi
Wifi_Driver->>Wifi_HAL: return wifi init status
Wifi_HAL->>coreThread: success
coreThread->>Wifi_HAL: getHalCapabilty()
Wifi_HAL->>Wifi_Driver: get phy device capabilities
Wifi_Driver->>Wifi_HAL: return phy device capabilities
Wifi_HAL->>coreThread: getHalCapabilty() status
coreThread->>Wifi_HAL:wifi_setRadioOperatingParameters
Wifi_HAL->>Wifi_Driver: set radio parameters
Wifi_HAL->>coreThread: success
note over Wifi_HAL: System is up and running
coreThread->>Wifi_HAL: wifi_createVAP()
Wifi_HAL->>coreThread: success