Skip to content

K
Kernel

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

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 15 1月, 2021 1 次提交
  3. 08 12月, 2020 1 次提交
  5. 03 12月, 2020 1 次提交
    • C
      rtw88: coex: add function to avoid cck lock · 8e6947dc
      由 Ching-Te Ku 提交于 
      Some AP will not follow the power save request, or it cannot stop
transmission until its queue is empty. It may bring the decreasing of
data rate.

WLAN firmware will count is the AP still leaked packet after power save
handshake was done or not to enable WLAN slot extend mechanism.

The extend WLAN slot mechanism will extend the WLAN slot after power save
handshake, 5 ms per times, maximum is 5 times to received the leaked packet
to avoid the rate lower down.

And if the transmission was already locked at CCK rate.
The extended WLAN slot can also increase the opportunity that we can
received the CCK's long packet and be released from CCK rate.

While BT multi-link status was finished, there is possible that it still
has some packet remained for seconds. Add a timer to remain the multi-link
mechanism to protect WLAN Rx.
Signed-off-by: NChing-Te Ku <ku920601@realtek.com>
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201126021059.11981-8-pkshih@realtek.com
      8e6947dc
  7. 11 11月, 2020 2 次提交
  9. 07 11月, 2020 3 次提交
  11. 29 9月, 2020 2 次提交
  13. 24 9月, 2020 2 次提交
    • A
      rtw88: Fix potential probe error handling race with wow firmware loading · ac4bac99
      由 Andreas Färber 提交于 
      If rtw_core_init() fails to load the wow firmware, rtw_core_deinit()
will not get called to clean up the regular firmware.

Ensure that an error loading the wow firmware does not produce an oops
for the regular firmware by waiting on its completion to be signalled
before returning. Also release the loaded firmware.

Fixes: c8e5695e ("rtw88: load wowlan firmware if wowlan is supported")
Cc: Chin-Yen Lee <timlee@realtek.com>
Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200920132621.26468-3-afaerber@suse.de
      ac4bac99
    • A
      rtw88: Fix probe error handling race with firmware loading · ecda9cda
      由 Andreas Färber 提交于 
      In case of rtw8822be, a probe failure after successful rtw_core_init()
has been observed to occasionally lead to an oops from rtw_load_firmware_cb():

