|
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6, v6.14-rc5, v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1, v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4, v6.13-rc3, v6.13-rc2, v6.13-rc1, v6.12, v6.12-rc7, v6.12-rc6, v6.12-rc5, v6.12-rc4, v6.12-rc3, v6.12-rc2, v6.12-rc1, v6.11, v6.11-rc7, v6.11-rc6, v6.11-rc5, v6.11-rc4, v6.11-rc3, v6.11-rc2, v6.11-rc1, v6.10, v6.10-rc7, v6.10-rc6, v6.10-rc5, v6.10-rc4, v6.10-rc3, v6.10-rc2, v6.10-rc1, v6.9, v6.9-rc7, v6.9-rc6, v6.9-rc5, v6.9-rc4, v6.9-rc3, v6.9-rc2, v6.9-rc1, v6.8, v6.8-rc7, v6.8-rc6, v6.8-rc5, v6.8-rc4, v6.8-rc3, v6.8-rc2, v6.8-rc1, v6.7, v6.7-rc8, v6.7-rc7, v6.7-rc6, v6.7-rc5, v6.7-rc4, v6.7-rc3, v6.7-rc2, v6.7-rc1, v6.6, v6.6-rc7, v6.6-rc6, v6.6-rc5, v6.6-rc4, v6.6-rc3, v6.6-rc2, v6.6-rc1, v6.5, v6.5-rc7, v6.5-rc6, v6.5-rc5, v6.5-rc4, v6.5-rc3, v6.5-rc2, v6.5-rc1, v6.4, v6.4-rc7, v6.4-rc6, v6.4-rc5, v6.4-rc4, v6.4-rc3, v6.4-rc2, v6.4-rc1, v6.3, v6.3-rc7, v6.3-rc6, v6.3-rc5, v6.3-rc4, v6.3-rc3, v6.3-rc2, v6.3-rc1, v6.2, v6.2-rc8, v6.2-rc7, v6.2-rc6, v6.2-rc5, v6.2-rc4, v6.2-rc3, v6.2-rc2, v6.2-rc1, v6.1, v6.1-rc8, v6.1-rc7, v6.1-rc6, v6.1-rc5, v6.1-rc4, v6.1-rc3, v6.1-rc2, v6.1-rc1 |
|
| #
d1747689 |
| 06-Oct-2022 |
Kees Cook <[email protected]> |
wifi: ath9k: Remove -Warray-bounds exception
GCC-12 emits false positive -Warray-bounds warnings with CONFIG_UBSAN_SHIFT (-fsanitize=shift). This is fixed in GCC 13[1], and there is top-level Makefi
wifi: ath9k: Remove -Warray-bounds exception
GCC-12 emits false positive -Warray-bounds warnings with CONFIG_UBSAN_SHIFT (-fsanitize=shift). This is fixed in GCC 13[1], and there is top-level Makefile logic to remove -Warray-bounds for known-bad GCC versions staring with commit f0be87c42cbd ("gcc-12: disable '-Warray-bounds' universally for now").
Remove the local work-around.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679
Signed-off-by: Kees Cook <[email protected]> Acked-by: Toke Høiland-Jørgensen <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
|
Revision tags: v6.0, v6.0-rc7, v6.0-rc6, v6.0-rc5, v6.0-rc4, v6.0-rc3, v6.0-rc2, v6.0-rc1, v5.19, v5.19-rc8, v5.19-rc7, v5.19-rc6, v5.19-rc5, v5.19-rc4, v5.19-rc3, v5.19-rc2, v5.19-rc1, v5.18 |
|
| #
e9503298 |
| 20-May-2022 |
Jakub Kicinski <[email protected]> |
wifi: ath9k: silence array-bounds warning on GCC 12
GCC 12 says:
drivers/net/wireless/ath/ath9k/mac.c: In function ‘ath9k_hw_resettxqueue’: drivers/net/wireless/ath/ath9k/mac.c:373:22: warning: arr
wifi: ath9k: silence array-bounds warning on GCC 12
GCC 12 says:
drivers/net/wireless/ath/ath9k/mac.c: In function ‘ath9k_hw_resettxqueue’: drivers/net/wireless/ath/ath9k/mac.c:373:22: warning: array subscript 32 is above array bounds of ‘struct ath9k_tx_queue_info[10]’ [-Warray-bounds] 373 | qi = &ah->txq[q]; | ~~~~~~~^~~
I don't know where it got the 32 from, relegate the warning to W=1+.
Acked-by: Kalle Valo <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
show more ...
|
|
Revision tags: v5.18-rc7, v5.18-rc6, v5.18-rc5, v5.18-rc4, v5.18-rc3, v5.18-rc2, v5.18-rc1, v5.17, v5.17-rc8, v5.17-rc7, v5.17-rc6, v5.17-rc5, v5.17-rc4, v5.17-rc3, v5.17-rc2, v5.17-rc1, v5.16, v5.16-rc8, v5.16-rc7, v5.16-rc6, v5.16-rc5, v5.16-rc4, v5.16-rc3, v5.16-rc2, v5.16-rc1, v5.15, v5.15-rc7, v5.15-rc6, v5.15-rc5, v5.15-rc4, v5.15-rc3, v5.15-rc2, v5.15-rc1, v5.14, v5.14-rc7, v5.14-rc6, v5.14-rc5, v5.14-rc4, v5.14-rc3, v5.14-rc2, v5.14-rc1, v5.13, v5.13-rc7, v5.13-rc6, v5.13-rc5, v5.13-rc4, v5.13-rc3, v5.13-rc2, v5.13-rc1, v5.12, v5.12-rc8, v5.12-rc7, v5.12-rc6, v5.12-rc5, v5.12-rc4, v5.12-rc3, v5.12-rc2, v5.12-rc1, v5.12-rc1-dontuse, v5.11, v5.11-rc7, v5.11-rc6, v5.11-rc5, v5.11-rc4, v5.11-rc3, v5.11-rc2, v5.11-rc1, v5.10, v5.10-rc7, v5.10-rc6, v5.10-rc5, v5.10-rc4, v5.10-rc3, v5.10-rc2, v5.10-rc1, v5.9, v5.9-rc8, v5.9-rc7, v5.9-rc6, v5.9-rc5, v5.9-rc4, v5.9-rc3, v5.9-rc2, v5.9-rc1, v5.8, v5.8-rc7, v5.8-rc6, v5.8-rc5, v5.8-rc4, v5.8-rc3, v5.8-rc2, v5.8-rc1, v5.7, v5.7-rc7, v5.7-rc6, v5.7-rc5, v5.7-rc4, v5.7-rc3, v5.7-rc2, v5.7-rc1, v5.6, v5.6-rc7, v5.6-rc6, v5.6-rc5, v5.6-rc4, v5.6-rc3, v5.6-rc2, v5.6-rc1, v5.5, v5.5-rc7, v5.5-rc6, v5.5-rc5, v5.5-rc4, v5.5-rc3, v5.5-rc2, v5.5-rc1, v5.4, v5.4-rc8, v5.4-rc7, v5.4-rc6, v5.4-rc5, v5.4-rc4, v5.4-rc3, v5.4-rc2, v5.4-rc1, v5.3, v5.3-rc8, v5.3-rc7, v5.3-rc6, v5.3-rc5, v5.3-rc4, v5.3-rc3, v5.3-rc2, v5.3-rc1, v5.2 |
|
| #
5a4f2040 |
| 05-Jul-2019 |
Christian Lamparter <[email protected]> |
ath9k: add loader for AR92XX (and older) pci(e)
Atheros cards with a AR92XX generation (and older) chip usually store their pci(e) initialization vectors on an external eeprom chip. However these ch
ath9k: add loader for AR92XX (and older) pci(e)
Atheros cards with a AR92XX generation (and older) chip usually store their pci(e) initialization vectors on an external eeprom chip. However these chips technically don't need the eeprom chip attached, the AR9280 Datasheet in section "6.1.2 DEVICE_ID" describes that "... if the EEPROM content is not valid, a value of 0xFF1C returns when read from the register". So, they will show up on the system's pci bus. However in that state, ath9k can't load, since it relies on having the correct pci-id, otherwise it doesn't know what chip it actually is. This happens on many embedded devices like routers and accesspoint since they want to keep the BOM low and store the pci(e) initialization vectors together with the calibration data on the system's FLASH, which is out of reach of the ath9k chip.
Furthermore, Some devices (like the Cisco Meraki Z1 Cloud Managed Teleworker Gateway) need to be able to initialize the PCIe wifi device. Normally, this should be done as a pci quirk during the early stages of booting linux. However, this isn't possible for devices which have the init code for the Atheros chip stored on NAND in an UBI volume. Hence, this module can be used to initialize the chip when the user-space is ready to extract the init code.
Martin Blumenstingl prodived the following fixes: owl-loader: add support for OWL emulation PCI devices owl-loader: don't re-scan the bus when ath9k_pci_fixup failed owl-loader: use dev_* instead of pr_* logging functions owl-loader: auto-generate the eeprom filename as fallback owl-loader: add a debug message when swapping the eeprom data owl-loader: add missing newlines in log messages
Reviewed-by: Julian Calaby <[email protected]> Signed-off-by: Christian Lamparter <[email protected]> Signed-off-by: Martin Blumenstingl <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
show more ...
|
|
Revision tags: v5.2-rc7 |
|
| #
0766789b |
| 25-Jun-2019 |
Kalle Valo <[email protected]> |
ath: fix SPDX tags
Commit ec8f24b7faaf ("treewide: Add SPDX license identifier - Makefile/Kconfig") marked various Makefiles and Kconfig files within ath directories as GPL-2.0. But these modules an
ath: fix SPDX tags
Commit ec8f24b7faaf ("treewide: Add SPDX license identifier - Makefile/Kconfig") marked various Makefiles and Kconfig files within ath directories as GPL-2.0. But these modules and drivers are actually ISC:
* ath * ar5523 * ath10k * ath5k * ath6kl * ath9k * wcn36xx * wil6210
Fix SPDX tags accordingly.
Signed-off-by: Kalle Valo <[email protected]>
show more ...
|
|
Revision tags: v5.2-rc6, v5.2-rc5, v5.2-rc4, v5.2-rc3, v5.2-rc2, v5.2-rc1, v5.1, v5.1-rc7, v5.1-rc6, v5.1-rc5, v5.1-rc4, v5.1-rc3, v5.1-rc2, v5.1-rc1, v5.0, v5.0-rc8, v5.0-rc7, v5.0-rc6, v5.0-rc5, v5.0-rc4, v5.0-rc3, v5.0-rc2, v5.0-rc1, v4.20, v4.20-rc7, v4.20-rc6, v4.20-rc5, v4.20-rc4, v4.20-rc3, v4.20-rc2, v4.20-rc1, v4.19, v4.19-rc8, v4.19-rc7, v4.19-rc6, v4.19-rc5, v4.19-rc4, v4.19-rc3, v4.19-rc2, v4.19-rc1, v4.18, v4.18-rc8, v4.18-rc7, v4.18-rc6, v4.18-rc5, v4.18-rc4, v4.18-rc3, v4.18-rc2, v4.18-rc1, v4.17, v4.17-rc7, v4.17-rc6, v4.17-rc5, v4.17-rc4, v4.17-rc3, v4.17-rc2, v4.17-rc1, v4.16, v4.16-rc7, v4.16-rc6, v4.16-rc5, v4.16-rc4, v4.16-rc3, v4.16-rc2, v4.16-rc1, v4.15, v4.15-rc9, v4.15-rc8, v4.15-rc7, v4.15-rc6, v4.15-rc5, v4.15-rc4, v4.15-rc3, v4.15-rc2 |
|
| #
9df7ddc3 |
| 27-Nov-2017 |
Matthias Schiffer <[email protected]> |
ath9k: move spectral scan support under a separate config symbol
At the moment, spectral scan support, and with it RELAY, is always enabled with ATH9K[_HTC]_DEBUGFS. Spectral scan support is current
ath9k: move spectral scan support under a separate config symbol
At the moment, spectral scan support, and with it RELAY, is always enabled with ATH9K[_HTC]_DEBUGFS. Spectral scan support is currently the only user of RELAY in ath9k, and it unconditionally reserves a relay channel.
Having debugfs support in ath9k is often useful even on very small embedded routers, where we'd rather like to avoid the code size and RAM usage of the relay support.
Signed-off-by: Matthias Schiffer <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
show more ...
|
|
Revision tags: v4.15-rc1, v4.14, v4.14-rc8 |
|
| #
b2441318 |
| 01-Nov-2017 |
Greg Kroah-Hartman <[email protected]> |
License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine
License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license identifiers to apply.
- when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary:
SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became the concluded license(s).
- when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time.
In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related.
Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches.
Reviewed-by: Kate Stewart <[email protected]> Reviewed-by: Philippe Ombredanne <[email protected]> Reviewed-by: Thomas Gleixner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
|
Revision tags: v4.14-rc7, v4.14-rc6, v4.14-rc5, v4.14-rc4, v4.14-rc3, v4.14-rc2, v4.14-rc1, v4.13, v4.13-rc7, v4.13-rc6, v4.13-rc5, v4.13-rc4, v4.13-rc3, v4.13-rc2, v4.13-rc1, v4.12, v4.12-rc7, v4.12-rc6, v4.12-rc5, v4.12-rc4, v4.12-rc3, v4.12-rc2, v4.12-rc1, v4.11, v4.11-rc8, v4.11-rc7, v4.11-rc6, v4.11-rc5, v4.11-rc4, v4.11-rc3, v4.11-rc2, v4.11-rc1, v4.10, v4.10-rc8, v4.10-rc7, v4.10-rc6, v4.10-rc5, v4.10-rc4 |
|
| #
1077ec47 |
| 12-Jan-2017 |
Christian Lamparter <[email protected]> |
ath9k: move RELAY and DEBUG_FS to ATH9K[_HTC]_DEBUGFS
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
ath9k: move RELAY and DEBUG_FS to ATH9K[_HTC]_DEBUGFS
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 <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
show more ...
|
|
Revision tags: v4.10-rc3, v4.10-rc2, v4.10-rc1, v4.9, v4.9-rc8, v4.9-rc7, v4.9-rc6, v4.9-rc5, v4.9-rc4, v4.9-rc3, v4.9-rc2, v4.9-rc1, v4.8, v4.8-rc8, v4.8-rc7, v4.8-rc6, v4.8-rc5, v4.8-rc4, v4.8-rc3, v4.8-rc2, v4.8-rc1, v4.7, v4.7-rc7, v4.7-rc6, v4.7-rc5, v4.7-rc4, v4.7-rc3, v4.7-rc2, v4.7-rc1, v4.6, v4.6-rc7, v4.6-rc6, v4.6-rc5, v4.6-rc4, v4.6-rc3, v4.6-rc2, v4.6-rc1, v4.5, v4.5-rc7, v4.5-rc6, v4.5-rc5, v4.5-rc4, v4.5-rc3, v4.5-rc2, v4.5-rc1, v4.4, v4.4-rc8, v4.4-rc7, v4.4-rc6, v4.4-rc5, v4.4-rc4, v4.4-rc3, v4.4-rc2, v4.4-rc1, v4.3, v4.3-rc7, v4.3-rc6, v4.3-rc5 |
|
| #
ed14dc0a |
| 09-Oct-2015 |
Miaoqing Pan <[email protected]> |
ath9k: feeding entropy in kernel from ADC capture
This patch is derived from commit 6301566e0b2d ("ath9k: export HW random number generator"),
We evaluated the entropy of the ADC data on QCA9531, Q
ath9k: feeding entropy in kernel from ADC capture
This patch is derived from commit 6301566e0b2d ("ath9k: export HW random number generator"),
We evaluated the entropy of the ADC data on QCA9531, QCA9561, QCA955x, and AR9340, and it has sufficient quality random data (at least 10 bits and up to 22 bits of min-entropy for a 32-bit value). We conservatively assume the min-entropy is 10 bits out of 32 bits. Thus, ATH9K_RNG_BUF_SIZE is set to 320 (u32) i.e., 1.25 kilobytes of data is inserted to fill up the pool as soon as the entropy counter becomes 896/4096 (set by random.c). Since ADC was not designed to be a dedicated HW RNG, we do not want to bind it to /dev/hwrng framework directly. This patch feeds the entropy directly from the WiFi driver to the input pool. The ADC register output is only used as a seed for the Linux entropy pool. No conditioning is needed, since all the conditioning is performed by the pool itself.
Signed-off-by: Miaoqing Pan <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
show more ...
|
|
Revision tags: v4.3-rc4, v4.3-rc3, v4.3-rc2, v4.3-rc1, v4.2, v4.2-rc8, v4.2-rc7, v4.2-rc6, v4.2-rc5 |
|
| #
360d9bb5 |
| 31-Jul-2015 |
Kalle Valo <[email protected]> |
Revert "ath9k: export HW random number generator"
This reverts commit 6301566e0b2dafa7d6779598621bca867962a0a2. Oleksij Rempel noticed that the randomness doesn't look to be good enough and Stephan
Revert "ath9k: export HW random number generator"
This reverts commit 6301566e0b2dafa7d6779598621bca867962a0a2. Oleksij Rempel noticed that the randomness doesn't look to be good enough and Stephan Mueller commented:
"I would say that the discussed RNG does not seem fit for hooking it up with the hwrandom framework."
http://lkml.kernel.org/g/[email protected]
So let's the revert the patch until we are sure that we can trust this random generator.
Signed-off-by: Kalle Valo <[email protected]>
show more ...
|
|
Revision tags: v4.2-rc4, v4.2-rc3 |
|
| #
6301566e |
| 15-Jul-2015 |
Miaoqing Pan <[email protected]> |
ath9k: export HW random number generator
We measured the FFT-based entropy in 3 ways, Shannon entropy, collision entropy, and directly measured min-entropy. Just to be conservative, we recommend the
ath9k: export HW random number generator
We measured the FFT-based entropy in 3 ways, Shannon entropy, collision entropy, and directly measured min-entropy. Just to be conservative, we recommend the estimated min-Entropy to be 10 bits per 16-bit value.
Analysis was done by Jacobson,David([email protected]).
Signed-off-by: Miaoqing Pan <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
show more ...
|
|
Revision tags: v4.2-rc2, v4.2-rc1, v4.1, v4.1-rc8, v4.1-rc7, v4.1-rc6, v4.1-rc5, v4.1-rc4, v4.1-rc3, v4.1-rc2, v4.1-rc1, v4.0, v4.0-rc7, v4.0-rc6, v4.0-rc5, v4.0-rc4 |
|
| #
637625f2 |
| 14-Mar-2015 |
Sujith Manoharan <[email protected]> |
ath9k: Register private AIC ops
AIC can be disabled or enabled on a per-card basis using MCI configuration, so register a function to check its status.
Signed-off-by: Sujith Manoharan <c_manoha@qca
ath9k: Register private AIC ops
AIC can be disabled or enabled on a per-card basis using MCI configuration, so register a function to check its status.
Signed-off-by: Sujith Manoharan <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
show more ...
|
|
Revision tags: v4.0-rc3, v4.0-rc2, v4.0-rc1, v3.19, v3.19-rc7, v3.19-rc6, v3.19-rc5, v3.19-rc4, v3.19-rc3, v3.19-rc2, v3.19-rc1, v3.18, v3.18-rc7, v3.18-rc6, v3.18-rc5, v3.18-rc4 |
|
| #
67dc74f1 |
| 06-Nov-2014 |
Oleksij Rempel <[email protected]> |
ath9k: move spectral.* to common-spectral.*
and rename exports from ath9k_spectral_* to ath9k_cmn_spectral_*
Signed-off-by: Oleksij Rempel <[email protected]> Signed-off-by: John W. Linville <
ath9k: move spectral.* to common-spectral.*
and rename exports from ath9k_spectral_* to ath9k_cmn_spectral_*
Signed-off-by: Oleksij Rempel <[email protected]> Signed-off-by: John W. Linville <[email protected]>
show more ...
|
|
Revision tags: v3.18-rc3, v3.18-rc2 |
|
| #
935477ed |
| 25-Oct-2014 |
Felix Fietkau <[email protected]> |
ath9k_hw: make support for PC-OEM cards optional
The initvals use up quite a bit of space, and PC-OEM support is typically not needed on embedded systems
Signed-off-by: Felix Fietkau <[email protected]
ath9k_hw: make support for PC-OEM cards optional
The initvals use up quite a bit of space, and PC-OEM support is typically not needed on embedded systems
Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: John W. Linville <[email protected]>
show more ...
|
|
Revision tags: v3.18-rc1, v3.17, v3.17-rc7, v3.17-rc6 |
|
| #
ce719152 |
| 16-Sep-2014 |
Lorenzo Bianconi <[email protected]> |
ath9k: add config for (en|dis)abling ACK timeout estimation
Add ACK timeout estimation algorithm to ath9k Makefile and Kconfig
Signed-off-by: Lorenzo Bianconi <[email protected]> Signed-
ath9k: add config for (en|dis)abling ACK timeout estimation
Add ACK timeout estimation algorithm to ath9k Makefile and Kconfig
Signed-off-by: Lorenzo Bianconi <[email protected]> Signed-off-by: John W. Linville <[email protected]>
show more ...
|
|
Revision tags: v3.17-rc5, v3.17-rc4, v3.17-rc3, v3.17-rc2, v3.17-rc1, v3.16, v3.16-rc7, v3.16-rc6, v3.16-rc5, v3.16-rc4, v3.16-rc3, v3.16-rc2, v3.16-rc1 |
|
| #
fbbcd146 |
| 11-Jun-2014 |
Felix Fietkau <[email protected]> |
ath9k: Add channel context structure
The channel context structure is defined to enable multi-channel concurrency support.
Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Rajkumar Man
ath9k: Add channel context structure
The channel context structure is defined to enable multi-channel concurrency support.
Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Rajkumar Manoharan <[email protected]> Signed-off-by: John W. Linville <[email protected]>
show more ...
|
|
Revision tags: v3.15, v3.15-rc8, v3.15-rc7, v3.15-rc6 |
|
| #
f2c3c952 |
| 11-May-2014 |
Oleksij Rempel <[email protected]> |
ath9k-common: create common-debug and move modal_eeprom to cmn
Signed-off-by: Oleksij Rempel <[email protected]> Signed-off-by: John W. Linville <[email protected]>
|
|
Revision tags: v3.15-rc5, v3.15-rc4, v3.15-rc3, v3.15-rc2, v3.15-rc1, v3.14, v3.14-rc8, v3.14-rc7, v3.14-rc6, v3.14-rc5 |
|
| #
cbbdf2ae |
| 01-Mar-2014 |
Oleksij Rempel <[email protected]> |
ath9k: move ath9k_beacon_config_sta to common-beacon
Signed-off-by: Oleksij Rempel <[email protected]> Signed-off-by: John W. Linville <[email protected]>
|
| #
13f71050 |
| 25-Feb-2014 |
Oleksij Rempel <[email protected]> |
ath9k: move ath9k_init_channels_rates to common-init
and rename it to ath9k_cmn_init_channels_rates. sbands are move to ath_common as well.
Signed-off-by: Oleksij Rempel <[email protected]> Si
ath9k: move ath9k_init_channels_rates to common-init
and rename it to ath9k_cmn_init_channels_rates. sbands are move to ath_common as well.
Signed-off-by: Oleksij Rempel <[email protected]> Signed-off-by: John W. Linville <[email protected]>
show more ...
|
|
Revision tags: v3.14-rc4, v3.14-rc3, v3.14-rc2 |
|
| #
9e495a26 |
| 06-Feb-2014 |
Sujith Manoharan <[email protected]> |
ath9k: Remove ath9k rate control
There is no benefit in retaining the legacy rate control module in the driver codebase.
It is known to be buggy and has less than optimal performance in real-world
ath9k: Remove ath9k rate control
There is no benefit in retaining the legacy rate control module in the driver codebase.
It is known to be buggy and has less than optimal performance in real-world environments compared with minstrel. The only reason that it was kept when we made the switch to minstrel as default was that it showed higher throughput numbers in a clean/ideal environment.
This is no longer the case and minstrel can push ath9k to the same throughput levels. In TCP, with 3-stream cards, more than 295 Mbps can be obtained in open air, with 2-stream cards, 210 Mbps is easily reached. To test performance issues, instead of using a broken rate control module, it is better to use the fixed-rate interface provided by mac80211 anyway.
The ath9k RC has not received any bug fixes in years and is just bit-rotting away - this patch removes it.
Signed-off-by: Sujith Manoharan <[email protected]> Signed-off-by: John W. Linville <[email protected]>
show more ...
|
|
Revision tags: v3.14-rc1, v3.13 |
|
| #
1cdbaf0d |
| 13-Jan-2014 |
Sujith Manoharan <[email protected]> |
ath9k: Add an option for station statistics
Also, rename node_stat to node_aggr.
Signed-off-by: Sujith Manoharan <[email protected]> Signed-off-by: John W. Linville <[email protected]>
|
|
Revision tags: v3.13-rc8, v3.13-rc7, v3.13-rc6, v3.13-rc5 |
|
| #
f65c0825 |
| 18-Dec-2013 |
Sujith Manoharan <[email protected]> |
ath9k: Cleanup spectral scan code
* Move definitions to spectral.h * Move processing/debug code to spectral.c
Signed-off-by: Sujith Manoharan <[email protected]> Signed-off-by: John W. Linv
ath9k: Cleanup spectral scan code
* Move definitions to spectral.h * Move processing/debug code to spectral.c
Signed-off-by: Sujith Manoharan <[email protected]> Signed-off-by: John W. Linville <[email protected]>
show more ...
|
|
Revision tags: v3.13-rc4, v3.13-rc3, v3.13-rc2, v3.13-rc1, v3.12 |
|
| #
e60001e7 |
| 28-Oct-2013 |
Sujith Manoharan <[email protected]> |
ath9k: Use CONFIG_ATH9K_WOW
Move the WoW code to wow.c and compile it conditionally based on CONFIG_ATH9K_WOW.
Signed-off-by: Sujith Manoharan <[email protected]> Signed-off-by: John W. Lin
ath9k: Use CONFIG_ATH9K_WOW
Move the WoW code to wow.c and compile it conditionally based on CONFIG_ATH9K_WOW.
Signed-off-by: Sujith Manoharan <[email protected]> Signed-off-by: John W. Linville <[email protected]>
show more ...
|
| #
9c9cb10f |
| 28-Oct-2013 |
Sujith Manoharan <[email protected]> |
ath9k: Fix wow.c compilation
The HW routines to set various WoW registers are present in wow.c. For some reason, it has been compiled as part of the main ath9k.ko module all this time, when it shoul
ath9k: Fix wow.c compilation
The HW routines to set various WoW registers are present in wow.c. For some reason, it has been compiled as part of the main ath9k.ko module all this time, when it should really be part of ath9k_hw.ko. This patch renames the file to ar9003_wow.ko and adds it to ath9k_hw.ko.
Signed-off-by: Sujith Manoharan <[email protected]> Signed-off-by: John W. Linville <[email protected]>
show more ...
|
|
Revision tags: v3.12-rc7 |
|
| #
ef6b19e4 |
| 24-Oct-2013 |
Sujith Manoharan <[email protected]> |
ath9k: Fix TX99 config option usage
Use CONFIG_ATH9K_TX99 to properly enclose the tx99 code and make sure that it is not compiled as part of the driver when it is not selected. Move the tx99 code to
ath9k: Fix TX99 config option usage
Use CONFIG_ATH9K_TX99 to properly enclose the tx99 code and make sure that it is not compiled as part of the driver when it is not selected. Move the tx99 code to a new file tx99.c and also add ATH9K_DEBUGFS as a dependency in Kconfig.
This reduces the module size on platforms like OpenWrt where ATH9K_DEBUGFS is selected, but TX99 might be disabled.
Cc: Luis R. Rodriguez <[email protected]> Signed-off-by: Sujith Manoharan <[email protected]> Signed-off-by: John W. Linville <[email protected]>
show more ...
|
|
Revision tags: v3.12-rc6 |
|
| #
ad40d3da |
| 14-Oct-2013 |
Janusz Dziedzic <[email protected]> |
ath9k/ath: move dfs pattern detector to ath
Move the DFS pattern detector code to the ath module so the other Atheros drivers can make us of it. This makes no functional changes.
Signed-off-by: Jan
ath9k/ath: move dfs pattern detector to ath
Move the DFS pattern detector code to the ath module so the other Atheros drivers can make us of it. This makes no functional changes.
Signed-off-by: Janusz Dziedzic <[email protected]> Reviewed-by: Luis R. Rodriguez <[email protected]> Signed-off-by: John W. Linville <[email protected]>
show more ...
|