proper dma_unmapping and freeing of skb's has to be done in the rx
cleanup for EDMA chipsets when the device is unloaded and this also
seems to address the following warning which shows up occasionally when
the device is unloaded
Call Trace:
[<c0148cd2>] warn_slowpath_common+0x72/0xa0
[<c03b669c>] ? dma_debug_device_change+0x19c/0x200
[<c03b669c>] ? dma_debug_device_change+0x19c/0x200
[<c0148da3>] warn_slowpath_fmt+0x33/0x40
[<c03b669c>] dma_debug_device_change+0x19c/0x200
[<c0657f12>] notifier_call_chain+0x82/0xb0
[<c0171370>] __blocking_notifier_call_chain+0x60/0x90
[<c01713bf>] blocking_notifier_call_chain+0x1f/0x30
[<c044f594>] __device_release_driver+0xa4/0xc0
[<c044f647>] driver_detach+0x97/0xa0
[<c044e65c>] bus_remove_driver+0x6c/0xe0
[<c029af0b>] ? sysfs_addrm_finish+0x4b/0x60
[<c0450109>] driver_unregister+0x49/0x80
[<c0299f54>] ? sysfs_remove_file+0x14/0x20
[<c03c3ab2>] pci_unregister_driver+0x32/0x80
[<f92c2162>] ath_pci_exit+0x12/0x20 [ath9k]
[<f92c8467>] ath9k_exit+0x17/0x36 [ath9k]
[<c06523cd>] ? mutex_unlock+0xd/0x10
[<c018e27f>] sys_delete_module+0x13f/0x200
[<c02139bb>] ? sys_munmap+0x4b/0x60
[<c06547c5>] ? restore_all+0xf/0xf
[<c0657a20>] ? spurious_fault+0xe0/0xe0
[<c01832f4>] ? trace_hardirqs_on_caller+0xf4/0x180
[<c065b863>] sysenter_do_call+0x12/0x38
---[ end trace 16e1c1521c06bcf9 ]---
Mapped at:
[<c03b7938>] debug_dma_map_page+0x48/0x120
[<f92ba3e8>] ath_rx_init+0x3f8/0x4b0 [ath9k]
[<f92b5ae4>] ath9k_init_device+0x4c4/0x7b0 [ath9k]
[<f92c2813>] ath_pci_probe+0x263/0x330 [ath9k]
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
During the endurance testing, rx frames are not getting DMAd from
MAC whereas pcu rx frame counters are getting updated properly.
As per systems team input updated the initval to fix rx dma stuck
issue.
Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ADC calibrations cannot run on 5 GHz with fast clock enabled. They
need to be disabled, otherwise they'll hang and IQ mismatch calibration
will not be run either.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Reported-by: Adrian Chadd <adrian@freebsd.org>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The commit 172805ad46
overwirtes additional clock settings of AR9330 to
all AR9300 chips.
Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
this callback is called during suspend/resume and also via iw command.
it configures parameters like sifs, slottime, acktimeout in
ath9k_hw_init_global_settings where few REG_READ, REG_RMW are also done
and hence the need for PS wrappers
Cc: stable@kernel.org
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Due to some recent optimization done in the way the mac address
bytes are written into the OTP memory, some AR9485 chipsets were
forced to use the first byte from the eeprom template and the
remaining bytes are read from OTP.
AR9485 happens to use generic eeprom template which has 0x1 as
the first byte causes issues in bringing up the card.
So fixed the eeprom template accordingly to address the issue.
Cc: stable@kernel.org
Cc: Paul Stewart <pstew@google.com>
Signed-off-by: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch addresses an issue with incorrect HW register
AR_PHY_TX_IQCAL_CORR_COEFF_B1 definition which leads to incorrect clibration.
Cc: stable@kernel.org
Signed-off-by: Alex Hacker <hacker@epn.ru>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The commit ebefce3d13 failed
to set proper PMU value to address ripple issue for AR9485.
Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
CTL power data incorrect in ctlPowerData_2G field of ar9300_eeprom.
Setting incorrect CTL power in calibration is causing lower tx power.
Tx power was reported as 3dBm while operating in channel 6 HT40+/
in channel 11 HT40- due to CTL powers in the calibration is set to
zero.
Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We receive many bug reports about system hang during suspend/resume
when ath9k driver is in use. Adrian Chadd remarked that this problem
happens on systems that have ASPM disabled.
To do not hit the bug, skip doing ->config_pci_powersave magic if PCIe
downstream port device, which ath9k device is connected to, has ASPM
disabled.
Bug was introduced by:
commit 53bc7aa08b
Author: Vivek Natarajan <vnatarajan@atheros.com>
Date: Mon Apr 5 14:48:04 2010 +0530
ath9k: Add support for newer AR9285 chipsets.
Patch should address:
https://bugzilla.kernel.org/show_bug.cgi?id=37462https://bugzilla.kernel.org/show_bug.cgi?id=37082https://bugzilla.redhat.com/show_bug.cgi?id=697157
however I did not receive confirmation about that, except from Camilo
Mesias, whose system stops hang regularly with this patch (but still
hangs from time to time, but this is probably some other bug).
Tested-by: Camilo Mesias <camilo@mesias.co.uk>
Cc: stable@kernel.org # 2.6.35+
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
With an uninitialized chainmask, the per-channel power will only contain
the power limits for a single chain instead of the combined tx power.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Some devices (e.g. Ubiquiti AirRouter) ship with broken EEPROM chainmask
data, which breaks the initial calibration after a hardware reset.
To fix this, mask the eeprom chainmask with the chainmask of the chip,
and use the chip chainmask if the result is zero.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: "Luis R. Rodriguez" <lrodriguez@atheros.com>
Cc: ath9k-devel@lists.ath9k.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
For unicast the hardware sometimes reports MIC errors even though the
frame that it received actually contains a valid MIC - on some chips this
can happen frequently enough to trigger TKIP countermeasures.
Fix this issue by not reporting MIC errors for unicast frames with a
valid key, letting mac80211 validate the MIC instead.
Additionally, strip the MIC for all frames that the hardware considers
valid to avoid wasting CPU cycles re-validating it.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Decryping frames on key_miss handling shouldn't be done for Michael
MIC failed frames as h/w would have already decrypted such frames
successfully anyway.
Also leaving CRC and PHY error(where the frame is going to be dropped
anyway), we are left to prcoess Decrypt error for which s/w decrypt is
selected anway and so having key_miss as a separate check doesn't serve
anything. So making key_miss handling mutually exlusive with other RX
status handling makes much more sense.
This patch addresses an issue with STA not reporting MIC failure events
resulting in STA being disconnected immediately.
Cc: stable@kernel.org
Signed-off-by: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
AR_AN_SYNTH9 is in the analog shift register range and thus needs to be
written using the ath9k_hw_analog_shift_rmw function.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The radio needs twice / four times as much time to stabilize for half/quarter
channels.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Now that the clock rate is initialized properly and SIFS, EIFS, USEC,
slot time and ACK timeout are properly calculated by the generic code,
the 'async FIFO' register hacks are no longer necessary.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Initialize the the clock-to-TSF field of AR_USEC and the SIFS and EIFS time
registers based on the clock rate instead of relying on initvals.
With those changes, some of the hardcoded AR9287 1.3+ specific overrides
can be dropped.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This chip uses the async FIFO feature and runs the MAC at 117 MHz
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Enabling half/quarter rate makes the MAC run at half/quarter clock speed.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
All devices support this, but some disable it using an EEPROM flag
for some reason. Improves 5 GHz performance on those devices.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use the proper masks for the register instead.
Fixes adding the (still unused) half/quarter PLL flags.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch removes read only registers that cause invalid
address access and also updates index for measurement filter
calibration window size.
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The power detector calibration is disabled because this block
doesn't exist in AR9003 based chips and also parallel
calibration is enabled otherwise the calibration will never stop.
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The number of temperature reading samples to average
during a Tx packet is decreased to 1 from 2 to improve
5G Tx EVM with chain 0-only mode.
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
While sending aggregated frames in AES, the AR5416 chips
required additional padding b/w subframes. This workaround
is not needed for edma (AR9003 family) chips. With this patch
~4Mbps thoughput improvement was observed in clear environment.
Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When no interface has been brought up, the chip's power
state continued as AWAKE. So during resume, the chip never
been powered up.
Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The received tx status of aggregated frame without BlockAck may
cause deaf state in AR5416 cards. So the driver does a reset to
recover. When this happens, we release the pcu_lock before doing
a reset as ath_rest acquires pcu_lock. This is ugly and also not
atomic. Fixing this addresses the TX DMA failure also.
ath_tx_complete_aggr can be called from different paths which
takes different variants of spin_lock. This patch also addresses
the following warning.
WARNING: at kernel/timer.c:1011 del_timer_sync+0x4e/0x50()
Call Trace:
<IRQ> [<ffffffff8104be3a>] warn_slowpath_common+0x7a/0xb0
[<ffffffff8104be85>] warn_slowpath_null+0x15/0x20
[<ffffffff8105915e>] del_timer_sync+0x4e/0x50
[<ffffffffa03726be>] ath_reset+0x3e/0x210 [ath9k]
[<ffffffff8135cdaf>] ? _raw_spin_unlock_bh+0x1f/0x30
[<ffffffffa037760a>] ath_tx_complete_aggr.isra.26+0x54a/0xa40 [ath9k]
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
