Remove the embedded branch to make the ATH_EP_RND macro a little
clearer. The new version also generates better code, saving 24
bytes of text:
textdata bss dec hex filename
878581641 24 89523 15db3 ath9k_orig.ko
878341641 24 89499 15d9b
Thanks for the response, Felix !
I have some questions to ask :
(2) I was timestamping the frame in ath_tx_txqaddbuf() and in
ath_tx_complete buf()
to get the (queuing + contention) delay. Can I somehow get just the
contention
delay in ath9k ?
(1) So I should interpret the ath_tx_status
On 26 February 2013 03:30, Oleksij Rempel bug-tr...@fisher-privat.net wrote:
AR9271 and AR7010+AR9280 works fine for me. No problems with
authentication and both have good speed, in my network about 8-10MB/s.
Sweet, thanks!
Adrian
___
ath9k-devel
On Mon, 2013-02-25 at 11:06 +0100, Marco Porsch wrote:
This is strange, why bother with the else if there's a continue?
I don't quite get this comment. The current logic is like this:
if (unrelated cases) {
continue;
} else if (related and blocking) {
allow = false;
Please let me know if this works better.
Thanks!
Adrian
htc_7010.fw - now it works better. It looks like speed is higher than with
20121128, but this may be luck , will see further.
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
On 2013-02-26 7:51 PM, abhinav narain wrote:
Thanks for the response, Felix !
I have some questions to ask :
(1) So I should interpret the ath_tx_status descriptor as :
14 retransmissions occurred while transmission of 1542*4 bytes.
Its not 14*4 retransmissions.
Aggregates are formed by the
