#
20907fc0 |
|
15-Oct-2023 |
Chin-Yen Lee <timlee@realtek.com> |
wifi: rtw88: dump firmware debug information in abnormal state Sometimes firmware may enter strange state or infinite loop due to unknown bug, and then it will lead critical function fail, such as sending H2C command or changing power mode. In these abnormal states, we add more debug information, including hardware register status, to help further investigation. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231016053554.744180-3-pkshih@realtek.com
|
#
8986f0a9 |
|
28-Jun-2023 |
Dmitry Antipov <dmantipov@yandex.ru> |
wifi: rtw88: simplify vif iterators Since all iterators called by 'rtw_iterate_vifs()' never uses 'mac' argument, it may be omitted, and 'struct rtw_vifs_entry' may be simplified accordingly. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230628072327.167196-4-dmantipov@yandex.ru
|
#
2ce9a91f |
|
15-Jun-2023 |
Po-Hao Huang <phhuang@realtek.com> |
wifi: rtw88: Fix action frame transmission fail before association For combo chips, antennas were controlled by bluetooth only during power on. If WiFi wish to do transmission, notification to the coexistence module are required. Previously we only do this before authentication. To allow transmission before auth, such as management TX, now we start the initiation of coexistence earlier so antennas are shared between WiFi and bluetooth after set_channel(), and frames could then be sent. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230615114348.7193-1-pkshih@realtek.com
|
#
3918dd01 |
|
27-May-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw88: correct PS calculation for SUPPORTS_DYNAMIC_PS This driver relies on IEEE80211_CONF_PS of hw->conf.flags to turn off PS or turn on dynamic PS controlled by driver and firmware. Though this would be incorrect, it did work before because the flag is always recalculated until the commit 28977e790b5d ("wifi: mac80211: skip powersave recalc if driver SUPPORTS_DYNAMIC_PS") is introduced by kernel 5.20 to skip to recalculate IEEE80211_CONF_PS of hw->conf.flags if driver sets SUPPORTS_DYNAMIC_PS. Correct this by doing recalculation while BSS_CHANGED_PS is changed and interface is added or removed. It is allowed to enter PS only if single one station vif is working. Without this fix, driver doesn't enter PS anymore that causes higher power consumption. Fixes: bcde60e599fb ("rtw88: remove misleading module parameter rtw_fw_support_lps") Cc: stable@vger.kernel.org # 6.1+ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230527082939.11206-2-pkshih@realtek.com
|
#
4a267bc5 |
|
15-Feb-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw88: use RTW_FLAG_POWERON flag to prevent to power on/off twice Use power state to decide whether we can enter or leave IPS accurately, and then prevent to power on/off twice. The commit 6bf3a083407b ("wifi: rtw88: add flag check before enter or leave IPS") would like to prevent this as well, but it still can't entirely handle all cases. The exception is that WiFi gets connected and does suspend/resume, it will power on twice and cause it failed to power on after resuming, like: rtw_8723de 0000:03:00.0: failed to poll offset=0x6 mask=0x2 value=0x2 rtw_8723de 0000:03:00.0: mac power on failed rtw_8723de 0000:03:00.0: failed to power on mac rtw_8723de 0000:03:00.0: leave idle state failed rtw_8723de 0000:03:00.0: failed to leave ips state rtw_8723de 0000:03:00.0: failed to leave idle state rtw_8723de 0000:03:00.0: failed to send h2c command To fix this, introduce new flag RTW_FLAG_POWERON to reflect power state, and call rtw_mac_pre_system_cfg() to configure registers properly between power-off/-on. Reported-by: Paul Gover <pmw.gover@yahoo.co.uk> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217016 Fixes: 6bf3a083407b ("wifi: rtw88: add flag check before enter or leave IPS") Cc: <Stable@vger.kernel.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230216053633.20366-1-pkshih@realtek.com
|
#
78d5bf92 |
|
02-Dec-2022 |
Sascha Hauer <s.hauer@pengutronix.de> |
wifi: rtw88: iterate over vif/sta list non-atomically The driver uses ieee80211_iterate_active_interfaces_atomic() and ieee80211_iterate_stations_atomic() in several places and does register accesses in the iterators. This doesn't cope with upcoming USB support as registers can only be accessed non-atomically. Split these into a two stage process: First use the atomic iterator functions to collect all active interfaces or stations on a list, then iterate over the list non-atomically and call the iterator on each entry. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Suggested-by: Ping-Ke shih <pkshih@realtek.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221202081224.2779981-7-s.hauer@pengutronix.de
|
#
6bf3a083 |
|
09-Aug-2022 |
Chih-Kang Chang <gary.chang@realtek.com> |
wifi: rtw88: add flag check before enter or leave IPS Enter or leave IPS controlled by mac80211 before driver support HW scan. After support HW scan, driver need to control IPS before start HW scan and scan complete, but mac80211 also ask driver enter or leave IPS. Therefore, we add flag check in IPS to prevent entering or leaving IPS twice. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220809084107.38137-7-pkshih@realtek.com
|
#
5d5d68bc |
|
20-Dec-2021 |
Chin-Yen Lee <timlee@realtek.com> |
rtw88: don't consider deep PS mode when transmitting packet In original flow, driver needs to ensure chip leave deep ps mode before transmitting any packet, and don't enter deep ps mode beofre PCIE DMA is finished. Now with the support of 8822ce's hardware setting and firmware after v9.9.11, these limits are removed. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20211221020230.20764-1-pkshih@realtek.com
|
#
9a711831 |
|
14-May-2021 |
Chin-Yen Lee <timlee@realtek.com> |
rtw88: add rtw_fw_feature_check api add api to check if a certain feature is supported. Signed-off-by: Chin-Yen Lee <timlee@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/20210514075517.14216-2-pkshih@realtek.com
|
#
fc3ac64a |
|
30-Oct-2020 |
Chin-Yen Lee <timlee@realtek.com> |
rtw88: decide lps deep mode from firmware feature. 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
|
#
f31e039f |
|
30-Oct-2020 |
Chin-Yen Lee <timlee@realtek.com> |
rtw88: add C2H response for checking firmware leave lps 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
|
#
690390d8 |
|
30-Oct-2020 |
Chin-Yen Lee <timlee@realtek.com> |
rtw88: sync the power state between driver and firmware In current flow, driver issues power requests to firmware for entering or leaving deep power mode. But driver does not wait for an ack from firmware via reading CPWM register when driver requests to enter deep power mode. The behavior will lead to unsynchronized state between firmware and driver. Furthermore, consecutive same power requests may confuse firmware and leads to unexpected value of CPWM register. This patch ensures that the power request will wait for an ack from firmware and only send one power request each time. 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-2-tehuang@realtek.com
|
#
6b6c150b |
|
07-Jan-2020 |
Yan-Hsuan Chuang <yhchuang@realtek.com> |
rtw88: use shorter delay time to poll PS state When TX packet arrives, driver should leave deep PS state to make sure the DMA is working. After requested to leave deep PS state, driver needs to poll the PS state to check if the mode has been changed successfully. The driver used to check the state of the hardware every 20 msecs, which means upon the first failure of state check, the CPU is delayed 20 msecs for next check. This is harmful for some time-sensitive applications such as media players. So, use shorter delay time each check from 20 msecs to 100 usecs. The state should be changed in several tries. But we still need to reserve ~15 msecs in total in case of the state just took too long to be changed successfully. If the states of driver and the hardware is not synchronized, the power state could be locked forever, which mean we could never enter/leave the PS state. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Reviewed-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
#
3dff7c6e |
|
18-Nov-2019 |
Yan-Hsuan Chuang <yhchuang@realtek.com> |
rtw88: allows to enable/disable HCI link PS mechanism Different interfaces have its own link-related power save mechanism. Such as PCI can enter L1 state based on the traffic on the link, and sometimes driver needs to enable/disable it to avoid some issues, like throughput degrade when PCI trying to enter L1 state even if driver is having heavy traffic. For now, rtw88 only supports PCIE chips, and they just need to disable ASPM L1 when driver is not in power save mode, such as IPS and LPS. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
#
4f5969c3 |
|
10-Nov-2019 |
YueHaibing <yuehaibing@huawei.com> |
rtw88: remove duplicated include from ps.c Remove duplicated include. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Reviewed-by: Simon Horman <simon.horman@netronome.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
#
4ee2f342 |
|
11-Oct-2019 |
Brian Norris <briannorris@chromium.org> |
rtw88: use a for loop in rtw_power_mode_change(), not goto No change in logic. Signed-off-by: Brian Norris <briannorris@chromium.org> Acked-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
#
be10b09b |
|
07-Oct-2019 |
Dan Carpenter <dan.carpenter@oracle.com> |
rtw88: Fix an error message The WARN_ON() macro doesn't take an error message, the argument is a condition so this won't display the warning message. Fixes: 27e117e4b01b ("rtw88: add deep power save support") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
#
3a2dd6b7 |
|
02-Oct-2019 |
Chin-Yen Lee <timlee@realtek.com> |
rtw88: check firmware leave lps successfully Driver needs to wait for firmware to restore hardware setting to active mode after leaving lps. After getting H2C from driver for leaving lps, firmware will issue null packet without PS bit to inform AP driver is active, and then restore REG_TCR Register if AP has receiced null packet. But the transmission of null packet may cost much more time in noisy environment. If driver does not wait for firmware, null packet with PS bit could be sent due to incorrect REG_TCR setting. And AP will be confused. In our test, 100ms is enough for firmware to send null packet to AP. If REG_TCR Register is still wrong after 100ms, we will modify it directly, force the PS bit to be cleared 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>
|
#
04b786e0 |
|
01-Oct-2019 |
Yan-Hsuan Chuang <yhchuang@realtek.com> |
rtw88: add deep PS PG mode for 8822c Compare with LCLK mode, PG mode saves more power, by turning off more circuits. Therefore, to recover from PG mode, driver needs to backup some information into rsvd page. Such as CAM entries, DPK results. As CAM entries can change, it is required to re-download CAM entries after set_key. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
#
d3be4d11 |
|
01-Oct-2019 |
Yan-Hsuan Chuang <yhchuang@realtek.com> |
rtw88: select deep PS mode when module is inserted 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>
|
#
3a068a2a |
|
01-Oct-2019 |
Yan-Hsuan Chuang <yhchuang@realtek.com> |
rtw88: not to enter LPS by coex strategy Sometimes LPS is not compatible with COEX's strategy, and COEX will not allow driver to enter it. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
#
27e117e4 |
|
01-Oct-2019 |
Yan-Hsuan Chuang <yhchuang@realtek.com> |
rtw88: add deep power save support 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>
|
#
d3e20fd1 |
|
01-Oct-2019 |
Yan-Hsuan Chuang <yhchuang@realtek.com> |
rtw88: LPS enter/leave should be protected by lock Protect LPS enter/leave routine with rtwdev->mutex. This helps to synchronize with driver's states correctly. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
#
5235d636 |
|
01-Oct-2019 |
Yan-Hsuan Chuang <yhchuang@realtek.com> |
rtw88: remove unused lps state check helper This is no more used, remove it. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
#
3d391c06 |
|
01-Oct-2019 |
Yan-Hsuan Chuang <yhchuang@realtek.com> |
rtw88: not to control LPS by each vif The original design of LPS enter/leave routines allows to control the LPS state by each interface. But the hardware cannot actually handle it that way. This means the hardware can only enter LPS once with an associated port, so there is no need to keep tracking the state of each vif. Hence the logic of enter/leave LPS state can be simple, just to check the state of the device's flag. And for leaving LPS state, it will get the same port id to send to inform the hardware. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
#
61d73095 |
|
01-Oct-2019 |
Yan-Hsuan Chuang <yhchuang@realtek.com> |
rtw88: not to enter or leave PS under IRQ Remove PS related *_irqsafe functions to avoid entering/leaving PS under interrupt context. Instead, make PS decision in watch_dog. This could simplify the logic and make the code look clean. But it could have a little side-effect that if the driver is having heavy traffic before the every-2-second watch_dog detect the traffic and decide to leave PS, the thoughput will be lower. Once traffic is detected by watch_dog and left PS state, the throughput will resume to the peak the hardware ought to have again. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
#
3c519605 |
|
01-Oct-2019 |
Yan-Hsuan Chuang <yhchuang@realtek.com> |
rtw88: remove redundant flag check helper function These helper functions seems useless. And in some cases we want to use test_and_[set/clear]_bit, these helpers will make the code more complicated. So remove them. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
#
4136214f |
|
31-Jul-2019 |
Yan-Hsuan Chuang <yhchuang@realtek.com> |
rtw88: add BT co-existence support Both RTL8822BE/RTL8822CE are WiFi + BT combo chips. Since WiFi and BT use 2.4GHz to transmit, it is important to make sure they run concurrently without interfering each other. To achieve this, WiFi driver requires a mechanism to collaborate with BT, whether they share the antenna(s) or not. The final decision made by the co-existence mechanism is to choose a proper strategy, or called "tdma/table", and inform either firmware or hardware of the strategy. To choose a strategy, co-existence mechanism needs to have enough information from WiFi and BT. BT information is provided through firmware C2H. The contents describe the current status of BT, such as if BT is connected or is idle, or the profile that is being used. WiFi information can be provided by WiFi itself. The WiFi driver will call various of "notify" functions each time the state of WiFi changed, such as WiFi is going to switch channel or is connected. Also WiFi driver can know if it shares antenna with BT by reading efuse content. Antenna configuration of the module will finally get a different strategy. Upon receiving any information from WiFi or BT, the WiFi driver will run the co-existence mechanism immediately. It will set the RF antenna configuration according to the strategy through the TDMA H2C to firmware and a hardware table. Based on the tdma/table, WiFi + BT should work with each other, and having a better user experience. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
#
e3037485 |
|
26-Apr-2019 |
Yan-Hsuan Chuang <yhchuang@realtek.com> |
rtw88: new Realtek 802.11ac driver This is a new mac80211 driver for Realtek 802.11ac wireless network chips. rtw88 now supports RTL8822BE/RTL8822CE now, with basic station mode functionalities. The firmware for both can be found at linux-firmware. https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git For RTL8822BE: rtw88/rtw8822b_fw.bin For RTL8822CE: rtw88/rtw8822c_fw.bin And for now, only PCI buses (RTL8xxxE) are supported. We will add support for USB and SDIO in the future. The bus interface abstraction can be seen in this driver such as hci.h. Most of the hardware setting are the same except for some TRX path or probing setup should be separated. Supported: * Basic STA/AP/ADHOC mode, and TDLS (STA is well tested) Missing feature: * WOW/PNO * USB & SDIO bus (such as RTL8xxxU/RTL8xxxS) * BT coexistence (8822B/8822C are combo ICs) * Multiple interfaces (for now single STA is better supported) * Dynamic hardware calibrations (to improve/stabilize performance) Potential problems: * static calibration spends too much time, and it is painful for driver to leave IDLE state. And slows down associate process. But reload function are under development, will be added soon! * TRX statictics misleading, as we are not reporting status correctly, or say, not reporting for "every" packet. The next patch set should have BT coexistence code since RTL8822B/C are combo ICs, and the driver for BT can be found after Linux Kernel v4.20. So it is better to add it first to make WiFi + BT work concurrently. Although now rtw88 is simple but we are developing more features for it. Even we want to add support for more chips such as RTL8821C/RTL8814B. Finally, rtw88 has many authors, listed alphabetically: Ping-Ke Shih <pkshih@realtek.com> Tzu-En Huang <tehuang@realtek.com> Yan-Hsuan Chuang <yhchuang@realtek.com> Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Tested-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|