Prepare qcom-next based on tag 'Linux 7.2-rc4' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git#862
Closed
Salendarsingh Gaud (sgaud-quic) wants to merge 1310 commits into
Conversation
…ort node The PCIe phy reference and the perst/wake GPIO properties are per root port and belong in the root port node (pcie@0), not in the RC controller node. Move phys, phy-names, perst-gpios, and wake-gpios from the controller to pcie0_port0 and pcie1_port0, adding labels to these nodes to allow board-level overrides, and renaming perst-gpios to reset-gpios to match the binding used in the root port context. Link: https://lore.kernel.org/r/20260611-wake-v2-29-2744251b1181@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Krishna Chaitanya Chundru <krishna.chaitanya.chundru@oss.qualcomm.com> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
…ort node The PCIe phy reference and the perst/wake GPIO properties are per root port and belong in the root port node (pcie@0), not in the RC controller node. Move phys, phy-names, perst-gpios, and wake-gpios from the controller to the existing pcieport0 and newly labeled pcie1_port0 and pcie2_port0, allowing board-level overrides. Rename perst-gpios to reset-gpios to match the binding used in the root port context. Link: https://lore.kernel.org/r/20260611-wake-v2-30-2744251b1181@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Krishna Chaitanya Chundru <krishna.chaitanya.chundru@oss.qualcomm.com> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
…ort node The PCIe phy reference and the perst/wake GPIO properties are per root port and belong in the root port node (pcie@0), not in the RC controller node. Move phys and phy-names from the controller to pcie0_port0 and pcie1_port0, adding labels to these nodes to allow board-level overrides. Move perst-gpios/wake-gpios from the controller overrides to the respective port nodes in the board file, renaming perst-gpios to reset-gpios to match the binding used in the root port context. Link: https://lore.kernel.org/r/20260611-wake-v2-31-2744251b1181@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Krishna Chaitanya Chundru <krishna.chaitanya.chundru@oss.qualcomm.com> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
…ort node The PCIe phy reference and the perst/wake GPIO properties are per root port and belong in the root port node (pcie@0), not in the RC controller node. Move phys, phy-names, perst-gpios, and wake-gpios from the controller to the existing pcieport0 and newly labeled pcie1_port0, allowing board-level overrides. Rename perst-gpios to reset-gpios to match the binding used in the root port context. Link: https://lore.kernel.org/r/20260611-wake-v2-32-2744251b1181@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Krishna Chaitanya Chundru <krishna.chaitanya.chundru@oss.qualcomm.com> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
…ort node The PCIe phy reference and the perst/wake GPIO properties are per root port and belong in the root port node (pcie@0), not in the RC controller node. Move phys and phy-names from the controller to the existing pcieport0 and newly labeled pcie1_port0, allowing board-level overrides. Move perst-gpios/wake-gpios from the controller overrides to the respective port nodes in the board files, renaming perst-gpios to reset-gpios to match the binding used in the root port context. Link: https://lore.kernel.org/r/20260611-wake-v2-33-2744251b1181@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Krishna Chaitanya Chundru <krishna.chaitanya.chundru@oss.qualcomm.com> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
…rt node The PCIe phy reference and the perst/wake GPIO properties are per root port and belong in the root port node (pcie@0), not in the RC controller node. Move phys from the controller to pcie_port0, and move perst-gpios/wake-gpios from the &pcie controller overrides to the &pcie_port0 node in the board files, renaming perst-gpios to reset-gpios to match the binding used in the root port context. Link: https://lore.kernel.org/r/20260611-wake-v2-34-2744251b1181@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Krishna Chaitanya Chundru <krishna.chaitanya.chundru@oss.qualcomm.com> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
…ort node The PCIe phy reference and the perst/wake GPIO properties are per root port and belong in the root port node (pcie@0), not in the RC controller node. Move phys and phy-names from the controller to the existing pcieport0 and pcie1_port0, allowing board-level overrides. Move perst-gpios/wake-gpios from the controller overrides to the respective port nodes in the board files, renaming perst-gpios to reset-gpios to match the binding used in the root port context. Link: https://lore.kernel.org/r/20260611-wake-v2-35-2744251b1181@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Krishna Chaitanya Chundru <krishna.chaitanya.chundru@oss.qualcomm.com> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
…ort node The PCIe phy reference and the perst/wake GPIO properties are per-root port and belong in the root port node (pcie@0), not in the RC controller node. Move phys from the controller to pcie0_port and pcie1_port0, and move perst-gpios/wake-gpios from the &pcie0/&pcie1 controller overrides to the respective &pcie0_port/&pcie1_port0 nodes in the board files, renaming perst-gpios to reset-gpios to match the binding used in the root port context. Link: https://lore.kernel.org/r/20260611-wake-v2-36-2744251b1181@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Krishna Chaitanya Chundru <krishna.chaitanya.chundru@oss.qualcomm.com> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
…port node The PCIe phy reference and the perst/wake GPIO properties are per root port and belong in the root port node (pcie@0), not in the RC controller node. Move phys and phy-names from the controller to pcie0_port0, pcie1_port0, and pcie2_port0, adding labels to these nodes to allow board-level overrides. Move perst-gpios/wake-gpios from the controller overrides to the respective port nodes in the board files, renaming perst-gpios to reset-gpios to match the binding used in the root port context. Link: https://lore.kernel.org/r/20260611-wake-v2-37-2744251b1181@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Krishna Chaitanya Chundru <krishna.chaitanya.chundru@oss.qualcomm.com> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
…ort node The PCIe phy reference and the perst/wake GPIO properties are per root port and belong in the root port node (pcie@0), not in the RC controller node. Move phys from the controller to pcieport0 and pcieport1. Add the missing pcieport1 label to the pcie1 root port node to allow board-level overrides. Move perst-gpios/wake-gpios from the &pcie0/&pcie1 controller overrides to the respective &pcieport0/ &pcieport1 nodes in the board files, renaming perst-gpios to reset-gpios to match the binding used in the root port context. Link: https://lore.kernel.org/r/20260611-wake-v2-19-2744251b1181@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Krishna Chaitanya Chundru <krishna.chaitanya.chundru@oss.qualcomm.com> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
According to the PCI Express specification (PCIe r7.0, Section 5.3.3.2), two link wakeup mechanisms are defined: Beacon and WAKE#. Beacon is a hardware-only mechanism and is invisible to software (PCIe r7.0, Section 4.2.7.8.1). This change adds support for the WAKE# mechanism in the PCI core. According to the PCIe specification, multiple WAKE# signals can exist in a system or each component in the hierarchy could share a single WAKE# signal. In configurations involving a PCIe switch, each downstream port (DSP) of the switch may be connected to a separate WAKE# line, allowing each endpoint to signal WAKE# independently. From figure 5.4 in sec 5.3.3.2, WAKE# can also be terminated at the switch itself. Such topologies are typically not described in Device Tree, therefore it is out of scope for this series. To support this, the WAKE# should be described in the device tree node of the endpoint/bridge. If all endpoints share a single WAKE# line, then each endpoint node shall describe the same WAKE# signal or a single WAKE# in the Root Port node. In pci_device_add(), PCI framework will search for the WAKE# in device node. Once found, register for the wake IRQ through dev_pm_set_dedicated_wake_irq() associates a wakeup IRQ with a device and requests it, but the PM core keeps the IRQ disabled by default. The IRQ is enabled by the PM core, only when the device is permitted to wake the system, i.e. during system suspend and after runtime suspend, and only when device wakeup is enabled. If the same WAKE# GPIO is described in multiple device tree nodes, only the first device that successfully registers the wake IRQ will succeed, while subsequent registrations may fail. This limitation does not affect functional correctness, since WAKE# is only used to bring the link to D0, and endpoint-specific wakeup handling is resolved later through PME detection (PME_EN is set in suspend path by PCI core by default). When the wake IRQ fires, the wakeirq handler invokes pm_runtime_resume() to bring the device back to an active power state, such as transitioning from D3cold to D0. Once the device is active and the link is usable, the endpoint may generate a PME, which is then handled by the PCI core through PME polling or the PCIe PME service driver to complete the wakeup of the endpoint. WAKE# is added in dts schema and merged based on below links. Link: https://lore.kernel.org/all/20250515090517.3506772-1-krishna.chundru@oss.qualcomm.com/ Link: devicetree-org/dt-schema#170 Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://lore.kernel.org/r/20260624-wakeirq_support-v11-1-120fbfaebe59@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
…r detach During driver detach, the device core holds the device mutex throughout the driver's remove callback chain. When the rpmsg endpoint is destroyed as part of that teardown, the GLINK endpoint destroy implementation attempts to unregister the underlying rpmsg device. That unregistration calls device_del(), which tries to re-acquire the same device mutex already held higher up the stack, causing rmmod to hang indefinitely. The deadlock manifests with the following call chain: [<0>] device_del+0x44/0x414 <- tries to acquire same mutex [<0>] device_unregister+0x18/0x34 [<0>] rpmsg_unregister_device+0x28/0x4c [<0>] qcom_glink_remove_rpmsg_device+0x70/0xc0 [<0>] qcom_glink_destroy_ept+0x58/0xbc [<0>] rpmsg_dev_remove+0x50/0x60 [<0>] device_remove+0x4c/0x80 [<0>] device_release_driver_internal+0x1cc/0x228 <- acquires device mutex [<0>] driver_detach+0x4c/0x98 [<0>] bus_remove_driver+0x6c/0xbc [<0>] driver_unregister+0x30/0x60 [<0>] unregister_rpmsg_driver+0x10/0x1c [<0>] fastrpc_exit+0x28/0x38 [fastrpc] [<0>] __arm64_sys_delete_module+0x1b8/0x294 [<0>] invoke_syscall+0x48/0x10c [<0>] el0_svc_common.constprop.0+0xc0/0xe0 [<0>] do_el0_svc+0x1c/0x28 [<0>] el0_svc+0x34/0x108 [<0>] el0t_64_sync_handler+0xa0/0xe4 [<0>] el0t_64_sync+0x198/0x19c The rpmsg device unregistration inside endpoint destroy is redundant. In both contexts where endpoint destruction is triggered: - Driver detach path: the driver core already tears down the rpmsg device. - Channel close path: the rpmsg device is already unregistered before endpoint destruction is reached. Remove the redundant unregistration to fix the deadlock. Co-developed-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com> Signed-off-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Fixes: a53e356 ("rpmsg: glink: fix rpmsg device leak") Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260604-rpmsg-glink-fix-deadlock-destroy-ept-v1-1-b8a54ad1e4fd@oss.qualcomm.com
…APIs ufs_qcom_enable_lane_clks() and ufs_qcom_disable_lane_clks() currently use clk_bulk_prepare_enable()/clk_bulk_disable_unprepare() on the entire host->clks array obtained from devm_clk_bulk_get_all(). This array contains all device clocks, not just lane symbol clocks. Since the UFS core framework already manages the non-lane clocks via the setup_clocks callback, the bulk enable/disable in the lane clock APIs resulted in duplicate reference count increments on those shared clocks. The extra enable counts were never balanced by a corresponding disable from the framework's clock gating path, preventing the clock reference counts from reaching zero and ultimately blocking CXO shutdown during low-power states. Fix this by restricting the lane clock APIs to only prepare/enable and disable/unprepare the three lane symbol clocks (tx_lane0_sync_clk, rx_lane0_sync_clk, rx_lane1_sync_clk), leaving the handling of all other clocks to the UFS core framewore. Link: https://lore.kernel.org/linux-scsi/20260713173434.883386-1-nitin.rawat@oss.qualcomm.com/ Signed-off-by: Nitin Rawat <nitin.rawat@oss.qualcomm.com> Signed-off-by: Giri Prasad Goriparthi <ggoripar@oss.qualcomm.com>
The ADSP PAS on several Qualcomm SoCs (e.g. SA8775P/lemans, QCS8300, Monaco) needs more than a single SMMU stream ID for the audio ML (machine-learning) offload use case. In addition to the primary ADSP stream ID, the DSP/SPF issues DMA transactions through extra stream IDs that are not covered by the existing single-entry mapping. Relax the iommus constraint to allow between 1 and 3 entries so the additional ML offload stream IDs can be described, fixing dtb_check schema violations on device trees that add them. Link: https://lore.kernel.org/all/20260717095825.3962666-2-pratyush.meduri@oss.qualcomm.com/ Signed-off-by: Pratyush Meduri <pratyush.meduri@oss.qualcomm.com>
…d SMMU mappings The audio ML (machine-learning) offload use case requires a contiguous, physically addressable buffer shared with the audio DSP/SPF, and issues DMA transactions through additional SMMU stream IDs that are not covered by the existing ADSP mapping. Add a dedicated reusable shared-dma-pool CMA region (16 MiB, 4 MiB aligned) and wire it to the q6apm DAIs node via memory-region. A dedicated pool guarantees the alignment and contiguity the DSP expects and isolates these allocations from the default CMA region. Under the EL2 (Gunyah/hypervisor) configuration the SMMU is fully enforcing, so the ML transactions are otherwise blocked and faulted: arm-smmu 15000000.iommu: Blocked unknown Stream ID 0x3060 arm-smmu 15000000.iommu: Blocked unknown Stream ID 0x3062 Add the ML-related stream IDs (0x3060 mask 0x9, 0x3062 mask 0x1) to the remoteproc_adsp iommus property in the EL2 overlay so these buffers are translated by the SMMU instead of being rejected. Link: https://lore.kernel.org/all/20260717095825.3962666-3-pratyush.meduri@oss.qualcomm.com/ Signed-off-by: Pratyush Meduri <pratyush.meduri@oss.qualcomm.com>
…d SMMU mappings The audio ML (machine-learning) offload use case requires a contiguous, physically addressable buffer shared with the audio DSP/SPF, and issues DMA transactions through additional SMMU stream IDs that are not covered by the existing ADSP mapping. Add a dedicated reusable shared-dma-pool CMA region (16 MiB, 4 MiB aligned) and wire it to the q6apm DAIs node via memory-region. A dedicated pool guarantees the alignment and contiguity the DSP expects and isolates these allocations from the default CMA region. Under the EL2 (Gunyah/hypervisor) configuration the SMMU is fully enforcing, so the ML transactions are otherwise blocked and faulted: arm-smmu 15000000.iommu: Blocked unknown Stream ID 0x2060 arm-smmu 15000000.iommu: Blocked unknown Stream ID 0x2062 Add the ML-related stream IDs (0x3060 mask 0x9, 0x3062 mask 0x1) to the remoteproc_adsp iommus property in the EL2 overlay so these buffers are translated by the SMMU instead of being rejected. Link: https://lore.kernel.org/all/20260717095825.3962666-4-pratyush.meduri@oss.qualcomm.com/ Signed-off-by: Pratyush Meduri <pratyush.meduri@oss.qualcomm.com>
This reverts commit e108373. This has been reported to break PCIe on at least SM8350 and Eliza platforms. I had originally tested this on Hamoa (X1E) where there were no adverse effects. It's highly likely that this stems from a difference in how the bootloader configures the clocks. Revert the offending change to fix the issue in the immediate, with the intent to revisit it in the upcoming cycle. Reported-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reported-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Fixes: e108373 ("clk: qcom: regmap-phy-mux: Rework the implementation") Closes: https://lore.kernel.org/all/c675lcfptr4xgg4hcjp66unmuozgsvgwvtymh7on6jcipjrdw7@jy4h7fkwqwjg/ Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
A wrong channel survey index was introduced in ath12k_mac_op_get_survey by [1], which can cause ACS to fail. The index is decremented before being used, resulting in an incorrect value when accessing the channel survey data. Fix the index handling to ensure the correct survey entry is used and avoid ACS failures. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Fixes: 4f242b1 ("wifi: ath12k: support get_survey mac op for single wiphy") # [1] Signed-off-by: Yingying Tang <yingying.tang@oss.qualcomm.com>
HAL_TLV_HDR_LEN was using the wrong bitmask; fix it to cover
bits [21:10]. Also drop HAL_SRNG_TLV_HDR_{TAG,LEN} and use the
generic TLV header bit definitions for TLV32/TLV64 encode/decode
to avoid redundant macros.
Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00068-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
Fixes: d889913 ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
Link: https://lore.kernel.org/linux-wireless/20260509025819.1641630-2-miaoqing.pan@oss.qualcomm.com/
Change TLV decode helpers to return the TLV value pointer and optionally decode tag/len/usrid via out parameters. This allows reusing the helpers for DP monitor RX status header TLV parsing and avoids duplicated header decoding in callers. No functional change intended. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00068-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: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com> Link: https://lore.kernel.org/linux-wireless/20260509025819.1641630-3-miaoqing.pan@oss.qualcomm.com/
… alignment Wi-Fi 7 monitor RX status TLV parsing needs to decode TLV headers and advance the pointer with the correct header alignment. Different targets use different TLV header layouts (32-bit vs 64-bit), but the HAL ops for dp_mon RX status header decode and header alignment were not populated for all wifi7 targets. Add dp_mon RX status TLV header decode callbacks and TLV header alignment helpers to the wifi7 HAL ops for QCC2072, QCN9274 and WCN7850. Export helpers to query the required TLV header alignment for 32-bit and 64-bit TLV headers so the caller can align the TLV walk correctly across targets. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00068-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: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com> Link: https://lore.kernel.org/linux-wireless/20260509025819.1641630-4-miaoqing.pan@oss.qualcomm.com/
Wi-Fi 7 monitor status parsing in dp_mon currently assumes a 64-bit TLV header and directly decodes tag/len/userid from struct hal_tlv_64_hdr. On chips using a 32-bit TLV header (e.g. QCC2072), this causes monitor RX status packets to be dropped during TLV parsing. Introduce HAL helpers to decode TLV header fields (tag/len/userid/value) for both 32-bit and 64-bit header layouts. Without changing the actual TLV parsing logic. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00068-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: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com> Link: https://lore.kernel.org/linux-wireless/20260509025819.1641630-5-miaoqing.pan@oss.qualcomm.com/
Validate the pointer to the next RX monitor TLV more strictly by ensuring that at least a full TLV header is available within the status buffer before continuing TLV parsing. Prevent potential out-of-bounds access when handling malformed or truncated RX monitor status data. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00068-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: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com> Link: https://lore.kernel.org/linux-wireless/20260509025819.1641630-6-miaoqing.pan@oss.qualcomm.com/
Export irq_can_set_affinity() for loadable drivers that need a runtime check for IRQ affinity capability. In hierarchical IRQ setups where the effective irqchip path lacks .irq_set_affinity(), drivers may need to switch to a fallback policy. Without this export, module drivers cannot use the core helper and have to open-code equivalent checks. Signed-off-by: Hangtian Zhu <hangtian.zhu@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260519011627.713068-1-hangtian.zhu@oss.qualcomm.com/
…unavailable Determine threaded NAPI policy from runtime IRQ capability of the DP MSI IRQ. If irq_can_set_affinity() reports that affinity cannot be set, enable threaded NAPI for DP interrupt groups so datapath processing is not constrained by a single-CPU softirq context. On RB3Gen2, where IRQ affinity is unavailable in the effective IRQ path, EHT160 UDP downlink throughput improved from 802 Mbps to 2.58 Gbps after enabling threaded NAPI. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00074-QCACOLSWPL_V1_TO_SILICONZ-1 Signed-off-by: Hangtian Zhu <hangtian.zhu@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260519011627.713068-1-hangtian.zhu@oss.qualcomm.com/
For WCN7850, MAC buffer ring size is updated to 2048 in 955df16 ("wifi: ath12k: change MAC buffer ring size to 2048") to increase peak throughput. But during the RX process, a phenomenon can still be observed where the throughput drops by about 30% from its peak value and then recovers, and this behavior repeats during RX. After increasing MAC buffer ring size to 4096, the data rate drop has gone. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Yingying Tang <yingying.tang@oss.qualcomm.com>
Commit [1] introduced a regression causing severely degraded MLO RX
throughput on WCN7850.
On WCN7850, there is only a single ar instance, but MLO uses two
link IDs. ath12k_dp_peer->hw_links[] is indexed using ar->hw_link_id,
which causes both MLO link IDs to be stored at the same index.
As a result, an incorrect link ID is assigned to MSDUs in
ath12k_dp_rx_deliver_msdu(), leading to severe MLO RX throughput loss.
Different chipsets identify the per-MSDU link differently:
- On QCN9274 / IPQ5332, the host owns multiple ar instances and the
per-MSDU hw_link_id from the RX descriptor maps cleanly through
dp_peer->hw_links[hw_link_id] to the IEEE link_id.
- On single-ar chipsets like WCN7850 / QCC2072, there is only one ar
instance for both MLO links, so dp_peer->hw_links[] has just one
valid slot and cannot be used to distinguish the two links. To
resolve the link, walk dp_peer->link_peers[] and match by
rxcb->peer_id, which on the link_peer side identifies the link
peer for the MSDU.
Add a new hw_op set_rx_link_id() so each chipset resolves the link
on the RX fast path using whatever signal it actually has, and let
the op itself decide whether to populate rx_status::link_valid and
rx_status::link_id:
QCN9274 / IPQ5332 : always derive link_id from
dp_peer->hw_links[rxcb->hw_link_id] and set
link_valid.
WCN7850 / QCC2072 : walk the link_peers[] of dp_peer to find the
link_peer whose peer_id matches rxcb->peer_id,
and set link_valid only when a match is found.
Otherwise leave link_valid clear so that
mac80211 can fall back to its own link
resolution path (via addr2 / deflink).
For WCN7850 / QCC2072, walking dp_peer->link_peers[] is bounded by
the number of links actually populated, so introduce a link_peers_map
bitmap (unsigned long) in struct ath12k_dp_peer that tracks populated
slots and use for_each_set_bit() to iterate. Non-MLO clients hit one
slot, current MLO clients hit two; the full ATH12K_NUM_MAX_LINKS
array is never scanned. The bitmap is maintained with WRITE_ONCE() on
the write side (under dp_hw->peer_lock) paired with READ_ONCE() on
both the lockless RX read side and the write-side RMW for KCSAN
correctness.
Also guard the dp_peer dereference in ath12k_mac_peer_cleanup_all()
with a NULL check, since peer->dp_peer can be NULL for self-peers or
peers not yet fully assigned, the pre-existing rcu_assign_pointer()
call there had the same latent issue.
This restores the correct link ID on WCN7850 without changing the
QCN9274 / IPQ5332 data path, which keeps its O(1) hw_links[]
indexing.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Fixes: 11157e0 ("wifi: ath12k: Use ath12k_dp_peer in per packet Tx & Rx paths") # [1]
Signed-off-by: Yingying Tang <yingying.tang@oss.qualcomm.com>
This reverts commit 8090556. Call trace: rcu_note_context_switch+0x4c4/0x508 (P) __schedule+0xbc/0x1204 schedule+0x34/0x110 schedule_timeout+0x84/0x11c __mhi_device_get_sync+0x164/0x228 [mhi] mhi_device_get_sync+0x1c/0x3c [mhi] ath12k_wifi7_pci_bus_wake_up+0x20/0x2c [ath12k_wifi7] ath12k_pci_read32+0x58/0x350 [ath12k] ath12k_pci_clear_dbg_registers+0x28/0xb8 [ath12k] ath12k_pci_panic_handler+0x20/0x44 [ath12k] ath12k_core_panic_handler+0x28/0x3c [ath12k] notifier_call_chain+0x78/0x1c0 atomic_notifier_call_chain+0x3c/0x5c ath12k_core_panic_handler() is invoked via atomic_notifier_call_chain(), which runs inside an RCU read-side critical section. The current code calls ath12k_pci_sw_reset() synchronously from this context, which eventually reaches mhi_device_get_sync() and schedule_timeout(), triggering a voluntary context switch within RCU. Revert change "wifi: ath12k: add panic handler" to avoid this issue. Tested-on: WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3 Link: https://lore.kernel.org/all/20260612032332.2278338-1-yingying.tang@oss.qualcomm.com/ Signed-off-by: Yingying Tang <yingying.tang@oss.qualcomm.com>
Commit afbab6e ("wifi: ath12k: modify ath12k_mac_op_bss_info_changed() for MLO") replaced the bss_info_changed() callback with vif_cfg_changed() and link_info_changed() to support Multi-Link Operation (MLO). As a result, the station power save configuration is no longer correctly applied in ath12k_mac_bss_info_changed(). Move the handling of 'BSS_CHANGED_PS' into ath12k_mac_op_vif_cfg_changed() to align with the updated callback structure introduced for MLO, ensuring proper power-save behavior for station interfaces. Tested-on: WCN7850 hw2.0 PCI WLAN.IOE_HMT.1.1-00011-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Fixes: afbab6e ("wifi: ath12k: modify ath12k_mac_op_bss_info_changed() for MLO") Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com> Link: https://lore.kernel.org/all/20250908015025.1301398-1-miaoqing.pan@oss.qualcomm.com/ Signed-off-by: Daizhuang Bai <daizhuang.bai@oss.qualcomm.com>
…ng_access_begin In ATH11K_QMI_EVENT_FW_READY, ATH11K_FLAG_REGISTERED is set unconditionally even when ath11k_core_qmi_firmware_ready() fails. This leaves the driver in an inconsistent state where initialization is considered complete although the firmware ready handling did not finish successfully. During the subsequent SSR, the driver enters the restart path based on this incorrect state and dereferences uninitialized srng members, resulting in a NULL pointer dereference. Call trace: ath11k_hal_srng_access_begin+0xc/0x60 [ath11k] (P) ath11k_ce_cleanup_pipes+0x17c/0x180 [ath11k] ath11k_core_restart+0x40/0x168 [ath11k] Fix this by: - skipping firmware_ready if ATH11K_FLAG_REGISTERED is already set - setting ATH11K_FLAG_REGISTERED only when firmware_ready succeeds - setting ATH11K_FLAG_QMI_FAIL and aborting the FW_READY handling on error Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1 Fixes: 6fe62a8 ("wifi: ath11k: Add cold boot calibration support on WCN6750") Signed-off-by: Gaole Zhang <gaole.zhang@oss.qualcomm.com> Link: https://lore.kernel.org/linux-wireless/20260609090609.4041009-1-gaole.zhang@oss.qualcomm.com/
# Conflicts: # drivers/remoteproc/qcom_q6v5_pas.c
# Conflicts: # Makefile
# Conflicts: # arch/arm64/boot/dts/qcom/monaco-evk.dts # arch/arm64/boot/dts/qcom/monaco.dtsi
# Conflicts: # Makefile
# Conflicts: # arch/arm64/boot/dts/qcom/Makefile # arch/arm64/boot/dts/qcom/talos.dtsi
# Conflicts: # arch/arm64/boot/dts/qcom/qcs8300-ride.dts # drivers/bluetooth/hci_qca.c # drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
# Conflicts: # drivers/firmware/qcom/Kconfig # drivers/firmware/qcom/Makefile
# Conflicts: # drivers/dma/qcom/bam_dma.c # drivers/misc/fastrpc.c # sound/soc/qcom/qdsp6/q6prm.h # sound/soc/qcom/sc8280xp.c
# Conflicts: # Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml
Adding merge log file and topic_SHA1 file Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
Test jobs on 4e02c94 |
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
20 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.
Name SHA Commits
tech/bsp/clk d8a14b9 30
tech/bsp/devfreq 5a26797 7
tech/security/firmware-smc de7413c 6
tech/bsp/soc-infra ff6ff7b 22
tech/bsp/pinctrl 79149ef 1
tech/bsp/remoteproc 39a86aa 13
tech/bus/peripherals fedd8c6 6
tech/bus/pci/all 6f0678f 42
tech/bus/pci/phy 66e44c2 14
tech/bus/usb/dwc 9dd47ad 3
tech/bus/usb/phy c3aa7d5 35
tech/debug/hwtracing d9accac 22
tech/pmic/misc bf8b27d 11
tech/mem/iommu 44df12a 8
tech/mm/audio/all 88b8f29 8
tech/mm/camss c394dfb 32
tech/mm/drm 814ffbc 66
tech/mm/fastrpc d167cb0 12
tech/mm/video bad0a97 39
tech/mm/gpu 0b8d9f4 7
tech/mproc/rpmsg 55dc464 1
tech/net/ath 1d97562 25
tech/net/bluetooth 33aa6a3 1
tech/pm/power bb88701 13
tech/pm/thermal 9fdfd80 12
tech/security/crypto c36112e 14
tech/security/ice beabac0 9
tech/storage/all cef1b3c 5
tech/all/dt/qcs6490 d7b9924 22
tech/all/dt/qcs9100 f75b90a 90
tech/all/dt/qcs8300 251e0b5 23
tech/all/dt/qcs615 9a58c35 9
tech/all/dt/agatti c828f10 1
tech/all/dt/eliza a80579c 22
tech/all/dt/hamoa 527ae65 40
tech/all/dt/glymur b8ca7ea 48
tech/all/dt/kaanapali 7614025 20
tech/all/dt/pakala 960924d 13
tech/all/config 9cc27aa 71
tech/overlay/dt 6a1064f 77
tech/all/workaround db439fb 20
tech/mproc/all 104969c 2
tech/noup/debug/all cbdd4bb 26
tech/hwe/unoq a2d85fe 4
early/hwe/shikra/drivers 87e9172 182
early/hwe/shikra/dt 6a36c4b 129