Please do not apply this patch set, it will need some changes.
Am 20.01.2014 19:48, schrieb Oleksij Rempel:
Ath9k_htc has too match outdated copy/paste from ath9k.
This patch set trying to remove some of it and make some function common
to both drivers.
Oleksij Rempel (5):
ath: add
drivers/net/wireless/ath/ath9k/main.c: In function ‘ath9k_has_tx_pending’:
drivers/net/wireless/ath/ath9k/main.c:1869: warning: ‘npend’ may be used
uninitialized in this function
Introduced by commit 10e2318103f5941aa70c318afe34bc41f1b98529 (ath9k:
optimize ath9k_flush).
Signed-off-by: Geert
Hi,
Thank you for your reply. This fixed half of the problem. If the link
quality is good all A-MPDUs are
at the maximum length, however if the link quality is not good (high
error) many A-MPDUs are smaller than
the maximum A-MPDU length. As mentioned before it has something to do
with the block
Thank you. I checked ath_tx_form_aggr() and the condition that checks:
do not step over block-ack window
causes the A-MPDU length limitation. So is there anything to do to force
max A-MPDU length?
Does setting retry to 1 solves this problem? My understanding is that if
retry is 1 then we move
Hi All,
This commit:
commit 4dc78c437a0a2ac152a2b2c5e91a814a6ef3599e
Author: Sujith Manoharan c_man...@qca.qualcomm.com
Date: Wed Dec 18 09:53:26 2013 +0530
ath9k: Fix RTC reset delay
The delay that is required after issuing a RTC reset
varies for each chip. Handle this properly.
Thank you. I checked ath_tx_form_aggr() and the condition that checks:
do not step over block-ack window
causes the A-MPDU length limitation. So is there anything to do to force
max A-MPDU length?
*YES! we told you earlier if link is lossy then this limit will not let
AMPDU to increase.*
Does
Josh Boyer wrote:
adds a udelay(1) call to the ath9k driver. This will cause a
build error on various ARM configs because the value passed to udelay
is too large:
ERROR: __bad_udelay [drivers/net/wireless/ath/ath9k/ath9k_hw.ko] undefined!
make[1]: *** [__modpost] Error 1
make: ***
Simon Wunderlich wrote:
we have found a regression in the IBSS creation/joining part of mac80211
which
is appearently connected to the TSF-syncing patches introduced last year[1].
It prevents beaconing of an adhoc member after rejoining a cell when this
cell
is currently empty. The
