Commit 3a2923e83c introduced a bug when a corrupt descriptor
is encountered - although the following descriptor is discarded
and returned to the queue for reuse the associated frame is
also returned for processing. This leads to a panic:
BUG: unable to handle kernel NULL pointer dereference at 000000000000003a
IP: [<ffffffffa02599a5>] ath_rx_tasklet+0x165/0x1b00 [ath9k]
Call Trace:
<IRQ>
[<ffffffff812d7fa0>] ? map_single+0x60/0x60
[<ffffffffa028f044>] ? ath9k_ioread32+0x34/0x90 [ath9k]
[<ffffffffa0292eec>] athk9k_tasklet+0xdc/0x160 [ath9k]
[<ffffffff8105e133>] tasklet_action+0x63/0xd0
[<ffffffff8105dbc0>] __do_softirq+0xc0/0x1e0
[<ffffffff8101a873>] ? native_sched_clock+0x13/0x80
[<ffffffff815f9d5c>] call_softirq+0x1c/0x30
[<ffffffff810151f5>] do_softirq+0x75/0xb0
[<ffffffff8105df95>] irq_exit+0xb5/0xc0
[<ffffffff815fa5b3>] do_IRQ+0x63/0xe0
[<ffffffff815f0cea>] common_interrupt+0x6a/0x6a
<EOI>
[<ffffffff8131840a>] ? intel_idle+0xea/0x150
[<ffffffff813183eb>] ? intel_idle+0xcb/0x150
[<ffffffff814a1db9>] cpuidle_enter+0x19/0x20
[<ffffffff814a23d9>] cpuidle_idle_call+0xa9/0x240
[<ffffffff8101c4bf>] cpu_idle+0xaf/0x120
[<ffffffff815cda8e>] rest_init+0x72/0x74
[<ffffffff81cf4c1a>] start_kernel+0x3b7/0x3c4
[<ffffffff81cf4662>] ? repair_env_string+0x5e/0x5e
[<ffffffff81cf4346>] x86_64_start_reservations+0x131/0x135
[<ffffffff81cf444a>] x86_64_start_kernel+0x100/0x10f
Making sure bf is cleared to NULL in this case restores the
old behaviour.
Signed-off-by: Tom Hughes <tom@compton.nu>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
commit 7a532fe713
ath9k_hw: fix interpretation of the rx KeyMiss flag
This commit used the rx key miss indication to detect packets that were
passed from the hardware without being decrypted, however it seems that
this bit is not only undefined in the static WEP case, but also for
dynamically allocated WEP keys. This caused a regression when using
WEP-LEAP.
This patch fixes the regression by keeping track of which key indexes
refer to CCMP keys and only using the key miss indication for those.
Reported-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
After the change "mac80211: remove spurious BSSID change flag",
BSS_CHANGED_BSSID will not be passed on association or IBSS
status changes. So it could be better to program bssid on ASSOC
or IBSS change notification. Not doing so, is affecting the
packet transmission.
Cc: stable@vger.kernel.org [3.4+]
Reported-by: Michael Leun <lkml20120218@newton.leun.net>
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
"ath9k: Fix softlockup in AR9485" with commit id
64bc1239c7 fixed the reported
issue, yet its better to avoid the possible infinite loop
in ar9003_get_pll_sqsum_dvc by having a timeout as suggested
by ath9k maintainers.
http://www.spinics.net/lists/linux-wireless/msg92126.html.
Based on my testing PLL's locking measurement is done in
~200us (2 iterations).
Cc: stable@vger.kernel.org
Cc: Rolf Offermanns <rolf.offermanns@gmx.net>
Cc: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
spin_unlock_bh(&txq->lock) already disables softirqs so we don't want
to do it here. Fixes smatch warnings:
drivers/net/wireless/ath/ath5k/base.c:1048 ath5k_drain_tx_buffs() error: double lock 'bottom_half:'
drivers/net/wireless/ath/ath5k/base.c:1056 ath5k_drain_tx_buffs() error: double unlock 'bottom_half:'
Reported-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
After setup_frame_info has been called, only info->control.rates is still
valid, other control fields have been overwritten by the ath_frame_info
data. Move the access to info->control.vif for checking short preamble
to setup_frame_info before it gets overwritten.
This regression was introduced in commit d47a61aa
"ath9k: Fix multi-VIF BSS handling"
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Reported-by: Thomas Hühn <thomas@net.t-labs.tu-berlin.de>
Acked-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Cc: stable@vger.kernel.org [3.4]
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The rate pointer variable for a rate series is used in a loop before it is
initialized. This went unnoticed because it was used earlier for the RTS/CTS
rate. This bug can lead to the wrong PHY type being passed to the
duration calculation function.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
steps to recreate:
load latest ath9k driver with AR9485
stop the network-manager and wpa_supplicant
bring the interface up
Call Trace:
[<ffffffffa0517490>] ? ath_hw_check+0xe0/0xe0 [ath9k]
[<ffffffff812cd1e8>] __const_udelay+0x28/0x30
[<ffffffffa03bae7a>] ar9003_get_pll_sqsum_dvc+0x4a/0x80 [ath9k_hw]
[<ffffffffa05174eb>] ath_hw_pll_work+0x5b/0xe0 [ath9k]
[<ffffffff810744fe>] process_one_work+0x11e/0x470
[<ffffffff8107530f>] worker_thread+0x15f/0x360
[<ffffffff810751b0>] ? manage_workers+0x230/0x230
[<ffffffff81079af3>] kthread+0x93/0xa0
[<ffffffff815fd3a4>] kernel_thread_helper+0x4/0x10
[<ffffffff81079a60>] ? kthread_freezable_should_stop+0x70/0x70
[<ffffffff815fd3a0>] ? gs_change+0x13/0x13
ensure that the PLL-WAR for AR9485/AR9340 is executed only if the STA is
associated (or) IBSS/AP mode had started beaconing. Ideally this WAR
is needed to recover from some rare beacon stuck during stress testing.
Before the STA is associated/IBSS had started beaconing, PLL4(0x1618c)
always seem to have zero even though we had configured PLL3(0x16188) to
query about PLL's locking status. When we keep on polling infinitely PLL4's
8th bit(ie check for PLL locking measurements is done), machine hangs
due to softlockup.
fixes https://bugzilla.redhat.com/show_bug.cgi?id=811142
Reported-by: Rolf Offermanns <rolf.offermanns@gmx.net>
Cc: stable@vger.kernel.org [3.0+]
Tested-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
'cfg80211: fix interface combinations' ensures that if an interface
type is not advertised by the driver in any of the interface combinations
(via ieee80211_iface_combination) then it shall be treated as a single
incompatible interface. if there are more than one interfaces present
and changing them to incompatible interface type is not possible.
These checks will be properly handled by cfg80211_change_iface ->
cfg80211_can_change_interface.
this patch is dependent on 'cfg80211: fix interface combinations'
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
this patch is dependent on the patch "cfg80211: fix interface
combinations"
In ath9k currently we have ADHOC interface as a single incompatible
interface. when drv_add_interface is called during resume we got to
consider number of vifs already present in addition to checking the
drivers 'opmode' information about ADHOC. we incorrectly assume
an ADHOC interface is already present. Then we may miss some driver
specific data for the ADHOC interface after resume.
The above mentioned checks can be removed from the driver,
as the patch 'cfg80211: fix interface combinations' ensures that
if an interface type is not advertised by the driver in any of the
interface combinations(via ieee80211_iface_combination) then it shall
be treated as a single incompatible interface. Fixes the following
warning on suspend/resume with ibss interface.
ath: phy0: Cannot create ADHOC interface when other
interfaces already exist.
WARNING: at net/mac80211/driver-ops.h:12
ieee80211_reconfig+0x1882/0x1ca0 [mac80211]()
Hardware name: 2842RK1
wlan2: Failed check-sdata-in-driver check, flags: 0x0
Call Trace:
[<c01361b2>] warn_slowpath_common+0x72/0xa0
[<f8aaa7c2>] ? ieee80211_reconfig+0x1882/0x1ca0
[mac80211]
[<f8aaa7c2>] ? ieee80211_reconfig+0x1882/0x1ca0
[mac80211]
[<c0136283>] warn_slowpath_fmt+0x33/0x40
[<f8aaa7c2>] ieee80211_reconfig+0x1882/0x1ca0 [mac80211]
[<c06c1d1a>] ? mutex_lock_nested+0x23a/0x2f0
[<f8a95097>] ieee80211_resume+0x27/0x70 [mac80211]
[<fd177edf>] wiphy_resume+0x8f/0xa0 [cfg80211]
Cc: stable@vger.kernel.org
Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On AR933x, the internal regulator settings need to be applied before the
PLL init to avoid stability issues.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
"> Can you provide more information about the issues with high power devices?
Tx being flakey and Rx not working at all."
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath_tx_setup_buffer() can fail if there is no ath_buf left, or if mapping DMA
failed. In this case it frees the skb passed to it.
If ath_tx_setup_buffer is called from ath_tx_form_aggr, the skb is still
linked into the tid buffer list and must be dequeued before being released.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It has been found that active Rx can interfere with stopping tx DMA, which
could result in at least parts of those "Failed to stop Tx DMA!" messages.
Stopping rx before tx should prevent that.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Pull more networking updates from David Miller:
"Ok, everything from here on out will be bug fixes."
1) One final sync of wireless and bluetooth stuff from John Linville.
These changes have all been in his tree for more than a week, and
therefore have had the necessary -next exposure. John was just away
on a trip and didn't have a change to send the pull request until a
day or two ago.
2) Put back some defines in user exposed header file areas that were
removed during the tokenring purge. From Stephen Hemminger and Paul
Gortmaker.
3) A bug fix for UDP hash table allocation got lost in the pile due to
one of those "you got it.. no I've got it.." situations. :-)
From Tim Bird.
4) SKB coalescing in TCP needs to have stricter checks, otherwise we'll
try to coalesce overlapping frags and crash. Fix from Eric Dumazet.
5) RCU routing table lookups can race with free_fib_info(), causing
crashes when we deref the device pointers in the route. Fix by
releasing the net device in the RCU callback. From Yanmin Zhang.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (293 commits)
tcp: take care of overlaps in tcp_try_coalesce()
ipv4: fix the rcu race between free_fib_info and ip_route_output_slow
mm: add a low limit to alloc_large_system_hash
ipx: restore token ring define to include/linux/ipx.h
if: restore token ring ARP type to header
xen: do not disable netfront in dom0
phy/micrel: Fix ID of KSZ9021
mISDN: Add X-Tensions USB ISDN TA XC-525
gianfar:don't add FCB length to hard_header_len
Bluetooth: Report proper error number in disconnection
Bluetooth: Create flags for bt_sk()
Bluetooth: report the right security level in getsockopt
Bluetooth: Lock the L2CAP channel when sending
Bluetooth: Restore locking semantics when looking up L2CAP channels
Bluetooth: Fix a redundant and problematic incoming MTU check
Bluetooth: Add support for Foxconn/Hon Hai AR5BBU22 0489:E03C
Bluetooth: Fix EIR data generation for mgmt_device_found
Bluetooth: Fix Inquiry with RSSI event mask
Bluetooth: improve readability of l2cap_seq_list code
Bluetooth: Fix skb length calculation
...
Here is the big USB 3.5-rc1 pull request for the 3.5-rc1 merge window.
It's touches a lot of different parts of the kernel, all USB drivers,
due to some API cleanups (getting rid of the ancient err() macro) and
some changes that are needed for USB 3.0 power management updates.
There are also lots of new drivers, pimarily gadget, but others as well.
We deleted a staging driver, which was nice, and finally dropped the
obsolete usbfs code, which will make Al happy to never have to touch
that again.
There were some build errors in the tree that linux-next found a few
days ago, but those were fixed by the most recent changes (all were due
to us not building with CONFIG_PM disabled.)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEABECAAYFAk+7qs0ACgkQMUfUDdst+ymjOgCfeoWqWk1bsKKt6SZULvQois5i
3csAn1Uapcm8Uswwpnj2v1/2Zh4rBHLA
=4jM1
-----END PGP SIGNATURE-----
Merge tag 'usb-3.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB 3.5-rc1 changes from Greg Kroah-Hartman:
"Here is the big USB 3.5-rc1 pull request for the 3.5-rc1 merge window.
It's touches a lot of different parts of the kernel, all USB drivers,
due to some API cleanups (getting rid of the ancient err() macro) and
some changes that are needed for USB 3.0 power management updates.
There are also lots of new drivers, pimarily gadget, but others as
well. We deleted a staging driver, which was nice, and finally
dropped the obsolete usbfs code, which will make Al happy to never
have to touch that again.
There were some build errors in the tree that linux-next found a few
days ago, but those were fixed by the most recent changes (all were
due to us not building with CONFIG_PM disabled.)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>"
* tag 'usb-3.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (477 commits)
xhci: Fix DIV_ROUND_UP compile error.
xhci: Fix compile with CONFIG_USB_SUSPEND=n
USB: Fix core compile with CONFIG_USB_SUSPEND=n
brcm80211: Fix compile error for .disable_hub_initiated_lpm.
Revert "USB: EHCI: work around bug in the Philips ISP1562 controller"
MAINTAINERS: Add myself as maintainer to the USB PHY Layer
USB: EHCI: fix command register configuration lost problem
USB: Remove races in devio.c
USB: ehci-platform: remove update_device
USB: Disable hub-initiated LPM for comms devices.
xhci: Add Intel U1/U2 timeout policy.
xhci: Add infrastructure for host-specific LPM policies.
USB: Add macros for interrupt endpoint types.
xhci: Reserve one command for USB3 LPM disable.
xhci: Some Evaluate Context commands must succeed.
USB: Disable USB 3.0 LPM in critical sections.
USB: Add support to enable/disable USB3 link states.
USB: Allow drivers to disable hub-initiated LPM.
USB: Calculate USB 3.0 exit latencies for LPM.
USB: Refactor code to set LPM support flag.
...
Conflicts:
arch/arm/mach-exynos/mach-nuri.c
arch/arm/mach-exynos/mach-universal_c210.c
drivers/net/wireless/ath/ath6kl/usb.c
Hub-initiated LPM is not good for USB communications devices. Comms
devices should be able to tell when their link can go into a lower power
state, because they know when an incoming transmission is finished.
Ideally, these devices would slam their links into a lower power state,
using the device-initiated LPM, after finishing the last packet of their
data transfer.
If we enable the idle timeouts for the parent hubs to enable
hub-initiated LPM, we will get a lot of useless LPM packets on the bus
as the devices reject LPM transitions when they're in the middle of
receiving data. Worse, some devices might blindly accept the
hub-initiated LPM and power down their radios while they're in the
middle of receiving a transmission.
The Intel Windows folks are disabling hub-initiated LPM for all USB
communications devices under a xHCI USB 3.0 host. In order to keep
the Linux behavior as close as possible to Windows, we need to do the
same in Linux.
Set the disable_hub_initiated_lpm flag for for all USB communications
drivers. I know there aren't currently any USB 3.0 devices that
implement these class specifications, but we should be ready if they do.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: Hansjoerg Lipp <hjlipp@web.de>
Cc: Tilman Schmidt <tilman@imap.cc>
Cc: Karsten Keil <isdn@linux-pingi.de>
Cc: Peter Korsgaard <jacmet@sunsite.dk>
Cc: Jan Dumon <j.dumon@option.com>
Cc: Petko Manolov <petkan@users.sourceforge.net>
Cc: Steve Glendinning <steve.glendinning@smsc.com>
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Cc: "Luis R. Rodriguez" <mcgrof@qca.qualcomm.com>
Cc: Jouni Malinen <jouni@qca.qualcomm.com>
Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Cc: Christian Lamparter <chunkeey@googlemail.com>
Cc: Brett Rudley <brudley@broadcom.com>
Cc: Roland Vossen <rvossen@broadcom.com>
Cc: Arend van Spriel <arend@broadcom.com>
Cc: "Franky (Zhenhui) Lin" <frankyl@broadcom.com>
Cc: Kan Yan <kanyan@broadcom.com>
Cc: Dan Williams <dcbw@redhat.com>
Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Cc: Ivo van Doorn <IvDoorn@gmail.com>
Cc: Gertjan van Wingerde <gwingerde@gmail.com>
Cc: Helmut Schaa <helmut.schaa@googlemail.com>
Cc: Herton Ronaldo Krzesinski <herton@canonical.com>
Cc: Hin-Tak Leung <htl10@users.sourceforge.net>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Chaoming Li <chaoming_li@realsil.com.cn>
Cc: Daniel Drake <dsd@gentoo.org>
Cc: Ulrich Kunitz <kune@deine-taler.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch fixes multiple issues with the current RTT
implementation in ath9k.
* The data that is obtained from the RTT interface registers
are stored in 31:5 - mask out the extra bits when reading them.
* A history buffer is maintained which is not needed at all.
Remove this array and just store the baseband data for each
chain (or bank).
* A 'num_readings' variable was being used to handle the
last entry. But it was being used in an improper manner, with
the result that the RTT values were never being written
to the RTT Interface registers. Fix this by using a simple
flag.
* Stop baseband operations before programming the calibration values
to the HW.
* Do not restore RX gain settings as part of RTT.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use the new bool function ether_addr_equal to add
some clarity and reduce the likelihood for misuse
of compare_ether_addr for sorting.
Done via cocci script:
$ cat compare_ether_addr.cocci
@@
expression a,b;
@@
- !compare_ether_addr(a, b)
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- compare_ether_addr(a, b)
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- !ether_addr_equal(a, b) == 0
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- !ether_addr_equal(a, b) != 0
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- ether_addr_equal(a, b) == 0
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- ether_addr_equal(a, b) != 0
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- !!ether_addr_equal(a, b)
+ ether_addr_equal(a, b)
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Conflicts:
drivers/net/ethernet/intel/e1000e/param.c
drivers/net/wireless/iwlwifi/iwl-agn-rx.c
drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c
drivers/net/wireless/iwlwifi/iwl-trans.h
Resolved the iwlwifi conflict with mainline using 3-way diff posted
by John Linville and Stephen Rothwell. In 'net' we added a bug
fix to make iwlwifi report a more accurate skb->truesize but this
conflicted with RX path changes that happened meanwhile in net-next.
In e1000e a conflict arose in the validation code for settings of
adapter->itr. 'net-next' had more sophisticated logic so that
logic was used.
Signed-off-by: David S. Miller <davem@davemloft.net>
Send the EAPOL and management frames in the same AC_VO queue. The issue
happens when the AP supports QOS, the management frames are sent to AC_VO
queue and EAP frame goes to AC_BE queue. Even though the EAP frame is
queued before the DEAUTH management frame, as they are queued on different
h/w queues, order of delivery between these frames cannot be controlled.
This fixes the connection failure seen in P2P case.
Signed-off-by: Vivek Natarajan <nataraja@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
This reverts commit a844adfd7b.
The commit a844adfd is degrading rx sensitivity of lower rate in
HT40 mode and it is confirmed that reverting the change is
improving rx sensitivity.
spur_freq_sd (for self-corr in AGC) is defined with respect to the
center of each 20MHz channel while spur_phase_delta (for self-corr
in Rx and spur data filter) is defined with respect to the center
of current RF channel.
So in short, we need to subtract spur_freq_sd (for self-corr in AGC)
by the offset between the center of primary20 and the center of RF
channel in SW. This offset could be +/10 MHz for dynamic 40.
Cc: Madhan Jaganathan <madhanj@qca.qualcomm.com>
Signed-off-by: Kai Shi <kaishi@qca.qualcomm.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Return status of ath6kl_htc_tx_issue() is ignored in
ath6kl_htc_tx_from_queue(), but failed tx packet is
is not cleaned up. To fix memory leak in this case, call
completion with error. Also, throw an error debug message
when tx fails in ath6kl_sdio_write_async() due to shortage
in bus request buffer.
kvalo: change the error message to WARN_ON_ONCE()
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
There are few cases where the tx skb is dropped but netstats is
not updated, fix this.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
When our driver device is removed on the AHB bus, our IO memory is never unmapped.
Signed-off-by: Jonathan Bither <jonbither@gmail.com>
Reviewed-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On the htc mbox layer, it will assign each endpoint (AC) with a
different Tx-packet-drop threshold, so lower priority AC is more
likely to drop packets and the cookies become more available to higher
priority AC.
On the htc pipe layer, assign the tx packet drop threshold as well, it
will let AC to drop packets when cookies below the tx packet drop
threshold.
Signed-off-by: Kevin Fang <kevin.fang@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
When a STA sends huge BK QoS data frame first and then sends BE/VI/VO
QoS data frame, the corresponding throughput becomes much lower than
that without sends BK QoS data frame before.
The root cause is that when station send BK stream, the tx credits of
BK stream don't return back to higher priority QoS stream such as BE,
VI, and VO stream. This patch will handle BK stream properly, when
there is higher priority QoS stream, it will seek tx credits from BK
stream properly.
Signed-off-by: Kevin Fang <kevin.fang@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
bss filter is configured to allow the frames from all the bss other
than the currenly connected one, this is done when a scan is requested
in connected state. There is no reason to filter out the currently
connected bss, configure the filter to allow all the bss. This would
fix the reporting of stale rssi of the current bss while scanning.
Reported-by: Naveen singh <navesing@qca.qualcomm.com>
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
With firmwares which do not support rsn capability override
(ATH6KL_FW_CAPABILITY_RSN_CAP_OVERRIDE) from host would
cause 4-way handshake failure when HT cap is advertised.
To fix this, do not advertise HT cap with cfg80211 for
those fw.
kvalo: fix a checkpatch warning
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
This patch enables all multicast packets in non suspend mode
and enable multicast filtering in wow suspend mode. This also
fixes a bug in multicast where the driver assumed disable
multicast-all command disabled/filtered all multicast
packets, which was wrong assumption, because firmware will
apply the programmed filter.
Multicast requirements
- Enable forward all multicast packets(no filtering) in
non suspend mode.
- Enable multicast filtering in wow suspend mode for both
AP and CLIENT.
kvalo: fix a checkpatch warning and drop unrelated newline removal
Signed-off-by: Naveen Gangadharan <ngangadh@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The patch "ath6kl: support fw reporting phy capabilities" gave the
firmware the ability to disable certain wiphy supported bands. Check if
this is the case in ath6kl_wmi_beginscan_cmd to avoid dereferencing a
NULL pointer.
kvalo: change the patch so that there's no code between declarations
Signed-off-by: Thomas Pedersen <c_tpeder@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Do not assume anyone before us includes it for us.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* PS_WAIT_FOR_TX_ACK is used in network-sleep mode and checking
it for handling IDLE transitions is incorrect. Fix this.
* RX PCU/DMA engines have to be stopped before setting the chip into
full-sleep mode - otherwise the chip becomes mute.
* Make things a bit clear by checking explicitly for network-sleep
mode in the tx() routine and add a couple of debug statements
to aid PS debugging.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fix merge between commit 3adadc08cc ("net ax25: Reorder ax25_exit to
remove races") and commit 0ca7a4c87d ("net ax25: Simplify and
cleanup the ax25 sysctl handling")
The former moved around the sysctl register/unregister calls, the
later simply removed them.
With help from Stephen Rothwell.
Signed-off-by: David S. Miller <davem@davemloft.net>
Extend debugfs entry for dfs_stats with DFS detection events
and shared pool statistics.
Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fix the following bug: in tkip mode, qos-null ps on/off packets
are dropped due to incorrect packet length so that ath9k softap
can't handle powersave state transition of peer STA correctly.
Signed-off-by: Michael Liang <mliang@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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>
Tom Hughes