Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Changes between Version 10 and Version 11 of DevDocs/HAL-usage

mtaylor (IP:
05/21/07 23:39:09 (14 years ago)

Removed radar functions no longer supported by the HAL. Added some comments for the one remaining radar related function. TODO: we need to update the line numbers or remove them.


  • DevDocs/HAL-usage

    v10 v11  
    2525ah_setTxPowerLimit sets the overall (max?) power limit of the device. The integer power limit parameter is specified in 0.5dBm steps. Thus it appears that a value of 20 would represent 10dBm. Also note that ah_setupTxDesc has a txPower parameter, so transmit power can be set on a per-packet basis. It appears that ah_setTxPowerLimit is used to limit the overall device power and the ah_setupTxDesc is used to set the per-ath%d device power limit. 
    26 {{{  
    27 523  
    28 524         void      __ahdecl(*ah_arEnable)(struct ath_hal *); 
    29 525         void      __ahdecl(*ah_arDisable)(struct ath_hal *); 
    30 526         void      __ahdecl(*ah_arReset)(struct ath_hal *); 
    31 527         HAL_BOOL  __ahdecl(*ah_radarHaveEvent)(struct ath_hal *); 
    32 528         HAL_BOOL  __ahdecl(*ah_processDfs)(struct ath_hal *, HAL_CHANNEL *); 
    33 }}} 
    34 ah_processDfs is related to radar handling. It refers to 802.11h and stands for Dynamic Frequency Selection. Something to do with access points changing channels dynamically if radar interference is encountered. (Anyone have more precise details?) 
    35 {{{ 
    36 529         u_int32_t __ahdecl(*ah_dfsNolCheck)(struct ath_hal *, HAL_CHANNEL *, u_int32_t); 
    3727530         HAL_BOOL  __ahdecl(*ah_radarWait)(struct ath_hal *, HAL_CHANNEL *); 
     29For 802.11a channels in regulatory domains where DFS rules apply, this function is used to retrieve the status of DFS handling from the HAL.  The function populates the HAL_CHANNEL structure passed in.  The updated channelFlags and privFlags values should indicate whether the channel requires DFS (CHANNEL_DFS flag) and whether it has been through the channel availability check process (CHANNEL_DFS_CLEAR flag).  The madwifi driver should wait to transmit until this has happened.  With our current HAL, however, it seems that the CHANNEL_DFS flags are returned incorrectly for the US (countrycode 840) and that for ETSI countries where it does know that DFS is required, it seems to always return CHANNEL_DFS_CLEAR immediately.  Note: I have yet to see the CHANNEL_DFS flag without CHANNEL_DFS_CLEAR already having been set.  [mtaylor] 
    4031=== Transmit functions ===