It does not work properly and reduces throughput.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The delay calculation is the same for all chips, however some parts of the
code missed the extra delay factor for half/quarter.
Clean up the code and move the delay calculation to a common place.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
For some reason the MAC timing is a bit off when waiting for ACKs, so add
some extra delay to the ACK timeout values. Significantly reduces the
number of retransmissions in my tests.
Also disable the 2.4 GHz ACK timeout workaround in half/quarter mode, it
is not required there.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
AR9462 uses modified version of 3-Wire hw scheme for btcoex.
MCI itself is not a separate hw scheme but it aids to manage
multiple bt profiles. In ar9462, bt priority traffic is identified
by the number of bt profile types instead of gpio. So that this
patch removes MCI hw scheme.
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
As of now beacon configuration is being called multiple times
in bss info change notification. This patch avoids multiple
configuration and make it simpler.
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This adds locking of the detector's shared pulse and PRI sequence
pools to enable multi-wiphy operation on SMP systems.
Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Without it, I get compile errors due to missing TASK_NORMAL,
TASK_UNINTERRUPTIBLE and schedule.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Since the RX path on USB devices is handled in process context we can
use GFP_KERNEL for RX buffer allocation. This should reduce the
likelihood of allocation failures.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Tested-By: Marc Dietrich <marvin24@gmx.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We're already using BBP for values > 128. Make that explicit and allow
debugfs access.
Signed-off-by: Anisse Astier <anisse@astier.eu>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch supports Avastar 88W8797 chipset with USB interface.
The corresponding firmware image file is located at:
"mrvl/usb8797_uapsta.bin"
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Kiran Divekar <dkiran@marvell.com>
Signed-off-by: Frank Huang <frankh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The current code unconditionally reads the target
power values for all modes from the EEPROM. However
In 'ar9003_hw_set_power_per_rate_table' the regulatory
caps are applied only on a mode specific subset of the
power values.
The reported TX power level is calculated from the
maximum of the power values. Because some of these
values are uncapped in certain cases, the reported
TX power will be wrong.
On the older chipset, we don't have such problems
because only the mode specific subset of the power
levels are retrieved from the EEPROM on those. Do
the same for the AR9003 chips to fix the issue.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Daniel Drake <dsd@laptop.org>
Tested-by: Dan Williams <dcbw@redhat.com>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This fixes two compile warnings, and removes a useless
cast when assigning the 'sc' variable.
Reported-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
found in 2012_03_22_RT5572_Linux_STA_v2.6.0.0_DPO
RT3070:
(0x2019,0x5201) Planex Communications, Inc. RT8070
(0x7392,0x4085) 2L Central Europe BV 8070
7392 is Edimax
RT35xx:
(0x1690,0x0761) Askey
was Fujitsu Stylistic 550, but 1690 is Askey
Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
I keep getting the following messages on the log buffer:
[ 2167.097507] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU
[ 2281.331305] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU
[ 2281.332539] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU
[ 2329.876605] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU
[ 2329.877354] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU
[ 2462.280756] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU
[ 2615.651689] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU
From the code comment I understand that this something that can -
and does, quite frequently - happen.
Signed-off-by: Eldad Zack <eldad@fogrefinery.com>
Acked-by: Franky Lin<frankyl@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Driver incorrectly validates command completion: instead of waiting
for a command to be acknowledged it continues execution. Most of the
time driver gets acknowledge of the command completion in a tasklet
before it executes the next one. But sometimes it sends the next
command before it gets acknowledge for the previous one. In such a
case one of the following error messages appear in the log:
Failed to send SYSTEM_CONFIG: Already sending a command.
Failed to send ASSOCIATE: Already sending a command.
Failed to send TX_POWER: Already sending a command.
After that you need to reload the driver to get it working again.
This bug occurs during roaming (reported by Sam Varshavchik)
https://bugzilla.redhat.com/show_bug.cgi?id=738508
and machine booting (reported by Tom Gundersen and Mads Kiilerich)
https://bugs.archlinux.org/task/28097https://bugzilla.redhat.com/show_bug.cgi?id=802106
This patch doesn't fix the delay issue during firmware load.
But at least device now works as usual after boot.
Cc: stable@kernel.org
Signed-off-by: Stanislav Yakovlev <stas.yakovlev@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ctx->vif is dereferenced in different part of iwlwifi code, so do not
nullify it.
This should address at least one of the possible reasons of WARNING at
iwlagn_mac_remove_interface, and perhaps some random crashes when
firmware reset is performed.
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The 'ath9k_hw_update_regulatory_maxpower'
helper function has been introduced by
commit a55f858852
(ath9k_hw: Cleanup TX power calculation for AR9287).
Updating of the max_power_level value has been moved
into the helper function in that change, however the
removed code from 'ath9k_hw_ar9287_set_txpower' has
not been replaced with a call of the new helper
function.
Due to that missing call, retrieving tx power for 2x2
and 3x3 chainmask is not handled properly. During the
calculation of the tx power for 2x2 and 3x3 chainmasks
the values are reduced. Those reductions must be
compensated during retrieving.
Fix this by adding the missing call of the helper
function.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In order to unifying regulatory limit handling
commit ca2c68cc7b
(ath9k_hw: clean up tx power handling) introduced
a new helper function 'ath9k_hw_apply_txpower',
and the direct calls of 'ah->eep_ops->set_txpower'
has been replaced by a call of the helper function.
This caused a change in the behaviour of the
'ath9k_hw_set_txpowerlimit' function. The purpose
of that function is to calculate and store the
rate txpower table and the regulatory limit without
touching the hardware registers. Before the commit,
the 'test' parameter of the function was passed to
the 'ah->eep_ops->set_txpower'. Now the calling of
the 'set_txpower' function happens indirectly through
'ath9k_hw_apply_txpower', so the 'test' argument of
the 'set_txpower' is always 'false'.
This patch restores the original behaviour of
'ath9k_hw_set_txpowerlimit' by adding a new
argument to 'ath9k_hw_apply_txpower.'
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The iwmc3200 driver selects other code in Kconfig that depends on
EXPERIMENTAL. Kconfig warns about this when CONFIG_EXPERIMENTAL
is not already set, so logically, these options should also
be marked experimental or promoted to stable.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Drivers that refer to a __devexit function in an operations
structure need to annotate that pointer with __devexit_p so
replace it with a NULL pointer when the section gets discarded.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Remove declaration of iwl_alloc_traffic_mem from iwl-agn.h,
from methods that was exposed to support MVM.
MVM doesn't have to use this declaration.
CC: netdev@vger.kernel.org
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
It can be moved to iwl-dev.h since it is op_mode specific.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Having cmd[], meta[] and skbs[] as separate arrays
in the TX queue structure is cache inefficient as
we need the data for a given entry together.
To improve this, create an array with these three
members (allocate meta as part of that struct) so
we have the data we need together located together
improving cache footprint.
The downside is that we need to allocate a lot of
memory in one chunk, about 10KiB (on 64-bit) which
isn't very efficient.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
This allows not to notify the transport about aggregation stopped
while aggregation haven't been started.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Remove declaration of iwl_alloc_traffic_mem from iwl-agn.h,
from methods that was exposed to support MVM.
MVM doesn't have to use this declaration.
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Please merge this with "iwlwifi: op_mode holds its pointer
to the config"
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Changed disable calibration bit field defines to enum.
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Each modules will hold a pointer to struct device instead.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Instead of using the shared area that we be killed.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Instead of using the shared area that we be killed.
Remove the pointer to config from shared since it is not
used any more.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Instead of using the shared area that will be killed.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Instead of using the shared area that we be killed.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Instead of using the shared area that we be killed.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
The driver layer now holds a pointer to the transport,
and shrd->drv is not needed any more, so kill it.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
We get two timing related fields for each bss from firmware in scan
results.
1) timestamp - Actual timestamp information in probe response/beacon
2) network_tsf - firmware's TSF value at the time the beacon or probe
response was received.
Both are needed while associating by firmware.
The patch takes care of following things.
1) We should pass "timestamp" to cfg80211_inform_bss(), but currently
"network_tsf" is being provided. This error is corrected here.
2) Rename "network_tsf" to "fw_tsf"
3) Make use of u64 variable instead of an array of u8/u32 to save
parsed "timestamp" information.
4) Use timestamp provided to stack in scan results using
cfg80211_inform_bss() while associating. (bss->tsf)
5) Allocate space to save fw_tsf in "priv" of cfg80211_bss
and retrieve it while associating.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Rearrange some code to save extra parameters to the functions.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
