summaryrefslogtreecommitdiff
path: root/drivers/net/wireless
AgeCommit message (Collapse)Author
2025-06-17wifi: ath12k: don't activate more links than firmware supportsBaochen Qiang
In case of ML connection, currently all useful links are activated at ASSOC stage: ieee80211_set_active_links(vif, ieee80211_vif_usable_links(vif)) this results in firmware crash when the number of links activated on the same device is more than supported. Since firmware supports activating at most 2 links for a ML connection, to avoid firmware crash, host needs to select 2 links out of the useful links. As the assoc link has already been chosen, the question becomes how to determine partner links. A straightforward principle applied here is that the resulted combination should achieve the best throughput. For that purpose, ideally various factors like bandwidth, RSSI etc should be considered. But that would be too complicate. To make it easy, the choice is to only take hardware modes into consideration. The SBS (single band simultaneously) mode frequency range covers 5 GHz and 6 GHz bands. In this mode, the two individual MACs are both active, with one working on 5g-high band and the other on 5g-low band (from hardware perspective 5 GHz and 6 GHz bands are referred to as a 'large' single 5 GHz band). The DBS (dual band simultaneously) mode covers 2 GHz band and the 'large' 5 GHz band, with one MAC working on 2 GHz band and the other working on 5 GHz band or 6 GHz band. Since 5,6 GHz bands could provide higher bandwidth than 2 GHz band, the preference is given to SBS mode. Other hardware modes results in only one working MAC at any given time, so it is chosen only when both SBS are DBS are not possible. For each hardware mode, if there are more than one partner candidate, just choose the first one. For now only single device MLO case is handled as it is easy. Other cases could be addressed in the future. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250522-ath12k-sbs-dbs-v1-6-54a29e7a3a88@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-06-17wifi: ath12k: update link active in case two links fall on the same MACBaochen Qiang
In case of two links established on the same device in an ML connection, depending on device's hardware mode capability, it is possible that both links fall on the same MAC. Currently, no specific action is taken to address this but just keep both links active. However this would result in lower throughput compared to even one link, because switching between these two links on the resulted MAC significantly impacts throughput. Check if both links fall in the frequency range of a single MAC. If so, send WMI_MLO_LINK_SET_ACTIVE_CMDID command to firmware such that firmware can deactivate one of them. Note the decision of which link getting deactivated is made by firmware, host only sends the vdev lists. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250522-ath12k-sbs-dbs-v1-5-54a29e7a3a88@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-06-17wifi: ath12k: support WMI_MLO_LINK_SET_ACTIVE_CMDID commandBaochen Qiang
Add WMI_MLO_LINK_SET_ACTIVE_CMDID command. This command allows host to send required link information to firmware such that firmware can make decision on activating/deactivating links in various scenarios. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250522-ath12k-sbs-dbs-v1-4-54a29e7a3a88@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-06-17wifi: ath12k: update freq range for each hardware modeBaochen Qiang
Previous patches parse and save hardware MAC frequency range information in ath12k_svc_ext_info structure. Such range represents hardware capability hence needs to be updated based on host information, e.g. guard the range based on host's low/high boundary. So update frequency range. The updated range is saved in ath12k_hw_mode_info structure and would be used when doing vdev activation and link selection in following patches. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250522-ath12k-sbs-dbs-v1-3-54a29e7a3a88@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-06-17wifi: ath12k: parse and save sbs_lower_band_end_freq from ↵Baochen Qiang
WMI_SERVICE_READY_EXT2_EVENTID event Firmware sends the boundary between lower and higher bands in ath12k_wmi_dbs_or_sbs_cap_params structure embedded in WMI_SERVICE_READY_EXT2_EVENTID event. The boundary is needed when updating frequency range in the following patch. So parse and save it for later use. Note ath12k_wmi_dbs_or_sbs_cap_params is placed after some other structures, so placeholders for them are added as well. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250522-ath12k-sbs-dbs-v1-2-54a29e7a3a88@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-06-17wifi: ath12k: parse and save hardware mode info from ↵Baochen Qiang
WMI_SERVICE_READY_EXT_EVENTID event for later use WLAN hardware might support various hardware modes such as DBS (dual band simultaneously), SBS (single band simultaneously) and DBS_OR_SBS etc, see enum wmi_host_hw_mode_config_type. Firmware advertises actual supported modes in WMI_SERVICE_READY_EXT_EVENTID event. For each mode, firmware advertises frequency range each hardware MAC can operate on. In MLO case such information is necessary during vdev activation and link selection (which is done in following patches), so add a new structure ath12k_svc_ext_info to ath12k_wmi_base, then parse and save those information to it for later use. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250522-ath12k-sbs-dbs-v1-1-54a29e7a3a88@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-06-17wifi: ath12k: Avoid CPU busy-wait by handling VDEV_STAT and BCN_STATBjorn Andersson
When the ath12k driver is built without CONFIG_ATH12K_DEBUG, the recently refactored stats code can cause any user space application (such at NetworkManager) to consume 100% CPU for 3 seconds, every time stats are read. Commit 'b8a0d83fe4c7 ("wifi: ath12k: move firmware stats out of debugfs")' moved ath12k_debugfs_fw_stats_request() out of debugfs, by merging the additional logic into ath12k_mac_get_fw_stats(). Among the added responsibility of ath12k_mac_get_fw_stats() was the busy-wait for `fw_stats_done`. Signalling of `fw_stats_done` happens when one of the WMI_REQUEST_PDEV_STAT, WMI_REQUEST_VDEV_STAT, and WMI_REQUEST_BCN_STAT messages are received, but the handling of the latter two commands remained in the debugfs code. As `fw_stats_done` isn't signalled, the calling processes will spin until the timeout (3 seconds) is reached. Moving the handling of these two additional responses out of debugfs resolves the issue. Fixes: b8a0d83fe4c7 ("wifi: ath12k: move firmware stats out of debugfs") Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Tested-by: Abel Vesa <abel.vesa@linaro.org> Link: https://patch.msgid.link/20250609-ath12k-fw-stats-done-v1-1-2b3624656697@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-06-17sysfs: treewide: switch back to bin_attribute::read()/write()Thomas Weißschuh
The bin_attribute argument of bin_attribute::read() is now const. This makes the _new() callbacks unnecessary. Switch all users back. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20250530-sysfs-const-bin_attr-final-v3-3-724bfcf05b99@weissschuh.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-16wifi: rtw89: coex: Add PTA grant signal setting offload to firmware featureChing-Te Ku
In the before experience there are many issue occurred because of the grant control signal can not be set in time especially WiFi power save enter/leave. To control the signal more accuracy, offload the control to firmware. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250611035523.36432-11-pkshih@realtek.com
2025-06-16wifi: rtw89: coex: Update hardware PTA resource binding logicChing-Te Ku
WiFi 7 generation has 2 MAC, the PTA should bind the input/output to correct MAC to do the packet arbitration as expected. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250611035523.36432-10-pkshih@realtek.com
2025-06-16wifi: rtw89: coex: Update BTG control for WiFi 7Ching-Te Ku
BTG means a path work for Bluetooth & Wi-Fi 2.4GHz. To earn a better coexistence performance, need to do some RF setting for BTG path. WiFi 7 generation offload the feature to firmware, to get a more accuracy control. And decrease driver I/O. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250611035523.36432-9-pkshih@realtek.com
2025-06-16wifi: rtw89: coex: Update Pre-AGC logic for WiFi 7Ching-Te Ku
Pre-AGC is Wi-Fi auto Rx gain control. The mechanism need to switching very fast, especially while Wi-Fi is under 2GHz/5GHz multi-port scenario. To earn a more accuracy & sensitive gain control, in the WiFi 7 later firmware, Pre-AGC mechanism has offloaded to firmware. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250611035523.36432-8-pkshih@realtek.com
2025-06-16wifi: rtw89: coex: Add H2C command to collect driver outsource information ↵Ching-Te Ku
to firmware In order to reduce driver I/O & some detail instant hardware control, some of the necessary API offload to Wi-Fi firmware. Collect the reference parameters to let firmware do decisions. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250611035523.36432-7-pkshih@realtek.com
2025-06-16wifi: rtw89: coex: refine debug log with format version and readable stringChing-Te Ku
Fix unexpected line warp. Collect firmware report format version and driver support report format version code to check unexpected C2H report exception. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250611035523.36432-6-pkshih@realtek.com
2025-06-16wifi: rtw89: coex: Update Wi-Fi status logic for WiFi 7Ching-Te Ku
Because WiFi 7 generation has dual MAC, logic need to assign & save the information to correct index. Update the related logic. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250611035523.36432-5-pkshih@realtek.com
2025-06-16wifi: rtw89: coex: Implement Wi-Fi MLO related logicChing-Te Ku
To make the logic can work well with WiFi 7 & before generations, extend & add logic for WiFi 7. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250611035523.36432-4-pkshih@realtek.com
2025-06-16wifi: rtw89: coex: RTL8922A add Wi-Fi firmware support for v0.35.63.0Ching-Te Ku
There were some driver API offloaded to firmware, and to recognize the feature add a version tag for it. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250611035523.36432-3-pkshih@realtek.com
2025-06-16wifi: rtw89: introduce rtw89_query_mr_chanctx_info() for multi-role chanctx infoZong-Zhe Yang
Add Wi-Fi 7 MLO related multi-role (MR) chanctx descriptors and query function. They are designed for other components, e.g. coex, which are interested in the following info. * whether a MLD exists and how many active link * the number of AP mode and station mode respectively * how many chanctx and the number of 2/5/6 GHz respectively Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250611035523.36432-2-pkshih@realtek.com
2025-06-16wifi: rtw89: scan abort when assign/unassign_vifChih-Kang Chang
If scan happen during start_ap, the register which control TX might be turned off during scan. Additionally, if set_channel occurs during scan will backup this register and set to firmware after set_channel done. When scan complete, firmware will also set TX by this register, causing TX to be disabled and beacon can't be TX. Therefore, in assign/unassign_vif call scan abort before set_channel to avoid scan racing with set_channel. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250610130034.14692-13-pkshih@realtek.com
2025-06-16wifi: rtw89: mcc: enlarge TX retry count when GC authChih-Kang Chang
The auth retry only continue 40ms, but the GO might switch to STA role 50ms when MCC. Therefore, enlarge the TX retry count from 32 to 60 to let GC TX time overlapping with GO timeslot. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250610130034.14692-12-pkshih@realtek.com
2025-06-16wifi: rtw89: mcc: use anchor pattern when bcn offset less than min of tobChih-Kang Chang
When the beacon offset is less than minimum of auxiliary tob (aux->duration - aux->limit.max_toa), the upper bound of the reference toa might be negative and lower than the lower bound, which causes the auxiliary result to exceed the NoA limit. Therefore, in this case, the anchor pattern is used for calculation. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250610130034.14692-11-pkshih@realtek.com
2025-06-16wifi: rtw89: mcc: clear normal flow NoA when MCC startChih-Kang Chang
Clear NoA setting before MCC starts. Otherwise, nulldata will be blocked to TX because firmware use the normal flow NoA to calculate timing. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250610130034.14692-10-pkshih@realtek.com
2025-06-16wifi: rtw89: mcc: enlarge scan time of GC when GO in MCCChih-Kang Chang
In original scan, the scan time only 45ms. The GO in MCC mode only stay 50ms and switch to STA role 50ms, which might cause GC can't scan GO. Therefore, enlarge scan time to 105ms to ensure GC have time overlapping with GO. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250610130034.14692-9-pkshih@realtek.com
2025-06-16wifi: rtw89: mcc: adjust TX nulldata early time from 3ms to 7msChih-Kang Chang
Adjust TX nulldata early time to let nulldata have more contention time to TX. Otherwise, AP is hard to receive nulldata 1, which causes the throughput test failed due to packet drops. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250610130034.14692-8-pkshih@realtek.com
2025-06-16wifi: rtw89: TX nulldata 0 after scan completeChih-Kang Chang
HW scan leak to TX nulldata 0 to AP after scan completed, which allowed AP start to TX packet to us. Therefore, driver TX nulldata 0 after scan completed. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250610130034.14692-7-pkshih@realtek.com
2025-06-16wifi: rtw89: mcc: stop TX during MCC prepareChih-Kang Chang
Stop TX during the MCC configuration period to prevent packet leakage. The stop time is defined as 'start_tsf - tsf', which means the duration from when MCC configuration begins until MCC starts. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250610130034.14692-6-pkshih@realtek.com
2025-06-16wifi: rtw89: mcc: adjust beacon filter when MCC and detect connectionChih-Kang Chang
MCC needs to wait at most 300ms to start. Additionally, if scanning happens before MCC starts, it will miss some beacons, which might cause beacon loss. Therefore, we reset beacon filter when MCC start to let hardware reset beacon loss counter. Additionally, GO is forbid to enter courtesy mode might cause STA beacon loss. Therefore, disable beacon filter when GO+STA. However, In WiFi 7 chip, even when GC+STA enable courtesy mode, the beacon might loss because switching to courtesy timeslot will disable TX/RX. If the TOB(time offset behind) or TOA(time offset ahead) is too close to the edge of timeslot, the beacon might not be received. Therefore, disable beacon filter when GC+STA in WiFi 7 chip. Because disabling the beacon filter might prevent disconnection when the AP power-off without sending a deauth. Therefore, driver TX QOS nulldata periodically to detect the AP status, and the connection is terminated if no ACK is received for 6 seconds. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250610130034.14692-5-pkshih@realtek.com
2025-06-16wifi: rtw89: mcc: correct frequency when MCCChih-Kang Chang
The frequency get from PPDU status set as center channel during MCC, but we need to report to mac80211 as primary channel. Therefore, we use the chanctx information in software to instead it. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250610130034.14692-4-pkshih@realtek.com
2025-06-16wifi: rtw89: mcc: update format of RF notify MCC H2C commandChih-Kang Chang
The RF notify MCC H2C command format of 8852C different from other chip, therefore add v0 format to update it. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250610130034.14692-3-pkshih@realtek.com
2025-06-16wifi: rtw89: extend HW scan of WiFi 6 chips for extra OP chan when concurrencyZong-Zhe Yang
HW scan flow has considered the timing when to get back op for the scanning interface. But, when concurrency, there are two interfaces with connection. The OP channel of another one was not back originally. It then easily lead to connection loss when scanning during concurrency. So, HW scan flow is extended to deal with second OP channel. And, H2C command is also extended to fill second MAC ID. The changes mentioned above are done for WiFi 6 chips first. HW scan has different handling architectures including FW and driver on WiFi 7 chips. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250610130034.14692-2-pkshih@realtek.com
2025-06-16wifi: rtlwifi: fix possible skb memory leak in _rtl_pci_init_one_rxdesc()Thomas Fourier
When `dma_mapping_error()` is true, if a new `skb` has been allocated, then it must be de-allocated. Compile tested only Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250613074014.69856-2-fourier.thomas@gmail.com
2025-06-16wifi: rtlwifi: rtl8821ae: make the read-only array params static constColin Ian King
Don't populate the read-only array params on the stack at run time, instead make it static const. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250611135521.172521-1-colin.i.king@gmail.com
2025-06-16wifi: rtlwifi: avoid stack size warning for _read_eeprom_infoArnd Bergmann
txpower_info_{2g,5g} are too big to fit on the stack, but in most of the rtlwifi variants this stays below the warning limit for stack frames. In rtl8192ee and a few others, I see a case where clang decides to fully inline this into rtl92ee_read_eeprom_info, triggering this warning: drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c:2178:6: error: stack frame size (1312) exceeds limit (1280) in 'rtl92ee_read_eeprom_info' [-Werror,-Wframe-larger-than] Mark _rtl92ee_read_txpower_info_from_hwpg() as noinline_for_stack to and mark _rtl92ee_get_chnl_group() as __always_inline to make clang behave the same way as gcc. Inlining _rtl92ee_get_chnl_group helps let the compiler see that the index is always in range. The same change appears to be necessary in all rtlwifi variants. A more thorough approach would be to avoid the use of the two structures on the stack entirely and combine them with the struct rtl_efuse data that is dynamically allocated and holds the same information. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250610092240.2639751-1-arnd@kernel.org
2025-06-12Merge tag 'net-6.16-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Jakub Kicinski: "Including fixes from bluetooth and wireless. Current release - regressions: - af_unix: allow passing cred for embryo without SO_PASSCRED/SO_PASSPIDFD Current release - new code bugs: - eth: airoha: correct enable mask for RX queues 16-31 - veth: prevent NULL pointer dereference in veth_xdp_rcv when peer disappears under traffic - ipv6: move fib6_config_validate() to ip6_route_add(), prevent invalid routes Previous releases - regressions: - phy: phy_caps: don't skip better duplex match on non-exact match - dsa: b53: fix untagged traffic sent via cpu tagged with VID 0 - Revert "wifi: mwifiex: Fix HT40 bandwidth issue.", it caused transient packet loss, exact reason not fully understood, yet Previous releases - always broken: - net: clear the dst when BPF is changing skb protocol (IPv4 <> IPv6) - sched: sfq: fix a potential crash on gso_skb handling - Bluetooth: intel: improve rx buffer posting to avoid causing issues in the firmware - eth: intel: i40e: make reset handling robust against multiple requests - eth: mlx5: ensure FW pages are always allocated on the local NUMA node, even when device is configure to 'serve' another node - wifi: ath12k: fix GCC_GCC_PCIE_HOT_RST definition for WCN7850, prevent kernel crashes - wifi: ath11k: avoid burning CPU in ath11k_debugfs_fw_stats_request() for 3 sec if fw_stats_done is not set" * tag 'net-6.16-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (70 commits) selftests: drv-net: rss_ctx: Add test for ntuple rules targeting default RSS context net: ethtool: Don't check if RSS context exists in case of context 0 af_unix: Allow passing cred for embryo without SO_PASSCRED/SO_PASSPIDFD. ipv6: Move fib6_config_validate() to ip6_route_add(). net: drv: netdevsim: don't napi_complete() from netpoll net/mlx5: HWS, Add error checking to hws_bwc_rule_complex_hash_node_get() veth: prevent NULL pointer dereference in veth_xdp_rcv net_sched: remove qdisc_tree_flush_backlog() net_sched: ets: fix a race in ets_qdisc_change() net_sched: tbf: fix a race in tbf_change() net_sched: red: fix a race in __red_change() net_sched: prio: fix a race in prio_tune() net_sched: sch_sfq: reject invalid perturb period net: phy: phy_caps: Don't skip better duplex macth on non-exact match MAINTAINERS: Update Kuniyuki Iwashima's email address. selftests: net: add test case for NAT46 looping back dst net: clear the dst when changing skb protocol net/mlx5e: Fix number of lanes to UNKNOWN when using data_rate_oper net/mlx5e: Fix leak of Geneve TLV option object net/mlx5: HWS, make sure the uplink is the last destination ...
2025-06-11Merge tag 'ath-current-20250608' of ↵Johannes Berg
git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath Jeff Johnson says: ================== ath.git updates for v6.16-rc2 Fix a handful of both build and stability issues across multiple drivers. ================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-06-11wifi: iwlwifi: fix merge damage related to iwl_pci_resumeEmmanuel Grumbach
The changes I made in wifi: iwlwifi: don't warn if the NIC is gone in resume conflicted with a major rework done in this area. The merge de-facto removed my changes. Re-add them. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20250603091754.70182-1-emmanuel.grumbach@intel.com Fixes: 06c4b2036818 ("Merge tag 'iwlwifi-next-2025-05-15' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-06-11Revert "wifi: mwifiex: Fix HT40 bandwidth issue."Francesco Dolcini
This reverts commit 4fcfcbe45734 ("wifi: mwifiex: Fix HT40 bandwidth issue.") That commit introduces a regression, when HT40 mode is enabled, received packets are lost, this was experience with W8997 with both SDIO-UART and SDIO-SDIO variants. From an initial investigation the issue solves on its own after some time, but it's not clear what is the reason. Given that this was just a performance optimization, let's revert it till we have a better understanding of the issue and a proper fix. Cc: Jeff Chen <jeff.chen_1@nxp.com> Cc: stable@vger.kernel.org Fixes: 4fcfcbe45734 ("wifi: mwifiex: Fix HT40 bandwidth issue.") Closes: https://lore.kernel.org/all/20250603203337.GA109929@francesco-nb/ Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://patch.msgid.link/20250605130302.55555-1-francesco@dolcini.it [fix commit reference format] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-06-11wifi: iwlwifi: move iwl-context-info header filesMiri Korenblit
context info is PCIE specific, so it should be located in pcie directory. The c files are already there, move also the header files. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250609211928.606f48f72bcd.I4b89d373d961146e5369d1aed9f625150de7bf7d@changeid
2025-06-11wifi: iwlwifi: pcie: add missing TOP reset codeJohannes Berg
The TOP reset requires code to handle the interrupt, which had been in my patch at some point, but clearly got lost. As the test had been running on the wrong hardware and failing due to that, we missed this. Add the missing code. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250609211928.3f84eb03cc00.If138ceeb8bb178b3931d96b537f746346227e681@changeid
2025-06-11wifi: iwlwifi: mld: respect AUTO_EML_ENABLE in iwl_mld_int_mlo_scan()Itamar Shalev
Respect this flag and don't scan for another link if it is set. Signed-off-by: Itamar Shalev <itamar.shalev@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250609211928.9ecb5c5301d4.I88b37e93d9ba66d4381f4976541b4aca2a20e36e@changeid
2025-06-11wifi: iwlwifi: mld: respect AUTO_EML_ENABLE in iwl_mld_retry_emlsr()Daniel Gabay
Respect this flag before initiating MLO scan. Signed-off-by: Daniel Gabay <daniel.gabay@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250609211928.b5c7fbdcb15c.Iaa176c49142b46b0b896728005357faec6a55fa6@changeid
2025-06-11wifi: iwlwifi: mld: remove unneeded compilationsMiri Korenblit
Those are internal files so they should not be compiled. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250609211928.3bfe5222fe79.I1ebd746b0c513e278d231b5c48f5438ca9b9231f@changeid
2025-06-10wifi: rtw88: Enable AP and adhoc modes for SDIO againBitterblue Smith
AP mode can be enabled again for SDIO now that the problem was fixed in commit b2effcdc2379 ("wifi: rtw88: sdio: map mgmt frames to queue TX_DESC_QSEL_MGMT") and commit fc5f5a0ec463 ("wifi: rtw88: sdio: call rtw_sdio_indicate_tx_status unconditionally"). Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/5ac60c1c-9cc8-41b8-871c-a067e74f70ea@gmail.com
2025-06-10wifi: rtw88: Rename the RTW_WCPU_11{AC,N} enumsBitterblue Smith
The RTW_WCPU_11AC and RTW_WCPU_11N enums are used to identify two types of microcontrollers used in Realtek chips, but these names are misleading. The "11AC" type was also used in 11n devices (e.g. RTL8733BU, not supported by rtw88), and the "11N" type was also used in 11ac devices (RTL8821AU, RTL8812AU). Rename RTW_WCPU_11AC to RTW_WCPU_3081 and RTW_WCPU_11N to RTW_WCPU_8051. (8051 is well known. It's less clear what 3081 is, but the out of tree drivers use this name.) Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/bfb1099c-db52-4b25-b111-17ab712e9404@gmail.com
2025-06-10wifi: rtw89: 8922a: pass channel information when enter LPSKuan-Chung Chen
Newer firmware requires the driver to pass channel information when switching from normal mode to low power mode; otherwise it will result in poor RX beacon performance. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250606020437.17160-1-pkshih@realtek.com
2025-06-10wifi: rtw89: add chip_ops::chan_to_rf18_val to get code of RF register valueKuan-Chung Chen
The RF 0x18 register stores radio frequency domain parameters, including band, center channel and bandwidth. This information is used in RF domain. Add a chip_ops to retrieve the RF 0x18 value, which allows driver to query for a specific channel. No logic is changed. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250606020408.17035-1-pkshih@realtek.com
2025-06-10wifi: rtw89: mac: add dummy handler of MAC C2H event class 27Ping-Ke Shih
The newer firmware add new C2H event class 27, which is to report WiFi role status. Since rtw89 doesn't use the status yet, add a dummy handler to avoid warning: rtw89_8922ae 0000:03:00.0: MAC c2h class 27 func 0 not support Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250606020302.16873-5-pkshih@realtek.com
2025-06-10wifi: rtw89: rfk: support IQK firmware command v1Ping-Ke Shih
Add new IQK firmware command format v1 (with suffix), and rename original command format to v0 for older firmware. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250606020302.16873-4-pkshih@realtek.com
2025-06-10wifi: rtw89: fw: add RFE type to RF TSSI H2C commandZong-Zhe Yang
Append a new field for RFE (RF Front End) type to RF TSSI H2C command. FW has forward compatibility when handling this H2C command, so just need to consider backward cases in FW point of view. | old FW | new FW ------------------------------ old driver | O | X ------------------------------ new driver | O | O Currently only RTL8922A uses this RF TSSI H2C command. Increase its FW format max and will let new FW binary align with it. Then, old driver won't load new FW. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250606020302.16873-3-pkshih@realtek.com
2025-06-10wifi: rtw89: 8852c: increase beacon loss to 6 secondsKuan-Chung Chen
Intermittent beacon loss from a specific AP causes the connection to be lost. Increasing the beacon loss count can make the connection more stable. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250606020302.16873-2-pkshih@realtek.com
generated by cgit (git 2.34.1) at 2025-09-19 11:13:26 +0000