The rate control algorithm, default is Minstrel for ath5k, determines
the number of retries to use for each rate. However, there exists in
ath5k_hw_setup_4word_tx_desc (which is called for AR5212 like devices)
a set number of retries defined by AR5K_TUNE_HWTXTRIES. The set
number of tries is added to the tx_tries0 variable setup by the rate
control algorithm. This changes the number of retries the rate
control algorithm considers necessary. By removing the
AR5K_TUNE_HWTXTRIES from the retry calculation the rate control
algorithm is given control over the number of retries.
Signed-off-by: Andrew Blaich <ablaich@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
it's never used. probably a leftover from the old OpenHAL days...
Signed-off-by: Bruno Randolf <br1@einfach.org>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Currently, the padding position is based on
ieee80211_get_hdrlen_from_skb(). This is not correct since the HW does
padding on RX (and expect the same padding to be present on TX) at the
following position :
- management : 24 + 6 if 4-addr format
- control : 24 + 6 if 4-addr format
- data : 24 + 6 if 4-addr format + 2 if QoS
- invalid : 24 + 6 if 4-addr format
whereas ieee80211_get_hdrlen_from_skb() is :
- management : 24
- control : 16 except for ACK/CTS where it is 10
- data : 24 + 6 if 4-addr format + 2 if QoS + 2 if QoS & order
- invalid : 24
So, correct frames are not affected : management frames do not use
4-addr format, control frames have no body and invalid frames are ...
not valid by definition. However, in order to use monitor interface for
debugging purpose, one must be able to send/receive any frames, be it
correct or not. Such frames are affected by incorrect padding.
Moreover, since padding is added on TX, we need to remove it before
calling ieee80211_tx_status. This affect TX packets received by monitor
interfaces.
It has been tested between an ath5k based card (AR5212) and an ar9170usb
based card (netgear WNDA3100) using a frame generator and a monitor
interface for each card.
v2: Added ath5k_add_padding / ath5k_remove_padding
Signed-off-by: Benoit Papillault <benoit.papillault@free.fr>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Andrew Blaich