summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-01-15wifi: ath12k: send peer meta data version to firmwareBaochen Qiang
Peer meta data version is currently not delivered to firmware, resulting in QCC2072 data path issues. Parse it from service ready ext2 event and send to firmware in WMI init command. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-16-fc8ce1e43969@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath12k: limit number of channels per WMI commandBaochen Qiang
Currently the number of channels can be sent in a single WMI command is calculated based on the maximum message length of the target, this results in WMI exchange hang for QCC2072 as its firmware can not support those many channels in a single command. Add a limit to avoid this issue. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-15-fc8ce1e43969@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath12k: handle REO status ring for QCC2072Baochen Qiang
For QCC2072 below REO status descriptors are different compared with QCN9274/WCN7850: hal_reo_get_queue_stats_status hal_reo_flush_queue_status hal_reo_flush_cache_status hal_reo_unblock_cache_status hal_reo_flush_timeout_list_status hal_reo_desc_thresh_reached_status Take hal_reo_get_queue_stats_status as an example: QCC2072: struct hal_reo_get_queue_stats_status_qcc2072 { __le32 tlv32_padding; struct hal_reo_get_queue_stats_status status; } __packed; QCN9274/WCN7850: struct hal_reo_get_queue_stats_status; Besides, QCC2072 has a 32 bits TLV header while QCN9274/WCN7850 has 64. This means that there is no difference between these 3 devices in layout of actual fields, because they all start after a 8 bytes offset QCC2072: { struct hal_tlv_hdr tlv; __le32 tlv32_padding; struct hal_reo_get_queue_stats_status status; } QCN9274/WCN7850: { struct hal_tlv_64_hdr tlv; struct hal_reo_get_queue_stats_status status; } Therefore current implementation luckily works for QCC2072 as well. However it leads to misunderstanding, which should be avoided. So add individual REO status ring handling for QCC2072. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-14-fc8ce1e43969@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath12k: handle REO CMD ring for QCC2072Baochen Qiang
As far as REO CMD ring is concerned, there are two differences between QCC2072 and the existing chips: For the first, the TLV header of ring descriptor for QCC2072 is 32 bits while 64 bits for existing chips. For the second, QCC2072 has different hal_reo_get_queue_stats, hal_reo_flush_cache and hal_reo_update_rx_queue structures. Take hal_reo_get_queue_stats as an example: QCC2072: struct hal_reo_get_queue_stats_qcc2072 { struct hal_reo_cmd_hdr cmd; [...] __le32 rsvd0[6]; } __packed; QCN9274/WCN7850: struct hal_reo_get_queue_stats { struct hal_reo_cmd_hdr cmd; [...] __le32 rsvd0[6]; __le32 tlv64_pad; } __packed; Note there is no tlv64_pad at the end for QCC2072, but all other former fields share the same layout. These make different ring entry size, so that parameter has to be updated with respect to existing chips. This is done in the newly introduced ath12k_hal_srng_create_config_qcc2072() function, which first creates all ring configs by utilizing ath12k_hal_srng_create_config_wcn7850() and then updates the individual field. Besides, the REO command TLV encoding also need to be corrected because of the different TLV bits. This is done by introducing a 32 bit variant for each of the existing 64 bit callback. Note the hal_reo_get_queue_stats_qcc2072 structure is introduced for the purpose of calculating ring entry size. Existing hal_reo_get_queue_stats structure gets used elsewhere even for QCC2072. This is working because the only difference is the tlv64_pad field that is located at the end and not getting used, hence can be ignored. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-13-fc8ce1e43969@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath12k: add hardware ops support for QCC2072Baochen Qiang
Due to HAL descriptors, QCC2027 has different offsets of MPDU start tag and MSDU end tag, compared with other chips. Hence add new hardware ops structure for QCC2072. All ops are directly taken from WCN7850, with the exception to rxdma_ring_sel_config, which needs a new function ath12k_dp_rxdma_ring_sel_config_qcc2072() to handle the difference mentioned above. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-12-fc8ce1e43969@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath12k: add HAL descriptor and ops for QCC2072Baochen Qiang
QCC2072 has different HAL descriptors hence require different HAL handling, compared to other chips. Add support for this. REO CMD/status ring handling is currently using the 64 bit ops .reo_init_cmd_ring = ath12k_wifi7_hal_reo_init_cmd_ring_tlv64, .reo_cmd_enc_tlv_hdr = ath12k_hal_encode_tlv64_hdr, .reo_status_dec_tlv_hdr = ath12k_hal_decode_tlv64_hdr, these will be updated to use 32 bit variants in upcoming patches. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-11-fc8ce1e43969@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath12k: support downloading auxiliary ucode image for QCC2072Baochen Qiang
QCC2072 requires another firmware image named aux_ucode.bin, add support to download it. Add a new hardware parameter download_aux_ucode to make sure other chips are not affected. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-10-fc8ce1e43969@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath12k: support LPASS_SHARED target memory typeBaochen Qiang
QCC2072 requires a new type of QMI target memory named LPASS_SHARED_V01, add support for it. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-9-fc8ce1e43969@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath12k: add hardware parameters for QCC2072Baochen Qiang
Add hardware parameters for QCC2072, these parameters are directly taken from WCN7850, with exceptions to hardware name, revision, firmware directory, iova_mask and RFKILL parameter set. Compared to WCN7850, QCC2072 doesn't require aligned IOVA when transmitting packets, hence iova_mask is set to zero. Besides, WCN7850 has a dedicated GPIO for RFKILL purpose, however QCC2072 has it coupled with WLAN_EN pin. For QCC2072, host is not allowed to send any RFKILL configuration info to firmware, or firmware crashes. Hence those parameters are all cleared to skip configuring command. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-8-fc8ce1e43969@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath12k: add hardware registers for QCC2072Baochen Qiang
Add hardware registers and populate hw_regs field in ath12k_wifi7_hw_ver_map for QCC2072. Note for some registers not defined and not used by QCC2072, a magic value is assigned. Also populate other fields to be the same with WCN7850. Among them, however, QCC2072 requires different HAL ops and descriptor size, both will be updated in upcoming patches. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-7-fc8ce1e43969@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath12k: fix mac phy capability parsingBaochen Qiang
Currently ath12k_pull_mac_phy_cap_svc_ready_ext() assumes only one band supported in each phy, hence it skips 5 GHz band if 2 GHz band support is detected. This does not work for device which gets only one phy but has both bands supported, such as QCC2072. Change to check each band individually to fix this issue. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-6-fc8ce1e43969@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath12k: refactor 320 MHz bandwidth support parsingBaochen Qiang
For single pdev device, 320 MHz bandwidth support is reported only in capability of WMI_HOST_HW_MODE_SINGLE mode, hence commit d4e244c85e45 ("wifi: ath12k: enable 320 MHz bandwidth for 6 GHz band in EHT PHY capability for WCN7850") relaxed the condition check in ath12k_wmi_tlv_mac_phy_caps_ext() to allow SINGLE mode getting parsed in ath12k_wmi_tlv_mac_phy_caps_ext_parse(). Since SINGLE mode is not assumed to be preferred, the function returns unconditionally after parsing 320 MHz support. This works for WCN7850 because it prefers another mode indeed, while it breaks QCC2072 since it prefers SINGLE mode. Due to the unconditional return, the subsequent EHT parsing is skipped. Consequently EHT related features are disabled. Refactor it by moving 320 MHz parsing to ath12k_wmi_tlv_mac_phy_caps_ext(), before the mode checking. This makes the code more straightforward, and work for both WCN7850 and QCC2072. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-5-fc8ce1e43969@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath12k: fix preferred hardware mode calculationBaochen Qiang
For single pdev device like WCN7850/QCC2072, preferred_hw_mode is initialized to WMI_HOST_HW_MODE_SINGLE. Later when firmware sends supported modes to host, each mode is compared with the initial one and if the priority of the new mode is higher, update the parameter and store mode capability. For WCN7850, this does not result in issue, as one of the supported mode indeed has a higher priority. However the only available mode of QCC2072 at this stage is WMI_HOST_HW_MODE_SINGLE, which fails the comparison, hence mode capability is not stored. Subsequently driver initialization fails. Fix it by accepting a mode with the same priority. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-4-fc8ce1e43969@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath12k: refactor REO status ring handlingBaochen Qiang
The entry of REO status ring of existing chips has a 64 bit TLV header, hence below functions take a 64 bit TLV assumption by default ath12k_wifi7_dp_rx_process_reo_status() ath12k_wifi7_hal_reo_status_queue_stats() ath12k_wifi7_hal_reo_flush_queue_status() ath12k_wifi7_hal_reo_flush_cache_status() ath12k_wifi7_hal_reo_unblk_cache_status() ath12k_wifi7_hal_reo_flush_timeout_list_status() ath12k_wifi7_hal_reo_desc_thresh_reached_status() ath12k_wifi7_hal_reo_update_rx_reo_queue_status() However this is not the case for QCC2072 of which the TLV is 32 bit. Refactor above functions to prepare for QCC2072 support, this is done by removing TLV length assumption and offloading TLV decoding work to a newly added callback _reo_status_dec_tlv_hdr. This way each chip can register its own handler hence can do the work accordingly. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-3-fc8ce1e43969@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath12k: refactor REO CMD ring handlingBaochen Qiang
The entry of REO CMD ring of existing chips has a 64 bit TLV header, hence below functions take a 64 bit TLV assumption by default ath12k_wifi7_hal_reo_init_cmd_ring() ath12k_wifi7_hal_reo_cmd_queue_stats() ath12k_wifi7_hal_reo_cmd_flush_cache() ath12k_wifi7_hal_reo_cmd_update_rx_queue() However this is not the case for QCC2072 of which the TLV is 32 bit, meaning above functions don't work for it. Rename/refactor above functions to prepare for QCC2072 support: Rename the first one to ath12k_wifi7_hal_reo_init_cmd_ring_tlv64() to better reflect what it is doing. There will be a 32 bit variant when QCC2072 support is in place. For the last ones, remove TLV length assumption and offload TLV encoding work to a newly added callback _reo_cmd_enc_tlv_hdr. This way each chip can register its own handler hence can do the work accordingly. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-2-fc8ce1e43969@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath12k: refactor PCI window register accessBaochen Qiang
Currently offset of PCI window register address is defined as 0x310c which is same across existing chips. However QCC2072 has a different offset 0x3278. In order to make the window selection logic work for QCC2072 as well, change to initialize this parameter per device at the probe time. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-1-fc8ce1e43969@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath11k: move .max_tx_ring to struct ath11k_hw_hal_paramsAlexandru Gagniuc
".max_tx_ring" is an upper bounds to indexing ".tcl2wbm_rbm_map". It is initialized in, core.c, a different file than the array. This spaghetti-like relation is fragile and not obvious. Accidentally setting ".max_tx_ring" too high leads to a hard to track out-of- bounds access and memory corruption. There is a small ambiguity on the meaning of "max_tx_ring": - The highest ring, max=3 implies there are 4 rings (0, 1, 2, 3) - The highest number to use for array indexing (there are 3 rings) Clarify this dependency by moving ".max_tx_ring" adjacent to the array ".tcl2wbm_rbm_map", and name it "num_tx_rings". Use ARRAY_SIZE() instead of #defines to initialize the length field. The intent is to make the code easier to understand rather than fix an existing bug. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20251228151408.2116108-1-mr.nuke.me@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath11k: Register handler for CFR capture eventVenkateswara Naralasetty
Firmware sends CFR meta data through the WMI event WMI_PEER_CFR_CAPTURE_EVENT. Parse the meta data coming from the firmware and invoke correlate_and_relay function to correlate the CFR meta data with the CFR payload coming from the other WMI event WMI_PDEV_DMA_RING_BUF_RELEASE_EVENT. Release the buffer to user space once correlate and relay return success. Tested-on: IPQ8074 hw2.0 PCI IPQ8074 WLAN.HK.2.5.0.1-00991-QCAHKSWPL_SILICONZ-1 Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 Signed-off-by: Venkateswara Naralasetty <quic_vnaralas@quicinc.com> Co-developed-by: Yu Zhang (Yuriy) <yu.zhang@oss.qualcomm.com> Signed-off-by: Yu Zhang (Yuriy) <yu.zhang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Signed-off-by: Qian Zhang <qian.zhang@oss.qualcomm.com> Link: https://patch.msgid.link/20251230082520.3401007-7-qian.zhang@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath11k: Register DBR event handler for CFR dataVenkateswara Naralasetty
Add handler for WMI_PDEV_DMA_RING_BUF_RELEASE_EVENT which indicates CFR data availability in the DB ring. Add CFR data processing from DB ring buffers. Use correlate_and_relay API to match CFR data with metadata from WMI_PEER_CFR_CAPTURE_EVENT. Release buffer to userspace through relayfs on successful correlation, otherwise hold buffer waiting for matching WMI event from firmware. Add new debug masks: - ATH11K_DBG_CFR: Enables CFR-related debug logs. - ATH11K_DBG_CFR_DUMP: Enables detailed CFR data dump for analysis. Tested-on: IPQ8074 hw2.0 PCI IPQ8074 WLAN.HK.2.5.0.1-00991-QCAHKSWPL_SILICONZ-1 Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 Signed-off-by: Venkateswara Naralasetty <quic_vnaralas@quicinc.com> Co-developed-by: Yu Zhang (Yuriy) <yu.zhang@oss.qualcomm.com> Signed-off-by: Yu Zhang (Yuriy) <yu.zhang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Signed-off-by: Qian Zhang <qian.zhang@oss.qualcomm.com> Link: https://patch.msgid.link/20251230082520.3401007-6-qian.zhang@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath11k: Register relayfs entries for CFR dumpVenkateswara Naralasetty
Provide a relayfs interface to collect the CFR dump from the user space. '/sys/kernel/debug/ieee80211/phyX/ath11k/cfr_capture' is exposed to user space to get CFR data. CFR format to user space: ___________________________________________ | CFR header | CFR payload | CFR tail data | |____________|_____________|_______________| CFR header contains the following fields, * Start magic number 0xDEADBEAF - 4 bytes * vendor id - 4 bytes * cfr metadata version - 1 byte * cfr data version - 1 byte * device type - 1 byte * platform type - 1 byte * CFR metadata length - 4 bytes * metadata - 92 bytes peer mac - 6 bytes capture status - 1 byte (1 for success 0 for failure) capture_bw - 1 byte channel_bw - 1 byte phy_mode - 1 byte prim20_chan - 2 bytes center_freq1 - 2 bytes center_freq2 - 2 bytes capture_mode - 1 byte capture_type - 1 byte sts_count - 1 byte num_rx_chain - 1 byte timestamp - 4 bytes length - 4 bytes chain_rssi - 32 bytes (4 bytes for each chain) chain_phase - 16 bytes (2 bytes for each chain) cfo_measurement - 4 bytes agc_gain - 8 bytes (1 bytes for each chain) rx_start_ts - 4 bytes CFR payload: CFR payload contains 8bytes of ucode header followed by the tone information. Tone order is positive tones, followed by PHY memory garbage, followed by negative tones. Dummy tones are uploaded to make number of tones always integer number of 64. Number of tones is not preamble type dependent. Each CFR tone has 14-bit I component and 14-bit Q component and is sign extended to 16-bit I/Q. Two tones are packed into one 64-bit unit as: [63:0] = [Tone1_Q(63:48) Tone1_I(47:32) Tone0_Q(31:16) Tone0_I(15:0)] CFR tail: end magic number 0xBEAFDEAD Tested-on: IPQ8074 hw2.0 PCI IPQ8074 WLAN.HK.2.5.0.1-00991-QCAHKSWPL_SILICONZ-1 Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 Signed-off-by: Venkateswara Naralasetty <quic_vnaralas@quicinc.com> Co-developed-by: Yu Zhang (Yuriy) <yu.zhang@oss.qualcomm.com> Signed-off-by: Yu Zhang (Yuriy) <yu.zhang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Signed-off-by: Qian Zhang <qian.zhang@oss.qualcomm.com> Link: https://patch.msgid.link/20251230082520.3401007-5-qian.zhang@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath11k: Add support unassociated client CFRVenkateswara Naralasetty
Provide debugfs interfaces support to config unassociated client CFR from the user space. To enable CFR capture for unassociated clients, echo "<mac address> <val> <periodicity>" > /sys/kernel/debug/ieee80211/phyX/ath11k/cfr_unassoc Mac address: mac address of the client. Val: 0 - start CFR capture 1 - stop CFR capture Periodicity: Periodicity at which hardware is expected to collect CFR dump. 0 - single shot capture. non zero - for Periodic captures (value must be multiple of 10 ms) Tested-on: IPQ8074 hw2.0 PCI IPQ8074 WLAN.HK.2.5.0.1-00991-QCAHKSWPL_SILICONZ-1 Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 Signed-off-by: Venkateswara Naralasetty <quic_vnaralas@quicinc.com> Co-developed-by: Yu Zhang (Yuriy) <yu.zhang@oss.qualcomm.com> Signed-off-by: Yu Zhang (Yuriy) <yu.zhang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Signed-off-by: Qian Zhang <qian.zhang@oss.qualcomm.com> Link: https://patch.msgid.link/20251230082520.3401007-4-qian.zhang@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath11k: Register debugfs for CFR configurationVenkateswara Naralasetty
Provide debugfs interfaces support to config CFR from the user space. To enable/disable cfr feature use command, echo <val> > /sys/kernel/debug/ieee80211/phyX/ath11k/enable_cfr where, val: 0 to disable CFR and 1 to enable CFR. To enable CFR capture for associated peers, echo "<val> <bw> <periodicity> <method>" > /sys/kernel/debug/ieee80211/phyX/netdev\:wlanx/stations/<mac>/cfr_capture val: 0 - stop CFR capture 1 - start CFR capture bw: CFR capture bandwidth 0 - 20MHZ 1 - 40MHZ 2 - 80MHZ Periodicity: Periodicity at which hardware is expected to collect CFR dump. 0 - single shot capture. non zero - for Periodic captures (value must be multiple of 10 ms) method: Method used by hardware to collect the CFR dump. 0 - from the ACKs of QOS NULL packets. Also, send the required WMI commands to the firmware based on the CFR configurations. Tested-on: IPQ8074 hw2.0 PCI IPQ8074 WLAN.HK.2.5.0.1-00991-QCAHKSWPL_SILICONZ-1 Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 Signed-off-by: Venkateswara Naralasetty <quic_vnaralas@quicinc.com> Co-developed-by: Yu Zhang (Yuriy) <yu.zhang@oss.qualcomm.com> Signed-off-by: Yu Zhang (Yuriy) <yu.zhang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Signed-off-by: Qian Zhang <qian.zhang@oss.qualcomm.com> Link: https://patch.msgid.link/20251230082520.3401007-3-qian.zhang@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath11k: Add initialization and deinitialization sequence for CFR moduleVenkateswara Naralasetty
Channel Frequency Response (CFR) module will be initialized only when the following criteria passes: * Enabled CFR support for the hardware through the hardware param 'cfr_support' * WMI service enabled for the CFR support 'WMI_TLV_SERVICE_CFR_CAPTURE_SUPPORT' Also, provide a configuration option CONFIG_ATH11K_CFR to enable CFR feature support during the compilation time. CFR module initialization includes Direct Buffer(DB) ring initialization where hardware uses the DB ring buffers to copy CFR data to host. Number of buffers and buffer size of the ring is based on the DB ring capabilities advertised by the firmware through WMI service ready. Also ring configurations are sent to firmware through ath11k_dbring_wmi_cfg_setup(). Predefine ath11k_cfr_dma_hdr, ath11k_look_up_table, and ath11k_cfr structs and fields for subsequent patches. Tested-on: IPQ8074 hw2.0 PCI IPQ8074 WLAN.HK.2.5.0.1-00991-QCAHKSWPL_SILICONZ-1 Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 Signed-off-by: Venkateswara Naralasetty <quic_vnaralas@quicinc.com> Co-developed-by: Yu Zhang (Yuriy) <yu.zhang@oss.qualcomm.com> Signed-off-by: Yu Zhang (Yuriy) <yu.zhang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Signed-off-by: Qian Zhang <qian.zhang@oss.qualcomm.com> Link: https://patch.msgid.link/20251230082520.3401007-2-qian.zhang@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath12k: do WoW offloads only on primary linkBaochen Qiang
In case of multi-link connection, WCN7850 firmware crashes due to WoW offloads enabled on both primary and secondary links. Change to do it only on primary link to fix it. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Fixes: 32f7b19668bd ("wifi: ath12k: support MLO as well if single_chip_mlo_support flag is set") Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20251103-ath12-primary-link-wow-v1-1-3cf523dc09f0@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath12k: clean up on error in ath12k_dp_setup()Dan Carpenter
Destroy the rhash_tbl before returning the error code. Fixes: a88cf5f71adf ("wifi: ath12k: Add hash table for ath12k_dp_link_peer") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/aUOw1J0TU4VgeXj6@stanley.mountain Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath12k: remove redundant pci_set_drvdata() callAlexander Minchev
pci_set_drvdata() is called twice in ath12k_pci_probe() with the same pointer. Remove the earlier call so drvdata is set after ath12k_base and ath12k_pci initialization is complete. Having two calls might suggest that drvdata needs to be set early for some reason, even though it is not used until after the 'ab' struct ath12k_base is fully populated. Even though exact placement is not critical, keeping a single pci_set_drvdata() at the end of the initialization makes it clearer that drvdata points to a fully initialized structure and avoids confusion for future changes. Tested on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Signed-off-by: Alexander Minchev <adminchev@proton.me> Link: https://patch.msgid.link/20251127072839.14167-2-adminchev@proton.me Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath11k: fix comment typo in monitor mode handlingChien Wong
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>
2026-01-15wifi: ath11k: Fix failure to connect to a 6 GHz APQian Zhang
STA fails to connect to a 6 GHz AP with the following errors: ath11k_pci 0000:01:00.0: failed to handle chan list with power type 1 wlp1s0: deauthenticating from c8:a3:e8:dd:41:e3 by local choice (Reason: 3=DEAUTH_LEAVING) ath11k_reg_handle_chan_list() treats the update as redundant and returns -EINVAL. That causes the connection attempt to fail. Avoid unnecessary validation during association. Apply the regulatory redundant check only when the power type is IEEE80211_REG_UNSET_AP, which only occurs during core initialization. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Signed-off-by: Qian Zhang <qian.zhang@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260108034607.812885-1-qian.zhang@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath11k: add pm quirk for Thinkpad Z13/Z16 Gen1Ross Vandegrift
Z16 Gen1 has the wakeup-from-suspend issues from [1] but was never added to the appropriate quirk list. I've tested this patch on top of 6.18.2, it fixes the issue for me on 21D4 Mark Pearson provided the other product IDs covering the second Z16 Gen1 and both Z13 Gen1 identifiers. They share the same firmware, and folks in the bugzilla report do indeed see the problem on Z13. [1] - https://bugzilla.kernel.org/show_bug.cgi?id=219196 Signed-off-by: Ross Vandegrift <ross@kallisti.us> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca> Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Link: https://patch.msgid.link/wj7o2kmb7g54stdjvxp2hjqrnutnq3jbf4s2uh4ctvmlxdq7tf@nbkj2ebakhrd Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: wil6210: fix a bunch of kernel-doc warningsRandy Dunlap
scripts/kernel-doc.py reports 51 kernel-doc warnings in wil6210.h. Fix all kernel-doc warnings reported in wil6210.h. Several comments are changed from "/**" to "/*" since it appears that "/**" was used for many non-kernel-doc comments. - add kernel-doc for missing function parameters - add one function "Returns:" - correct kernel-doc struct name to match actual struct name in 2 places Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20251117020213.443126-1-rdunlap@infradead.org Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath9k: add OF dependency to AHBRosen Penev
The conversion to OF missed adding a Kconfig dependency. Fixes: 2fa490c0d759 ("wifi: ath9k: ahb: replace id_table with of") Signed-off-by: Rosen Penev <rosenp@gmail.com> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Link: https://patch.msgid.link/20250802000432.3079550-1-rosenp@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath9k: fix kernel-doc warnings in common-debug.hRandy Dunlap
Modify kernel-doc comments in common-debug.h to avoid warnings: Warning: drivers/net/wireless/ath/ath9k/common-debug.h:21 bad line: may have had errors. Warning: ../drivers/net/wireless/ath/ath9k/common-debug.h:23 bad line: may have had errors. Warning: ../drivers/net/wireless/ath/ath9k/common-debug.h:26 bad line: decryption process completed Warning: ../drivers/net/wireless/ath/ath9k/common-debug.h:28 bad line: encountered an error Fixes: 99c15bf575b1 ("ath9k: Report total tx/rx bytes and packets in debugfs.") Fixes: 1395d3f00a41 ("ath9k: Add debugfs file for RX errors") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Link: https://patch.msgid.link/20251117020251.447692-1-rdunlap@infradead.org Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath9k: debug.h: fix kernel-doc bad lines and struct ath_tx_statsRandy Dunlap
Repair "bad line" warnings by starting each line with " *". Add or correct kernel-doc entries for missing struct members in struct ath_tx_stats. Warning: ../drivers/net/wireless/ath/ath9k/debug.h:144 bad line: may have had errors. Warning: ../drivers/net/wireless/ath/ath9k/debug.h:146 bad line: may have had errors. Warning: ../drivers/net/wireless/ath/ath9k/debug.h:156 bad line: Valid only for: Warning: ../drivers/net/wireless/ath/ath9k/debug.h:157 bad line: - non-aggregate condition. Warning: ../drivers/net/wireless/ath/ath9k/debug.h:158 bad line: - first packet of aggregate. Warning: drivers/net/wireless/ath/ath9k/debug.h:191 struct member 'xretries' not described in 'ath_tx_stats' Warning: drivers/net/wireless/ath/ath9k/debug.h:191 struct member 'data_underrun' not described in 'ath_tx_stats' Warning: drivers/net/wireless/ath/ath9k/debug.h:191 struct member 'delim_underrun' not described in 'ath_tx_stats' Fixes: 99c15bf575b1 ("ath9k: Report total tx/rx bytes and packets in debugfs.") Fixes: fec247c0d5bf ("ath9k: Add debug counters for TX") Fixes: 5a6f78afdabe ("ath9k: show excessive-retry MPDUs in debugfs") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Link: https://patch.msgid.link/20251117020304.448687-1-rdunlap@infradead.org Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15wifi: ath5k: debug.h: fix enum ath5k_debug_level kernel-docRandy Dunlap
Add a description for ATH5K_DEBUG_ANI and delete the descriptions for 3 undefined enum descriptions to prevent these warnings: Warning: drivers/net/wireless/ath/ath5k/debug.h:111 Enum value 'ATH5K_DEBUG_ANI' not described in enum 'ath5k_debug_level' Warning: drivers/net/wireless/ath/ath5k/debug.h:111 Excess enum value '%ATH5K_DEBUG_DUMP_RX' description in 'ath5k_debug_level' Warning: drivers/net/wireless/ath/ath5k/debug.h:111 Excess enum value '%ATH5K_DEBUG_DUMP_TX' description in 'ath5k_debug_level' Warning: drivers/net/wireless/ath/ath5k/debug.h:111 Excess enum value '%ATH5K_DEBUG_TRACE' description in 'ath5k_debug_level' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20251128010401.546506-1-rdunlap@infradead.org Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15dt-bindings: net: wireless: ath11k: Combine two if:then: clausesKrzysztof Kozlowski
Simplify the binding by combining two if:then: clauses which have exactly the same conditional part. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20251230114835.52504-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-01-15soc: renesas: Fix missing dependency on new CONFIG_CACHEMAINT_FOR_DMAJonathan Cameron
The Kconfig menu entry was converted to a menuconfig to allow it to be hidden for !CONFIG_RISCV. The drivers under this new option were selected by some other Kconfig symbols and so an extra select CACHEMAINT_FOR_DMA is needed. Fixes: 4d1608d0ab33 ("cache: Make top level Kconfig menu a boolean dependent on RISCV") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202512100411.WxJU2No9-lkp@intel.com/ Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20251210160047.201379-3-Jonathan.Cameron@huawei.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-15riscv: ERRATA_STARFIVE_JH7100: Fix missing dependency on new ↵Jonathan Cameron
CONFIG_CACHEMAINT_FOR_DMA The Kconfig menu entry was converted to a menuconfig to allow it to be hidden for !CONFIG_RISCV. The drivers under this new option were selected by some other Kconfig symbols and so an extra select CACHEMAINT_FOR_DMA is needed. Fixes: 4d1608d0ab33 ("cache: Make top level Kconfig menu a boolean dependent on RISCV") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202512100509.g6llkMMr-lkp@intel.com/ Signed-off-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://patch.msgid.link/20251210160047.201379-2-Jonathan.Cameron@huawei.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-16Merge tag 'drm-misc-next-2026-01-15' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for 6.20: Core Changes: - atomic: Introduce Gamma/Degamma LUT size check - gem: Fix a leak in drm_gem_get_unmapped_area - gpuvm: API sanitation for Rust bindings - panic: Few corner-cases fixes Driver Changes: - Replace system workqueue with percpu equivalent - amdxdna: Update message buffer allocation requirements, Update firmware version check - imagination: Add AM62P support - ivpu: Implement warm boot flow - rockchip: Get rid of atomic_check fixups, Add Rockchip RK3506 Support - rocket: Cleanups - bridge: - dw-hdmi-qp: Add support for HPD-less setups - panel: - mantix: Various power management related improvements - new panels: Innolux G150XGE-L05, - dma-buf: - cma: Call clear_page instead of memset Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://patch.msgid.link/20260115-lilac-dragon-of-opposition-ac0a30@houat
2026-01-15kernel: modules: Add SPDX license identifier to kmod.cTim Bird
Add a GPL-2.0 license identifier line for this file. kmod.c was originally introduced in the kernel in February of 1998 by Linus Torvalds - who was familiar with kernel licensing at the time this was introduced. Signed-off-by: Tim Bird <tim.bird@sony.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-01-16rust: driver: drop device private data post unbindDanilo Krummrich
Currently, the driver's device private data is allocated and initialized from driver core code called from bus abstractions after the driver's probe() callback returned the corresponding initializer. Similarly, the driver's device private data is dropped within the remove() callback of bus abstractions after calling the remove() callback of the corresponding driver. However, commit 6f61a2637abe ("rust: device: introduce Device::drvdata()") introduced an accessor for the driver's device private data for a Device<Bound>, i.e. a device that is currently bound to a driver. Obviously, this is in conflict with dropping the driver's device private data in remove(), since a device can not be considered to be fully unbound after remove() has finished: We also have to consider registrations guarded by devres - such as IRQ or class device registrations - which are torn down after remove() in devres_release_all(). Thus, it can happen that, for instance, a class device or IRQ callback still calls Device::drvdata(), which then runs concurrently to remove() (which sets dev->driver_data to NULL and drops the driver's device private data), before devres_release_all() started to tear down the corresponding registration. This is because devres guarded registrations can, as expected, access the corresponding Device<Bound> that defines their scope. In C it simply is the driver's responsibility to ensure that its device private data is freed after e.g. an IRQ registration is unregistered. Typically, C drivers achieve this by allocating their device private data with e.g. devm_kzalloc() before doing anything else, i.e. before e.g. registering an IRQ with devm_request_threaded_irq(), relying on the reverse order cleanup of devres. Technically, we could do something similar in Rust. However, the resulting code would be pretty messy: In Rust we have to differentiate between allocated but uninitialized memory and initialized memory in the type system. Thus, we would need to somehow keep track of whether the driver's device private data object has been initialized (i.e. probe() was successful and returned a valid initializer for this memory) and conditionally call the destructor of the corresponding object when it is freed. This is because we'd need to allocate and register the memory of the driver's device private data *before* it is initialized by the initializer returned by the driver's probe() callback, because the driver could already register devres guarded registrations within probe() outside of the driver's device private data initializer. Luckily there is a much simpler solution: Instead of dropping the driver's device private data at the end of remove(), we just drop it after the device has been fully unbound, i.e. after all devres callbacks have been processed. For this, we introduce a new post_unbind() callback private to the driver-core, i.e. the callback is neither exposed to drivers, nor to bus abstractions. This way, the driver-core code can simply continue to conditionally allocate the memory for the driver's device private data when the driver's initializer is returned from probe() - no change needed - and drop it when the driver-core code receives the post_unbind() callback. Closes: https://lore.kernel.org/all/DEZMS6Y4A7XE.XE7EUBT5SJFJ@kernel.org/ Fixes: 6f61a2637abe ("rust: device: introduce Device::drvdata()") Acked-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Igor Korotin <igor.korotin.linux@gmail.com> Link: https://patch.msgid.link/20260107103511.570525-7-dakr@kernel.org [ Remove #ifdef CONFIG_RUST, rename post_unbind() to post_unbind_rust(). - Danilo] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-16rust: driver: add DriverData type to the DriverLayout traitDanilo Krummrich
Add an associated type DriverData to the DriverLayout trait indicating the type of the driver's device private data. Acked-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Igor Korotin <igor.korotin.linux@gmail.com> Link: https://patch.msgid.link/20260107103511.570525-6-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-16rust: driver: add DEVICE_DRIVER_OFFSET to the DriverLayout traitDanilo Krummrich
Add an associated const DEVICE_DRIVER_OFFSET to the DriverLayout trait indicating the offset of the embedded struct device_driver within Self::DriverType, i.e. the specific driver structs, such as struct pci_driver or struct platform_driver. Acked-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Igor Korotin <igor.korotin.linux@gmail.com> Link: https://patch.msgid.link/20260107103511.570525-5-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-16rust: driver: introduce a DriverLayout traitDanilo Krummrich
The DriverLayout trait describes the layout of a specific driver structure, such as `struct pci_driver` or `struct platform_driver`. In a first step, this replaces the associated type RegType of the RegistrationOps with the DriverLayout::DriverType associated type. Acked-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Igor Korotin <igor.korotin.linux@gmail.com> Link: https://patch.msgid.link/20260107103511.570525-4-dakr@kernel.org [ Rename driver::Driver to driver::DriverLayout, as it represents the layout of a driver structure rather than the driver structure itself. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-15selftests/bpf: Add test for bpf_override_return helperJiri Olsa
We do not actually test the bpf_override_return helper functionality itself at the moment, only the bpf program being able to attach it. Adding test that override prctl syscall return value on top of kprobe and kprobe.multi. Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Song Liu <song@kernel.org> Link: https://lore.kernel.org/bpf/20260112121157.854473-2-jolsa@kernel.org
2026-01-15arm64/ftrace,bpf: Fix partial regs after bpf_prog_runJiri Olsa
Mahe reported issue with bpf_override_return helper not working when executed from kprobe.multi bpf program on arm. The problem is that on arm we use alternate storage for pt_regs object that is passed to bpf_prog_run and if any register is changed (which is the case of bpf_override_return) it's not propagated back to actual pt_regs object. Fixing this by introducing and calling ftrace_partial_regs_update function to propagate the values of changed registers (ip and stack). Reported-by: Mahe Tardy <mahe.tardy@gmail.com> Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org> Acked-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/bpf/20260112121157.854473-1-jolsa@kernel.org
2026-01-15Merge tag 'ftrace-v6.19-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull ftrace fix from Steven Rostedt: - Fix allocation accounting on boot up The ftrace records for each function that ftrace can attach to is done in a group of pages. At boot up, the number of pages are calculated and allocated. After that, the pages are filled with data. It may allocate more than needed due to some functions not being recorded (because they are unused weak functions), this too is recorded. After the data is filled in, a check is made to make sure the right number of pages were allocated. But this was off due to the assumption that the same number of entries fit per every page. Because the size of an entry does not evenly divide into PAGE_SIZE, there is a rounding error when a large number of pages is allocated to hold the events. This causes the check to fail and triggers a warning. Fix the accounting by finding out how many pages are actually allocated from the functions that allocate them and use that to see if all the pages allocated were used and the ones not used are properly freed. * tag 'ftrace-v6.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: ftrace: Do not over-allocate ftrace memory
2026-01-15dt-bindings: display/msm/rgmu: Document A612 RGMUJie Zhang
RGMU a.k.a Reduced Graphics Management Unit is a small state machine with the sole purpose of providing IFPC (Inter Frame Power Collapse) support. Compared to GMU, it doesn't manage GPU clock, voltage scaling, bw voting or any other functionalities. All it does is detect an idle GPU and toggle the GDSC switch. As it doesn't access DDR space, it doesn't require iommu. So far, only Adreno 612 GPU has an RGMU core. Document it in qcom,adreno-rgmu.yaml. Signed-off-by: Jie Zhang <jie.zhang@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Patchwork: https://patchwork.freedesktop.org/patch/696679/ Message-ID: <20251231-qcs615-spin-2-v6-4-da87debf6883@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-01-15dt-bindings: display/msm: gpu: Document A612 GPUAkhil P Oommen
A612 GPU has a new IP called RGMU (Reduced Graphics Management Unit) which replaces GMU. But it doesn't do clock or voltage scaling. So we need the gpu core clock in the GPU node along with the power domain to do clock and voltage scaling from the kernel. Update the bindings to describe this GPU. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/696676/ Message-ID: <20251231-qcs615-spin-2-v6-3-da87debf6883@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-01-15dt-bindings: display/msm: gpu: Simplify conditional schema logicAkhil P Oommen
JSON Schema conditionals can become complex and error-prone when combined with regex patterns. To improve readability and maintainability, replace nested if-else blocks with a flattened structure using explicit enums. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/696674/ Message-ID: <20251231-qcs615-spin-2-v6-2-da87debf6883@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-01-15drm/msm/a6xx: Retrieve gmu core range by indexAkhil P Oommen
Some GPUs like A612 doesn't use a named register range resource. This is because the reg-name property is discouraged when there is just a single resource. To address this, retrieve the 'gmu' register range by its index. It is always guaranteed to be at index 0. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/696673/ Message-ID: <20251231-qcs615-spin-2-v6-1-da87debf6883@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-21 05:55:10 +0000