lwn.git/drivers/net/wireless/ath/ath9k/hw.h, branch docs-6.1

ath9k: fetch calibration data via nvmem subsystem

2021-09-16T08:07:41+00:00

On most embedded ath9k devices (like range extenders, routers, accesspoints, ...) the calibration data is stored in a MTD partitions named "ART", or "caldata"/ "calibration". Since commit 4b361cfa8624 ("mtd: core: add OTP nvmem provider support"): All MTD partitions are all automatically available through the nvmem subsystem. This feature - together with an nvmem cell definition either in the platform data or via device-tree allows drivers to get the data necessary for initializing the WIFI, without having to wait around for the filesystem and userspace to do the extractions. Signed-off-by: Christian Lamparter Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/f9b732b50a3453fadf3923cc75d365bae3505fe7.1630157099.git.chunkeey@gmail.com

ath9k: Postpone key cache entry deletion for TXQ frames reference it

2020-12-17T06:51:20+00:00

Do not delete a key cache entry that is still being referenced by pending frames in TXQs. This avoids reuse of the key cache entry while a frame might still be transmitted using it. To avoid having to do any additional operations during the main TX path operations, track pending key cache entries in a new bitmap and check whether any pending entries can be deleted before every new key add/remove operation. Also clear any remaining entries when stopping the interface. Signed-off-by: Jouni Malinen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20201214172118.18100-6-jouni@codeaurora.org

ath9k: add calibration timeout for AR9002

2020-04-28T09:07:21+00:00

ADC & I/Q calibrations could take infinite time to comple, since they depend on received frames. In particular the I/Q mismatch calibration requires receiving of OFDM frames for completion. But in the 2.4GHz band, a station could receive only CCK frames for a very long time. And while we wait for the completion of one of the mentioned calibrations, the NF calibration is blocked. Moreover, in some environments, I/Q calibration is unable to complete until a correct noise calibration will be performed due to AGC behaviour. In order to avoid delaying NF calibration on forever, limit the maximum duration of ADCs & I/Q calibrations. If the calibration is not completed within the maximum time, it will be interrupted and a next calibration will be performed. The code that selects the next calibration has been reworked to the loop so incompleted calibration will be respinned later. Ð maximum calibration time of 30 seconds was selected to give the calibration enough time to complete and to not interfere with the long (NF) calibration. Run tested with AR9220. Signed-off-by: Sergey Ryazanov Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200424004923.17129-7-ryazanov.s.a@gmail.com

ath9k: do not miss longcal on AR9002

2020-04-28T09:07:14+00:00

Each of AGC & I/Q calibrations can take a long time. Long calibration and NF calibration in particular are forbiden for parallel run with ADC & I/Q calibrations. So, the chip could not be ready to perform the long calibration at the time of request. And a request to perform the long calibration may be lost. In order to fix this, preserve the long calibration request as a calibration state flag and restore the long calibration request each time the calibration function is called again (i.e. on each subsequent ivocation of the short calibration). This feature will be twice useful after the next change, which will make it possible to start the long calibration before all ADCs & I/Q calibrations are completed. Run tested with AR9220. Signed-off-by: Sergey Ryazanov Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200424004923.17129-4-ryazanov.s.a@gmail.com

ath9k: Differentiate between max combined and per chain power

2019-04-29T14:53:43+00:00

The ath9k driver uses as maximum allowed txpower the constant MAX_RATE_POWER. It is used to set a maximum txpower limit for the PHY (which is combined txpower) and also the maximum txpower for per chain rates. Its value 63 is derived from the maximum number the registers can store for the per chain txpower. The max txpower a user can set because of this is 31 dBm (floor(63 / 2)). This also means that a device with multiple tx chains is even limited further: * 1 chain: 31 dBm per chain * 2 chains: 28 dBm per chain * 3 chains: 26 dBm per chain This combined txpower limit of 31 dBm becomes even more problematic when some extra antenna gain is set in the EEPROM. A high power device is then no longer able to reach its potential limits. Instead the code dealing with the combined txpower must use a higher limit than 63 and only the code dealing with the per chain txpower have to use the limit of 63. Since the antenna gain can be quite large and 8 bit variables are often used in ath9k for txpower, a large, divisible by two number like 254 is a good choice for this new limit. Signed-off-by: Sven Eckelmann Signed-off-by: Kalle Valo

ath9k: use timespec64 for tsf_ts

2018-06-29T11:44:49+00:00

ath9k is the last remaining user of the deprecated getrawmonotonic() interface. There is nothing wrong with this usage, but migrating to a timespec64 based interface lets us clean up the old API. Signed-off-by: Arnd Bergmann Signed-off-by: Kalle Valo

ath9k: Read noise floor calibration data from eeprom

2018-01-25T05:33:36+00:00

AR9003 devices can have calibrated noise floor values which can be used instead of hard coded one. Read them from eeprom and save interpolated value in nf limits for the current channel. Signed-off-by: Wojciech Dubowik Signed-off-by: Kalle Valo

ath9k: add MSI support

2018-01-16T14:29:22+00:00

On new Intel platforms like ApolloLake, legacy interrupt mechanism (INTx) is not supported, so WLAN modules are not working because interrupts are missing, therefore this patch is to add MSI support to ath9k. With module paremeter "use_msi=1", ath9k driver would try to use MSI instead of INTx. Signed-off-by: Russell Hu Signed-off-by: Kalle Valo

ath9k: add noise floor override option

2017-04-19T14:08:27+00:00

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 Signed-off-by: Mathias Kretschmer Signed-off-by: Kalle Valo

Revert "ath9k_hw: implement temperature compensation support for AR9003+"

2016-10-13T11:11:30+00:00

This reverts commit 171f6402e4aa ("ath9k_hw: implement temperature compensation support for AR9003+"). Some users report that this commit causes a regression in performance under some conditions. Fixes: 171f6402e4aa ("ath9k_hw: implement temperature compensation support for AR9003+") Cc: # 4.8 Signed-off-by: Felix Fietkau [kvalo@qca.qualcomm.com: improve commit log] Signed-off-by: Kalle Valo