summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek
AgeCommit message (Collapse)Author
2025-02-21wifi: rtw89: fw: propagate error code from rtw89_h2c_tx()Ping-Ke Shih
The error code should be propagated to callers during downloading firmware header and body. Remove unnecessary assignment of -1. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250217064308.43559-4-pkshih@realtek.com
2025-02-21wifi: rtw89: fw: get sb_sel_ver via get_unaligned_le32()Ping-Ke Shih
The sb_sel_ver is selection version for secure boot recorded in firmware binary data, and its size is 4 and offset is 58 (not natural alignment). Use get_unaligned_le32() to get this value safely. Find this by reviewing. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250217064308.43559-3-pkshih@realtek.com
2025-02-21wifi: rtw89: fw: add blacklist to avoid obsolete secure firmwarePing-Ke Shih
To ensure secure chip only runs expected secure firmware, stop using obsolete firmware in blacklist which weakness or flaw was found. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250217064308.43559-2-pkshih@realtek.com
2025-02-21wifi: rtw89: add H2C command of TX time for WiFi 7 chipsPing-Ke Shih
BT-coexistence configure WiFi TX time to share time slots with Bluetooth devices. Since the format is different from WiFi 6 chips, add the new format accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250217063053.38936-3-pkshih@realtek.com
2025-02-21wifi: rtw89: mac: define registers of agg_limit and txcnt_limit to share ↵Ping-Ke Shih
common flow The agg_limit and txcnt_limit are used by BT-coexistence to reduce WiFi TX time at once to share time with Bluetooth devices. Since these registers address are different from WiFi 6 and 7 chips, define them accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250217063053.38936-2-pkshih@realtek.com
2025-02-21wifi: rtw89: 8922a: fix incorrect STA-ID in EHT MU PPDUKuan-Chung Chen
EHT MU PPDU contains user field of EHT-SIG field with STA-ID that must match AID subfield in the Associate Response. Add a necessary setting to prevent these from being inconsistent. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250217061235.32031-1-pkshih@realtek.com
2025-02-21wifi: rtw89: rtw8852b{t}: fix TSSI debug timestampsDmitry Antipov
Since the vendor driver is claimed to measure 'tssi_alimk_time' of 'struct rtw89_tssi_info' in microseconds, adjust rtw8852b{t}-specific '_tssi_alimentk()' to not mess the former with nanoseconds and print both per-call and accumulated times. Compile tested only. Fixes: 7f18a70d7b4d ("wifi: rtw89: 8852b: rfk: add TSSI") Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250213095006.1308810-1-dmantipov@yandex.ru
2025-02-21wifi: rtw88: Add support for Mercusys MA30N and D-Link DWA-T185 rev. A1Zenm Chen
Add two more USB IDs found in https://github.com/RinCat/RTL88x2BU-Linux-Driver to support Mercusys MA30N and D-Link DWA-T185 rev. A1. Signed-off-by: Zenm Chen <zenmchen@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250210073610.4174-1-zenmchen@gmail.com
2025-02-10wifi: rtw89: debugfs depends on CFG80211's onePing-Ke Shih
The wiphy_locked_debugfs_read() and wiphy_locked_debugfs_write() used by rtw89 are defined if CFG80211_DEBUGFS enabled. Add the dependency accordingly. Fixes: 8fdf78f3cd5f ("wifi: rtw89: debugfs: use wiphy_locked_debugfs_{read,write}() if needed") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202502101810.3CUpUL7p-lkp@intel.com/ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250210123105.10466-1-pkshih@realtek.com
2025-02-10wifi: rtlwifi: rtl8192de: Fix typos of debug message of phy settingAndrew Kreimer
There are some typos in comments/messages: - althougth -> although - asume -> assume Fix them via codespell. Signed-off-by: Andrew Kreimer <algonell@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250206082457.9148-1-algonell@gmail.com
2025-02-10wifi: rtw88: Fix rtw_update_sta_info() for RTL8814AUBitterblue Smith
This function tells the firmware what rates it can use. Put the 3SS and 4SS HT rates supported by the other station into the rate mask. Remove the 3SS and 4SS rates from the rate mask if the hardware only has 2 spatial streams. And finally, select the right rate ID (a parameter for the firmware) when the hardware has 3 spatial streams. 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/48d1d90f-2aeb-4ec5-9a24-0980e10eae1e@gmail.com
2025-02-10wifi: rtw88: Extend TX power stuff for 3-4 spatial streamsBitterblue Smith
Although the RTL8814AU only has 3 spatial streams, maybe some other chip has 4. Correct the TX power index and TX power limit calculations for 3SS and 4SS HT/VHT rates. With this the RTL8814AU can set the TX power correctly. 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/d0c0e126-0794-4c4e-9203-ea39a707b673@gmail.com
2025-02-10wifi: rtw88: Rename RTW_RATE_SECTION_MAX to RTW_RATE_SECTION_NUMBitterblue Smith
It fits the meaning of the enum better. 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/5a1c5a46-8ebb-43b0-9ab1-b78e2a22b3d2@gmail.com
2025-02-10wifi: rtw88: Constify some more structs and arraysBitterblue Smith
These structs and arrays are never modified, so make them const: rtw_band_2ghz rtw_band_5ghz rtw_pci_tx_queue_idx_addr rtw_pci_ops rtw_cck_rates rtw_ofdm_rates rtw_ht_1s_rates rtw_ht_2s_rates rtw_vht_1s_rates rtw_vht_2s_rates rtw_rate_section rtw_rate_size rtw_sdio_ops rtw_usb_ops 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/502f124e-ccf3-4c09-80a4-1e5c5304822b@gmail.com
2025-02-10wifi: rtw88: Extend rtw_fw_send_ra_info() for RTL8814AUBitterblue Smith
The existing code is suitable for chips with up to 2 spatial streams. Inform the firmware about the rates it's allowed to use when transmitting 3 spatial streams. 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/08e2f328-1aab-4e50-93ac-c1e5dd9541ac@gmail.com
2025-02-10wifi: rtw88: Extend rf_base_addr and rf_sipi_addr for RTL8814AUBitterblue Smith
These members of struct rtw_chip_info each have a size of 2. Increase their size to 4, which is the number of RF paths the RTL8814AU has. This is required to read and write the RF registers of the RTL8814AU. 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/7a4d8209-b8af-4943-b5de-f53d6edf591a@gmail.com
2025-02-10wifi: rtw88: Extend struct rtw_pwr_track_tbl for RTL8814AUBitterblue Smith
Currently this struct has the members required for chips with 2 RF paths. Add more members to support chips with 4 RF paths, like the RTL8814AU. 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/be5a73f4-a0fe-43d6-9457-930cde199284@gmail.com
2025-02-10wifi: rtw88: Fix download_firmware_validate() for RTL8814AUBitterblue Smith
After the firmware is uploaded, download_firmware_validate() checks some bits in REG_MCUFW_CTRL to see if everything went okay. The RTL8814AU power on sequence sets bits 13 and 12 to 2, which this function does not expect, so it thinks the firmware upload failed. Make download_firmware_validate() ignore bits 13 and 12. 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/049d2887-22fc-47b7-9e59-62627cb525f8@gmail.com
2025-02-10wifi: rtw88: Fix __rtw_download_firmware() for RTL8814AUBitterblue Smith
Don't call ltecoex_read_reg() and ltecoex_reg_write() when the ltecoex_addr member of struct rtw_chip_info is NULL. The RTL8814AU doesn't have this feature. 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/55b5641f-094e-4f94-9f79-ac053733f2cf@gmail.com
2025-02-10wifi: rtw88: Fix a typo of debug message in rtw8723d_iqk_check_tx_failed()Andrew Kreimer
There is a typo in debug messages: - afer -> after Fix it via codespell. Signed-off-by: Andrew Kreimer <algonell@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250203180913.5435-1-algonell@gmail.com
2025-02-10wifi: rtw89: regd: avoid using BITMAP_FROM_U64() to assign function bitmapPing-Ke Shih
Since there are two function features for now, func_bitmap[] has single one element, which BITMAP_FROM_U64() generating two elements is exceeded. Change to assign function bitmap barely. With i386-allmodconfig (a 32 bit system), it throws >> include/linux/bitmap.h:736:33: warning: excess elements in array initializer 736 | ((unsigned long) ((u64)(n) >> 32)) | ^ drivers/net/wireless/realtek/rtw89/regd.c:16:34: note: in expansion of macro 'BITMAP_FROM_U64' 16 | .func_bitmap = { BITMAP_FROM_U64(_fmap), }, \ | ^~~~~~~~~~~~~~~ drivers/net/wireless/realtek/rtw89/regd.c:20:9: note: in expansion of macro 'COUNTRY_REGD' 20 | COUNTRY_REGD("00", RTW89_WW, RTW89_WW, RTW89_WW, 0x0); | ^~~~~~~~~~~~ Fixes: 79a36fc56bea ("wifi: rtw89: regd: handle supported regulatory functions by country") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202502031932.BMQ4lhJT-lkp@intel.com/ Cc: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250205014051.13765-1-pkshih@realtek.com
2025-02-10wifi: rtw89: coex: Update Wi-Fi/Bluetooth coexistence version to 7.0.3Ching-Te Ku
Refine the TWS Bluetooth related coexistence mechanism. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250205013233.10945-4-pkshih@realtek.com
2025-02-10wifi: rtw89: coex: To avoid TWS serials A2DP lag, adjust slot arrangementChing-Te Ku
The TWS(True wireless stereo) serials Bluetooth audio device need to keep packet traffic not only with DUT, it also need to synchronize packet with its assistant earbud. And all the BR/EDR Bluetooth device need to do page scan to keep re-connect event sensitively between different DUT. These behavior will make TWS Bluetooth device cost more time slot to keep the good audio performance. This patch decrease half of Wi-Fi slot(from 40ms to 20ms) in a single cycle. Make the slot more flexible to prevent audio lag. The single cycle will be shorter, then it will bring some slot protection cost make Wi-Fi throughput decrease about 5%. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250205013233.10945-3-pkshih@realtek.com
2025-02-10wifi: rtw89: coex: Assign value over than 0 to avoid firmware timer hangChing-Te Ku
If the slot duration is 0, the firmware timer will trigger timer hang at the timer initializing state in a low rate due to hardware algorithm. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250205013233.10945-2-pkshih@realtek.com
2025-02-10wifi: rtw89: fw: validate multi-firmware header before getting its sizePing-Ke Shih
To access firmware elements appended after multi-firmware, add its size as offset to get start address of firmware elements. +-----+-------+------+---------+--------------+ -- | sig | fw_nr | rsvd | version | reserved | \ +---------------------------------------------+ | fw 0 | cv | type | mp | rsvd | shift | size | rsvd | | +---------------------------------------------+ | fw 1 | cv | type | mp | rsvd | shift | size | rsvd | | +---------------------------------------------+ | fw N-1 | ... | | +=============================================+ | mfw size | fw 0 content | | +=============================================+ | | fw 1 content | | +=============================================+ | | ... | | +=============================================+ | | fw N -1 content | | +=============================================+ --/ | fw element TLV X | +=============================================+ | fw element TLV Y | +=============================================+ | fw element TLV Z | +=============================================+ To avoid Coverity warning when getting mfw size, validate it header ahead. Addresses-Coverity-ID: 1544385 ("Untrusted array index read") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250203072911.47313-5-pkshih@realtek.com
2025-02-10wifi: rtw89: fw: validate multi-firmware header before accessingPing-Ke Shih
A firmeware file contains multi-firmware with a header to represent contents. The mfw_hdr->fw_nr is to define number of firmware in file. +-----+-------+------+---------+--------------+ | sig | fw_nr | rsvd | version | reserved | +---------------------------------------------+ -- fw 0 | cv | type | mp | rsvd | shift | size | rsvd | \ +---------------------------------------------+ | fw 1 | cv | type | mp | rsvd | shift | size | rsvd | | mfw_hdr->fw_nr +---------------------------------------------+ | fw N-1 | ... | / +=============================================+ -- | fw 0 content | | (pointed by fw0 shift/size) | +=============================================+ To avoid Coverity warning, validate header is in range of firmware size, and also validate the range of actual firmware content is in range. Addresses-Coverity-ID: 1494046 ("Untrusted loop bound") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250203072911.47313-4-pkshih@realtek.com
2025-02-10wifi: rtw89: ps: update H2C command with more info for PSEric Huang
Adding beacon BW offset, OP1dB table and rfe_type to lps_ml_cmn_info. These information will help FW to configure RX more accurately. Signed-off-by: Eric Huang <echuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250203072911.47313-3-pkshih@realtek.com
2025-02-10wifi: rtw89: call power_on ahead before selecting firmwarePing-Ke Shih
Driver selects firmware by hardware version, which normally can be read from registers before selecting firmware. However, certain chips such as RTL8851B, it needs to read hardware version from efuse while doing power_on, but do power_on after selecting firmware in current flow. To resolve this flow problem, move power_on out from rtw89_mac_partial_init(), and call rtw89_mac_pwr_on() separately at proper places to have expected flow. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250203072911.47313-2-pkshih@realtek.com
2025-02-03wifi: rtl8xxxu: retry firmware download on errorSoeren Moch
Occasionally there is an EPROTO error during firmware download. This error is converted to EAGAIN in the download function. But nobody tries again and so device probe fails. Implement download retry to fix this. This error was observed (and fix tested) on a tbs2910 board [1] with an embedded RTL8188EU (0bda:8179) device behind a USB hub. [1] arch/arm/boot/dts/nxp/imx/imx6q-tbs2910.dts Signed-off-by: Soeren Moch <smoch@web.de> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250127194828.599379-1-smoch@web.de
2025-02-03wifi: rtw88: Don't use static local variable in ↵Bitterblue Smith
rtw8821c_set_tx_power_index_by_rate Some users want to plug two identical USB devices at the same time. This static variable could theoretically cause them to use incorrect TX power values. Move the variable to the caller and pass a pointer to it to rtw8821c_set_tx_power_index_by_rate(). 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/fe42858c-9b9f-4f03-9aaa-737472c2cd90@gmail.com
2025-02-03wifi: rtw88: Don't use static local variable in ↵Bitterblue Smith
rtw8822b_set_tx_power_index_by_rate Some users want to plug two identical USB devices at the same time. This static variable could theoretically cause them to use incorrect TX power values. Move the variable to the caller and pass a pointer to it to rtw8822b_set_tx_power_index_by_rate(). 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/8a60f581-0ab5-4d98-a97d-dd83b605008f@gmail.com
2025-02-03wifi: rtl8xxxu: Enable AP mode for RTL8192CU (RTL8188CUS)Ezra Buehler
This allows the driver to be used in wireless access point mode on the AT91SAM9G25-based GARDENA smart Gateway. Unfortunately, the data throughput in AP mode appears to be lower than with the vendor driver (or in STA mode). Especially when sending, the data rate is significantly lower. My measurements performed with iperf3 and an Edimax EW-7811Un (VID: 7392, PID: 7811) showed a maximum TX rate of about 4 Mbits/sec compared to the ~24 Mbits/sec measured with the rtl8192cu driver. Although the performance might be good enough for our use case, this is something that should be further looked into. Signed-off-by: Ezra Buehler <ezra.buehler@husqvarnagroup.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250122071512.10165-1-ezra@easyb.ch
2025-02-03wifi: rtw89: pci: not assert wiphy_lock to free early_h2c for PCI probe/removePing-Ke Shih
Except probe/remove flow, the consumers of early_h2c list are interface start and debugfs. There must be no race between probe/remove flow and interface start. The failed probe flow is to free early_h2c list as well as remove flow, at these two moments debugfs doesn't present. Thus, it is safe to free early_h2c list without held wiphy_lock in these situations. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250122060310.31976-11-pkshih@realtek.com
2025-02-03wifi: rtw89: remove definition of driver mutexPing-Ke Shih
No consumers of driver mutex now, so remove definition eventually. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250122060310.31976-10-pkshih@realtek.com
2025-02-03wifi: rtw89: manual cosmetic along lockdep_assert_wiphy()Ping-Ke Shih
With spatch script, already remove most driver mutex and generate lockdep_assert_wiphy(), and some are needed to refine manually further to be expected: - lockdep_assert_wiphy() always be the first statement in function - return directly rather than unnecessary goto - change assert from mutex to wiphy lock, which script can't convert automatically. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250122060310.31976-9-pkshih@realtek.com
2025-02-03wifi: rtw89: remove consumers of driver mutexPing-Ke Shih
All need lock have taken both driver mutex and wiphy lock, so we can remove driver mutex safely by below spatch script. Also, check every lockdep_assert_wiphy() is executed without locks warning at runtime. @ rule1_1 @ @@ - lockdep_assert_held(&rtwdev->mutex); + lockdep_assert_wiphy(rtwdev->hw->wiphy); @ rule1_2 @ @@ - guard(mutex)(&rtwdev->mutex); + lockdep_assert_wiphy(rtwdev->hw->wiphy); @ rule2_1 @ @@ - mutex_lock(&rtwdev->mutex); + lockdep_assert_wiphy(rtwdev->hw->wiphy); ... - mutex_unlock(&rtwdev->mutex); @ rule2_2 @ @@ - mutex_unlock(&rtwdev->mutex); + lockdep_assert_wiphy(rtwdev->hw->wiphy); ... - mutex_lock(&rtwdev->mutex); @ rule3_1 @ type t; identifier fn; @@ t fn(struct wiphy *wiphy, ...) { ... - lockdep_assert_wiphy(rtwdev->hw->wiphy); + lockdep_assert_wiphy(wiphy); ... } @ rule3_1_1 @ type t; identifier fn; @@ t fn(...) { ... struct wiphy *wiphy = ...; ... - lockdep_assert_wiphy(rtwdev->hw->wiphy); + lockdep_assert_wiphy(wiphy); ... } @ rule3_2 @ type t; identifier fn; @@ t fn(struct ieee80211_hw *hw, ...) { ... - lockdep_assert_wiphy(rtwdev->hw->wiphy); + lockdep_assert_wiphy(hw->wiphy); ... } @ rule3_2_1 @ type t; identifier fn; @@ t fn(...) { ... struct ieee80211_hw *hw = ...; ... - lockdep_assert_wiphy(rtwdev->hw->wiphy); + lockdep_assert_wiphy(hw->wiphy); ... } The compiler warnings will be fixed manually by latter patch: rtw89/mac80211.c:371:1: warning: statement expected after label Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250122060310.31976-8-pkshih@realtek.com
2025-02-03wifi: rtw89: debugfs: use debugfs_short_fopsPing-Ke Shih
With this change, the object code size can reduce 768 bytes. text data bss dec hex filename 77257 4262 4 81523 13e73 debug.o (before) 76489 4262 4 80755 13b73 debug.o (after) Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250122060310.31976-7-pkshih@realtek.com
2025-02-03wifi: rtw89: debugfs: use wiphy_locked_debugfs_{read,write}() if neededPing-Ke Shih
If a debugfs entry takes driver mutex now, let it uses wiphy_locked_debugfs_{read,write}() to take both driver mutex and wiphy lock. Add rwlock option to support this. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250122060310.31976-6-pkshih@realtek.com
2025-02-03wifi: rtw89: debugfs: specify buffer size allocated by devm_kazlloc() for ↵Ping-Ke Shih
reading Some debufs entries need output buffer over default size 4K. Since reading of many debugfs entries is to access IO, it costs time to dynamically re-allocate larger buffer and access IO again and again. Add an option to specify the size it needs. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250122060310.31976-5-pkshih@realtek.com
2025-02-03wifi: rtw89: debugfs: implement file_ops::read/write to replace seq_filePing-Ke Shih
Since debugfs needs wiphy lock held, wiphy_locked_debugfs_{read,write}() will be adopted, so implmenet file_ops::read/write along with their arguments. For reading part, it needs lots of changes because seq_file is not suitable for wiphy_locked_debugfs_{read,write}(), so use spatch script below to convert basically, and manually implement the functions. @ rule1 @ identifier m; @@ - seq_printf(m, + p += scnprintf(p, end - p, ...) @ rule2 @ identifier m; @@ - seq_puts(m, + p += scnprintf(p, end - p, ...) For current version, only 4K buffer to output. To note ourselves, add ellipsis symbol "..." to trailing if buffer is full. Later, add an option to specify buffer size needed by a debugfs entry. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250122060310.31976-4-pkshih@realtek.com
2025-02-03wifi: rtw89: use wiphy_work() to replace ieee802111_work()Ping-Ke Shih
For certain works protected by driver mutex, use wiphy_work() directly to have wiphy lock held naturally. Then every this kind of works is protected by both wiphy lock and driver mutex. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250122060310.31976-3-pkshih@realtek.com
2025-02-03wifi: rtw89: add wiphy_lock() to work that isn't held wiphy_lock() yetPing-Ke Shih
To ensure where are protected by driver mutex can also be protected by wiphy_lock(), so afterward we can remove driver mutex safely. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250122060310.31976-2-pkshih@realtek.com
2025-02-03wifi: rtw89: cleanup unused rtwdev::roc_workZong-Zhe Yang
The needed one was moved to rtwvif::roc_work. And, rtwdev::roc_work is unused. So, remove it. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250120034004.21135-1-pkshih@realtek.com
2025-02-03wifi: rtw89: regd: refactor init/setup flow and prototypeZong-Zhe Yang
The regulatory and wiphy setup should be done in rtw89_regd_setup(). And, what rtw89_regd_init() should do is to initialize target regulatory domain (regd), if and only if one is programmed in efuse. Since HW is registered after rtw89_regd_setup() and before rtw89_regd_init(), do not fill fields of regulatory in rtw89_regd_init(). So, move the regulatory->reg_6ghz_power assignment into rtw89_regd_setup(). Besides, rtw89_regd_notifier is assigned in rtw89_regd_setup() instead of rtw89_regd_init(). To reduce confusion, stop passing rtw89_regd_notifier to rtw89_regd_init(). And, rename rtw89_regd_init() to rtw89_regd_init_hint(). Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250120032723.19042-4-pkshih@realtek.com
2025-02-03wifi: rtw89: regd: handle supported regulatory functions by countryZong-Zhe Yang
There are two regulatory functions including TAS (Time Average SAR) and DAG (Dynamic Antenna Gain) for now. They are used to improve RF behavior. But, availability depends on country. Extend regd map to record the status of whether a country allows to enable certain regulatory functions. Also, extend the handling of loading regd map via FW element for this. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250120032723.19042-3-pkshih@realtek.com
2025-02-03wifi: rtw89: regd: support loading regd table from fw elementZong-Zhe Yang
Regd table is a table that we use to describe how to map Realtek RF TX power settings on different countries. Originally, a common regd table for all chips is implemented in driver. However, in order to work on all chips, the common regd table might have some trade-off. So now, there are also an individual regd table for some chips. And, we support loading it from FW element. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250120032723.19042-2-pkshih@realtek.com
2025-02-03wifi: rtw89: phy: disable CFO track when two PHY are working simultaneouslyPing-Ke Shih
To have good performance, adjust hardware XTAL to track CFO (carrier frequency offset). However, there is only one hardware XTAL, so it is not possible to track on two PHY simultaneously. It also can't track on single one PHY when two PHY are working, because the adjustment of XTAL will affect all PHY. Thus, disable CFO track for this case. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250117072828.16728-9-pkshih@realtek.com
2025-02-03wifi: rtw89: phy: support EDCCA log per PHYPing-Ke Shih
The registers of EDCCA log for PHY 1 isn't a simple offset, so define them accordingly. Then the function use register set to access reports according to phy_idx. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250117072828.16728-8-pkshih@realtek.com
2025-02-03wifi: rtw89: phy: support EDCCA per PHYPing-Ke Shih
Dynamic mechanism EDCCA (Energy Detection Clear Channel Assessment) is to dynamically adjusted to make EDCCA suitable for situations. Use PHY context to support two PHY. For the EDCCA log part, registers to report EDCCA for PHY 1 is not a simple offset from PHY 0, so add them by separate patch. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250117072828.16728-7-pkshih@realtek.com
2025-02-03wifi: rtw89: phy: support ch_info per PHYPing-Ke Shih
The ch_info is to record current channel info such as minimum RSSI of connected stations, and to assist in dynamic mechanisms of DIG and EDCCA. Move the struct to PHY context, so the dynamic mechanisms can use the info of the same PHY. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250117072828.16728-6-pkshih@realtek.com
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-05 01:11:06 +0000