| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
When driver was developed, FCC regulation didn't enable channel 144
and there was no demand for channel 144 at that time. Although HW
actually supports channel 144, driver didn't announce channel 144.
Therefore, channel 144 (20 MHz), channel 142 (40 MHz) and channel
138 (80 MHz) couldn't be used.
Today, channel 144 has been enabled by regulations and
is gradually being supported. With test requirements,
we declare hw supports channel 144.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201204013823.3729-1-pkshih@realtek.com
|
|
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: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201126021059.11981-8-pkshih@realtek.com
|
|
The original mechanism may cause A2DP glitch during WiFi connecting AP.
Because the original TDMA may decrease too much A2DP slot.
This patch add a timer and variable to let the case A2DP + WL_Connecting
performed more well.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201109085909.9143-9-pkshih@realtek.com
|
|
Adjust space and comments, and fix "line over 80 characters" warnings
reported by checkpatch.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201109085909.9143-5-pkshih@realtek.com
|
|
This patch checks the supported lps deep mode from firmware feature,
and allows different firmware have different deep power mode.
Original module parameter rtw_fw_lps_deep_mode is replaced with
rtw_disable_lps_deep_mode for user to disable lps deep mode.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201030084826.9034-5-tehuang@realtek.com
|
|
Originally driver checks if firmware has left lps via reading the setting
of REG_TCR register. But this way may fail when firmware is frequently
changing power state. Therefore, firmware provides a safer option for
driver. When firmware leaves lps successfully, it sends a C2H response
to inform driver.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201030084826.9034-4-tehuang@realtek.com
|
|
Some functions need the support of firmware with special version.
In order to get the feature of current firmware, we store the information
in firmware header and parse after firmware is loaded. The current feature
list in firmware header includes checking leave lps via C2H and
supported lps deep mode.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201030084826.9034-3-tehuang@realtek.com
|
|
This patch adds a function which is able to dump firmware fifo when
firmware crashes. If firmware needs more than one time to dump all logs,
it will set a bit called "more bit" in the header of the first log, and
driver needs to set a register to inform firmware that it is ready for the
next dump.
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200925061219.23754-5-tehuang@realtek.com
|
|
This handles the situation when firmware crashes.
When firmware crashes, it will send an interrupt, and driver will queue
a work for recovery.
In the work, driver will reset it's internal association state, which
includes removing associated sta's macid, resetting vifs' states
and removing keys. After resetting the driver's state, driver will call
rtw_enter_ips() to force the chipset power off to reset the chip.
Finally, driver calls ieee80211_restart_hw() to inform mac80211 stack
to restart.
Since only 8822c firmware supports this feature, the interrupt will only
be triggered when 8822c chipset is loaded.
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200925061219.23754-3-tehuang@realtek.com
|
|
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: c8e5695eae99 ("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: Andreas Färber <afaerber@suse.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200920132621.26468-3-afaerber@suse.de
|
|
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
c8e5695eae9959fc5774c0f490f2450be8bad3de ("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: e3037485c68e ("rtw88: new Realtek 802.11ac driver")
Fixes: c8e5695eae99 ("rtw88: load wowlan firmware if wowlan is supported")
Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200920132621.26468-2-afaerber@suse.de
|
|
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly
and remove .data field.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200817090637.26887-16-allen.cryptic@gmail.com
|
|
Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1].
[1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200821064959.GA23693@embeddedor
|
|
Fix the transmission is not sent with short GI under
some conditions even if the receiver supports short GI.
If VHT capability IE exists in the beacon, the original
code uses the short GI for 80M field as driver's short GI
setting for transmission, even the current bandwidth is
not 80MHz.
Short GI supported fields for 20M/40M are informed in HT
capability information element, and short GI supported
field for 80M is informed in VHT capability information
element.
These three fields may be set to different values.
Driver needs to record each short GI support field for
each bandwidth, and send correct info depends on current
bandwidth to the WiFi firmware.
Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver")
Signed-off-by: Tsang-Shian Lin <thlin@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200717064937.27966-3-yhchuang@realtek.com
|
|
Add a set of logic with corresponding coexistence parameters to
handle the situation under BT inquiry/page.
We will set PSTDMA while WL-Busy + BT inquiry/page to separate
WL/BT slots. PSTDMA can protect WL data rate and BT performance.
If WL-Busy + BT inquiry/page and there was BT device paired,
We will set the mechanism to 4Slot PSTDMA.
In 4Slot PSTDMA, the paired devices can perform more smoothly
and prevent some issues trigger from insufficient data.
And to avoid A2DP glitch or disconnection, we will adjust ACL
data priority higher than inquiry/page.
In addition, we found sometimes BT inquiry/page still working
last for seconds after BT had notified inquiry/page finished.
It will lead to A2DP glitch cause of ACL data, inquiry/page
priority toggled. To fix the corner, we add a timer to remain
the inquiry/page status.
And we found WL busy/idle threshold is too sensitive,
it will keep switching in some weak network environment and
coexistence mechanism will switch between TDMA and PSTDMA.
The very frequently switching may destroyed not only the
handshake with AP, but BT performance. And it will trigger
some unexpected error.
To prevent the frequently switching, we add a timer to delay
the status change while WL busy switch to idle.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200715023324.8600-1-yhchuang@realtek.com
|
|
Since single rf path chips don't support TX SPBC, tell mac80211
to not advertise it.
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200603094218.19942-5-yhchuang@realtek.com
|
|
8821c is capable of 2.4G and 5G.
Implement rtw_chip_ops::set_channel() to set 2G and 5G channels.
This includes MAC, BB and RF related settings.
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200616091625.26489-5-yhchuang@realtek.com
|
|
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: f5df1a8b4376 ("rtw88: 8723d: Add 8723DE to Kconfig and Makefile")
Tested-by: You-Sheng Yang <vicamo.yang@canonical.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200529025009.2468-4-yhchuang@realtek.com
|
|
Some chips are not able to receive LDPC packets. Add an attribute
to rtw_chip_info to determine if the LDPC capability in [ht/vht]_cap
should be advertised or not.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200504105010.10780-6-yhchuang@realtek.com
|
|
The WLAN CPU of 8723D device is different from others, add legacy
firmware download function for it. A new variable wlan_cpu is used to
decide which firmware download function we should use.
Legacy firmware file contains 32 bytes header including version and
subversion. When downloading to wlan cpu, header is excluded.
Firmware is downloaded via beacon queue to reserved page that is a part of
TX buffer. Since 11N WLAN CPU uses different control registers, this patch
introduces related control registers.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200422034607.28747-2-yhchuang@realtek.com
|
|
8723D use SIPI to indirectly read RF register instead of directly read,
so introduce a new struct rtw_rf_sipi_addr and new function
rtw_phy_read_rf_sipi(). Since other chips don't use the new function,
only 8723D needs to fill struct rtw_rf_sipi_addr in rtw_chip_info.
Because there are two kinds of functions for reading RF registers now,
change rtw_phy_read_rf() to chip->ops->read_rf() in
rtw_phy_write_rf_reg_sipi() so that we can switch tp proper RF read
functions depends on the type of the chip.
Though 8723D is an 1x1 chip, it has two RF PHY and we can switch to
one of them, and that should be configured properly. Hence, add a
fix_rf_phy_num to struct rtw_chip_info to allow driver to set one of
the PHY's registers for 8723D, even it is only 1x1. Another variable
rf_phy_num is introduced to keep the constraint number of RF path we
can access, and its value is:
rf_phy_num = (fix_rf_phy_num ? fix_rf_phy_num : rf_path_num)
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200420055054.14592-5-yhchuang@realtek.com
|
|
8723D doesn't support beamform because rtw88 only supports VHT beamform
but 8723d doesn't have VHT capability. Though 8723d doesn't support
beamform, BSS_CHANGED_MU_GROUPS is still marked as changed when doing
disassociation. So, add wrapper functions for all beamform ops to make
sure they aren't NULL before calling.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200420055054.14592-3-yhchuang@realtek.com
|
|
User space program such as iw can set antenna mask for the device.
So add set antenna support by configure the trx mode.
This is useful for some tests want to see the output of different
antenna configuration (e.g. path A v.s. path B).
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200410100950.3199-3-yhchuang@realtek.com
|
|
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: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200312080852.16684-4-yhchuang@realtek.com
|
|
Remove unused fab_version member from struct rtw_hal.
Some of the checks being made were nonsense.
Signed-off-by: Kevin Lo <kevlo@kevlo.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
The hardware value of secondary channel offset isn't very intuitive. This
commit adds enumeration, so we can easier to check the logic with the
suffix of enumeration name, likes _UPPER or _LOWER.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Reviewed-by: Chris Chiu <chiu@endlessm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Driver could possibly be dead-locked while canceling works with
*_sync() with mutex lock held. Those cancel_delayed_work_sync()
functions will wait until the work is done, but if we hold the
lock, they will never acquire the lock.
To prevent this, simply release the lock and acquire again after
the works have been canceled. And to avoid the works being queued
again, check if the device is at RTW_FLAG_RUNNING state, otherwise
just return and do nothing.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Fix typo, should use rtw_hci_stop()
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
dm_lock is never used. Thus, remove this redundant spinlock.
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
The rate mask is used to tell firmware the supported rate depends on
negotiation. We loop 2 times for all VHT/HT 2SS rate mask first, and then
only keep the part according to chip's NSS.
This commit fixes the logic error of '&' operations for VHT/HT rate, and
we should run this logic before adding legacy rate.
To access HT MCS map, index 0/1 represent MCS 0-7/8-15 respectively. Use
NL80211_BAND_xxx is incorrect, so fix it as well.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Reviewed-by: Chris Chiu <chiu@endlessm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Net-detect is an option of wowlan to allow the device to
be woken up from suspend mode when configured network is detected.
When user enables net-detect and lets the device enter suspend
state, wowlan firmware will periodically scan until beacon or
probe response of configured networks are received.
Between two scans, wowlan firmware keeps wifi chip in idle mode
to reduce power consumption. If configured networks are detected,
wowlan firmware will trigger resume process.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Wake on WLAN(wowlan) is a feature which allows devices
to be woken up from suspend state through wlan events.
When user enables wowlan feature and then let the device
enter suspend state, wowlan firmware will be loaded by
the driver and periodically monitors wifi packets.
Power consumption of wifi chip will be reduced in this
state.
If wowlan firmware detects that specific wlan event
happens, it will issue wakeup signal to trigger resume
process. Driver will load normal firmware and let wifi
chip return to the original state.
Currently supported wlan events include receiving magic packet,
rekey packet and deauth packet, and disconnecting from AP.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Driver used to download normal firmware only,
but some devices support wowlan and require to
download wowlan firmware when system suspends.
So modify rtw_load_firmware() and its callback to
allow driver to download both normal and wowlan firmware.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Otherwise, the waiters (e.g., "modprobe rtwpci") will block forever.
Fixes: f530c1961af2 ("rtw88: fix potential NULL pointer access for firmware")
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Acked-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Driver could access a NULL firmware pointer if we don't
return here.
Fixes: 5195b90426409 ("rtw88: avoid FW info flood")
Reported-by: kbuild test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
The FW info was printed everytime driver is powered on, such as
leaving IDLE state. It will flood the kernel log.
Move the FW info printing to callback when FW is loaded, so
that will only be printed once when device is probed.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
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: kbuild test robot <lkp@intel.com>
Fixes: f39e9bd49a3d ("rtw88: add set_bitrate_mask support")
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
This commit adds several Tx/Rx physical information to phy_info
debugfs for 8822B/8822C. By this debugfs, we can know physical
information, such as Tx/Rx rate, RSSI, EVM,SNR, etc. The
information is gotten from the packets of Tx/Rx path. It has
no impact for the performance of 8822B/8822C.
In the fields, we may meet different kinds of problems, but
we may have no professional instrument to check them. At
this moment, this debugfs is a good tool, and it may provide
useful information for debug.
Signed-off-by: Tsang-Shian Lin <thlin@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Reviewed-by: Chris Chiu <chiu@endlessm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Support setting bit rate from upper layer.
After configuring the original rate control result in the driver, the
result is then masked by the bit rate mask received from the ops
set_bitrate_mask. Lastly, the masked result will be sent to firmware.
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Reviewed-by: Chris Chiu <chiu@endlessm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Enable MU-MIMO transmit beamformee support for chipset 8822b and 8822c.
If the driver is in station mode and associated with an AP, and the
capabilities of both meet the requirement of beamforming, driver will
run as a beamformee and the corresponding chip settings will be set.
In addition, module parameter support_bf is added to enable or disable
beamforming. Sometimes driver will need to disable for inter-operate
issues, and it would be easier for driver to debug.
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Add support for NL80211_EXT_FEATURE_CAN_REPLACE_PTK0 feature.
According to the "Hardware crypto acceleration" documentation section,
when set_key() is called with %DISABLE_KEY command, for outgoing frames,
we flush out frames in the queues with the old key; for incoming frames,
no frames will be passed to mac80211 decrypted with the old key due to
rtw_sec_clear_cam().
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Disable efuse if the efuse is enabled when we failed to setup the efuse
information, otherwise the hardware will not turn off.
Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
8822C is a 2x2 11ac chip, and then NSS must be less or equal to 2. However,
current nss of hw cap is 3, likes
hw cap: hci=0x0f, bw=0x07, ptcl=0x03, ant_num=7, nss=3
This commit adds constraint to make sure NSS <= rf_path_num, and result
looks like
hw cap: hci=0x0f, bw=0x07, ptcl=0x03, ant_num=7, nss=2
Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Based on the mac80211's TXQ implementation, TX-AMSDU can
be used to get higher MAC efficiency. To make mac80211
aggregate MSDUs, low level driver just need to leave skbs
in the TXQ, and mac80211 will try to aggregate them if
possible. As driver will schedule a tasklet when the TX
queue is woke, until the tasklet being served, there will
have some skbs in the queue if traffic is heavy.
Driver can control the max AMSDU size depending on the
current bit rate used by hardware/firmware. The higher
rates are used, the larger AMSDU size can be.
It is tested that can achieve higher T-Put at higher rates.
If the environment is relatively clean, and the bit_rate
is high enough, we can get about 80Mbps improvement.
For lower bit rates, not much gain can we get, so leave
the max_amsdu length low to prevent aggregation.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Whenever the firmware increases/decreases the bit rate used
to transmit to a peer, it sends an RA report through C2H to
driver. Driver can then record the bit rate in the peer's
struct rtw_sta_info, and report to mac80211 when it asks us
for the statistics of the sta by ieee80211_ops::sta_statistics
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
We can indicate IEEE80211_HW_HAS_RATE_CONTROL to mac80211 because
the hardware has its own rate control algorithm. And what driver needs
to do is to choose an RA mask according the peer's capabilities.
But the hardware is not able to setup BA session by itself. So driver
requires to initiate tx BA session for hardware, and tells it if it is
possible to transmit AMPDU. The hardware can then aggregate MPDUs.
And the size of AMPDU is controlled by the TX descriptor and the
register value. Since the TX descriptor will reference the max AMPDU
size from ieee80211_sta::ht_cap::ampdu_factor, just set the register
value to 0x3f, and let it be controlled by TX descriptor.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
The mac80211 provides software TX queue for driver, as long as
driver has hooked ieee80211_ops::wake_tx_queue. Each time a
packet is queued onto the TX queue, that queue will be woken
up the inform driver to serve the queue.
Now driver only supports PCI interface ICs, there's no specific
traffic control for each queue, just schedule a tasklet, and
dump all of the packets at once to the DMA ring. Instead of TX
the packets whenever TX queue is woke, tasklet handler can have
more packets dumped to the device, takes advantage of burst
write with DMA engine.
And if the driver is going to support USB/SDIO ICs, the tasklet
can be more flexible for aggregating the packets, enhance the
efficiency of bandwidth usage.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
The module parameter rtw_fw_support_lps is misleading. It
is not used to represent the firmware's property, but to
determine if driver wants to ask firmware to enter LPS.
However, driver should better enable/disable PS through
cfg80211_ops::set_power_mgmt instead.
For example, one could use iw command to set PS state.
$ sudo iw wlanX set power_save [on/off]
So rtw_fw_support_lps should be removed because it is
misleading and useless. Instead of checking the parameter,
set PS mode according to IEEE80211_CONF_PS.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Add a module parameter to select deep PS mode. And the mode
cannot be changed after the module has been inserted and probed.
If anyone wants to change the deep mode, should change the mode
and probe the device again to setup the changed deep mode.
When the device is probed, driver will check the deep PS mode
with different IC's PS mode suppotability. If none of the
PS mode is matched, the deep PS mode is changed to NONE,
means deep PS is disabled.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Deep power save allows firmware/hardware to operate in a
lower power state. And the deep power save mode depends on
LPS mode. So, before entering deep PS, driver must first
enter LPS mode.
Under Deep PS, most of hardware functions are shutdown,
driver will not be able to read/write registers and transfer
data to the device. Hence TX path must be protected by each
interface. Take PCI for example, DMA engine should be idle,
and no nore activities on the PCI bus.
If driver wants to operate on the device, such as register
read/write, it must first acquire the mutex lock and wake
up from Deep PS, otherwise the behavior is undefined.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
