Skip to content

K
Kernel

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

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 23 12月, 2019 8 次提交
    • J
      iwlwifi: pcie: extend hardware workaround to context-info · d84a7a65
      由 Johannes Berg 提交于 
      After more investigation on the hardware side, it appears that the
hardware bug regarding 2^32 boundary reaching/crossing also affects
other uses of the DMA engine, in particular the ones triggered by
the context-info (image loader) mechanism.

It also turns out that the bug only affects devices with gen2 TX
hardware engine, so we don't need to change context info for gen3.
The TX path workarounds are simpler to still keep for both though.

Add the workaround to that code as well; this is a lot simpler as
we have just a single way to allocate DMA memory there.

I made the algorithm recursive (with a small limit) since it's
actually (almost) impossible to hit this today - dma_alloc_coherent
is currently documented to always return 32-bit addressable memory
regardless of the DMA mask for it, and so we could only get REALLY
unlucky to get the very last page in that area.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      d84a7a65
    • H
      iwlwifi: Don't ignore the cap field upon mcc update · 2763bba6
      由 Haim Dreyfuss 提交于 
      When receiving a new MCC driver get all the data about the new country
code and its regulatory information.
Mistakenly, we ignored the cap field, which includes global regulatory
information which should be applies to every channel.
Fix it.
Signed-off-by: NHaim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      2763bba6
    • J
      iwlwifi: mvm: report TX rate to mac80211 directly for RS offload · ed780545
      由 Johannes Berg 提交于 
      If we have offloaded rate scaling, which is always true for those
devices supporting HE, then report the TX rate directly from the
data the firmware gives us, instead of only passing it to mac80211
on frame status only and for it to track it.

First of all, this makes us always report the last good rate that
the rate scaling algorithm picked, which is better than reporting
the last rate for any frame since management frames etc. are sent
with very low rates and could interfere.

Additionally, this allows us to properly report HE rates, though
in case there's a lot of trigger-based traffic, we don't get any
choice in the rates and don't report that properly right now.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      ed780545
    • 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 13 次提交