Go back –> Main ath9k driver page

ath9k TODO list

This page documents work being done and which needs to be done for ath9k.

HAL unification

We are working hard at Atheros to make upstream support for new Atheros chipsets come to Linux as quickly as possible. In order to achieve this we are working on sharing as much code as is possible. We have already determined we can only share the hardware code. Atheros refers to the hardware code as HAL still, but upstream in the Linux kernel we refer to this as hardware code, and the respective module for it is ath9k_hw. So we strive to share code on ath9k_hw.

HAL unification is our effort at Atheros to unify the Atheros HAL with what we have worked on upstream in ath9k_hw. A lot of this work consists of Making the Atheros HAL adapt to the coding style and take advantage of the code cleanups already being done and being done on ath9k_hw. The goal is to get the Atheros HAL to come as close as is possible to the style and structure used upstream in the Linux kernel, and for the parts that we cannot share use scripts / spatch to do some final conversion. We will need this to work both ways, for patches being merged into the Atheros HAL and also for patches coming from the community into ath9k_hw.

Here are a few major tasks being worked on right now:

• Update coding style guidelines for the Atheros HAL to match more closely with upstream Linux requirements
• Change most coding style to match more closely with upstream Linux requirements

• Unify the array names and style for initvals, and start making more concrete commit log entries for each update. To ensure we don't modify the data structure for coding style considerations we can use the initvals-tools to check the checksums of each initval array.

• Define ath9k_hw module maintainers which will always review hardware code updates. This is required so we don't fork hardware code, we want to unify our testing on the same hardware code.

On the table

These are items being reviewed for implementation and suppport

DFS

DFS for AP mode is being reviewed.

Minstrel HT support

Minstrel HT support will be tested once Minstrel HT addresses some of the concerns our systems engineering team had. At the moment the only thing I can think of that needs to be added still is include CCK rates into the scope of rates that Minstrel HT tests for. CCK rates will help with longer ranges. Once CCK rates are taken into consideration we can start coordinating a schedule to test ath9k with Minstrel HT. Goal is to replace ath9k RC completely.

Atheros AR9003 becaon processing hw support

Atheros AR9003 supports hardware beacon processing, it can do checksumming of beacons, etc, once that gets implemented in software add we should use the mac80211 beacon monitor flag so that a driver can do its own beacon monitoring.

Being worked on

AR9485 support

AR9485 is a cheaper version of the AR9285. Should consist of some initval updates and a few ath9k_hw changes. Goal is to get most code in synch for ath9k_hw through HAL unification principles.

AR93xx family support

Check out the AR93xx TODO page for details on this.

Available work, any takers?

• Use new wiphy->n_addresses, wiphy->addresses and wiphy->addr_mask instead of the ath->bssidmask. See this patch for reference:

    cfg80211: export multiple MAC addresses in sysfs
    
    If a device has multiple MAC addresses, userspace will
    need to know about that. Similarly, if it allows the
    MAC addresses to vary by a bitmask.
    
    If a driver exports multiple addresses, it is assumed
    that it will be able to deal with that many different
    addresses, which need not necessarily match the ones
    programmed into the device; if a mask is set then the
    device should deal addresses within that mask based
    on an arbitrary "base address".
    
    To test it all and show how it is used, add support
    to hwsim even though it can't actually deal with
    addresses different from the default.
    
    Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

Then add an nl80211 command for displaying this stuff.

• Remove this redundancy crap: bf->bf_buf_addr = bf->bf_dmacontext;

• Noise floor per channel (will help with other chips as well) – look for ATH_NF_PER_CHAN

• ath9k sends all data traffic right now through A-MPDU aggregation. As per Matt Smith we should not send voice data under a BA agreement.  If you have to give up on transmitting a frame, it will leave a hole at the receiver which will then require a BAR to move past.  Since you will typically only send one frame at a time, it (use of A-MPDU aggregation) doesn't buy you anything.  IIRC, there are industry certification tests that send more than one frame a second at AC_VO, however, which one needs to to pass.

Cleanup

* Cleanup HW capabilities

• Still too convoluted.
• Figure out why we use two routines to fill the TX descriptor:
  • ar9003_hw_fill_txdesc()
  • ar9003_hw_set11n_txdesc() We'll need to try to synchronize this on the HAL first prior to modifying on ath9k so we can synchronize both code bases

* Cleanup ChannelFlags

• Still a bit ugly.

Will not be supported

• WEP 152 - there are no plans to support this in mac80211