Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 06 10月, 2018 1 次提交
    • L
      iwlwifi: mvm: check for n_profiles validity in EWRD ACPI · 2e1976bb
      由 Luca Coelho 提交于 
      When reading the profiles from the EWRD table in ACPI, we loop over
the data and set it into our internal table.  We use the number of
profiles specified in ACPI without checking its validity, so if the
ACPI table is corrupted and the number is larger than our array size,
we will try to make an out-of-bounds access.

Fix this by making sure the value specified in the ACPI table is
valid.

Fixes: 69964905 ("iwlwifi: mvm: add support for EWRD (Dynamic SAR) ACPI table")
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      2e1976bb
  3. 05 10月, 2018 20 次提交
  5. 02 10月, 2018 7 次提交
    • F
      ath9k: add back support for using active monitor interfaces for tx99 · 6df0580b
      由 Felix Fietkau 提交于 
      Various documented examples on how to set up tx99 with ath9k rely
on setting up a regular monitor interface for setting the channel.
My previous patch "ath9k: fix tx99 with monitor mode interface" made
it possible to set it up this way again. However, it was removing support
for using an active monitor interface, which is required for controlling
the bitrate as well, since the bitrate is not passed down with a regular
monitor interface.

This patch partially reverts the previous one, but keeps support for using
a regular monitor interface to keep documented steps working in cases
where the bitrate does not matter

Fixes: d9c52fd1 ("ath9k: fix tx99 with monitor mode interface")
Signed-off-by: NFelix Fietkau <nbd@nbd.name>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      6df0580b
    • B
      ath10k: add missing sanity check on diag download · e720ba1d
      由 Brian Norris 提交于 
      ath10k_hw_diag_fast_download() generally has good boundary checking, but
it misses verifying that the next metadata header actually fits in the
remaining buffer space. Add such a check.

Fixes: 39501ea6 ("ath10k: download firmware via diag Copy Engine for QCA6174 and QCA9377.")
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      e720ba1d
    • S
      ath9k: fix reporting calculated new FFT upper max · 4fb5837a
      由 Simon Wunderlich 提交于 
      Since the debug print code is outside of the loop, it shouldn't use the loop
iterator anymore but instead print the found maximum index.

Cc: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      4fb5837a
    • S
      ath9k: FFT magnitude check: don't consider lower 3 data bits · 4e7a3fa5
      由 Simon Wunderlich 提交于 
      There were a lot of Magnitude Mismatch while getting FFT samples on my
hardware (Atheros AR9462. I've compared the reported magnitude with
the data in the FFT bin, and the FFT bin was less accurate:

[ 5395.193030] ath: phy0: FFT HT20 frame: max mag 0x89,max_mag_idx 28,
,magnitude 0x89 max_exp 0, data[28] = 0x88
[ 5395.194525] ath: phy0: FFT HT20 frame: max mag 0x89,max_mag_idx 28,
,magnitude 0x89 max_exp 0, data[28] = 0x88
[ 5395.196012] ath: phy0: FFT HT20 frame: max mag 0x88,max_mag_idx 28,
,magnitude 0x88 max_exp 0, data[28] = 0x88
[ 5395.197509] ath: phy0: FFT HT20 frame: max mag 0x6C,max_mag_idx 28,
,magnitude 0x6C max_exp 0, data[28] = 0x68
[ 5395.199015] ath: phy0: FFT HT20 frame: max mag 0x78,max_mag_idx 28,
,magnitude 0x78 max_exp 0, data[28] = 0x78
[ 5395.200497] ath: phy0: FFT HT20 frame: max mag 0xA1,max_mag_idx 28,
,magnitude 0xA1 max_exp 0, data[28] = 0xA0
[ 5395.202011] ath: phy0: FFT HT20 frame: max mag 0x91,max_mag_idx 28,
,magnitude 0x91 max_exp 0, data[28] = 0x90
[ 5395.203482] ath: phy0: FFT HT20 frame: max mag 0x89,max_mag_idx 28,
,magnitude 0x89 max_exp 0, data[28] = 0x88
[ 5395.204999] ath: phy0: FFT HT20 frame: max mag 0x27,max_mag_idx 4,
,magnitude 0x27 max_exp 0, data[4] = 0x20
[ 5395.206461] ath: phy0: FFT HT20 frame: max mag 0x41,max_mag_idx 28,
,magnitude 0x41 max_exp 0, data[28] = 0x40
[ 5395.207977] ath: phy0: FFT HT20 frame: max mag 0x51,max_mag_idx 28,
,magnitude 0x51 max_exp 0, data[28] = 0x50
[ 5395.209454] ath: phy0: FFT HT20 frame: max mag 0x53,max_mag_idx 28,
,magnitude 0x53 max_exp 0, data[28] = 0x50
[ 5395.210940] ath: phy0: FFT HT20 frame: max mag 0x40,max_mag_idx 28,
,magnitude 0x40 max_exp 0, data[28] = 0x40
[ 5395.212441] ath: phy0: FFT HT20 frame: max mag 0x59,max_mag_idx 28,
,magnitude 0x59 max_exp 0, data[28] = 0x58
[ 5395.213932] ath: phy0: FFT HT20 frame: max mag 0x53,max_mag_idx 28,
,magnitude 0x53 max_exp 0, data[28] = 0x50
[ 5395.215428] ath: phy0: FFT HT20 frame: max mag 0x7D,max_mag_idx 28,
,magnitude 0x7D max_exp 0, data[28] = 0x78
[ 5395.216910] ath: phy0: FFT HT20 frame: max mag 0x8C,max_mag_idx 28,
,magnitude 0x8C max_exp 0, data[28] = 0x88
[ 5395.218413] ath: phy0: FFT HT20 frame: max mag 0x7B,max_mag_idx 28,
,magnitude 0x7B max_exp 0, data[28] = 0x78
[ 5395.219900] ath: phy0: FFT HT20 frame: max mag 0x43,max_mag_idx 28,
,magnitude 0x43 max_exp 0, data[28] = 0x40

It seems like the lower 3 bits on my hardware are always zeroed, but the
magnitude matches otherwise. Therefore, let's not make the magnitude
check so strict so we can get those samples released to userspace.

Cc: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      4e7a3fa5
    • S
      ath9k: fix and simplify FFT max index retrieval · 2f85786b
      由 Simon Wunderlich 提交于 
      FFT max index retrieval was not retrieved correctly for HT20/HT40 FFT
frames. Fixing the retrieval allows us to remove the fixup function as
well. While at it, split the spectral_max_index function into versions
for ht20 and ht40 to simplify the code.

Cc: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      2f85786b
    • S
      ath9k: return when short FFT frame was handled · b796a6c0
      由 Simon Wunderlich 提交于 
      With the loop break like this, there are false "FFT report truncated"
messages because the iterator is not advanced as the check expects.

Instead, just return, for a single frame there is nothing left to be
done anyways.

Cc: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      b796a6c0
    • S
      ath9k: add counters for good and errorneous FFT/spectral frames · 03224678
      由 Simon Wunderlich 提交于 
      This is helpful to see whether spectral samples get discarded.
Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      03224678
  7. 01 10月, 2018 12 次提交