Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 23 12月, 2019 5 次提交
    • L
      iwlwifi: mvm: fix NVM check for 3168 devices · b3f20e09
      由 Luca Coelho 提交于 
      We had a check on !NVM_EXT and then a check for NVM_SDP in the else
block of this if.  The else block, obviously, could only be reached if
using NVM_EXT, so it would never be NVM_SDP.

Fix that by checking whether the nvm_type is IWL_NVM instead of
checking for !IWL_NVM_EXT to solve this issue.
Reported-by: NStefan Sperling <stsp@stsp.name>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      b3f20e09
    • L
      iwlwifi: fix TLV fragment allocation loop · 4f565ee2
      由 Luca Coelho 提交于 
      In the allocation loop, "pages" will never become zero (because of the
DIV_ROUND_UP), so if we can't allocate any size and pages becomes 1,
we will keep trying to allocate 1 page until it succeeds.  And in that
case, as coverity reported, block will never be NULL.
Reported-by: Ncoverity-bot <keescook+coverity-bot@chromium.org>
Addresses-Coverity-ID: 1487402 ("Control flow issues")
Fixes: 14124b25 ("iwlwifi: dbg_ini: implement monitor allocation flow")
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Fixes: 14124b25 ("iwlwifi: dbg_ini: implement monitor allocation flow")
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      4f565ee2
    • J
      iwlwifi: pcie: allocate smaller dev_cmd for TX headers · a89c72ff
      由 Johannes Berg 提交于 
      As noted in the previous commit, due to the way we allocate the
dev_cmd headers with 324 byte size, and 4/8 byte alignment, the
part we use of them (bytes 20..40-68) could still cross a page
and thus 2^32 boundary.

Address this by using alignment to ensure that the allocation
cannot cross a page boundary, on hardware that's affected. To
make that not cause more memory consumption, reduce the size of
the allocations to the necessary size - we go from 324 bytes in
each allocation to 60/68 on gen2 depending on family, and ~120
or so on gen1 (so on gen1 it's a pure reduction in size, since
we don't need alignment there).

To avoid size and clearing issues, add a new structure that's
just the header, and use kmem_cache_zalloc().
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      a89c72ff
    • J
      iwlwifi: pcie: detect the DMA bug and warn if it happens · c5a4e8eb
      由 Johannes Berg 提交于 
      Warn if the DMA bug is going to happen. We don't have a good
way of actually aborting in this case and we have workarounds
in place for the cases where it happens, but in order to not
be surprised add a safety-check and warn.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      c5a4e8eb
    • J
      iwlwifi: pcie: work around DMA hardware bug · c4a786b3
      由 Johannes Berg 提交于 
      There's a hardware bug in the flow handler (DMA engine), if the
address + len of some TB wraps around a 2^32 boundary, the carry
bit is then carried over into the next TB.

Work around this by copying the data to a new page when we find
this situation, and then copy it in a way that we cannot hit the
very end of the page.

To be able to free the new page again later we need to chain it
to the TSO page, use the last pointer there to make sure we can
never use the page fully for DMA, and thus cannot cause the same
overflow situation on this page.

This leaves a few potential places (where we didn't observe the
problem) unaddressed:
 * The second TB could reach or cross the end of a page (and thus
   2^32) due to the way we allocate the dev_cmd for the header
 * For host commands, a similar thing could happen since they're
   just kmalloc().
We'll address these in further commits.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      c4a786b3
  3. 20 12月, 2019 2 次提交
  5. 10 12月, 2019 2 次提交
  7. 28 11月, 2019 1 次提交
  9. 20 11月, 2019 14 次提交
  11. 15 11月, 2019 16 次提交