When driver fail to reset card ah->curchan value stay NULL. When
later driver try to update tx power it oops by using ah->curchan
(calltrace is shown below).
This problem were reported at various places and for some it was
fixed by making ath9k_hw_chip_reset() do not fail. I have this bug
report on some oldish RHEL kernel with AR9285, however it's hard to
debug where reset fail when kernel OOPS, so I think this patch
should be applied. Hopefully ah->curchan is not used unconditionally
on other places until is initialized on ath9k_config().
ath: phy0: Chip reset failed
ath: phy0: Unable to reset hardware; reset status -22 (freq 2412 MHz)
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<f8a35585>] ath9k_hw_set_txpowerlimit+0x25/0x80 [ath9k_hw]
Oops: 0000 [#1] SMP
<snip>
Call Trace:
[<f8aac1aa>] ? ath9k_cmn_update_txpow+0x1a/0x30 [ath9k_common]
[<f8cf4f4e>] ? ath_complete_reset+0x4e/0x130 [ath9k]
[<f8cf54d7>] ? ath9k_start+0x127/0x1e0 [ath9k]
[<f8c2e52f>] ? ieee80211_do_open+0x30f/0x910 [mac80211]
[<c07bd96d>] ? dev_open+0x8d/0xf0
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The array field eeprom_data in struct th9k_platform_data
is a fixed size array so it can never be NULL.
Addresses-Coverity-ID: 1364903
Cc: Arend Van Spriel <arend.vanspriel@broadcom.com>
Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Somehow I missed this in my RX rate cleanup series, causing some
drivers to not report correct bandwidth since this flag isn't
used by mac80211 anymore. Fix this, and make hwsim also report
higher bandwidths appropriately.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Quite a lot of patches for rtlwifi and iwlwifi this time, but changes
also for other active wireless drivers.
Major changes:
ath9k
* add support for Dell Wireless 1601 PCI device
* add debugfs file to manually override noise floor
ath10k
* bump up FW API to 6 for a new QCA6174 firmware branch
wil6210
* support 8 kB RX buffers
iwlwifi
* work to support A000 devices continues
* add support for FW API 30
* add Geographical and Dynamic Specific Absorption Rate (SAR) support
* support a few new PCI device IDs
rtlwifi
* work on adding Bluetooth coexistance support, not finished yet
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJY+cipAAoJEG4XJFUm622b+04H/2u7zhIqv3R5NsmGRlwjKmvd
6us1hcYzUiBW1kBFFtcvokwgqv3Rw/EUi+NYA5UCHgo30HTVJWTqW0q+BUEI7U0X
iwuFdHbs/qjj8hXKgZwaJMVyRhXAbq+iHYaMY5OEDNTRSbxqXA4V69SHGK9vLX0l
KQLJBZX3etnwsyRWrmd4E0roGGfD5tMPpGMUDSlvTPWt0I+1QFUxRI9ohn1fRBpD
p+UHHC+SYF6NzxvfqyPwm6ndb2XOwdAKYljlf4KrBwHtSXvAH8p5EASm4PjGbavY
0mrkv0cb8QOKQNVe9q4B4AmM4iAITZ9i3sQBPJ+EBN2P+kS/lFU5L/+5z3VQjms=
=KTEG
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-for-davem-2017-04-21' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for 4.12
Quite a lot of patches for rtlwifi and iwlwifi this time, but changes
also for other active wireless drivers.
Major changes:
ath9k
* add support for Dell Wireless 1601 PCI device
* add debugfs file to manually override noise floor
ath10k
* bump up FW API to 6 for a new QCA6174 firmware branch
wil6210
* support 8 kB RX buffers
iwlwifi
* work to support A000 devices continues
* add support for FW API 30
* add Geographical and Dynamic Specific Absorption Rate (SAR) support
* support a few new PCI device IDs
rtlwifi
* work on adding Bluetooth coexistance support, not finished yet
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
* connection quality monitoring with multiple thresholds
* support for FILS shared key authentication offload
* pre-CAC regulatory compliance - only ETSI allows this
* sanity check for some rate confusion that hit ChromeOS
(but nobody else uses it, evidently)
* some documentation updates
* lots of cleanups
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEExu3sM/nZ1eRSfR9Ha3t4Rpy0AB0FAlj12HMACgkQa3t4Rpy0
AB0ztBAAi0tH9xR/7iYgChyZV4S8PpYKo2QoQZofG8vzAztboqI4clAxbWEOsJHh
qddjm+foiHVJtZj2LqxjDcaxk69VIh/ERSlR7ve7GCzz9WAAWBMHZop2eArHvgI1
pqP4mQEZ7QISVo88H3LeRdj8NmTwfZYH8u8e2CN3yEpSh1PPrU+slaXRLrjB4uql
XWwwJYQatgDw6Dj4vTIk++DqGo7OhK6CrC1gZLnyOtitTiPzRtfj8rdRHeRKdlj4
wOkUaenjs5r9KsofNYZpzckHp2NEpgIruqCsNdRGHf14EWBC5Q1N35OUOecyQ67T
3VeSnHxU4qjomkXgwqmDKFFOdqtqIruor3YDdO1iwO2TNF+JlNfq5AqUNec/XjUv
VDmj1NRZE0ftJtCkDFm1Q/ABfVDH9i2O6ZBs6a3zb65lA83q1y4xlF48LqDzG3qi
fNnfRO2rOOiyosF3HEkF5u1mfD6MRUtZAc2ZiHckGUpAngs5QOWKqtVgcgWjmbFW
qDTKsFYi2YpGXZAnUjqS4ZtmcgRGEXqg1STJBt4cA8cnmI9Ka5GplACVhqzGeneH
EYMESEct9BOpR6BjABmbZL09NtCkiTPYjiL4V//USr4f6NFhOeHHMYuxYFYIEgC6
ldRjf4EUzZw0QJ8X6L+zxYI5m40fEJ7bGhlIdMo7fWXpRpCaF1Y=
=f4VT
-----END PGP SIGNATURE-----
Merge tag 'mac80211-next-for-davem-2017-04-18' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next
Johannes Berg says:
====================
My last pull request has been a while, we now have:
* connection quality monitoring with multiple thresholds
* support for FILS shared key authentication offload
* pre-CAC regulatory compliance - only ETSI allows this
* sanity check for some rate confusion that hit ChromeOS
(but nobody else uses it, evidently)
* some documentation updates
* lots of cleanups
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Introduce a debugfs option to manually override the noise floor,
ignoring the automatically tuned noise floor of the driver/hw.
In my tests with a AR9580 based module and a tx99 5 MHz interferer,
I could tune the noisefloor to -95 dBm or above to allow communication
again. The automatic noise floor calibration sometimes could adapt to
the situation as well, but not reliably and permanently.
I would consider this "feature" experimental and interesting for people
debugging the noise floor calibration or other effects of the hardware.
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The macro results are assigned to u8 variables/fields. Adding the cast
fixes plenty of clang warnings about "implicit conversion from 'int' to
'u8'".
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Add the Dell Wireless 1601 card as an AR9462 in the ath9k pci list.
Note that the wowlan feature is supported and has been tested
successfully.
Signed-off-by: Damien Thébault <damien@dtbo.net>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The > should be >= or we read one space beyond the end of the array.
Fixes: ab5c4f71d8 ("ath9k: allow to load EEPROM content via firmware API")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer or accessing memory beyond the endpoint array should a
malicious device lack the expected endpoints.
Fixes: 36bcce4306 ("ath9k_htc: Handle storage devices")
Cc: stable <stable@vger.kernel.org> # 2.6.39+
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Doing so enables the FFT generation without prior
configuration, leading to an IRQ storm caused by
invalid (or at least unwanted) PHY errors.
Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Set the NL80211_EXT_FEATURE_CQM_RSSI_LIST wiphy extended feature
wholesale in all mac80211-based drivers that do not set the
IEEE80211_VIF_BEACON_FILTER flags on their interfaces. mac80211 will
be processing supplied RSSI values in ieee80211_rx_mgmt_beacon and
will detect when the thresholds set by
ieee80211_set_cqm_rssi_range_config are crossed. Remaining (few)
drivers need code to enable the firmware to monitor the thresholds.
This is mostly only compile-tested.
Signed-off-by: Andrew Zaborowski <andrew.zaborowski@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fix typos and add the following to the scripts/spelling.txt:
aligment||alignment
I did not touch the "N_BYTE_ALIGMENT" macro in
drivers/net/wireless/realtek/rtlwifi/wifi.h to avoid unpredictable
impact.
I fixed "_aligment_handler" in arch/openrisc/kernel/entry.S because
it is surrounded by #if 0 ... #endif. It is surely safe and I
confirmed "_alignment_handler" is correct.
I also fixed the "controler" I found in the same hunk in
arch/openrisc/kernel/head.S.
Link: http://lkml.kernel.org/r/1481573103-11329-8-git-send-email-yamada.masahiro@socionext.com
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch fixes the OTP register definitions for the AR934x and AR9550
WMAC SoC.
Previously, the ath9k driver was unable to initialize the integrated
WMAC on an Aerohive AP121:
| ath: phy0: timeout (1000 us) on reg 0x30018: 0xbadc0ffe & 0x00000007 != 0x00000004
| ath: phy0: timeout (1000 us) on reg 0x30018: 0xbadc0ffe & 0x00000007 != 0x00000004
| ath: phy0: Unable to initialize hardware; initialization status: -5
| ath9k ar934x_wmac: failed to initialize device
| ath9k: probe of ar934x_wmac failed with error -5
It turns out that the AR9300_OTP_STATUS and AR9300_OTP_DATA
definitions contain a typo.
Cc: Gabor Juhos <juhosg@openwrt.org>
Cc: stable@vger.kernel.org
Fixes: add295a4af "ath9k: use correct OTP register offsets for AR9550"
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: Chris Blake <chrisrblake93@gmail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath_tx_count_airtime is doing a lot of unnecessary work:
- Redundant station lookup
- Redundant rcu_read_lock/unlock
- Useless memcpy of bf->rates
- Useless NULL check of bf->bf_mpdu
- Redundant lookup of the skb tid
Additionally, it tries to look up the mac80211 queue index from the txq,
which fails if the frame was delivered via the power save queue.
This patch fixes all of these issues by passing down the right set of
pointers instead of doing extra work
Cc: stable@vger.kernel.org
Fixes: 63fefa0504 ("ath9k: Introduce airtime fairness scheduling between stations")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The code currently relies on refcounting to disable IRQs from within the
IRQ handler and re-enabling them again after the tasklet has run.
However, due to race conditions sometimes the IRQ handler might be
called twice, or the tasklet may not run at all (if interrupted in the
middle of a reset).
This can cause nasty imbalances in the irq-disable refcount which will
get the driver permanently stuck until the entire radio has been stopped
and started again (ath_reset will not recover from this).
Instead of using this fragile logic, change the code to ensure that
running the irq handler during tasklet processing is safe, and leave the
refcount untouched.
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
In an RFC patch, Sven Eckelmann and Simon Wunderlich reported:
"QCA 802.11n chips (especially AR9330/AR9340) sometimes end up in a
state in which a read of AR_CFG always returns 0xdeadbeef.
This should not happen when when the power_mode of the device is
ATH9K_PM_AWAKE."
Include the check for the default register state in the existing MAC
hang check.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Also include common MAC alive check. This should make the hang checks
more reliable for modes where beacons are not sent and is used as a
starting point for further hang check improvements
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Currently, the common ath9k_common module needs to have a
dependency on RELAY and DEBUG_FS in order to built. This
is usually not a problem. But for RAM and FLASH starved
AR71XX devices, every little bit counts.
This patch adds a new symbol CONFIG_ATH9K_COMMON_DEBUG
which makes it possible to drop the RELAY and DEBUG_FS
dependency there and move it to ATH_(HTC)_DEBUGFS.
Note: The shared FFT/spectral code (which is the only user
of the relayfs in ath9k*) needs DEBUG_FS to export the relayfs
interface to dump the data to userspace. So it makes no sense
to have the functions compiled in, if DEBUG_FS is not there.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Trivial fix to spelling mistake in ath_err message
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
preference to ACCESS_ONCE(), and new code is expected to use one of the
former. So far, there's been no reason to change most existing uses of
ACCESS_ONCE(), as these aren't currently harmful.
However, for some new features (e.g. KTSAN / Kernel Thread Sanitizer),
it is necessary to instrument reads and writes separately, which is not
possible with ACCESS_ONCE(). This distinction is critical to correct
operation.
It's possible to transform the bulk of kernel code using the Coccinelle
script below. However, for some files (including the ath9k ar9003 mac
driver), this mangles the formatting. As a preparatory step, this patch
converts the driver to use {READ,WRITE}_ONCE() without said mangling.
----
virtual patch
@ depends on patch @
expression E1, E2;
@@
- ACCESS_ONCE(E1) = E2
+ WRITE_ONCE(E1, E2)
@ depends on patch @
expression E;
@@
- ACCESS_ONCE(E)
+ READ_ONCE(E)
----
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: ath9k-devel@qca.qualcomm.com
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: linux-wireless@vger.kernel.org
Cc: ath9k-devel@lists.ath9k.org
Cc: netdev@vger.kernel.org
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
preference to ACCESS_ONCE(), and new code is expected to use one of the
former. So far, there's been no reason to change most existing uses of
ACCESS_ONCE(), as these aren't currently harmful.
However, for some new features (e.g. KTSAN / Kernel Thread Sanitizer),
it is necessary to instrument reads and writes separately, which is not
possible with ACCESS_ONCE(). This distinction is critical to correct
operation.
It's possible to transform the bulk of kernel code using the Coccinelle
script below. However, for some files (including the ath9k ar9002 mac
driver), this mangles the formatting. As a preparatory step, this patch
converts the driver to use {READ,WRITE}_ONCE() without said mangling.
----
virtual patch
@ depends on patch @
expression E1, E2;
@@
- ACCESS_ONCE(E1) = E2
+ WRITE_ONCE(E1, E2)
@ depends on patch @
expression E;
@@
- ACCESS_ONCE(E)
+ READ_ONCE(E)
----
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: ath9k-devel@qca.qualcomm.com
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: linux-wireless@vger.kernel.org
Cc: ath9k-devel@lists.ath9k.org
Cc: netdev@vger.kernel.org
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The most notable change here is the inclusion of airtime fairness
scheduling to ath9k. It prevents slow clients from hogging all the
airtime and unfairly slowing down faster clients.
Otherwise smaller changes and cleanup.
Major changes:
ath9k
* cleanup eeprom endian handling
* add airtime fairness scheduling
ath10k
* fix issues for new QCA9377 firmware version
* support dev_coredump() for firmware crash dump
* enable channel 169 on 5 GHz band
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAABAgAGBQJYalDTAAoJEG4XJFUm622ba2EH/ivoHG9CvmT6HgNw77odDr6b
Zc7plDi2dd9LIzp3rF/9j8Ietfzpu31Pp9Qz0o1Su/s8RJIlXKVF5UeG5IignnEG
02rv7Z+BGPW7SUNDb0cLa27PMYqUAh8vI39sxYSdQ9NQLIlpMLIxxx5iOZyAK5eV
HBRS0pVlSxbAntb1JgWiN/LjjXe/PdhX3CR/b9b468KAcWB6UWj9nXQxFmz7d3uM
dH3buDTgwaq7K24ZAFc1BsD7rgxprpauXxgIMWCKxRERf64WFfYkYdfdCER+PSPH
maV5Te1KzTJBrQHDOPs1ezVe8gDUhb5YE4BJY9SppZpOE1arucq2g3+3obQUeHE=
=DAVq
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-for-davem-2017-01-02' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for 4.11
The most notable change here is the inclusion of airtime fairness
scheduling to ath9k. It prevents slow clients from hogging all the
airtime and unfairly slowing down faster clients.
Otherwise smaller changes and cleanup.
Major changes:
ath9k
* cleanup eeprom endian handling
* add airtime fairness scheduling
ath10k
* fix issues for new QCA9377 firmware version
* support dev_coredump() for firmware crash dump
* enable channel 169 on 5 GHz band
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
These are one-line functions that just call spin_lock/unlock_bh(); turn
them into static inlines to avoid the function call overhead.
Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
This reworks the ath9k driver to schedule transmissions to connected
stations in a way that enforces airtime fairness between them. It
accomplishes this by measuring the time spent transmitting to or
receiving from a station at TX and RX completion, and accounting this to
a per-station, per-QoS level airtime deficit. Then, an FQ-CoDel based
deficit scheduler is employed at packet dequeue time, to control which
station gets the next transmission opportunity.
Airtime fairness can significantly improve the efficiency of the network
when station rates vary. The following throughput values are from a
simple three-station test scenario, where two stations operate at the
highest HT20 rate, and one station at the lowest, and the scheduler is
employed at the access point:
Before / After
Fast station 1: 19.17 / 25.09 Mbps
Fast station 2: 19.83 / 25.21 Mbps
Slow station: 2.58 / 1.77 Mbps
Total: 41.58 / 52.07 Mbps
The benefit of airtime fairness goes up the more stations are present.
In a 30-station test with one station artificially limited to 1 Mbps,
we have seen aggregate throughput go from 2.14 to 17.76 Mbps.
Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The ar9300_eeprom logic is already using only 8-bit (endian neutral),
__le16 and __le32 fields to state explicitly how the values should be
interpreted.
All other EEPROM implementations (4k, 9287 and def) were using u16 and
u32 fields with additional logic to swap the values (read from the
original EEPROM) so they match the current CPUs endianness.
The EEPROM format defaults to "all values are Little Endian", indicated
by the absence of the AR5416_EEPMISC_BIG_ENDIAN in the u8 EEPMISC
register. If we detect that the EEPROM indicates Big Endian mode
(AR5416_EEPMISC_BIG_ENDIAN is set in the EEPMISC register) then we'll
swap the values to convert them into Little Endian. This is done by
activating the EEPMISC based logic in ath9k_hw_nvram_swap_data even if
AH_NO_EEP_SWAP is set (this makes ath9k behave like the FreeBSD driver,
which also does not have a flag to enable swapping based on the
AR5416_EEPMISC_BIG_ENDIAN bit). Before this logic was only used to
enable swapping when "current CPU endianness != EEPROM endianness".
After changing all relevant fields to __le16 and __le32 sparse was used
to check that all code which reads any of these fields uses
le{16,32}_to_cpu.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
There are two ways of swapping the EEPROM data in the ath9k driver:
1) swab16 based on the first two EEPROM "magic" bytes (same for all
EEPROM formats)
2) field and EEPROM format specific swab16/swab32 (different for
eeprom_def, eeprom_4k and eeprom_9287)
The result of the first check was used to also enable the second swap.
This behavior seems incorrect, since the data may only be byte-swapped
(afterwards the data could be in the correct endianness).
Thus we introduce a separate check based on the "eepmisc" register
(which is part of the EEPROM data). When bit 0 is set, then the EEPROM
format specific values are in "big endian". This is also done by the
FreeBSD kernel, see [0] for example.
This allows us to parse EEPROMs with the "correct" magic bytes but
swapped EEPROM format specific values. These EEPROMs (mostly found in
lantiq and broadcom based big endian MIPS based devices) only worked
due to platform specific "hacks" which swapped the EEPROM so the
magic was inverted, which also enabled the format specific swapping.
With this patch the old behavior is still supported, but neither
recommended nor needed anymore.
[0]
50719b56d9/sys/dev/ath/ath_hal/ah_eeprom_9287.c (L351)
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The AR5416_VER_MASK macro does the same as get_eeprom_rev, except that
one has to know the actual EEPROM type (and providing a reference to
that in a variable named "eep"). Additionally the eeprom_*.c
implementations used the same shifting logic multiple times to get the
eeprom revision which was also unnecessary duplication of
get_eeprom_rev.
Also use the AR5416_EEP_VER_MINOR_MASK macro where needed and introduce
a similar macro (AR5416_EEP_VER_MAJOR_MASK) for the major version.
Finally drop AR9287_EEP_VER_MINOR_MASK since it simply duplicates the
already defined AR5416_EEP_VER_MINOR_MASK.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
get_eeprom(ah, EEP_MINOR_REV) and get_eeprom_rev(ah) are both doing the
same thing: returning the EEPROM revision (12 lowest bits). Make the
code consistent by using get_eeprom_rev(ah) everywhere.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
This allows deciding if we have to swap the EEPROM data (so it matches
the system's native endianness) even if no byte-swapping (swab16, based on
the first two bytes in the EEPROM) is needed.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The eepMisc field was not set explicitly. The default value of 0 means
that the values in the EEPROM (template) should be interpreted as little
endian. However, this is not clear until comparing the AR9003 code with
the other EEPROM formats.
To make the code easier to understand we explicitly state that the values
are little endian - there are no functional changes with this patch.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
This replaces a magic number with a named #define. Additionally it
removes two "eeprom format" specific #defines for the "big endianness"
bit which are the same on all eeprom formats.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Major changes:
rsi
* filter rx frames
* configure tx power
* make it possible to select antenna
* support 802.11d
brcmfmac
* cleanup of scheduled scan code
* support for bcm43341 chipset with different chip id
* support rev6 of PCIe device interface
ath10k
* add spectral scan support for QCA6174 and QCA9377 families
* show used tx bitrate with 10.4 firmware
wil6210
* add power save mode support
* add abort scan functionality
* add support settings retry limit for short frames
bcma
* add Dell Inspiron 3148
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAABAgAGBQJYQGivAAoJEG4XJFUm622bqG0IAJtSGt4Fxv2jL7GPmPpEUtYK
F6G1PCk9LxO44rOZ15E/CT1vPk6Bnwqp9brdngmXwl7jc+jGs4MQN7g6cD4UZgPm
gxjx8cah2HPRVgEE7PeOILthRxwPA+9klycsvwtglkgQ1SpQVmLHDTLpeOAkRluY
olJGINoGHTD6osud6p3oKK+VP891omJvu8TPqRjhrhLhbQTWAuTxl2Gsdye30yag
CsdaEZb9wdUEBoS80EVRwvgBzqrdKU5kGDGbuzytcyrFrRHo4flti1KgxDg3nIpI
jC4Liwg0yE/aYZlfMqi/960rt8AttCJBDt/vwqp0mOE4IwFsE9Yaio6xXUonAC8=
=a6a/
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-for-davem-2016-12-01' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for 4.10
Major changes:
rsi
* filter rx frames
* configure tx power
* make it possible to select antenna
* support 802.11d
brcmfmac
* cleanup of scheduled scan code
* support for bcm43341 chipset with different chip id
* support rev6 of PCIe device interface
ath10k
* add spectral scan support for QCA6174 and QCA9377 families
* show used tx bitrate with 10.4 firmware
wil6210
* add power save mode support
* add abort scan functionality
* add support settings retry limit for short frames
bcma
* add Dell Inspiron 3148
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The usb_*_msg() functions expect a timeout in msecs but are given HZ,
which is ticks per second. If HZ=100, firmware download often times out
when there is modest USB utilization and the device fails to initialize.
Replaces HZ in usb_*_msg timeouts with 1000 msec since HZ is one second
for timeouts in jiffies.
Signed-off-by: Anthony Romano <anthony.romano@coreos.com>
Acked-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Declare the structure ath_bus_ops as const as it is only passed as an
argument to the function ath9k_init_device. This argument is of type
const struct ath_bus_ops *, so ath_bus_ops structures with this property
can be declared as const.
Done using Coccinelle:
@r1 disable optional_qualifier @
identifier i;
position p;
@@
static struct ath_bus_ops i@p = {...};
@ok1@
identifier r1.i;
position p;
expression e1,e2;
@@
ath9k_init_device(e1,e2,&i@p)
@bad@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p
@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
static
+const
struct ath_bus_ops i={...};
@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct ath_bus_ops i;
File size before:
text data bss dec hex filename
1295 232 0 1527 5f7 ath/ath9k/ahb.o
File size after:
text data bss dec hex filename
1359 176 0 1535 5ff ath/ath9k/ahb.o
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Radar pulse and spectral scan reports are provided by the HW
with the ATH9K_RXERR_PHY flag set. Those are forwarded to
the dfs-detector and spectral module for further processing.
For some older chips, the pre-conditions checked in those
modules are ambiguous, since ATH9K_PHYERR_RADAR is used to
tag both types. As a result, spectral frames are fed into
the dfs-detector and vice versa.
This could lead to a false radar detection on a non-DFS
channel (which is uncritical), but more relevant it causes
useless CPU load for processing invalid frames.
This commit ensures that the dfs-detector and spectral
collector are only fed when they are active.
Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Major changes:
iwlwifi
* finalize and enable dynamic queue allocation
* use dev_coredumpmsg() to prevent locking the driver
* small fix to pass the AID to the FW
* use FW PS decisions with multi-queue
ath9k
* add device tree bindings
* switch to use mac80211 intermediate software queues to reduce
latency and fix bufferbloat
wl18xx
* allow scanning in AP mode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAABAgAGBQJYOAC4AAoJEG4XJFUm622bUYkH/3SSYp6moSdKpVnVPx7ST7yK
t9WHR9IMZFIhD6vq8AK6+8OQr1TgGjHfPu+WZj7CIl8nu53kcgPRi51gg1mndbNg
9N3RbVp06nGbM2VnW8ZIpg3OLIXatZ4c9g3LFvvtyobYvWGJ6W4D79JdlmTG1ELr
XAjInbxFsgon+CwqCMOaAJx8xYp42rBnPRZZvhOq9O33kRw8Umo9UQw0s1U2Vfgx
prxQ6d0GxNAPEe8QiDw/vtBcXWFMOhQeDl8sK70ZcojSn1FY730NsIh/Y86PcQTK
6TsvOL5gg+rd0ln8TZRAslnDrZBAhTEDqUzLQMRJ9VjEj5RFd8eLCSIzHfaroI8=
=4qCH
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-for-davem-2016-11-25' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for 4.10
Major changes:
iwlwifi
* finalize and enable dynamic queue allocation
* use dev_coredumpmsg() to prevent locking the driver
* small fix to pass the AID to the FW
* use FW PS decisions with multi-queue
ath9k
* add device tree bindings
* switch to use mac80211 intermediate software queues to reduce
latency and fix bufferbloat
wl18xx
* allow scanning in AP mode
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit b2d70d4944 ("ath9k: make GPIO API to support both of WMAC and
SOC") refactored ath9k_hw_gpio_get() to support both WMAC and SOC GPIOs,
changing the return on success from 1 to BIT(gpio). This broke some callers
like ath_is_rfkill_set(). This doesn't fix any known bug in mainline at the
moment, but should be fixed anyway.
Instead of fixing all callers, change ath9k_hw_gpio_get() back to only
return 0 or 1.
Fixes: b2d70d4944 ("ath9k: make GPIO API to support both of WMAC and SOC")
Cc: <stable@vger.kernel.org> # v4.7+
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
[kvalo@qca.qualcomm.com: mention that doesn't fix any known bug]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
This switches ath9k over to using the mac80211 intermediate software
queueing mechanism for data packets. It removes the queueing inside the
driver, except for the retry queue, and instead pulls from mac80211 when
a packet is needed. The retry queue is used to store a packet that was
pulled but can't be sent immediately.
The old code path in ath_tx_start that would queue packets has been
removed completely, as has the qlen limit tunables (since there's no
longer a queue in the driver to limit).
The mac80211 intermediate software queues offer significant latency
reductions, and this patch allows ath9k to realise them. The exact gains
from this varies with the test scenario, but in an access point scenario
we have seen latency reductions ranging from 1/3 to as much as an order
of magnitude. We also achieve slightly better aggregation.
Median latency (ping) figures with this patch applied at the access point,
with two high-rate stations and one low-rate station (HT20 5Ghz), running
a Flent rtt_fair_var_up test with one TCP flow and one ping flow going to
each station:
Fast station Slow station
Default pfifo_fast qdisc: 430.4 ms 638.7 ms
fq_codel qdisc on iface: 35.5 ms 211.8 ms
This patch set: 22.4 ms 38.2 ms
Median aggregation sizes over the same test:
Default pfifo_fast qdisc: 9.5 pkts 1.9 pkts
fq_codel qdisc on iface: 11.2 pkts 1.9 pkts
This patch set: 13.9 pkts 1.9 pkts
This patch is based on Tim's original patch set, but reworked quite
thoroughly.
Cc: Tim Shepard <shep@alum.mit.edu>
Cc: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Add missing space in a dev_err message and join wrapped text so
it does not span multiple lines. Fix spelling mistake on "unknown".
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
This allows setting the MAC address and specifying that the firmware
will be requested from userspace (because there might not be a hardware
EEPROM connected to the chip) for ath9k based PCI devices using
the device tree.
There is some out-of-tree code to "convert devicetree to
ath9k_platform_data" (for example in OpenWrt and LEDE) which becomes
obsolete with this patch.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The active_high LED of my Wistron DNMA-92 is still being recognized as
active_low on 4.7.6 mainline. When I was preparing my former commit
0f9edcdd88 ("ath9k: Fix LED polarity for some Mini PCI AR9220 MB92
cards.") to fix that I must have somehow messed up with testing, because
I tested the final version of that patch before sending it, and it was
apparently working; but now it is not working on 4.7.6 mainline.
I initially added the PCI_DEVICE_SUB section for 0x0029/0x2096 above the
PCI_VDEVICE section for 0x0029; but then I moved the former below the
latter after seeing how 0x002A sections were sorted in the file.
This turned out to be wrong: if a generic PCI_VDEVICE entry (that has
both subvendor and subdevice IDs set to PCI_ANY_ID) is put before a more
specific one (PCI_DEVICE_SUB), then the generic PCI_VDEVICE entry will
match first and will be used.
With this patch, 0x0029/0x2096 has finally got active_high LED on 4.7.6.
While I'm at it, let's fix 0x002A too by also moving its generic definition
below its specific ones.
Fixes: 0f9edcdd88 ("ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards.")
Cc: <stable@vger.kernel.org> #4.7+
Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
[kvalo@qca.qualcomm.com: improve the commit log based on email discussions]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Mostly simple overlapping changes.
For example, David Ahern's adjacency list revamp in 'net-next'
conflicted with an adjacency list traversal bug fix in 'net'.
Signed-off-by: David S. Miller <davem@davemloft.net>
The old WDS 4-addr frame support is very limited, e.g.
* no encryption is possible on such links
* it cannot support rate/HT/VHT negotiation
* management APIs are very restricted
These make the WDS legacy mode useless in practice.
All of these are resolved by the 4-addr AP/client support,
so there's also no reason to improve WDS in the future.
Therefore, add a Kconfig option to disable legacy WDS.
This gives people an "emergency valve" while they migrate
to the better-supported 4-addr AP/client option; we plan
to remove it (and the associated cfg80211/mac80211 code,
which is the ultimate goal) in the future.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The quality of ADC entropy is 10 bits of min-entropy for
a 32-bit value, change '(((x) * 8 * 320) >> 10)' to
'(((x) * 8 * 10) >> 5)' for easier understanding.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
This reverts commit 171f6402e4 ("ath9k_hw: implement temperature compensation
support for AR9003+"). Some users report that this commit causes a regression
in performance under some conditions.
Fixes: 171f6402e4 ("ath9k_hw: implement temperature compensation support for AR9003+")
Cc: <stable@vger.kernel.org> # 4.8
Signed-off-by: Felix Fietkau <nbd@nbd.name>
[kvalo@qca.qualcomm.com: improve commit log]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath9k RNG will dominates all the noise sources from the real HW
RNG, disable it by default. But we strongly recommand to enable
it if the system without HW RNG, especially on embedded systems.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Acked-by: Stephan Mueller <smueller@chronox.de>
Acked-by: Stephan Mueller <smueller@chronox.de>
Reviewed-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Commit 3c97f5de1f ("ath10k: implement NAPI support") conflicts with
ath-current. To avoid any merge problems merge ath-current to ath-next already now.
Conflicts:
drivers/net/wireless/ath/ath10k/htt_rx.c
The constant "123", which is the number of elements in
mask_m / mask_p, is repeated several times in this function.
Replace memsets with array initialization, and replace a loop
conditional with ARRAY_SIZE() so that we don't repeat ourselves.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Reviewed-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
For non-aggregated frames, ath9k was leaving handling of powersave
filtered packets to mac80211. This can be too slow if the intermediate
queue is already filled with packets and mac80211 does not immediately
send a new packet via drv_tx().
Improve response time with filtered frames by triggering clearing the
powersave filter internally.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
It removes the need for undoing the padding changes to skb->data and it
improves performance by eliminating one tx status lookup per MPDU in the
status path. It is also useful for preparing a follow-up fix to better
handle powersave filtering.
A side effect is that these counters, available via debugfs, become now invalid:
* dot11TransmittedFragmentCount
* dot11FrameDuplicateCount,
* dot11ReceivedFragmentCount
* dot11MulticastReceivedFrameCount
Signed-off-by: Felix Fietkau <nbd@nbd.name>
[kvalo@qca.qualcomm.com: add a note about counters, thanks to Zefir Kurtisi]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
A regression was introduced in commit id 79d4db1214 ("ath9k: cleanup
led_pin initial") that broken the WLAN status led on my laptop with
AR9287 after suspending and resuming.
Steps to reproduce:
* Suspend (laptop)
* Resume (laptop)
* Observe that the WLAN led no longer turns ON/OFF depending on the
status and is always red
Even though for my case it only needs to be set to OUT in ath9k_start
but for consistency bring back the IN direction setting as well.
Fixes: 79d4db1214 ("ath9k: cleanup led_pin initial")
Cc: Miaoqing Pan <miaoqing@codeaurora.org>
Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Cc: <stable@vger.kernel.org> # 4.7+
Link: https://bugzilla.kernel.org/show_bug.cgi?id=151711
Signed-off-by: Giedrius Statkevičius <giedrius.statkevicius@gmail.com>
[kvalo@qca.qualcomm.com: improve commit log]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
We get 1 warning about global functions without a declaration
in the ath9k gpio driver when building with W=1:
drivers/net/wireless/ath/ath9k/gpio.c:25:6: warning: no previous prototype for 'ath_fill_led_pin' [-Wmissing-prototypes]
In fact, this function is only used in the file in which it is declared
and don't need a declaration, but can be made static.
so this patch marks it 'static'.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
A station pointer can be passed to the driver on tx, before it has been
marked as associated. Since ath9k_sta_state was initializing the entry
too late, it resulted in some spurious crashes.
Fixes: df3c6eb34d ("ath9k: Use sta_state() callback")
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
just to comply with current ath9k_hw_nvram_read to return value, hence
behaving reacting accordingly.
Signed-off-by: Eduardo Abinader <eduardo.abinader@riverbed.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Fixes smatch warning:
ath9k_vif_iter_set_beacon() warn if statement not indented
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The use of config_enabled() against config options is ambiguous. In
practical terms, config_enabled() is equivalent to IS_BUILTIN(), but the
author might have used it for the meaning of IS_ENABLED(). Using
IS_ENABLED(), IS_BUILTIN(), IS_MODULE() etc. makes the intention
clearer.
This commit replaces config_enabled() with IS_ENABLED() where possible.
This commit is only touching bool config options.
I noticed two cases where config_enabled() is used against a tristate
option:
- config_enabled(CONFIG_HWMON)
[ drivers/net/wireless/ath/ath10k/thermal.c ]
- config_enabled(CONFIG_BACKLIGHT_CLASS_DEVICE)
[ drivers/gpu/drm/gma500/opregion.c ]
I did not touch them because they should be converted to IS_BUILTIN()
in order to keep the logic, but I was not sure it was the authors'
intention.
Link: http://lkml.kernel.org/r/1465215656-20569-1-git-send-email-yamada.masahiro@socionext.com
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Stas Sergeev <stsp@list.ru>
Cc: Matt Redfearn <matt.redfearn@imgtec.com>
Cc: Joshua Kinard <kumba@gentoo.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Markos Chandras <markos.chandras@imgtec.com>
Cc: "Dmitry V. Levin" <ldv@altlinux.org>
Cc: yu-cheng yu <yu-cheng.yu@intel.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Will Drewry <wad@chromium.org>
Cc: Nikolay Martynov <mar.kolya@gmail.com>
Cc: Huacai Chen <chenhc@lemote.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
Cc: Rafal Milecki <zajec5@gmail.com>
Cc: James Cowgill <James.Cowgill@imgtec.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Alex Smith <alex.smith@imgtec.com>
Cc: Adam Buchbinder <adam.buchbinder@gmail.com>
Cc: Qais Yousef <qais.yousef@imgtec.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Mikko Rapeli <mikko.rapeli@iki.fi>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Brian Norris <computersforpeace@gmail.com>
Cc: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Cc: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Roland McGrath <roland@hack.frob.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Tony Wu <tung7970@gmail.com>
Cc: Huaitong Han <huaitong.han@intel.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Juergen Gross <jgross@suse.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Andrea Gelmini <andrea.gelmini@gelma.net>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Rabin Vincent <rabin@rab.in>
Cc: "Maciej W. Rozycki" <macro@imgtec.com>
Cc: David Daney <david.daney@cavium.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Reduce indentation, use a variable to save a few pointer dereferences
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
AR_PHY_65NM_CH0_THERM and AR_CH0_THERM were supposed to refer to the
same register, however they had different SREV checks.
Remove the duplicate and use the checks. Since there were other SREV
checks present in the only place that uses this, this will probaby not
affect runtime behavior.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The register layout of AR_PHY_SPECTRAL_SCAN has changed, only AR9280
uses the old layout
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
There were two paths in the code for "external" eeprom sources. The code
in eeprom.c only handled the cases where the eeprom data was loaded via
request_firmware. ahb.c and pci.c on the other hand had some duplicate
code which was only used when the eeprom data was passed via
ath9k_platform_data.
With this change all eeprom data handling is now unified in eeprom.c.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
This patch fixes some issues with interface reconfiguration. It could
for example happen that an AP interface in beacon slot 0 was removed
leaving an IBSS station in one of the other slots. When this happens
the driver never sends out the beacon as it only tries to send a beacon
from slot 0.
Appart from that the tracking of required changes to the beacon config is
relatively complicated and prone to errors.
The approach taken here is to solve reconfiguration issues is to
reconfigure the beacons when any interface changes. This means that
the complexity of deciding whether an interface change may modify the
beacon configuration is gone. It also means that the beacon config will
be reliably updated when an interface is removed.
The issue that a single non-AP interface might not be in beacon
slot 0 and wouldn't be send out is solved by moving it into the
first slot. The TSF value in hardware is adjusted accordingly so
that the timestamp of the beacons stay consistent.
Signed-off-by: Benjamin Berg <benjamin.berg@open-mesh.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The removed ATH9K_SLOT_TIME_X constants simply map the value in microseconds
to the same integer. These constants were not used consistently, so fix the
inconsistency issue by replacing all occurances with the integer equivalent.
Signed-off-by: Benjamin Berg <benjamin.berg@open-mesh.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The ath9k driver modifies the TSF for VIFs for the purpose of sending
beacons in a staggered fashion. This patch exposes this VIF specific
adjustment of the TSF value to mac80211. Without the change the TSF
routines handle the hardware TSF value instead of the actual TSF value as
seen on the air.
Signed-off-by: Benjamin Berg <benjamin.berg@open-mesh.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
These changes make ath9k_hw_reset more consistent with other places that
handle the TSF value by using the same helper routine.
A slight improvement is to not assume that a fixed time of 1.5ms has
passed for the initval writes when compared to the first write attempt.
Instead the TSF value is re-calculated which will yield a higher accuracy
of the restored TSF timer.
Signed-off-by: Benjamin Berg <benjamin.berg@open-mesh.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The ath9k TSF handling routines need to be aware of the channel context that
is being modified. With this change the TSF related values that are stored
in each channel context will be correctly tracked and the harware will only
be updated if the modified context is currently the active one.
Without this change the TSF modifications done using these routines would
for example be lost during a hardware reset as done by ath_complete_reset.
Signed-off-by: Benjamin Berg <benjamin.berg@open-mesh.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Beacons were not send out at (timestamp % beacon_time == 0) for interfaces
other than the primary one. To send out beacons with the correct timestamp
according to 10.1.3.2 of the 802.11 standard the tsf_adjustment has to be
set to the negative time difference instead of positive. This way the
later beacons get corrected to have a lower (and similar) timestamp with
regard to the beacon from slot 0.
I am not aware about any issues that have been caused by this.
Signed-off-by: Benjamin Berg <benjamin.berg@open-mesh.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
No functional changes, this simply makes the code easier to understand
because all initialization based on ath9k_platform_data is now within
one function.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath9k_hw_init_macaddr unconditionally returns 0 in all cases, making the
return value unnecessary.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Currently setting the MAC address via ath9k_platform_data works only due
to the order in which init.c sets common->macaddr, which is done after
ath9k_hw_init_macaddr was executed. It would be better if the latter
was independent of the order in which it's being called.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
No functional changes - this only removes a variable which is set but
never read.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Some devices running OpenWrt need this and it makes sense to add this
to ath9k_platform_data as the next patches will add a devicetree
(boolean) property for it as well.
Suggested-by: Vittorio Gambaletta <openwrt@vittgam.net>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Add the following to support beacon report radio measurement
with the measurement mode field set to passive or active:
1. Propagate the required scan duration to the device
2. Report the scan start time (in terms of TSF)
3. Report each BSS's detection time (also in terms of TSF)
TSF times refer to the BSS that the interface that requested the
scan is connected to.
Signed-off-by: Assaf Krauss <assaf.krauss@intel.com>
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
[changed ath9k/10k, at76c59x-usb, iwlegacy, wl1251 and wlcore to match
the new API]
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The function ar9003_hw_apply_minccapwr_thresh takes as second parameter not
a pointer to the channel but a boolean value describing whether the channel
is 2.4GHz or not. This broke (according to the origin commit) the ETSI
regulatory compliance on 5GHz channels.
Fixes: 3533bf6b15 ("ath9k: Fix regulatory compliance")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Cc: Simon Wunderlich <sw@simonwunderlich.de>
Cc: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Just setting the proper return for reading beyond the eeprom data.
Signed-off-by: Eduardo Abinader <eduardo.abinader@riverbed.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Several cases of overlapping changes, except the packet scheduler
conflicts which deal with the addition of the free list parameter
to qdisc_enqueue().
Signed-off-by: David S. Miller <davem@davemloft.net>
ath.git patches for 4.8. Major changes:
ath10k
* enable btcoex support without restarting firmware
* enable ipq4019 support using AHB bus
* add QCA9887 chipset support
* retrieve calibration data from EEPROM, currently only for QCA9887
wil6210
* add pm_notify handling
On TX99 mode, instead of assuming interrupt mask non ATH9K_INT_GLOBAL,
let ath9k_hw_disable_interrupts proper set interrupt ref count.
This prevents some PCI PERR occurring specialy when setting 11b and n rates.
Signed-off-by: Eduardo Abinader <eduardo.abinader@riverbed.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
As there is current support for ar9002 tx99 mode, just allow
to init debugfs and enable tx99.
Signed-off-by: Eduardo Abinader <eduardo.abinader@riverbed.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Just some code cleanup to remove an empty if clause.
Signed-off-by: Eduardo Abinader <eduardo.abinader@riverbed.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Major changes:
iwlwifi
* remove IWLWIFI_DEBUG_EXPERIMENTAL_UCODE kconfig option
* work for RX multiqueue continues
* dynamic queue allocation work continues
* add Luca as maintainer
* a bunch of fixes and improvements all over
brcmfmac
* add 4356 sdio support
ath6kl
* add ability to set debug uart baud rate with a module parameter
wil6210
* add debugfs file to configure firmware led functionality
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAABAgAGBQJXNbEBAAoJEG4XJFUm622bKfAH/2CnQV7dBCT5QwEiKYoOdsCR
eTiH7OYjTPw/rjKaG3laFgFbecnfUnHoGt55WKqRY58JycLza+SPTTv57hFTnOl+
4kDhUEjUggxMs5BRb3H7wtcnQVs/pTkgqKqwUrmFNkG6idENQgorK6DG4SNCwIdf
JrmxiHcN73xSATxlduoA9bGpluW3OvnFfRrJfyT6UBWZaFqFe3qsoKDx08S2WU2z
kUI9ZUO9Ht7Q85QdLfPQI7xo54dXo9a+8v3yc7fNFbcu1s8cqeYuofXfypjK7H/B
DEY96mubDnmDt8YE8yR9wStVzTr5zf39urE3o+/xSKSKhQxmNo8+x2TBSm5nFSQ=
=0HKi
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-for-davem-2016-05-13' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers patches for 4.7
Major changes:
iwlwifi
* remove IWLWIFI_DEBUG_EXPERIMENTAL_UCODE kconfig option
* work for RX multiqueue continues
* dynamic queue allocation work continues
* add Luca as maintainer
* a bunch of fixes and improvements all over
brcmfmac
* add 4356 sdio support
ath6kl
* add ability to set debug uart baud rate with a module parameter
wil6210
* add debugfs file to configure firmware led functionality
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Since commit cd6cfd7311
"ath9k: do not set half/quarter channel flags in AR_PHY_MODE" the
condition "rfMode & (AR_PHY_MODE_QUARTER | AR_PHY_MODE_HALF)" would
never evaluate to true.
Fix this by using the available IS_CHAN_HALF_RATE and IS_CHAN_QUARTER_RATE
marcros instead.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Cc: Felix Fietkau <nbd@openwrt.org>
Acked-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
There's no need to keep the same for loop twice in the code.
Move the txpower cap before the loop to reduce code complexity.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Since ATH9K_TX99 depends on ATH9K_DEBUGFS anyway move it there
such that "make menuconfig" will indent TX99 support below ath9k
debugging.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The same functionality as ar9003_hw_tx_power_regwrite is hardcoded in
ar9003_hw_tx99_set_txpower. Just reuse the existing ar9003_hw_tx_power_regwrite
for TX99 setup too.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Conflicts:
net/ipv4/ip_gre.c
Minor conflicts between tunnel bug fixes in net and
ipv6 tunnel cleanups in net-next.
Signed-off-by: David S. Miller <davem@davemloft.net>
ath.git patches for 4.7. Major changes:
ath10k
* implement set_tsf() for 10.2.4 branch
* remove rare MSI range support
* remove deprecated firmware API 1 support
ath9k
* add module parameter to invert LED polarity
wcn36xx
* fixes to get the driver properly working on Dragonboard 410c
The Wistron DNMA-92 and Compex WLM200NX have inverted LED polarity
(active high instead of active low).
The same PCI Subsystem ID is used by both cards, which are based on
the same Atheros MB92 design.
Cc: <linux-wireless@vger.kernel.org>
Cc: <ath9k-devel@qca.qualcomm.com>
Cc: <ath9k-devel@lists.ath9k.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The LED can be active high instead of active low on some hardware.
Add the led_active_high module parameter. It defaults to -1 to obey
platform data as before.
Setting the parameter to 1 or 0 will force the LED respectively
active high or active low.
Cc: <linux-wireless@vger.kernel.org>
Cc: <ath9k-devel@qca.qualcomm.com>
Cc: <ath9k-devel@lists.ath9k.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ah is written twice with the same value, remove one of the
redundant assignments to ah.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Tx power limitations at upper layers are interpreted in
the EIRP domain. When the user requests a given maximum
txpower, e.g. with: 'iw phy0 set txpower fixed 1500',
he expects the EIRP to be at or below 15dBm.
In ath9k_hw_apply_txpower(), the interpretation is
different: the antenna-gain is capped against the
current txpower limit in the regulatory, but not
against the user set value. It ensures that the
resulting EIRP is below the limit defined by the
active countrycode, but not below the value the
user requested.
In a scenario like e.g.
a) antenna_gain=6
b) countrycode limits to eirp=18
c) user set txpower=15
this will cause a setting for AR_PHY_POWER_TX_RATE
regs resulting in an EIRP > 15.
This patch ensures that antenna-gain is considered
whenever the txpower limit is adjusted and with that
the user set limits are kept.
Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Replace an explicit initialisation for one local variable at the beginning
by a conditional assignment.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Oleksij Rempel <linux@rempel-privat.de>
Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
by moving common code to ar5008_hw_cmn_spur_mitigate i forgot to move
mask_m & mask_p initialisation. This coused a performance regression
on ar9281.
Fixes: f911085ffa ("ath9k: split ar5008_hw_spur_mitigate and reuse common code in ar9002_hw_spur_mitigate.")
Reported-by: Gustav Frederiksen <lkml2017@openmailbox.org>
Tested-by: Gustav Frederiksen <lkml2017@openmailbox.org>
Cc: <stable@vger.kernel.org> # 4.2+
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
This enum is already perfectly aliased to enum nl80211_band, and
the only reason for it is that we get IEEE80211_NUM_BANDS out of
it. There's no really good reason to not declare the number of
bands in nl80211 though, so do that and remove the cfg80211 one.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
ath.git patches for 4.7. Major changes:
ath10k
* implement push-pull tx model using mac80211 software queuing support
* enable scan in AP mode (NL80211_FEATURE_AP_SCAN)
wil6210
* add basic PBSS (Personal Basic Service Set) support
* add initial P2P support
* add oob_mode module parameter
In ath9k_hif_usb_rx_stream(), i is initialised in the for loop it's
used in.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Oleksij Rempel <linux@rempel-privat.de>
[Rewrote commit message]
Signed-off-by: Julian Calaby <julian.calaby@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
"(thermometer < 0) ? 0 : (thermometer == X)" is equivalent to
"thermometer == X" for X >= 0.
Signed-off-by: Ivan Safonov <insafonov@gmail.com>
[Updated commit message]
Signed-off-by: Julian Calaby <julian.calaby@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
If no valid ADC randomness output, ath9k rng will continuously
reading ADC, which will cause high CPU load. So increase the
delay to wait for ADC ready.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114261
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
A cleanup patch in linux-3.18 moved around some code in the ath9k
driver and left some code to be indented in a misleading way,
made worse by the addition of some new code for p2p mode, as
discovered by a new gcc-6 warning:
drivers/net/wireless/ath/ath9k/init.c: In function 'ath9k_set_hw_capab':
drivers/net/wireless/ath/ath9k/init.c:851:4: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation]
hw->wiphy->iface_combinations = if_comb;
^~
drivers/net/wireless/ath/ath9k/init.c:847:3: note: ...this 'if' clause, but it is not
if (ath9k_is_chanctx_enabled())
^~
The code is in fact correct, but the indentation is not, so I'm
reformatting it as it should have been after the original cleanup.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 499afaccf6 ("ath9k: Isolate ath9k_use_chanctx module parameter")
Fixes: eb61f9f623 ("ath9k: advertise p2p dev support when chanctx")
Signed-off-by: David S. Miller <davem@davemloft.net>
Code that was added back in 2.6.38 has an obvious overflow
when accessing a static array, and at the time it was added
only a code comment was put in front of it as a reminder
to have it reviewed properly.
This has not happened, but gcc-6 now points to the specific
overflow:
drivers/net/wireless/ath/ath9k/eeprom.c: In function 'ath9k_hw_get_gain_boundaries_pdadcs':
drivers/net/wireless/ath/ath9k/eeprom.c:483:44: error: array subscript is above array bounds [-Werror=array-bounds]
maxPwrT4[i] = data_9287[idxL].pwrPdg[i][4];
~~~~~~~~~~~~~~~~~~~~~~~~~^~~
It turns out that the correct array length exists in the local
'intercepts' variable of this function, so we can just use that
instead of hardcoding '4', so this patch changes all three
instances to use that variable. The other two instances were
already correct, but it's more consistent this way.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 940cd2c12e ("ath9k_hw: merge the ar9287 version of ath9k_hw_get_gain_boundaries_pdadcs")
Signed-off-by: David S. Miller <davem@davemloft.net>
Allow to set wl_active_time and wl_qc_time for SOC chips, also adjust
bt_time_extend and bt_first_slot_time.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The registers of AR_GPIO_INPUT_MUX1 and AR_GPIO_PDPU were removed
from SOC chips, fix invalid accessing
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Add bits definition for AR_BT_COEX_MODE2 and AR_BT_COEX_MODE3, which
needed by SOC chips (AR9340, AR9531, AR9550, AR9561).
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Add new platform data to allow override BTCoex default pin.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Make ath_init_leds() and ath_deinit_leds() pairs as the only
API to set leds, also removed direction configuration from
ath9k_start() and ath9k_stop(). So the initial is more clear
now.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
For SOC GPIOs, should call ath9k_hw_gpio_free() to release
the GPIO resource.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
commit 61b559dea4 ("ath9k: add extra GPIO led support")
added ath9k to support access SOC's GPIOs, but implemented
in a separated API: ath9k_hw_request_gpio().
So this patch make the APIs more common, to support both
of WMAC and SOC GPIOs. The new APIs as below,
void ath9k_hw_gpio_request_in();
void ath9k_hw_gpio_request_out();
void ath9k_hw_gpio_free();
NOTE, the BSP of the SOC chips(AR9340, AR9531, AR9550, AR9561)
should set the corresponding MUX registers correctly.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Define correct GPIO numbers and MASK bits to indicate the WMAC
GPIO resource.
Allow SOC chips(AR9340, AR9531, AR9550, AR9561) to access all GPIOs
which rely on gpiolib framework. But restrict SOC AR9330 only to
access WMAC GPIO which has the same design with the old chips.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
These lines belong inside the if-statement above, not in the
main body of the switch.
Found by smatch.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
commit f49c90db4d ("ath9k: Add a macro to identify PCOEM chips")
defined AR_SREV_9003_PCOEM macro, its more clear to use the macro
instead of checking one by one. Also removed PCOEM chips checking
in the callback of ar9003_hw_do_pcoem_manual_peak_cal() which only
for PCOEM chips.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
HW peak detect calibration would fail, enable all ar9300
chips manual peak calibration instead.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
HW peak detect calibration would fail for AR9300 chips and
we went for implementing the SW way of doing it instead of
HW doing the peak detect calibration.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
HW peak detect calibration would fail for AR9300 chips and
we went for implementing the SW way of doing it instead of
HW doing the peak detect calibration.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
HW peak detect calibration would fail for AR9300 chips and
we went for implementing the SW way of doing it instead of
HW doing the peak detect calibration.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
HW peak detect calibration would fail for AR9300 chips and
we went for implementing the SW way of doing it instead of
HW doing the peak detect calibration.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
HW peak detect calibration would fail for AR9300 chips and
we went for implementing the SW way of doing it instead of
HW doing the peak detect calibration.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
HW peak detect calibration would fail for AR9300 chips and
we went for implementing the SW way of doing it instead of
HW doing the peak detect calibration.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
HW peak detect calibration would fail for AR9300 chips and
we went for implementing the SW way of doing it instead of
HW doing the peak detect calibration.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
HW peak detect calibration would fail for AR9300 chips and
we went for implementing the SW way of doing it instead of
HW doing the peak detect calibration.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
HW peak detect calibration would fail for AR9300 chips and
we went for implementing the SW way of doing it instead of
HW doing the peak detect calibration.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
commit 14c5932805 ("ath9k: Update QCA953x initvals")
disabled HW peak detect calibartion on QCA953x 1.0, which
should also be applied on 2.0.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath.git patches for 4.6. Major changes:
ath10k
* dt: add bindings for ipq4019 wifi block
* start adding support for qca4019 chip
ath9k
* add device ID for Toshiba WLM-20U2/GN-1080
* allow more than one interface on DFS channels
JP WiFi certification for bandwidth of channel 14 failed, the OBW
is lower than the requirement. Clear the bb filter calibration power
threshold to increase OBW(+2). The fix only for qca9531 chip now.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
In some configurations, this function uses more than the warning limit
of 1024 bytes:
drivers/net/wireless/ath/ath9k/ar9003_aic.c: In function 'ar9003_aic_cal_post_process':
drivers/net/wireless/ath/ath9k/ar9003_aic.c:434:1: error: the frame size of 1040 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
It turns out that there are two large arrays on the stack here, but
almost all the data in them is never used outside of the loop in
which it gets written, so we can replace the array with a single
instance.
The .valid flag is used later, so I'm replacing the array of structures
with an array of bools. An obvious follow-up optimization would be
to replace it with a bitmask and set_bit()/find_first_bit()/
find_last_bit()/... operations. However, I have not tested this patch,
so I sticked to the simpler transformation that does the job of
reducing the stack usage to a harmless level.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Make NF load complete quickly and reliably. NF load execution
is delayed by HW to end of frame if frame Rx or Tx is ongoing.
Increasing timeout to max frame duration. If NF cal is ongoing
before NF load, stop it before load, and restart it afterwards.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
I think this limit was added when CSA with multiple interfaces wasn't
working yet. It should no longer be necessary
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
One crash issue be found on ar9300: RTC_RC reg read leads crash, leading
the data bus error, due to RTC_RC reg write not happen properly.
Warm Reset trigger in continuous beacon stuck for one of the customer for
other chip, noticed the MAC was stuck in RTC reset. After analysis noticed
DMA did not complete when RTC was put in reset.
So, before resetting the MAC need to make sure there are no pending DMA
transactions because this reset does not reset all parts of the chip.
The 12th and 11th bit of MAC _DMA_CFG register used to do that.
12 cfg_halt_ack 0x0
0 DMA has not yet halted
1 DMA has halted
11 cfg_halt_req 0x0
0 DMA logic operates normally
1 Request DMA logic to stop so software can reset the MAC
The Bit [12] of this register indicates when the halt has taken effect or
not. the DMA halt IS NOT recoverable; once software sets bit [11] to
request a DMA halt, software must wait for bit [12] to be set and reset
the MAC.
So, the same thing we implemented for ar9580 chip.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
BB panic(0x4000409) observed while AP enabling/disabling
bursting.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
commit c24bd3620c ("ath9k: Do not maintain ANI state per-channel")
removed per-channel handling, the code to check 'curchan' also
should be removed as never used.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Fixes commit 54da20d83f ("ath9k_hw: improve ANI processing and rx desensitizing parameters")
Call ath9k_ani_restart() only when the phy error rate reach the
ANI immunity threshold. Sync the logic with internal code base.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
drivers/net/wireless/ath/ath9k/channel.c:230: warning: type qualifiers ignored on function return type
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Stanislaw Gruszka