summaryrefslogtreecommitdiffstats
path: root/drivers/net/wireless/realtek (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
| * wifi: rtw89: 8922a: new implementation for RFK pre-notify H2CKuan-Chung Chen2024-08-073-22/+53
| | | | | | | | | | | | | | | | | | | | For firmware version 0.35.31 and above, update H2C RFK pre-notify to new implementation. Rename existing H2C to v0 for backward compatibility. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240731070506.46100-2-pkshih@realtek.com
| * wifi: rtw89: pass chanctx_idx to rtw89_btc_{path_}phymap()Zong-Zhe Yang2024-08-027-37/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | Originally, rtw89_btc_phymap() and rtw89_btc_path_phymap() access chan with hard-code RTW89_CHANCTX_0. But, they are problematic when the chip supports multiple channels. So, change their prototype and pass chanctx_idx ahead. Let callers still pass RTW89_CHANCTX_0 for now, but we will refine callers in the following. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240727080650.12195-8-pkshih@realtek.com
| * wifi: rtw89: fw: correct chan access in assoc_cmac_tbl_g7 and update_beacon_beZong-Zhe Yang2024-08-021-2/+2
| | | | | | | | | | | | | | | | | | | | Originally, these H2C commands access chan with hard-code RTW89_CHANCTX_0. They are problematic when the chip supports multiple channels. So, correct them by accessing right chan under rtwvif. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240727080650.12195-7-pkshih@realtek.com
| * wifi: rtw89: pass rtwvif to RFK scanZong-Zhe Yang2024-08-028-16/+24
| | | | | | | | | | | | | | | | | | | | | | For chips supporting multiple channels, they need to get target info from rtwvif, e.g. PHY index and Chanctx index. So, change rfk_scan prototype and pass rtwvif ahead. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240727080650.12195-6-pkshih@realtek.com
| * wifi: rtw89: pass rtwvif to RFK channelZong-Zhe Yang2024-08-029-17/+18
| | | | | | | | | | | | | | | | | | | | | | For chips supporting multiple channels, they need to get target info from rtwvif, e.g. PHY index and Chanctx index. So, change rfk_channel prototype and pass rtwvif ahead. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240727080650.12195-5-pkshih@realtek.com
| * wifi: rtw89: rename sub_entity to chanctxZong-Zhe Yang2024-08-0224-223/+223
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally, we planed to fill MAC_0/1 indicators with chanctx and use sub_entity_xxx for these things. However, there are some reasons listed below which make us give up this plan after we know our Wi-Fi 7 HW design. 1. one link is bound to one HW band during its life time but, one link might change chanctx dynamically 2. in concurrent mode, assume 1st vif is MLD 1st vif's 2nd link might use the same chanctx as 2nd vif but, they are not on the same HW band So, we let sub_entity_xxx stuffs deal with only chanctx now. And, to be more readable, we rename sub_entity related words to chanctx. No logic is changed. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240727080650.12195-4-pkshih@realtek.com
| * wifi: rtw89: mcc: stop at a role holding chanctxZong-Zhe Yang2024-08-023-6/+38
| | | | | | | | | | | | | | | | | | | | | | | | In general, MCC (multi-channel concurrency) stops when some chanctx is unassigned. Originally, we let FW to stop at a fixed role. However, it might be the one to be unassigned. So, iterate MCC roles and select one which is still holding chanctx. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240727080650.12195-3-pkshih@realtek.com
| * wifi: rtw89: chan: refine MCC re-plan flow when unassign chanctxZong-Zhe Yang2024-08-021-12/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally during unassign-chanctx, MCC (multi-channel concurrency) is re-planed before set-channel if need. But, we might calculate MCC stuffs based on old channel info. And, the following set-channel might be racing with FW MCC state mechanism. So, we refine this flow. Now, if MCC re-plan is needed here, it will be done after set-channel. Besides, to be more rigorous, we now ensure entity isn't paused before we deal with MCC things here. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240727080650.12195-2-pkshih@realtek.com
| * wifi: rtw88: always wait for both firmware loading attemptsDmitry Antipov2024-08-021-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In 'rtw_wait_firmware_completion()', always wait for both (regular and wowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()' has failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue 'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually the wowlan one) is still in progress, causing UAF detected by KASAN. Fixes: c8e5695eae99 ("rtw88: load wowlan firmware if wowlan is supported") Reported-by: syzbot+6c6c08700f9480c41fe3@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6c6c08700f9480c41fe3 Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240726114657.25396-1-dmantipov@yandex.ru
| * wifi: rtw89: fix typo of rtw89_phy_ra_updata_XXXZong-Zhe Yang2024-08-023-7/+7
| | | | | | | | | | | | | | | | `updata` should be `update` Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240724052626.12774-5-pkshih@realtek.com
| * wifi: rtw89: 885xb: reset IDMEM mode to prevent download firmware failurePing-Ke Shih2024-08-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For different firmware type, it could change IDMEM mode, so reset it to default to avoid encountering error for RTL8851B/RTL8852B/RTL8852BT if that kind of firmware was downloaded before. rtw89_8851be 0000:02:00.0: Firmware version 0.29.41.3, cmd version 0, type 5 rtw89_8851be 0000:02:00.0: Firmware version 0.29.41.3, cmd version 0, type 3 rtw89_8851be 0000:02:00.0: MAC has already powered on rtw89_8851be 0000:02:00.0: fw security fail rtw89_8851be 0000:02:00.0: download firmware fail rtw89_8851be 0000:02:00.0: [ERR]fwdl 0x1E0 = 0x62 rtw89_8851be 0000:02:00.0: [ERR]fwdl 0x83F2 = 0x8 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f51c rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f524 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f51c rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f500 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f51c rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f53c rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f520 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f520 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f508 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f534 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f520 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f534 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f508 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f53c rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f524 rtw89_8851be 0000:02:00.0: failed to setup chip information rtw89_8851be: probe of 0000:02:00.0 failed with error -16 Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240724052626.12774-4-pkshih@realtek.com
| * wifi: rtw89: add support for hardware rfkillKuan-Chung Chen2024-08-0210-0/+184
| | | | | | | | | | | | | | | | | | | | Add support for ieee80211::rfkill_poll ops. This enables periodic monitoring of the hardware rfkill state, triggering updates when the status changes. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240724052626.12774-3-pkshih@realtek.com
| * wifi: rtw89: add EVM statistics for 1SS rateKuan-Chung Chen2024-08-024-13/+52
| | | | | | | | | | | | | | | | | | | | To more accurately debug performance issues, EVM statistics will differentiate between different space streams, and only beacon and data frames will be included. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240724052626.12774-2-pkshih@realtek.com
| * wifi: rtw88: 8822c: Parse channel from IE to correct invalid hardware reportsPo-Hao Huang2024-08-027-3/+63
| | | | | | | | | | | | | | | | | | | | For CCK packets we could get incorrect reports from hardware. And this causes wrong frequencies being reported. Parse the channel information from IE if provided by AP to fix this. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240724050501.7550-1-pkshih@realtek.com
| * wifi: rtw88: 8703b: Fix reported RX band widthBitterblue Smith2024-07-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The definition of GET_RX_DESC_BW is incorrect. Fix it according to the GET_RX_STATUS_DESC_BW_8703B macro from the official driver. Tested only with RTL8812AU, which uses the same bits. Cc: stable@vger.kernel.org Fixes: 9bb762b3a957 ("wifi: rtw88: Add definitions for 8703b chip") Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Tested-by: Fiona Klute <fiona.klute@gmx.de> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/1cfed9d5-4304-4b96-84c5-c347f59fedb9@gmail.com
| * wifi: rtw88: 8822c: Fix reported RX band widthBitterblue Smith2024-07-311-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "iw dev wlp2s0 station dump" shows incorrect rx bitrate: tx bitrate: 866.7 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 2 rx bitrate: 86.7 MBit/s VHT-MCS 9 VHT-NSS 1 This is because the RX band width is calculated incorrectly. Fix the calculation according to the phydm_rxsc_2_bw() function from the official drivers. After: tx bitrate: 866.7 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 2 rx bitrate: 390.0 MBit/s VHT-MCS 9 80MHz VHT-NSS 1 It also works correctly with the AP configured for 20 MHz and 40 MHz. Tested with RTL8822CE. Cc: stable@vger.kernel.org Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver") Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/bca8949b-e2bd-4515-98fd-70d3049a0097@gmail.com
| * wifi: rtw89: 8852bt: add 8852BE-VT to Makefile and KconfigPing-Ke Shih2024-07-312-0/+23
| | | | | | | | | | | | | | | | RTL8852BE-VT is a WiFi 6 2x2 chip, which can operate on 2/5 GHz channels and 80MHz bandwidth. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240720021340.12102-8-pkshih@realtek.com
| * wifi: rtw89: 8852bte: add PCI entry of 8852BE-VTPing-Ke Shih2024-07-311-0/+93
| | | | | | | | | | | | | | | | PCI device ID 10ec:b520 of RTL8852BE-VT is added as PCI entry, and define chip capabilities for driver common routines. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240720021340.12102-7-pkshih@realtek.com
| * wifi: rtw89: 8852bt: declare firmware features of RTL8852BTPing-Ke Shih2024-07-311-0/+4
| | | | | | | | | | | | | | | | Firmware features are enabled after being supported, including TX wake, firmware crash simulation, hardware scan. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240720021340.12102-6-pkshih@realtek.com
| * wifi: rtw89: 8852bt: add chip_ops of RTL8852BTPing-Ke Shih2024-07-312-0/+463
| | | | | | | | | | | | | | | | | | Add chip_info of RTL8852BT accordingly, including power on/off function, BB reset, TSSI settings while setting channel, RF calibration, and BT coexistence. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240720021340.12102-5-pkshih@realtek.com
| * wifi: rtw89: 8852bt: add chip_info of RTL8852BTPing-Ke Shih2024-07-316-4/+455
| | | | | | | | | | | | | | | | | | Add chip_info of RTL8852BT accordingly, including firmware elements support, MAC memory quota (WDE, PLE and etc), SER IMR used by firmware, BTC registers, register based H2C/C2H, WoWLAN stub. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240720021340.12102-4-pkshih@realtek.com
| * wifi: rtw89: 8852bt: rfk: use predefined string choice for DPK enable/disablePing-Ke Shih2024-07-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | clang warns precedence of '?:' and '&'. Even though original logic is correct, use str_enable_disable() to avoid clang confusing. Another way to fix is to add parentheses around '&', but I choose former one. >> drivers/net/wireless/realtek/rtw89/rtw8852bt_rfk.c:1827:46: warning: operator '?:' has lower precedence than '&'; '&' will be evaluated first [-Wbitwise-conditional-parentheses] 1827 | kidx, dpk->is_dpk_enable & off_reverse ? "enable" : "disable"); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202407200741.dMG9uvHU-lkp@intel.com/ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240720021340.12102-3-pkshih@realtek.com
| * wifi: rtw89: 8852bt: add set_channel_rfPing-Ke Shih2024-07-312-0/+229
| | | | | | | | | | | | | | | | Add RF part of set_channel() is to configure RF registers, and then hardware can TX/RX on specified frequency and bandwidth. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240720021340.12102-2-pkshih@realtek.com
| * wifi: rtw89: select WANT_DEV_COREDUMPZong-Zhe Yang2024-07-311-0/+1
| | | | | | | | | | | | | | | | | | We have invoked device coredump when fw crash. Should select WANT_DEV_COREDUMP by ourselves. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240718070616.42217-2-pkshih@realtek.com
| * wifi: rtw88: select WANT_DEV_COREDUMPZong-Zhe Yang2024-07-311-0/+1
| | | | | | | | | | | | | | | | | | We have invoked device coredump when fw crash. Should select WANT_DEV_COREDUMP by ourselves. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240718070616.42217-1-pkshih@realtek.com
| * wifi: rtw88: debugfs: support multiple adapters debuggingPing-Ke Shih2024-07-314-129/+180
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally in order to read partial registers from large area, we write a range value stored into a static variable and read registers according to the static variable. However, if we install more than one adapters supported by this driver, the static variables will be overwritten by latter adapters. To resolve the problem, move the static variables to struct rtw_dev for each adapter. With changes, smatch spends too much time to parse rtw_debugfs_init(): debug.c:1289 rtw_debugfs_init() parse error: turning off implications after 60 seconds Move stuffs of adding debugfs entries to three rtw_debugfs_add_xxx() functions. Reported-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Closes: https://lore.kernel.org/linux-wireless/cd6a2acf3c2c36d938b40140b52a779516f446a9.camel@realtek.com/T/#m27662022c70d9f893ba96f6c6a8dd8fce2434dfe Tested-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240718064155.38955-1-pkshih@realtek.com
| * wifi: rtw88: 8821cu: Remove VID/PID 0bda:c82cNick Morrow2024-07-171-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | Remove VID/PID 0bda:c82c as it was inadvertently added to the device list in driver rtw8821cu. This VID/PID is for the rtw8822cu device and it is already in the appropriate place for that device. Cc: stable@vger.kernel.org Signed-off-by: Nick Morrow <morrownr@gmail.com> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/335d7fa1-0ba5-4b86-bba5-f98834ace1f8@gmail.com
| * wifi: rtw88: usb: Support USB 3 with RTL8822CU/RTL8822BUBitterblue Smith2024-07-178-12/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Realtek wifi 5 devices which support USB 3 are weird: when first plugged in, they pretend to be USB 2. The driver needs to send some commands to the device, which make it disappear and come back as a USB 3 device. Implement the required commands in rtw88. When a USB 3 device is plugged into a USB 2 port, rtw88 will try to switch it to USB 3 mode only once. The device will disappear and come back still in USB 2 mode, of course. Some people experience heavy interference in the 2.4 GHz band in USB 3 mode, so add a module parameter switch_usb_mode with the default value 1 to let people disable the switching. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/77906c62-5674-426f-bde1-1b2a12a0339d@gmail.com
| * wifi: rtw89: 8852bt: rfk: Fix spelling mistake "KIP_RESOTRE" -> "KIP_RESTORE"Colin Ian King2024-07-171-1/+1
| | | | | | | | | | | | | | | | | | There is a spelling mistake in a literal string. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240710112253.228171-1-colin.i.king@gmail.com
| * wifi: rtw88: Set efuse->ext_lna_5g - fix typoBitterblue Smith2024-07-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | efuse->ext_lna_2g is set twice and efuse->ext_lna_5g is not set at all. Set each one once. Nothing uses these members right now. They will be used by the RTL8821AU and RTL8812AU drivers. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/8ccc9e13-0d45-417d-8f88-93a0ad294f77@gmail.com
* | wifi: rtlwifi: rtl8192du: Initialise value32 in ↵Bitterblue Smith2024-08-071-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | _rtl92du_init_queue_reserved_page GCC complains: In file included from include/linux/ieee80211.h:21, from include/net/mac80211.h:20, from drivers/net/wireless/realtek/rtlwifi/rtl8192du/../wifi.h:14, from drivers/net/wireless/realtek/rtlwifi/rtl8192du/hw.c:4: In function 'u32p_replace_bits', inlined from '_rtl92du_init_queue_reserved_page.isra' at drivers/net/wireless/realtek/rtlwifi/rtl8192du/hw.c:225:2: >> include/linux/bitfield.h:189:18: warning: 'value32' is used uninitialized [-Wuninitialized] Part of the variable is indeed left uninitialised. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202408062100.DWhN0CYH-lkp@intel.com/ Fixes: e769c67105d3 ("wifi: rtlwifi: Add rtl8192du/hw.{c,h}") Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/2a808244-93d0-492c-b304-ae1974df5df9@gmail.com
* Merge tag 'rtw-next-2024-07-05' of https://github.com/pkshih/rtwKalle Valo2024-07-0965-2176/+8131
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | rtw-next patches for v6.11 Some cleanups of rtl8xxxu and rtlwifi, and some fixes of rtw88. The major change is to develop WoWLAN and preparation of RTL8852BE-VT listed below: rtw89: - preparation of RTL8852BE-VT * add RF calibration code * move shared code with RTL8852BE to common module - add WoWLAN for WiFi 6 chips - support 36-bit PCI DMA
| * wifi: rtw89: Fix array index mistake in rtw89_sta_info_get_iter()Aleksandr Mishin2024-07-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In rtw89_sta_info_get_iter() 'status->he_gi' is compared to array size. But then 'rate->he_gi' is used as array index instead of 'status->he_gi'. This can lead to go beyond array boundaries in case of 'rate->he_gi' is not equal to 'status->he_gi' and is bigger than array size. Looks like "copy-paste" mistake. Fix this mistake by replacing 'rate->he_gi' with 'status->he_gi'. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: e3ec7017f6a2 ("rtw89: add Realtek 802.11ax driver") Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240703210510.11089-1-amishin@t-argos.ru
| * wifi: rtlwifi: fix default typoFredrik Lönnegren2024-07-058-8/+8
| | | | | | | | | | | | | | | | | | Change 'defult' to 'default' in comments in several rtlwifi drivers. Signed-off-by: Fredrik Lönnegren <fredrik@frelon.se> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240703070627.135328-1-fredrik@frelon.se
| * wifi: rtw89: unify the selection logic of RFK table when MCCZong-Zhe Yang2024-07-057-26/+141
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Driver will notify FW the target index of RFK table to use at some moments. When MCC (multi-channel concurrent), the correctness of the notification is especially important. We now unify the selection logic of RFK table as below among chips. 1. check each table if it matches target channel 2. check all tables if any is idle by iterating active channels 3. replace the first table if all are busy unexpectedly Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240702124452.18747-2-pkshih@realtek.com
| * wifi: rtw89: mac: parse MRC C2H failure reportZong-Zhe Yang2024-07-052-0/+50
| | | | | | | | | | | | | | | | | | | | MRC (multi-role concurrency) has a C2H event for status report. Newer FW will report some kinds of failures. We parse them now and show by debug log. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240702124452.18747-1-pkshih@realtek.com
| * wifi: rtw89: 8852bx: add extra handles of BTC for 8852BT in 8852b_commonPing-Ke Shih2024-07-051-0/+5
| | | | | | | | | | | | | | | | For 8852BT, the initial settings of BT-coexistence is a little bit different, so add the extra handles. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240701014619.7300-2-pkshih@realtek.com
| * wifi: rtw89: 8852bx: move BTC common code from 8852b to 8852b_commonPing-Ke Shih2024-07-053-167/+216
| | | | | | | | | | | | | | | | | | | | The BT coexistence part of 8852B and 8852BT are similar, so move shared code into common module. Don't change logic for existing RTL8852BE. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240701014619.7300-1-pkshih@realtek.com
| * wifi: rtw88: usb: schedule rx work after everything is set upMarcin Ślusarz2024-07-051-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Right now it's possible to hit NULL pointer dereference in rtw_rx_fill_rx_status on hw object and/or its fields because initialization routine can start getting USB replies before rtw_dev is fully setup. The stack trace looks like this: rtw_rx_fill_rx_status rtw8821c_query_rx_desc rtw_usb_rx_handler ... queue_work rtw_usb_read_port_complete ... usb_submit_urb rtw_usb_rx_resubmit rtw_usb_init_rx rtw_usb_probe So while we do the async stuff rtw_usb_probe continues and calls rtw_register_hw, which does all kinds of initialization (e.g. via ieee80211_register_hw) that rtw_rx_fill_rx_status relies on. Fix this by moving the first usb_submit_urb after everything is set up. For me, this bug manifested as: [ 8.893177] rtw_8821cu 1-1:1.2: band wrong, packet dropped [ 8.910904] rtw_8821cu 1-1:1.2: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status because I'm using Larry's backport of rtw88 driver with the NULL checks in rtw_rx_fill_rx_status. Link: https://lore.kernel.org/linux-wireless/CA+shoWQ7P49jhQasofDcTdQhiuarPTjYEDa--NiVVx494WcuQw@mail.gmail.com/ Signed-off-by: Marcin Ślusarz <mslusarz@renau.com> Cc: Tim K <tpkuester@gmail.com> Cc: Ping-Ke Shih <pkshih@realtek.com> Cc: Larry Finger <Larry.Finger@lwfinger.net> Cc: Kalle Valo <kvalo@kernel.org> Cc: linux-wireless@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240528110246.477321-1-marcin.slusarz@gmail.com
| * wifi: rtw89: 8852bt: rfk: add RCKPing-Ke Shih2024-07-022-0/+44
| | | | | | | | | | | | | | | | RCK is synchronize RC calibration. Driver triggers this calibration and writes the result to registers. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240627025849.25198-5-pkshih@realtek.com
| * wifi: rtw89: 8852bt: rfk: add DACKPing-Ke Shih2024-07-023-0/+503
| | | | | | | | | | | | | | | | DACK (digital-to-analog converters calibration) is used to calibrate DAC to output signals as expected. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240627025849.25198-4-pkshih@realtek.com
| * wifi: rtw89: 8852bt: rfk: add RX DCKPing-Ke Shih2024-07-022-0/+58
| | | | | | | | | | | | | | | | | | RX DCK stands for receiver DC calibration. With this calibration, we have proper DC offset to reflect correct received signal strength indicator. Do this calibration when bringing up interface and going to connect. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240627025849.25198-3-pkshih@realtek.com
| * wifi: rtw89: 8852bt: rfk: add IQKPing-Ke Shih2024-07-023-0/+894
| | | | | | | | | | | | | | | | | | | | | | IQ signal calibration is a very important calibration to yield good RF performance. We do this calibration once we are going to an AP. During scanning phase, without this calibration RF performance is still acceptable because it transmits and receives with low data rate at this phase. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240627025849.25198-2-pkshih@realtek.com
| * wifi: rtw89: constrain TX power according to Transmit Power EnvelopeZong-Zhe Yang2024-07-026-18/+262
| | | | | | | | | | | | | | | | | | | | | | | | | | Calculate a TX power constraint based on content of ieee80211 Transmit Power Envelope (TPE). Since HW control registers aren't designed as many as all kinds of TPE fields, we strictly intersect all TPE inputs in driver. Then, according to result, constrain TX power via TX power limit/limit_RU. Besides, extend dbgfs txpwr_table to show info about 6 GHz regulatory. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240626023237.7901-1-pkshih@realtek.com
| * wifi: rtw89: coex: Add coexistence policy for hardware scanChing-Te Ku2024-07-022-1/+26
| | | | | | | | | | | | | | | | | | Add additional policy option to let Bluetooth audio can play well during Wi-Fi is hardware scanning. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240626023129.7776-1-pkshih@realtek.com
| * wifi: rtl8xxxu: 8188f: Limit TX power indexMartin Kaistra2024-06-271-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TX power index is read from the efuse on init, the values get written to the TX power registers when the channel gets switched. When the chip has not yet been calibrated, the efuse values are 0xFF, which on some boards leads to USB timeouts for reading/writing registers after the first frames have been sent. The vendor driver (v5.11.5-1) checks for these invalid values and sets default values instead. Implement something similar in rtl8188fu_parse_efuse(). Fixes: c888183b21f3 ("wifi: rtl8xxxu: Support new chip RTL8188FU") Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240624140037.231657-1-martin.kaistra@linutronix.de
| * wifi: rtw89: 8852b: fix definition of KIP register numberKuan-Chung Chen2024-06-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | An incorrect definition caused DPK to fail to backup and restore a set of KIP registers. Fixing this will improve RX throughput from 902 to 997 Mbps. Fixes: 5b8471ace5b1 ("wifi: rtw89: 8852b: rfk: add DPK") Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240621123617.6687-2-pkshih@realtek.com
| * wifi: rtw89: 8852b: set AMSDU limit to 5000Ping-Ke Shih2024-06-271-1/+1
| | | | | | | | | | | | | | | | Enlarge AMSDU limit to improve MAC efficient to get better TX throughput from 851 to 895 Mbps. No change for RX throughput 902 Mbps. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240621123617.6687-1-pkshih@realtek.com
| * wifi: rtw89: 8852bt: rfk: add DPKPing-Ke Shih2024-06-274-0/+1362
| | | | | | | | | | | | | | | | | | | | | | | | | | DPK is short for digital pre-distortion calibration. It can adjusts digital waveform according to PA linear characteristics dynamically to enhance TX EVM for high power. Do this calibration when we are going to run on AP channel. To prevent power offset out of boundary, it monitors thermal and set proper boundary to register. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240621073458.55187-3-pkshih@realtek.com
| * wifi: rtw89: 8852bt: rfk: add TSSIPing-Ke Shih2024-06-276-0/+1764
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TSSI is transmitter signal strength indication, which is a close-loop hardware circuit to feedback actual transmitting power as a reference for next transmission. It does full calibration when we are going to connect an AP. When switching bands or channels for scanning or some reasons, reset hardware status to prevent use wrong power value feedback from previous transmission. It also loads tables of compensation values reflecting current temperature into registers according to channel and band group to transmit packets with expected power. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240621073458.55187-2-pkshih@realtek.com
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-13 18:31:49 +0100