| Age | Commit message (Collapse) | Author |
|---|
|
beacons configuration SHOULD be done only if the STA is associated.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Previously ath9k left the initialization of slot timing and ACK/CTS
timeout to the mode specific initvals. This does not handle short vs
long slot in 2.4 GHz and uses a rather strange value for the 2.4 GHz
ACK timeout (64 usec).
This patch uses the proper ath9k_hw functions for setting slot time and
timeouts and also implements the switch between short and long slot
time in 2.4 GHz
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Update the beacon queue parameters with best effort queue parameters for
IBSS mode. This reduces the number of beacons generated by ath9k and
ensures a fair beacon distribution when there are multiple IBSS stations.
Also CWmin is quadrupled to achieve the expected percentage of
distribution.
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This patch changes ath9k to pass proper MCS indexes and flags
between the RC and the rest of the driver code.
sc->cur_rate_table remains, as it's used by the RC code internally,
but the rest of the driver code no longer uses it, so a potential
new RC for ath9k would not have to update it.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
And move it to hw code on mac.c where it belongs.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
ath9k uses this for now, ath9k_htc is expected to re-use this
as well. We lave ath5k as is, but it certainly can also be
converted later.
The ath9k module parameter and debugfs entry is kept.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
When the TSF is reset power save state is disabled and
then restored. The helpers to disable power save and restore
it use a lock provided by the driver core. Move the callers
of the helpers outside of the hw code.
We reset the TSF when mac80211 tells us and on the beacon.c
helper ath9k_hw_beaconinit() when it is made explicitly required.
Add a helper on beacon.c which will deal with ps awake/restore
if we need to reset the TSF upon ath9k_hw_beaconinit().
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
DPRINTF() is used in hw specific related code, as such
ensure we don't rely on the private driver core ath_softc
struct when calling it. Drivers can then implement their
own DPRINTF() as they see fit.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This patch moves the sanity check on beacon interval
which was done only for mesh mode to all operating
modes just to be safe.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
It looks like mac80211 can request the driver to start beaconing with
a beacon interval of zero in some cases (at least for mesh point). This
does not sound correct and something may need to be fixed in
mac80211. However, taken into account the unpleasantness of getting
stuck in an infinite busy loop with rtnl_lock held, let's add a quick
workaround in the driver to avoid the worst symptom while someone more
familiar with the mesh implementation can figure out what should be done
with mac80211 as far as beacon interval configuration is concerned.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
I have a TrendNet 652-BRP running OpenWRT + ath9k very well. The only
problem is that the beacon gets stuck maybe once a day. After
Vasanthakumar Thiagarajan's "ath9k: cleanup beacon parameters
configuration" patch, ath9k would nearly re-configure the beacons after it
detected the stuck beacon, and did a reset. But it would fail the
SC_OP_TSF_RESET check in ath_beacon_config_ap. This patch gets the beacon
fully reconfigured after the reset.
Signed-off-by: Jeff Hansen <x@jeffhansen.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
The previous version used a simple loop to go through all Beacon
frames when determining the next TBTT and DTIM count. This is not too
bad for the case where the setup happens before timesync (i.e., very
small TSF), but this can become very heavy operation if a short Beacon
interval is used and the current TSF is large.
In preparation for a patch to update timer setup based on Beacon
timestamp, optimize this routine to take fixed time regardless of the
actual TSF value.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This patch configures the beacon timers with beacon interval
and beacon period passed through vif.bss_conf. Also cache the
currecnt beacon configuration which will be used to configure
the beacon timers when the driver triggers it after reset.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
On x86 this allows us to do the following small savings:
shave off 23 % off of the module's data, and
shave off 6 % off of the module's text.
We save 456 bytes, for those counting.
$ size ath9k.ko
text data bss dec hex filename
250794 3628 1600 256022 3e816 ath9k.ko
$ size ath9k-old.ko
text data bss dec hex filename
239114 15308 1600 256022 3e816 ath9k-old.ko
$ du -b ath9k.ko
4034244 ath9k.ko
$ du -b ath9k-old.ko
4033788 ath9k-old.ko
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
We currently have two beacon interval configuration knobs:
hw.conf.beacon_int and vif.bss_info.beacon_int. This is
rather confusing, even though the former is used when we
beacon ourselves and the latter when we are associated to
an AP.
This just deprecates the hw.conf.beacon_int setting in favour
of always using vif.bss_info.beacon_int. Since it touches all
the beaconing IBSS code anyway, we can also add support for
the cfg80211 IBSS beacon interval configuration easily.
NOTE: The hw.conf.beacon_int setting is retained for now due
to drivers still using it -- I couldn't untangle all
drivers, some are updated in this patch.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
