summaryrefslogtreecommitdiff
path: root/drivers/net/wireless
AgeCommit message (Collapse)Author
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
2025-02-03wifi: rtw89: phy: support DIG per PHYPing-Ke Shih
DIG standing for dynamic initial gain is to define RX coverage. Adjust this value dynamically to gain good RX performance. Use PHY context to extend DIG algorithm to support two PHY. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250117072828.16728-5-pkshih@realtek.com
2025-02-03wifi: rtw89: phy: support env_monitor per PHYPing-Ke Shih
The env_monitor is to collect information of current operating channel as helper to make decision with better hardware parameters to adopt current environment. Use PHY context as argument to control PHY accordingly, and use rtw89_phy_{write32,read32}_idx with phy_idx to access registers. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250117072828.16728-4-pkshih@realtek.com
2025-02-03wifi: rtw89: phy: add PHY context array to support functions per PHYPing-Ke Shih
To support MLO working on PHY 0 and PHY 1, extend existing PHY dynamic mechanism from PHY 0 to PHY 0/1. Implement a 2 elements array for two PHY instances, and pass pointer of each element as argument to existing functions. Then existing algorithm is kept, unchanged. Also provide iterate and get function to access PHY context. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250117072828.16728-3-pkshih@realtek.com
2025-02-03wifi: rtw89: phy: rename to RTW89_PHY_NUM as proper namingPing-Ke Shih
The meaning is number of PHY, not maximum ID of PHY. Change to proper naming. No change logic at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250117072828.16728-2-pkshih@realtek.com
2025-01-30Merge tag 'net-6.14-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Jakub Kicinski: "Including fixes from IPSec, netfilter and Bluetooth. Nothing really stands out, but as usual there's a slight concentration of fixes for issues added in the last two weeks before the merge window, and driver bugs from 6.13 which tend to get discovered upon wider distribution. Current release - regressions: - net: revert RTNL changes in unregister_netdevice_many_notify() - Bluetooth: fix possible infinite recursion of btusb_reset - eth: adjust locking in some old drivers which protect their state with spinlocks to avoid sleeping in atomic; core protects netdev state with a mutex now Previous releases - regressions: - eth: - mlx5e: make sure we pass node ID, not CPU ID to kvzalloc_node() - bgmac: reduce max frame size to support just 1500 bytes; the jumbo frame support would previously cause OOB writes, but now fails outright - mptcp: blackhole only if 1st SYN retrans w/o MPC is accepted, avoid false detection of MPTCP blackholing Previous releases - always broken: - mptcp: handle fastopen disconnect correctly - xfrm: - make sure skb->sk is a full sock before accessing its fields - fix taking a lock with preempt disabled for RT kernels - usb: ipheth: improve safety of packet metadata parsing; prevent potential OOB accesses - eth: renesas: fix missing rtnl lock in suspend/resume path" * tag 'net-6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (88 commits) MAINTAINERS: add Neal to TCP maintainers net: revert RTNL changes in unregister_netdevice_many_notify() net: hsr: fix fill_frame_info() regression vs VLAN packets doc: mptcp: sysctl: blackhole_timeout is per-netns mptcp: blackhole only if 1st SYN retrans w/o MPC is accepted netfilter: nf_tables: reject mismatching sum of field_len with set key length net: sh_eth: Fix missing rtnl lock in suspend/resume path net: ravb: Fix missing rtnl lock in suspend/resume path selftests/net: Add test for loading devbound XDP program in generic mode net: xdp: Disallow attaching device-bound programs in generic mode tcp: correct handling of extreme memory squeeze bgmac: reduce max frame size to support just MTU 1500 vsock/test: Add test for connect() retries vsock/test: Add test for UAF due to socket unbinding vsock/test: Introduce vsock_connect_fd() vsock/test: Introduce vsock_bind() vsock: Allow retrying on connect() failure vsock: Keep the binding until socket destruction Bluetooth: L2CAP: accept zero as a special value for MTU auto-selection Bluetooth: btnxpuart: Fix glitches seen in dual A2DP streaming ...
2025-01-28Merge tag 'driver-core-6.14-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core and debugfs updates from Greg KH: "Here is the big set of driver core and debugfs updates for 6.14-rc1. Included in here is a bunch of driver core, PCI, OF, and platform rust bindings (all acked by the different subsystem maintainers), hence the merge conflict with the rust tree, and some driver core api updates to mark things as const, which will also require some fixups due to new stuff coming in through other trees in this merge window. There are also a bunch of debugfs updates from Al, and there is at least one user that does have a regression with these, but Al is working on tracking down the fix for it. In my use (and everyone else's linux-next use), it does not seem like a big issue at the moment. Here's a short list of the things in here: - driver core rust bindings for PCI, platform, OF, and some i/o functions. We are almost at the "write a real driver in rust" stage now, depending on what you want to do. - misc device rust bindings and a sample driver to show how to use them - debugfs cleanups in the fs as well as the users of the fs api for places where drivers got it wrong or were unnecessarily doing things in complex ways. - driver core const work, making more of the api take const * for different parameters to make the rust bindings easier overall. - other small fixes and updates All of these have been in linux-next with all of the aforementioned merge conflicts, and the one debugfs issue, which looks to be resolved "soon"" * tag 'driver-core-6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (95 commits) rust: device: Use as_char_ptr() to avoid explicit cast rust: device: Replace CString with CStr in property_present() devcoredump: Constify 'struct bin_attribute' devcoredump: Define 'struct bin_attribute' through macro rust: device: Add property_present() saner replacement for debugfs_rename() orangefs-debugfs: don't mess with ->d_name octeontx2: don't mess with ->d_parent or ->d_parent->d_name arm_scmi: don't mess with ->d_parent->d_name slub: don't mess with ->d_name sof-client-ipc-flood-test: don't mess with ->d_name qat: don't mess with ->d_name xhci: don't mess with ->d_iname mtu3: don't mess wiht ->d_iname greybus/camera - stop messing with ->d_iname mediatek: stop messing with ->d_iname netdevsim: don't embed file_operations into your structs b43legacy: make use of debugfs_get_aux() b43: stop embedding struct file_operations into their objects carl9170: stop embedding file_operations into their objects ...
2025-01-28Merge tag 'ath-current-20250124' of ↵Kalle Valo
git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath ath.git patch for v6.14-rc Fix an issue in the ath12k driver where 6 GHz operation no longer works with new firmware.
2025-01-28wifi: brcmfmac: use random seed flag for BCM4355 and BCM4364 firmwareAditya Garg
Before 6.13, random seed to the firmware was given based on the logic whether the device had valid OTP or not, and such devices were found mainly on the T2 and Apple Silicon Macs. In 6.13, the logic was changed, and the device table was used for this purpose, so as to cover the special case of BCM43752 chip. During the transition, the device table for BCM4364 and BCM4355 Wi-Fi chips which had valid OTP was not modified, thus breaking Wi-Fi on these devices. This patch adds does the necessary changes, similar to the ones done for other chips. Fixes: ea11a89c3ac6 ("wifi: brcmfmac: add flag for random seed during firmware download") Cc: stable@vger.kernel.org Signed-off-by: Aditya Garg <gargaditya08@live.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/47E43F07-E11D-478C-86D4-23627154AC7C@live.com
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-04 10:20:02 +0000