[    3.924268] pci 0001:01:00.0: [10ec:b822] type 00 class 0xff0000
[    3.930531] pci 0001:01:00.0: reg 0x10: [io  0x0000-0x00ff]
[    3.936360] pci 0001:01:00.0: reg 0x18: [mem 0x00000000-0x0000ffff 64bit]
[    3.944042] pci 0001:01:00.0: supports D1 D2
[    3.948438] pci 0001:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    3.957312] pci 0001:01:00.0: BAR 2: no space for [mem size 0x00010000 64bit]
[    3.964645] pci 0001:01:00.0: BAR 2: failed to assign [mem size 0x00010000 64bit]
[    3.972332] pci 0001:01:00.0: BAR 0: assigned [io  0x10000-0x100ff]
[    3.986240] rtw_8822be 0001:01:00.0: enabling device (0000 -> 0001)
[    3.992735] rtw_8822be 0001:01:00.0: failed to map pci memory
[    3.998638] rtw_8822be 0001:01:00.0: failed to request pci io region
[    4.005166] rtw_8822be 0001:01:00.0: failed to setup pci resources
[    4.011580] rtw_8822be: probe of 0001:01:00.0 failed with error -12
[    4.018827] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[    4.029121] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[    4.050828] Unable to handle kernel paging request at virtual address edafeaac9607952c
[    4.058975] Mem abort info:
[    4.058980]   ESR = 0x96000004
[    4.058990]   EC = 0x25: DABT (current EL), IL = 32 bits
[    4.070353]   SET = 0, FnV = 0
[    4.073487]   EA = 0, S1PTW = 0
[    4.073501] dw-apb-uart 98007800.serial: forbid DMA for kernel console
[    4.076723] Data abort info:
[    4.086415]   ISV = 0, ISS = 0x00000004
[    4.087731] Freeing unused kernel memory: 1792K
[    4.090391]   CM = 0, WnR = 0
[    4.098091] [edafeaac9607952c] address between user and kernel address ranges
[    4.105418] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[    4.111129] Modules linked in:
[    4.114275] CPU: 1 PID: 31 Comm: kworker/1:1 Not tainted 5.9.0-rc5-next-20200915+ #700
[    4.122386] Hardware name: Realtek Saola EVB (DT)
[    4.127223] Workqueue: events request_firmware_work_func
[    4.132676] pstate: 60000005 (nZCv daif -PAN -UAO BTYPE=--)
[    4.138393] pc : rtw_load_firmware_cb+0x54/0xbc
[    4.143040] lr : request_firmware_work_func+0x44/0xb4
[    4.148217] sp : ffff800010133d70
[    4.151616] x29: ffff800010133d70 x28: 0000000000000000
[    4.157069] x27: 0000000000000000 x26: 0000000000000000
[    4.162520] x25: 0000000000000000 x24: 0000000000000000
[    4.167971] x23: ffff00007ac21908 x22: ffff00007ebb2100
[    4.173424] x21: ffff00007ad35880 x20: edafeaac96079504
[    4.178877] x19: ffff00007ad35870 x18: 0000000000000000
[    4.184328] x17: 00000000000044d8 x16: 0000000000004310
[    4.189780] x15: 0000000000000800 x14: 00000000ef006305
[    4.195231] x13: ffffffff00000000 x12: ffffffffffffffff
[    4.200682] x11: 0000000000000020 x10: 0000000000000003
[    4.206135] x9 : 0000000000000000 x8 : ffff00007e73f680
[    4.211585] x7 : 0000000000000000 x6 : ffff80001119b588
[    4.217036] x5 : ffff00007e649c80 x4 : ffff00007e649c80
[    4.222487] x3 : ffff80001119b588 x2 : ffff8000108d1718
[    4.227940] x1 : ffff800011bd5000 x0 : ffff00007ac21600
[    4.233391] Call trace:
[    4.235906]  rtw_load_firmware_cb+0x54/0xbc
[    4.240198]  request_firmware_work_func+0x44/0xb4
[    4.245027]  process_one_work+0x178/0x1e4
[    4.249142]  worker_thread+0x1d0/0x268
[    4.252989]  kthread+0xe8/0xf8
[    4.256127]  ret_from_fork+0x10/0x18
[    4.259800] Code: f94013f5 a8c37bfd d65f03c0 f9000260 (f9401681)
[    4.266049] ---[ end trace f822ebae1a8545c2 ]---

To avoid this, wait on the completion callbacks in rtw_core_deinit()
before releasing firmware and continuing teardown.

