rdkcentral/rdkb-halif-wifi

Purpose and delivery model

This repository defines the RDK-B Wi-Fi Hardware Abstraction Layer (HAL) contract: a platform-independent C API implemented by OEM/SoC vendors and consumed by upper RDK components. It is primarily an interface/documentation repository, not a HAL implementation. The deliverable is a single, statically loadable, process-lifetime library with one initialized HAL instance.

Core interface: include/wifi_hal.h

Build/package metadata: configure.ac, build_ut.sh

Entry point and lifecycle

Consumers must call wifi_init() before every other API. The HAL remains available for the process lifetime, is expected to be thread-safe, and APIs must not block. HAL-created memory remains HAL-owned; caller-created memory remains caller-owned unless an API specifies otherwise.

The upper layer owns persistent Wi-Fi configuration; the HAL applies requested state to the platform and reports standardized return codes.

Primary API root: include/wifi_hal.h

Contract reference: docs/pages/halSpec.md

API partitioning

The public contract is divided by Wi-Fi domain rather than implementation layers:

• Common/generic types, initialization, capability discovery, and shared operations.

• Radio configuration and PHY-level control.

• AP/VAP creation, configuration, and connected-device management.

• Station/client operation and scan/connection status.

• Telemetry, extender, emulation, and deprecated compatibility surfaces.

Paths: include/wifi_hal_generic.h, include/wifi_hal_radio.h, include/wifi_hal_ap.h

Additional domains: include/wifi_hal_sta.h, include/wifi_hal_telemetry.h, include/wifi_hal_extender.h

Primary control flow

An upper RDK process initializes the HAL, queries capabilities, then configures radios and creates/configures VAPs. Vendor HAL code translates these abstract operations to the Linux Wi-Fi stack and vendor driver. Capability APIs are the feature boundary: upper layers use them to avoid invoking unavailable platform features.

Expected sequence: initialization → capability discovery → radio operating parameters → VAP lifecycle.

API surfaces: include/wifi_hal.h, include/wifi_hal_radio.h, include/wifi_hal_ap.h

Asynchronous event boundary

The HAL exposes callback-registration APIs for operations whose outcomes arrive asynchronously, including management-frame transmission, AP association/deauthentication/disassociation events, STA connection changes, and scan results. Callers must copy callback data unless API documentation says otherwise. This separates non-blocking request APIs from driver/kernel-originated events.

Relevant contracts: include/wifi_hal_ap.h, include/wifi_hal_sta.h, include/wifi_hal_client_mgt.h

Platform and infrastructure boundary

The vendor implementation sits between RDK consumers and Linux kernel Wi-Fi facilities/drivers. cfg80211/nl80211 and hostapd are optional vendor-selected integration components. Kernel boot is expected to start HAL dependencies before wifi_init().

The repository uses Autotools metadata and a unit-test build script; documentation is generated from Doxygen-oriented interface comments.

Paths: configure.ac, docs/generate_docs.sh, docs/pages/halSpec.md

Operational constraints

Vendor implementations must map internal/system failures to fixed API return codes, log errors and critical events consistently (specified log filename: wifi_vendor_hal.log), and minimize idle CPU/memory use. Compile-time feature flags may vary implementations, while runtime capability reporting preserves a stable upper-layer contract.

Compatibility and optional interfaces: include/wifi_hal_deprecated.h, include/wifi_hal_emu.h