Sync ath12k to wireless-2026-07-26 - #874
Open
Hangtian Zhu (zhuhangtian) wants to merge 103 commits into
Open
Conversation
Correct a typo in the monitor mode comment where "it make" was mistakenly used instead of "it doesn't make". The comment explains that the brief period where monitor mode appears enabled before being removed is harmless in practice. Also, use more common phrase "in practice" instead of "in practise". Signed-off-by: Chien Wong <m@xv97.com> Link: https://patch.msgid.link/20251030143041.12027-1-m@xv97.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Hangtian Zhu (zhuhangtian)
requested review from
a team,
Komal Bajaj (Komal-Bajaj),
Nicolas Dechesne (ndechesne) and
Tingwei Zhang (quic-tingweiz)
July 29, 2026 06:01
|
Merge Check Failed: No CR Numbers Found Error: No Change Request numbers were found. Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests. |
PR #874 — validate-patchPR: #874
Final Summary
[/VALIDATE_PATCH_REPORT]
|
PR #874 — checker-log-analyzerPR: #874
Detailed report: Full report
|
|
Merge Check Failed: No CR Numbers Found Error: No Change Request numbers were found. Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests. |
1 similar comment
|
Merge Check Failed: No CR Numbers Found Error: No Change Request numbers were found. Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests. |
Hangtian Zhu (zhuhangtian)
changed the title
Hangtian Zhu (zhuhangtian)
force-pushed
the
qcom-6.18.y
branch
from
July 29, 2026 08:34
4b44b94 to
0ee40f9
Compare
|
Merge Check Failed: No CR Numbers Found Error: No Change Request numbers were found. Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests. |
miaoqing-quic
approved these changes
Jul 29, 2026
|
Merge Check Failed: No Change Task Found No associated change tasks found for CR 4626161 on any of the following entities: Entities:
CR: 4626161 Please ensure the CR has a change task associated with at least one of the entities for this branch. |
PR #874 — validate-patchPR: #874
Final Summary
|
PR #874 — checker-log-analyzerPR: #874
Detailed report: Full report
|
Test jobs on 0ee40f9 |
Test Matrix
|
Shiraz Hashim (shashim-quic)
requested changes
Jul 29, 2026
Shiraz Hashim (shashim-quic)
left a comment
Shiraz Hashim (shashim-quic)
left a comment
There was a problem hiding this comment.
- e70436c UPSTREAM: Merge tag 'char-misc-7.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Please check why this was picked.
Author
the merge commit from ath-next is not clean, it brings conflict fixes on ath12k, the commit in this PR only includes ath12k changes from that merge commit. |
Currently, the FILS discovery template is always fetched from the default link of a virtual interface in both Multi-Link Operation (MLO) and non-MLO cases. However, in the MLO case there is a need to fetch the FILS discovery template from a specific link instead of the default link. Hence, add support for fetching the FILS discovery template based on the link ID from the corresponding link data. Signed-off-by: Sriram R <quic_srirrama@quicinc.com> Co-developed-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com> Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com> Link: https://patch.msgid.link/20260220-fils-prob-by-link-v1-1-a2746a853f75@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
…y link ID Currently, the unsolicited probe response template is always fetched from the default link of a virtual interface in both Multi-Link Operation (MLO) and non-MLO cases. However, in the MLO case there is a need to fetch the unsolicited probe response template from a specific link instead of the default link. Hence, add support for fetching the unsolicited probe response template based on the link ID from the corresponding link data. Signed-off-by: Sriram R <quic_srirrama@quicinc.com> Co-developed-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com> Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com> Link: https://patch.msgid.link/20260220-fils-prob-by-link-v1-2-a2746a853f75@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Smatch complains: drivers/net/wireless/ath/ath12k/qmi.c:3342 ath12k_qmi_aux_uc_load() warn: inconsistent indenting Fix it. Compile tested only. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202602061221.5SCuwKhy-lkp@intel.com/ Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260209-ath12k-fix-indention-v1-1-6b87ae99745e@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Add initial thermal support by wiring up a per-radio (pdev) hwmon temperature sensor backed by the existing WMI pdev temperature command and event. When userspace reads the sysfs file temp1_input, the driver sends WMI_PDEV_GET_TEMPERATURE_CMDID (tag WMI_TAG_PDEV_GET_TEMPERATURE_CMD) and waits for the corresponding WMI_PDEV_TEMPERATURE_EVENTID (tag WMI_TAG_PDEV_TEMPERATURE_EVENT) to get the temperature and pdev_id. Export the reported value in millidegrees Celsius as required by hwmon. The temperature reported is per-radio (pdev). In a multi-radio wiphy under a single phy, a separate hwmon device is created for each radio. Sample command and output: $ cat /sys/devices/pci0000:00/.../ieee80211/phyX/hwmonY/temp1_input $ 50000 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Co-developed-by: Aishwarya R <aishwarya.r@oss.qualcomm.com> Signed-off-by: Aishwarya R <aishwarya.r@oss.qualcomm.com> Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260223132622.43464-1-maharaja.kennadyrajan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
During recovery of an MLO setup from a core reset, ATH12K_GROUP_FLAG_REGISTERED is set because ath12k_mac_unregister is not called during core reset. So, when an MLO setup is recovering from a core reset, ath12k_core_mlo_setup() is skipped. Hence, the firmware will not have information about partner links. This makes MLO association fail after recovery. To resolve this, call ath12k_core_mlo_setup() during recovery, to set up MLO. Also, if MLO setup fails during recovery, call ath12k_mac_unregister() and ath12k_mac_destroy() to unregister mac and then tear down the mac structures. Also, initiate MLO teardown in the hardware group stop sequence to align with the hardware group start sequence. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01181-QCAHKSWPL_SILICONZ-1 Signed-off-by: Ramya Gnanasekar <ramya.gnanasekar@oss.qualcomm.com> Signed-off-by: Roopni Devanathan <roopni.devanathan@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260227041127.3265879-1-roopni.devanathan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Currently, rxdma1_enable and supports_monitor are set to false in IPQ5332 hardware parameters, which skips monitor ring configuration and removes NL80211_IFTYPE_MONITOR from the supported interface modes. Set rxdma1_enable and supports_monitor to true so that monitor rings are configured and monitor mode is enabled on IPQ5332. Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.7-00587-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260227033332.687805-1-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Currently, the Rx path uses new infrastructure to extract the required HAL parameters. Consequently, the HAL Rx descriptor argument is no longer needed in the following helper functions. Remove the unused argument from the following helper functions. ath12k_dp_rx_h_undecap() ath12k_dp_rx_check_nwifi_hdr_len_valid() ath12k_wifi7_dp_rx_h_mpdu() Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Signed-off-by: Karthikeyan Periyasamy <karthikeyan.periyasamy@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260227042128.3494167-1-karthikeyan.periyasamy@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
…stats
To get firmware statistics, currently ar->pdev->pdev_id is passed as an
argument to ath12k_mac_get_fw_stats() in ath12k_mac_op_sta_statistics().
For single pdev device like WCN7850, its value is 0 which represents the
SoC pdev id. As a result, WCN7850 firmware sends the same reply to host
twice, which further results in memory leak:
unreferenced object 0xffff88812e286000 (size 192):
comm "softirq", pid 0, jiffies 4294981997
hex dump (first 32 bytes):
10 a5 40 11 81 88 ff ff 10 a5 40 11 81 88 ff ff ..@.......@.....
00 00 00 00 00 00 00 00 80 ff ff ff 33 05 00 00 ............3...
backtrace (crc cecc8c82):
__kmalloc_cache_noprof
ath12k_wmi_tlv_fw_stats_parse
ath12k_wmi_tlv_iter
ath12k_wmi_op_rx
ath12k_htc_rx_completion_handler
ath12k_ce_per_engine_service
ath12k_pci_ce_workqueue
process_one_work
bh_worker
tasklet_action
handle_softirqs
Detailed explanation is:
1. ath12k_mac_get_fw_stats() called in ath12k_mac_op_sta_statistics() to
get vdev statistics, making the caller thread wait.
2. firmware sends the first reply, ath12k_wmi_tlv_fw_stats_data_parse()
allocates buffers to cache necessary information. Following that, in
ath12k_wmi_fw_stats_process() if events of all started vdev haved been
received, is_end flag is set hence the waiting thread gets waken up by
the ar->fw_stats_done/->fw_stats_complete signals.
3. ath12k_mac_get_fw_stats() wakes up and returns successfully.
ath12k_mac_op_sta_statistics() saves required parameters and calls
ath12k_fw_stats_reset() to free buffers allocated earlier.
4. firmware sends the second reply. As usual, buffers are allocated and
attached to the ar->fw_stats.vdevs list. Note this time there is no
thread waiting, therefore no chance to free those buffers.
5. ath12k module gets unloaded. If there has been no more firmware
statistics request made since step 4, or if the request fails (see
the example in the following patch), there is no chance to call
ath12k_fw_stats_reset(). Consequently those buffers leak.
Actually for single pdev device, using SoC pdev id in
ath12k_mac_op_sta_statistics() is wrong, because the purpose is to get
statistics of a specific station, which is mapped to a specific pdev. That
said, the id of actual individual pdev should be fetched and used instead.
The helper ath12k_mac_get_target_pdev_id() serves for this purpose, hence
use it to fix this issue. Note it also works for other devices as well due
to the single_pdev_only check inside.
The same applies to ath12k_mac_op_get_txpower() and
ath12k_mac_op_link_sta_statistics() as well.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Fixes: 79e7b04 ("wifi: ath12k: report station mode signal strength")
Fixes: e92c658 ("wifi: ath12k: add get_txpower mac ops")
Fixes: ebebe66 ("wifi: ath12k: fill link station statistics for MLO")
Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Link: https://patch.msgid.link/20260129-ath12k-fw-stats-fixes-v1-1-55d66064f4d5@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
… from AP In ath12k_wmi_tlv_fw_stats_data_parse() and ath12k_wmi_tlv_rssi_chain_parse(), the driver uses ieee80211_find_sta_by_ifaddr() to look up the station associated with the incoming firmware statistics. This works under normal conditions but fails during AP disconnection, resulting in log messages like: wlan0: deauthenticating from xxxxxx by local choice (Reason: 3=DEAUTH_LEAVING) wlan0: moving STA xxxxxx to state 3 wlan0: moving STA xxxxxx to state 2 wlan0: moving STA xxxxxx to state 1 ath12k_pci 0000:02:00.0: not found station bssid xxxxxx for vdev stat ath12k_pci 0000:02:00.0: not found station of bssid xxxxxx for rssi chain ath12k_pci 0000:02:00.0: failed to pull fw stats: -71 ath12k_pci 0000:02:00.0: time out while waiting for get fw stats wlan0: Removed STA xxxxxx wlan0: Destroyed STA xxxxxx The failure happens because the station has already been removed from ieee80211_local::sta_hash by the time firmware statistics are requested through drv_sta_statistics(). Switch the lookup to ath12k_link_sta_find_by_addr(), which searches the driver's link station hash table that still has the station recorded at that time. This also implicitly fixes another issue: the current code always uses deflink regardless of which link the statistics belong to, which is incorrect in MLO scenarios. The new helper returns the correct link station. Additionally, raise the log level on lookup failures. With the updated helper, such failures should no longer occur under normal conditions. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Fixes: 79e7b04 ("wifi: ath12k: report station mode signal strength") Fixes: 6af5bc3 ("wifi: ath12k: report station mode per-chain signal strength") Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260129-ath12k-fw-stats-fixes-v1-2-55d66064f4d5@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
In the ath12k driver, the BDF_MEM_REGION_TYPE address is derived by adding a fixed bdf_addr_offset to the WCSS Q6 region base address. The current offset (0xC00000) works only when the Q6 region contains the IPQ5332 ucode alone. On some IPQ5332 platform variants, additional devices share the same WCSS Q6 processor and place their firmware ucode in the same Q6 region. This results in multiple ucode sections within the region, and the existing offset can cause the BDF memory region to overlap with firmware read-only sections, which can lead to firmware crash and driver boot failure. Increase the bdf_addr_offset to 0x1A00000, determined by analyzing firmware memory maps across all known IPQ5332 platform variants. This value represents the upper bound of the largest combined firmware and ensures all IPQ5332 variants can allocate the BDF region safely without overlapping firmware regions. Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260710053534.879233-1-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Currently when running 128 clients UDP DL test in 5 GHz HE80 (NSS 2x2), firmware uses the default max MSDU count (16K MSDUs). This lower limit causes the firmware to compute a smaller TQM drop threshold, aggregate packets at a reduced rate, and results in increased packet drops with TQM drop threshold as the completion reason. To fix this issue, set WMI_PDEV_PARAM_SET_CONG_CTRL_MAX_MSDUS to the TX descriptor count using ath12k_wmi_pdev_set_param(). This increases the TQM drop threshold, reduces drop events, and improves throughput from ~722 Mbps to ~1060 Mbps with 1200 Mbps ingress. Add a new HW capability flag (supports_cong_ctrl_max_msdus) and enable the WMI parameter only on supported platforms. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01181-QCAHKSWPL_SILICONZ-1 Signed-off-by: Thiraviyam Mariyappan <thiraviyam.mariyappan@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260622062614.760166-1-thiraviyam.mariyappan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
The driver currently retrieves reserved memory regions using index-based lookup, which depends on the ordering of reserved-memory nodes in the device tree. Since different platforms define these regions in varying orders and combinations, this approach is not compatible and can result in incorrect memory region access. Switch to looking up memory regions by name instead of index so it does not depend on node order. Use names already defined in qcom,ipq5332-wifi.yaml, so there are no backward compatibility issues. Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1 Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com> Link: https://patch.msgid.link/20260630062048.1615178-2-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
ath12k_qmi_assign_target_mem_chunk() uses a large switch-case to handle both memory region identification and allocation for each memory request type, leading to redundant allocation logic. Refactor this by introducing ath12k_qmi_get_mem_reg_name() to map memory request types to their corresponding reserved memory region names. Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1 Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com> Link: https://patch.msgid.link/20260630062048.1615178-3-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
… region Currently, the Q6 region contains a read-only firmware region along with the BDF_MEM_REGION_TYPE and HOST_DDR_REGION_TYPE memory areas. The firmware expects these writable memory regions to be assigned after the Q6 read-only section. However, the ath12k driver currently allocates the HOST_DDR_REGION_TYPE starting from the base of the Q6 region, which includes the read-only firmware area. As a result, the allocated memory regions overlap with the read-only section, causing the firmware to assert during QMI memory allocation. The Q6 memory region layout is as follows: Q6 Reserved Memory +--------------------------------------+ | | | Read-only Firmware Region | | (Q6 RO Region) | | | +--------------------------------------+ <--- bdf_addr_offset | Writable Memory Region | | (BDF + HOST_DDR allocations) | | | +--------------------------------------+ Fix this by allocating the required memory regions only after the end of the read-only region in the Q6 address space. The bdf_addr_offset parameter indicates where the writable region starts. Both HOST_DDR and BDF regions are allocated sequentially after this offset, with each region placed immediately after the previous one to avoid gaps and overlaps. Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1 Fixes: 6757079 ("wifi: ath12k: add support for fixed QMI firmware memory") Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com> Link: https://patch.msgid.link/20260630062048.1615178-4-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
…uest Currently, in ath12k_wmi_send_scan_start_cmd(), the logic to populate the hint_bssid copies the BSSID in the wrong direction, from the firmware message to the argument buffer. Swap the parameters so that the BSSID is correctly populated in the firmware message from the argument buffer. Compile tested only. Reported-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Closes: https://lore.kernel.org/linux-wireless/afbff608-a005-43c4-af76-968a58bf0cc3@oss.qualcomm.com/ Fixes: d889913 ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Assisted-by: Claude:claude-sonnet-4-6 Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260713-ath12k_wmi_send_scan_start_cmd-bad-hint_bssid-v1-1-4ffc4a472992@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
ath12k_wmi_scan_req_arg stores scan parameters in CPU-native byte order, while ath12k_wmi_send_scan_start_cmd() writes them into a WMI command buffer whose contents must be in little-endian format. The existing code copies the channel list and writes s_ssid and hint_bssid related values to the command buffer without endian conversion. As a result, scan requests contain invalid parameters on big-endian systems and fail. Convert the channel list as well as the s_ssid and hint_bssid related values to little-endian before writing them to the WMI command buffer. This preserves the existing behaviour on little-endian systems while fixing scan requests on big-endian architectures. Signed-off-by: Alexander Wilhelm <alexander.wilhelm@westermo.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260703-fix-channel-list-copy-v2-1-372c39306d79@westermo.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
'struct ath12k_dp_arch_ops' is not modified in this driver. Constifying this structure moves some data to a read-only section, so increases overall security, especially when the structure holds some function pointers. On a x86_64, with allmodconfig, as an example: Before: ====== text data bss dec hex filename 6318 3384 0 9702 25e6 drivers/net/wireless/ath/ath12k/wifi7/dp.o After: ===== text data bss dec hex filename 6478 3224 0 9702 25e6 drivers/net/wireless/ath/ath12k/wifi7/dp.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/969d732e2c6f169e1aa5e89c7e01743a1adb55df.1784010931.git.christophe.jaillet@wanadoo.fr Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
…erface Currently, the station always follows the listen interval regardless of the DTIM value. The DTIM function does not work as expected. The default value of the listen interval is 5 so that the STA wakes up every 500ms when power save is on. This can cause a data transmission delay. Set the DTIM policy to DTIM stick mode so that the station follows the AP DTIM interval rather than the listen interval, which is set in the peer assoc command. DTIM stick mode is preferable per the firmware team's request. Apply this only for STA vdevs and only when STA power save is supported, to avoid affecting unsupported targets and P2P client vdevs. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3 Signed-off-by: Daizhuang Bai <daizhuang.bai@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260717014302.284034-1-daizhuang.bai@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
When running 'iw dev wlan0 survey dump' the values for the channel busy time have the same sequence across bands. This is caused by indexing into the ath12k survey array using a band-local index rather than the global index passed by mac80211. This results in surveys for 5 GHz and 6 GHz channels returning values from 2.4 GHz slots, making the survey unusable on those bands. Further, there are redundant survey slots for multi-radio/single-phy instances. Fix by moving the survey data into ath12k_hw so multiple radios under a single wiphy share one table, and index into it using the global mac80211 index. A new spinlock in ath12k_hw serialises access to the survey array, which is now shared across all radios under a single hw. Band busy-times Before this fix: 2.4 GHz: 9, 2, 2, 2, 4, 2, 10, 16, 4, 12, 5 5 GHz: 9, 2, 2, 2, 4, 2, 10, 16, 4, 12, 5 6 GHz: 9, 2, 2, 2, 4, 2, 10, 16, 4, 12, 5 After this fix, times are independent: 2.4 GHz: 23, 5, 5, 12, 2, 12, 26, 5, 3, 1, 27 5 GHz: 30, 40, 29, 27, 118, 118, 112, 120, 11, 11, 11 6 GHz: 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1 Tested-on: wcn7850 hw2.0 PCI WLAN.IOE_HMT.1.1-00018-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Fixes: 4f242b1 ("wifi: ath12k: support get_survey mac op for single wiphy") Signed-off-by: Matthew Leach <matthew.leach@collabora.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260703-ath12-survey-band-fix-v3-1-2fb050c2505a@collabora.com [fixed ath12k-check issues] Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Currently, in ath12k_wmi_op_rx(), the firmware buffer is read without first verifying that the buffer has enough data to hold a header. This could result in a buffer overread. Update the logic to verify the buffer contains at least enough data to hold a wmi_cmd_hdr before reading from the buffer. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3 Fixes: d889913 ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Assisted-by: Claude:claude-sonnet-4-6 Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260716-ath12k_wmi_op_rx-overread-v1-1-327a4b1c2372@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
The QMI framework proposes a set of services which are defined by an integer identifier. The different QMI client lookup for the services via this identifier. Moreover, the function qmi_add_lookup() and qmi_add_server() must match the service ID but the code in different places set the same value but with a different macro name. These macros are spreaded across the different subsystems implementing the protocols associated with a service. It would make more sense to define them in the QMI header for the sake of consistency and clarity. This change use an unified naming for the services and enumerate the ones implemented in the Linux kernel. More services can come later and put the service ID in this same header. Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260309230346.3584252-2-daniel.lezcano@oss.qualcomm.com [bjorn: Lower case hex constants] Signed-off-by: Bjorn Andersson <andersson@kernel.org>
…cted event from mac80211/driver When any incumbent signal is detected by an AP/mesh interface operating in 6 GHz band, FCC mandates the AP/mesh to vacate the channels affected by it [1]. Add a new API cfg80211_incumbent_signal_notify() that can be used by mac80211 or drivers to notify the higher layers about the signal interference event with the interference bitmap in which each bit denotes the affected 20 MHz in the operating channel. Add support for the new nl80211 event and nl80211 attribute as well to notify userspace on the details about the interference event. Userspace is expected to process it and take further action - vacate the channel, or reduce the bandwidth. [1] - https://apps.fcc.gov/kdb/GetAttachment.html?id=nXQiRC%2B4mfiA54Zha%2BrW4Q%3D%3D&desc=987594%20D02%20U-NII%206%20GHz%20EMC%20Measurement%20v03&tracking_number=277034 Signed-off-by: Hari Chandrakanthan <quic_haric@quicinc.com> Signed-off-by: Amith A <amith.a@oss.qualcomm.com> Link: https://patch.msgid.link/20260216032027.2310956-2-amith.a@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
…023_xmit() Currently ieee80211_8023_xmit() accesses the sta pointer without any sanity check, assuming that only unicast packets for an authorized station are processed. But the sta pointer could become NULL when a framework to support 802.3 offload for the multicast packets is added in the follow-up patches. Add the valid sta pointer sanity check to avoid the invalid pointer access. This aligns with some of the subordinate functions called by ieee80211_8023_xmit() that already NULL-check 'sta' such as ieee80211_select_queue() and ieee80211_aggr_check(). Signed-off-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com> Link: https://patch.msgid.link/20260604162403.1563729-2-tamizh.raja@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
…path mac80211 already supports multicast-to-unicast conversion for native 802.11 TX paths, but this handling is missing for the 802.3 transmit path. Due to that the packet never converted to unicast and directly pass it to 802.11 Tx path by checking the destination address as multicast. Extend ieee80211_subif_start_xmit_8023() to honor the multicast_to_unicast setting by cloning and converting multicast Ethernet frames into per-station unicast transmissions, following the same behavior of the native 802.11 TX path and allow it to take 802.3 path. Signed-off-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com> Link: https://patch.msgid.link/20260604162403.1563729-3-tamizh.raja@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
…upport mac80211 converts 802.3 multicast packets to 802.11 format before driver TX, even when Ethernet encapsulation offload is enabled. This prevents drivers that support multicast Ethernet encapsulation offload from receiving frames in native 802.3 format. Introduce the IEEE80211_OFFLOAD_ENCAP_MCAST flag to bypass the 802.11 encapsulation step and pass the multicast packet to the driver in 802.3 format. Drivers that support multicast Ethernet encapsulation offload can advertise this flag. Disable multicast encapsulation offload in MLO case for drivers not advertising MLO_MCAST_MULTI_LINK_TX support for AP mode and for 3-address AP_VLAN multicast packets. Signed-off-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com> Link: https://patch.msgid.link/20260604162403.1563729-4-tamizh.raja@oss.qualcomm.com [fix unlikely(), indentation] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In multi-radio wiphy architecture, where a single wiphy can have multiple radios tied to it, radio specific configuration parameters and global wiphy parameters are maintained for the entire physical device and common to all radios. But, each radio in a wiphy can have different values for each radio configuration parameter, like RTS threshold. With the current debugfs directory structure, the values of global wiphy configuration parameters can be viewed, but, values of individual radio configuration parameters cannot be viewed, as radio specific configuration parameters are not maintained, separately. To address this, in addition to maintaining global wiphy configuration parameters common to all radios, create separate debugfs directories for each radio in a wiphy to maintain parameters corresponding to that radio in this directory. In implementation, maintain a dentry structure in wiphy_radio_cfg, a structure containing radio configurations of a wiphy. This struct is maintained to denote per-radio configurations of a wiphy. Create separate directories representing each radio within phy#X directory in debugfs during wiphy registration. Sample directory structure with this change: ls /sys/kernel/debug/ieee80211/phy0/radio radio0/ radio1/ radio2/ Signed-off-by: Roopni Devanathan <quic_rdevanat@quicinc.com> Link: https://patch.msgid.link/20251024044649.483557-2-quic_rdevanat@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
…rectories In multi-radio wiphy architecture, where a single wiphy can have multiple radios tied to it, radio specific configuration parameters and global wiphy parameters are maintained for the entire physical device and common to all radios. But, each radio in a wiphy can have different values for each radio configuration parameter like RTS threshold. With the current debugfs directory structure, the values of global wiphy configuration parameters can be viewed, but, values of individual radio configuration parameters cannot be viewed. To address this requirement, maintain separate entries of each radio configuration parameter i.e., RTS threshold in corresponding radio- specific debugfs directory. This way, radio-specific configuration parameters can be maintained along with global wiphy configuration parameters. Whenever the values are changed for one radio, the values for rest of the radios in the wiphy and the global wiphy parameter value will remain intact. Sample output: /# iw phy#0 set rts 100 radio 1 /# iw phy#0 set rts 468 radio 0 /# cat /sys/kernel/debug/ieee80211/phy0/rts_threshold -1 /# cat /sys/kernel/debug/ieee80211/phy0/radio0/radio_rts_threshold 468 /# cat /sys/kernel/debug/ieee80211/phy0/radio1/radio_rts_threshold 100 /# iw phy#0 set rts 500 /# cat /sys/kernel/debug/ieee80211/phy0/rts_threshold 500 /# cat /sys/kernel/debug/ieee80211/phy0/radio0/radio_rts_threshold 500 /# cat /sys/kernel/debug/ieee80211/phy0/radio1/radio_rts_threshold 500 Signed-off-by: Roopni Devanathan <quic_rdevanat@quicinc.com> Link: https://patch.msgid.link/20251024044649.483557-3-quic_rdevanat@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
…to cfg80211 Export michael_mic() so that the ath11k and ath12k drivers can call it. In addition, move it from mac80211 to cfg80211 so that the ipw2x00 drivers, which depend on cfg80211 but not mac80211, can also call it. Currently these drivers have their own local implementations of michael_mic() based on crypto_shash, which is redundant and inefficient. By consolidating all the Michael MIC code into cfg80211, we'll be able to remove the duplicate Michael MIC code in the crypto/ directory. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Link: https://patch.msgid.link/20260408030651.80336-3-ebiggers@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
…SOC_GLOBAL_RESET ath12k_pci_soc_global_reset() tries to reset the device by writing to the PCIE_SOC_GLOBAL_RESET register. But it doesn't do a read-back to ensure that the write gets flushed to the device before the delay. This may lead to the delay on the host to be insufficient, if the posted write doesn't reach the device before the delay. So add a read-back after writing to the PCIE_SOC_GLOBAL_RESET register and before the delay. Compile tested only. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Fixes: d889913 ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Reported-by: Alex Williamson <alex@shazbot.org> Closes: https://lore.kernel.org/linux-pci/20260622160822.09350246@shazbot.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com> Tested-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com> Link: https://patch.msgid.link/20260623141649.41087-2-manivannan.sadhasivam@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
…estroy When unbinding the ath12k driver, kernel NULL pointer dereferences occur in irq_work_sync() called from rhashtable_destroy(). Two hash tables are affected: 1. ath12k_link_sta hash table in ath12k_base 2. ath12k_dp_link_peer hash table in ath12k_dp The issue happens because the destroy functions are called unconditionally in cleanup paths, but the hash tables are only initialized late in their respective init functions. If the device was never fully started or if the init functions failed before initializing the hash tables, the pointers will be NULL. The issues are always reproducible from a VM because the MSI addressing initialization is failing. Call trace for ath12k_link_sta_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_link_sta_rhash_tbl_destroy+0x19/0x40 [ath12k] ath12k_core_stop+0xe/0x80 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Call trace for ath12k_dp_link_peer_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_dp_link_peer_rhash_tbl_destroy+0x29/0x50 [ath12k] ath12k_dp_cmn_device_deinit+0x21/0x140 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Fix this by adding NULL checks before calling rhashtable_destroy() in both destroy functions. The NULL check approach was chosen because the rhashtable pointer serves as the initialization state indicator. The init can fail at various points, leaving some components uninitialized. Checking the pointer directly is simpler than adding separate state flags that would need synchronization. Fixes: 57ccca4 ("wifi: ath12k: Add hash table for ath12k_link_sta in ath12k_base") Fixes: a88cf5f ("wifi: ath12k: Add hash table for ath12k_dp_link_peer") Cc: stable@vger.kernel.org Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260615112103.601982-1-jtornosm@redhat.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Hangtian Zhu (zhuhangtian)
force-pushed
the
qcom-6.18.y
branch
from
July 31, 2026 06:40
0ee40f9 to
997c628
Compare
|
Merge Check Failed: No Change Task Found No associated change tasks found for CR 4626161 on any of the following entities: Entities:
CR: 4626161 Please ensure the CR has a change task associated with at least one of the entities for this branch. |
Author
drop the Merge commit, please check. |
Shiraz Hashim (shashim-quic)
approved these changes
Jul 31, 2026
PR #874 — validate-patchPR: #874
Final Summary
|
PR #874 — checker-log-analyzerPR: #874
Detailed report: Full report
|
Test Matrix
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
19 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Sync ath12k to wireless-2026-07-26, ath-next edc84a9396acf1a0e78c46230dd0bcee1b84ac53
CRs-Fixed: 4626161