Note that rtw_wait_firmware_completion() was introduced with
c8e5695e ("rtw88: load wowlan firmware
if wowlan is supported"), so backports to earlier branches may need to
inline wait_for_completion(&rtwdev->fw.completion) instead.

Fixes: e3037485 ("rtw88: new Realtek 802.11ac driver")
Fixes: c8e5695e ("rtw88: load wowlan firmware if wowlan is supported")
Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200920132621.26468-2-afaerber@suse.de
      ecda9cda
  15. 27 8月, 2020 2 次提交
  17. 02 8月, 2020 1 次提交
  19. 15 7月, 2020 3 次提交
  21. 30 5月, 2020 1 次提交
    • P
      rtw88: fix EAPOL 4-way failure by finish IQK earlier · 7a242fb6
      由 Ping-Ke Shih 提交于 
      Connecting to an AP with WPA2 security may fail. The IQK
and the EAPOL 4-way handshake may overlap because the
driver does IQK right after assoc success.

For 802.11n devices, the IQK is done in the driver and it
could require more than 100ms to complete. During IQK, any
TX/RX events are paused. So if the EAPOL 4-way handshake
started before IQK finished, then the 1/4 and 2/4 part of
the handshake could be dropped. The AP will then issue
deauth with reason IEEE8021X_FAILED (23).

To resolve this, move IQK routine into managed TX prepare
(ieee80211_ops::mgd_prepare_tx()). The callback is called
before the managed frames (auth/assoc) are sent. This will
make sure that the IQK is completed before the handshake
starts. But don't do IQK during scanning because doing it
on each channel will take too long.

For 802.11ac devices, the IQK is done in firmware and it
takes less time to complete. Therefore we don't see a
failure during the EAPOL 4-way handshake. But it is still
worth moving the IQK into ieee80211_ops::mgd_prepare_tx().

Fixes: f5df1a8b ("rtw88: 8723d: Add 8723DE to Kconfig and Makefile")
Tested-by: NYou-Sheng Yang <vicamo.yang@canonical.com>
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200529025009.2468-4-yhchuang@realtek.com
      7a242fb6
  23. 06 5月, 2020 1 次提交
  25. 23 4月, 2020 1 次提交
  27. 21 4月, 2020 2 次提交
  29. 15 4月, 2020 1 次提交
  31. 24 3月, 2020 1 次提交
    • Y
      rtw88: associate reserved pages with each vif · 895c096d
      由 Yan-Hsuan Chuang 提交于 
      Each device has only one reserved page shared with all of the
vifs, so it seems not reasonable to pass vif as one of the
arguments to rtw_fw_download_rsvd_page(). If driver is going
to run more than one vif, the content of reserved page could
not be built for all of the vifs.

To fix it, let each vif maintain its own reserved page list,
and build the final reserved page to download to the firmware
from all of the vifs. Hence driver should add reserved pages
to each vif according to the vif->type when adding the vif.

For station mode, add reserved page with rtw_add_rsvd_page_sta().
If the station mode is going to suspend in PNO (net-detect)
mode, remove the reserved pages used for normal mode, and add
new one for wowlan mode with rtw_add_rsvd_page_pno().

For beacon mode, only beacon is required to be added using
rtw_add_rsvd_page_bcn().

This would make the code flow simpler as we don't need to
add reserved pages when vif is running, just add/remove them
when ieee80211_ops::[add|remove]_interface.

When driver is going to download the reserved page, it will
collect pages from all of the vifs, this list is maintained
by rtwdev, with build_list as the pages' member. That way, we
can still build a list of reserved pages to be downloaded.
Also we can get the location of the pages from the list that
is maintained by rtwdev.

The biggest problem is that the first page should always be
beacon, if other type of reserved page is put in the first
page, the tx descriptor and offset could be wrong.
But station mode vif does not add beacon into its list, so
we need to add a dummy page in front of the list, to make
sure other pages will not be put in the first page. As the
dummy page is allocated when building the list, we must free
it before building a new list of reserved pages to firmware.
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200312080852.16684-4-yhchuang@realtek.com
      895c096d
  33. 12 3月, 2020 1 次提交
  35. 13 2月, 2020 2 次提交
  37. 26 1月, 2020 6 次提交
  39. 08 11月, 2019 1 次提交
  41. 07 11月, 2019 1 次提交
  43. 31 10月, 2019 1 次提交
  45. 25 10月, 2019 1 次提交
    • Y
      rtw88: fix GENMASK_ULL for u64 · 5c70e971
      由 Yan-Hsuan Chuang 提交于 
      This fixes compile warning:

    In file included from include/linux/bitops.h:5:0,
                     from include/linux/kernel.h:12,
                     from include/asm-generic/bug.h:19,
                     from arch/mips/include/asm/bug.h:42,
                     from include/linux/bug.h:5,
                     from include/net/mac80211.h:16,
                     from drivers/net/wireless/realtek/rtw88/main.h:8,
                     from drivers/net/wireless/realtek/rtw88/main.c:5:
    drivers/net/wireless/realtek/rtw88/main.c: In function 'rtw_update_rate_mask':
      include/linux/bits.h:23:11: warning: right shift count is negative
      [-Wshift-count-negative]
       (~UL(0) >> (BITS_PER_LONG - 1 - (h))))
               ^
    drivers/net/wireless/realtek/rtw88/main.c:622:17: note: in expansion of macro 'GENMASK'
      u64 cfg_mask = GENMASK(63, 0);
                     ^~~~~~~
Reported-by: Nkbuild test robot <lkp@intel.com>
Fixes: f39e9bd4 ("rtw88: add set_bitrate_mask support")
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Reported-by: Nkbuild test robot <lkp@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      5c70e971
  47. 24 10月, 2019 2 次提交