NOTE: this page is for archival only, see the note at the end of the page.

Go back –> Atheros Linux wireless drivers


ath6kl is the wireless driver for Atheros AR600x family of chips. It has been tested to work with the latest in the family, AR6003.

Subscribe to this page!

You should subscribe to this page so you can get e-mail updates on changes and news for ath6kl automatically. You'll get an e-mail as soon as this page gets updated.

Get the latest ath6kl driver

We are in the process of putting together the driver for submission into the staging area via the wireless-testing tree.

Supported chipsets

  • AR6003


The following modes have been tested with this card.

Modes of operation

  • Station Mode

  • AP Mode

  • IBSS Mode


  • 802.11abg
  • 802.11n
    • HT20
    • HT40
    • AMPDU
    • Short GI (40 MHz only)
  • 802.11i
    • WEP 64 / 127
    • WPA1 / WPA2
  • 802.11d
  • 802.11h
  • WMM
  • BT co-existence

Design Notes


The AR6003 is the third-generation Wi-Fi chip from Atheros optimized for the throughput, size, and energy efficiency needs of mobile and embedded devices. With its tiny footprint and energy-saving qualities, the AR6003 rounds out Atheros’ comprehensive Align® ecosystem of 1-stream 11n solutions, targeting smartphones, mobile gaming and portable CE devices.

Driver Architecture

AR600x software is partitioned into host-side and target-side software. The host side software or the driver is provided as a reference implementation for selected platforms/OSes including Linux. The current avatar of Linux driver is referred to as 'ath6kl' or the Legacy driver for AR600x family of chips. The target-side software or the firmware runs on the cbhip's network processor and is stored in the target memory. It is a maintained by Atheros and is released as binary only.

The 'ath6kl' driver is organized into the following layers which collectively define the host software stack. In general, functions in the highest layer may call other functions at the same layer or one layer down. Functions do not make direct calls to higher layers, though upper layers may register callbacks with lower layers. A brief summary of the driver components is given below. Refer to the <link> for further details.

<Block Diagram>

1) Wireless Device Driver: Bridges the control and data paths between the kernel and the HTC/WMI layers. On the control path, it handles both the vendor specific proprietary ioctls and the standard ones defined under wireless extensions. The layer also implements the CFG80211 APIs and therefore provides support for nl80211 based applications. On the data path it handles the data between the HTC layer and IP stack. The relevant sources are present in the ath6kl/os/linux/ directory.

2) Wireless Module Interface (WMI): If the wireless application must send control messages to the AR600x chipset, it calls into the WMI to create the messages. This layer understands the host/target messaging protocol (WMI Protocol) and its source is in the ath6kl/wmi/ directory. The header files ath6kl/include/wmi.h and ath6kl/include/wmix.h list all messages from host to target (commands) and from target to host (requests and events).

3) Host/Target Communication (HTC): The wireless device driver calls into HTC to handle message transport. HTC does not understand the contents of messages it transports (only WMI understands the contents of control messages), but it does understand the mechanics of messaging with the AR600x chipset. It handles flow control and knows which chipset addresses must be read and written to relay messages. This layer source is in the ath6kl/htc2/ directory.

4) Host Interconnect Framework (HIF): HTC calls into the HIF layer when it needs to access the chipset address space. An HIF implementation exists for each combination of platform and interconnect API (e.g., HIF for Linux standard SDIO/MMC stack). This layer abstracts away register and memory access details and provides an interconnect-independent and platform-independent API for use (mainly) by HTC. This layer source is in the ath6kl/hif/ directory.

5) Physical Interconnect: The HIF layer relies on underlying interconnect-specific and platform-specific software to drive a hardware controller of some sort. The interconnect layer plays a role in device discovery, setting up an appropriate address space mapping and performing reads/writes through that address space, and deals with error management over the physical connection. For most serial buses, the HIF layers interfaces with a bus driver that provides an abstracted view of the underlying host bus adapter. These bus drivers may be provided by partners, OS vendors, or Atheros.

This is a static dump of the old wiki, taken after locking it in January 2015. The new wiki is at
versions of this page: last, v34, v33, v32, v31, v30, v29, v28, v27, v26, v25, v24, v23, v22, v21, v20, v19, v18, v17, v16, v15, v14, v13, v12, v11, v10, v9, v8, v7, v6, v5, v4, v3, v2, v1