Prepare qcom-next based on tag 'Linux 6.19-rc5' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #171
+68,791
−1,737
Conversation
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
Replace the hardcoded context ID mask (0xFF0) with GENMASK(11, 4) to improve readability and follow kernel bitfield conventions. Use FIELD_PREP and FIELD_GET instead of manual shifts for setting and extracting ctxid values. Link: https://lore.kernel.org/r/20251128050534.437755-3-ekansh.gupta@oss.qualcomm.com Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
…support Current FastRPC message context uses a 12-bit mask where the upper 8 bits represent the context ID from idr_alloc_cyclic and the lower 4 bits represent the PD type. This layout works for normal FastRPC calls but fails for polling mode because DSP expects a 16-bit context with an additional async mode bit. To enable polling mode support from DSP(DSP writes to poll memory), DSP expects a 16-bit context where the upper 8 bits are context ID, the lower 4 bits are PD type and the 5th bit from the end denotes async mode(not yet upstreamed). If this bit is set, DSP disables polling. With the current design, odd context IDs set this bit, causing DSP to skip poll memory updates. Update the context mask to ensure a hole which won't get populated, ensuring polling mode works as expected. This is not a bug and the change is added to support polling mode. Link: https://lore.kernel.org/r/20251128050534.437755-4-ekansh.gupta@oss.qualcomm.com Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
For any remote call to DSP, after sending an invocation message, fastRPC driver waits for glink response and during this time the CPU can go into low power modes. This adds latency to overall fastrpc call as CPU wakeup and scheduling latencies are included. Add polling mode support with which fastRPC driver will poll continuously on a memory after sending a message to remote subsystem which will eliminate CPU wakeup and scheduling latencies and reduce fastRPC overhead. Poll mode can be enabled by user by using FASTRPC_IOCTL_SET_OPTION ioctl request with FASTRPC_POLL_MODE request id. Link: https://lore.kernel.org/r/20251128050534.437755-5-ekansh.gupta@oss.qualcomm.com Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
…hy bindings for qcs8300 The gcc_aux_clk is not required by the PCIe PHY on qcs8300 and is not specified in the device tree node. Hence, move the qcs8300 phy compatibility entry into the list of PHYs that require six clocks. Removed the phy_aux clock from the PCIe PHY binding as it is no longer used by any instance. Link: https://lore.kernel.org/all/20251024095609.48096-2-ziyue.zhang@oss.qualcomm.com/ Fixes: e46e59b ("dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Document the QCS8300 QMP PCIe PHY Gen4 x2") Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
…en4 2-lanes PHY The fourth and sixth PCIe instances on Glymur are both Gen4 2-lane PHY. So document the compatible. Link: https://lore.kernel.org/all/20251015-phy-qcom-pcie-add-glymur-v1-1-1af8fd14f033@linaro.org/ Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Glymur platform has two Gen4 2-lanes controllers, the fourth and sixth instances. Add support for their PHYs. Link: https://lore.kernel.org/all/20251015-phy-qcom-pcie-add-glymur-v1-2-1af8fd14f033@linaro.org/ Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
On the Qualcomm Glymur platform the PCIe host is compatible with the DWC controller present on the X1E80100 platform. So document the PCIe controllers found on Glymur and use the X1E80100 compatible string as a fallback in the schema. Link: https://lore.kernel.org/all/20251017-glymur_pcie-v5-3-82d0c4bd402b@oss.qualcomm.com/ Signed-off-by: Prudhvi Yarlagadda <quic_pyarlaga@quicinc.com> Signed-off-by: Wenbin Yao <wenbin.yao@oss.qualcomm.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
Add a compatible for the Power Domain Controller on Kaanapali platforms. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20251021-knp-pdc-v2-1-a38767f5bb8e@oss.qualcomm.com
…ali QMP PHY Document QMP combo PHY for Kaanapali. Use fallback to indicate the compatibility of the QMP PHY on the Kaanapali with that on the SM8750. Signed-off-by: Ronak Raheja <ronak.raheja@oss.qualcomm.com> Co-developed-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/linux-usb/20251021-knp-usb-v2-1-a2809fffcfab@oss.qualcomm.com/
…Y for Kaanapali Document M31 eUSB2 PHY for Kaanapali which handles the USB2 path. Use fallback to indicate the compatibility of the M31 eUSB2 PHY on the Kaanapali with that on the SM8750. Signed-off-by: Ronak Raheja <ronak.raheja@oss.qualcomm.com> Co-developed-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/linux-usb/20251021-knp-usb-v2-2-a2809fffcfab@oss.qualcomm.com/
… compatible Define a Glymur compatible string for the QMP combo PHY, along with resource requirements. Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Wesley Cheng <wesley.cheng@oss.qualcomm.com> Link: https://lore.kernel.org/all/20251209-linux-next-12825-v8-1-42133596bda0@oss.qualcomm.com/
…atible The Glymur USB subsystem contains a multiport controller, which utilizes two QMP UNI PHYs. Add the proper compatible string for the Glymur SoC, and the required clkref clock name. Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Wesley Cheng <wesley.cheng@oss.qualcomm.com> Link: https://lore.kernel.org/all/20251209-linux-next-12825-v8-2-42133596bda0@oss.qualcomm.com/
Add the Glymur compatible to the M31 eUSB2 PHY, and use the SM8750 as the fallback. Signed-off-by: Wesley Cheng <wesley.cheng@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/all/20251209-linux-next-12825-v8-3-42133596bda0@oss.qualcomm.com/
…patible Add the compatible string for identifying a SMB2370 USB repeater device. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Wesley Cheng <wesley.cheng@oss.qualcomm.com> Link: https://lore.kernel.org/all/20251209-linux-next-12825-v8-4-42133596bda0@oss.qualcomm.com/
…upport Introduce support for the SMB2370 based eUSB2 repeater. Configure the proper repeater tuning settings, as if this is not done correctly, it can lead to instability on the USB2 link, which leads to USB2 enumeration failures, or random disconnects. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Wesley Cheng <wesley.cheng@oss.qualcomm.com> Link: https://lore.kernel.org/all/20251209-linux-next-12825-v8-5-42133596bda0@oss.qualcomm.com/
Glymur contains a USB multiport controller which supports a QMP UNI PHY. These ports do not have typeC capability, so it needs to be differentiated in this manner. Update the QMP PHY sequence required to bring up the UNI PHY for Glymur. The UNI PHY follows mostly the same register field definitions as previous SoCs. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Wesley Cheng <wesley.cheng@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/all/20251209-linux-next-12825-v8-6-42133596bda0@oss.qualcomm.com/
QMP combo phy V6 and above use the clamp register from the PCS always on (AON) address space. Update the driver accordingly. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Elson Roy Serrao <quic_eserrao@quicinc.com> Signed-off-by: Wesley Cheng <wesley.cheng@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/all/20251209-linux-next-12825-v8-7-42133596bda0@oss.qualcomm.com/
For SuperSpeed USB to work properly, there is a set of HW settings that need to be programmed into the USB blocks within the QMP PHY. Ensure that these settings follow the latest settings mentioned in the HW programming guide. The QMP USB PHY on Glymur is a USB43 based PHY that will have some new ways to define certain registers, such as the replacement of TXA/RXA and TXB/RXB register sets. This was replaced with the LALB register set. There are also some PHY init updates to modify the PCS MISC register space. Without these, the QMP PHY PLL locking fails. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Wesley Cheng <wesley.cheng@oss.qualcomm.com> Link: https://lore.kernel.org/all/20251209-linux-next-12825-v8-8-42133596bda0@oss.qualcomm.com/
…lymur platforms Starting with Glymur, the PCIe and DP PHYs qserdes register offsets differ for the same version number. So in order to be able to differentiate between them, add these ones with DP prefix. Add the necessary PHY setting tables for enabling the DP path within the QMP subsystem. Introduced some new callbacks for v8 specific sequences, such as for clock configurations based on the different link speeds. Wesley Cheng added some updated settings from the hardware programming guides on existing PHY tables and clock settings. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Co-developed-by: Wesley Cheng <wesley.cheng@oss.qualcomm.com> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Wesley Cheng <wesley.cheng@oss.qualcomm.com> Link: https://lore.kernel.org/all/20251209-linux-next-12825-v8-9-42133596bda0@oss.qualcomm.com/
Two platform-data fields for SM8750 were missed:
- get_vpu_buffer_size = iris_vpu33_buf_size
Without this, the driver fails to allocate the required internal
buffers, leading to basic decode/encode failures during session
bring-up.
- max_core_mbps = ((7680 * 4320) / 256) * 60
Without this capability exposed, capability checks are incomplete and
v4l2-compliance for encoder fails.
Link: https://lore.kernel.org/linux-media/20251218-iris-sm8750-fix-v1-1-9a6df5cd6fd3@oss.qualcomm.com/
Fixes: a5925a2 ("media: iris: add VPU33 specific encoding buffer calculation")
Fixes: a688243 ("media: iris: Add support for ENUM_FRAMESIZES/FRAMEINTERVALS for encoder")
Cc: stable@vger.kernel.org
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
…e configuration The QCS6490 rb3gen2 board uses the same Qualcomm QCM6490 platform but has a different thermal junction temperature specification due to package-level differences. Update passive/hot trip thresholds to 105°C and critical trip thresholds to 115°C for various subsystem TSENS sensors. Disable CPU cooling maps for CPU TSENS since CPU thermal mitigation is handled automatically in hardware on this board. Signed-off-by: Manaf Meethalavalappu Pallikunhi <manaf.pallikunhi@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251215105934.2428987-1-manaf.pallikunhi@oss.qualcomm.com
Most modern Qualcomm platforms (>= SM8150) expose information about the DDR memory present on the system via SMEM. Details from this information is used in various scenarios, such as multimedia drivers configuring the hardware based on the "Highest Bank address Bit" (hbb), or the list of valid frequencies in validation scenarios... Add support for parsing v3-v5 version of the structs. Unforunately, they are not versioned, so some elbow grease is necessary to determine which one is present. See for reference: v3: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/1d11897d2cfcc7b85f28ff74c445018dbbecac7a v4: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/f6e9aa549260bbc0bdcb156c2b05f48dc5963203 v5: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/blob/uefi.lnx.4.0.r31-rel/QcomModulePkg/Include/Protocol/DDRDetails.h?ref_type=heads Link: https://lore.kernel.org/r/20250410-topic-smem_dramc-v2-1-dead15264714@oss.qualcomm.com Reviewed-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
Add the camera DT binding header, which will be utilized by the camera downstream drivers and DTSI files. Signed-off-by: Chandan Kumar Jha <cjha@qti.qualcomm.com>
Add CAMX overlay dts file for lemans boards. This change also enables the compilation of the CAMX overlay on Lemans boards. Co-developed-by: Vikram Sharma <vikramsa@qti.qualcom.com> Signed-off-by: Vikram Sharma <vikramsa@qti.qualcomm.com> Signed-off-by: Chandan Kumar Jha <cjha@qti.qualcomm.com>
Add CAMX overlay dts file for rb3gen2 vision mezzanine board. This change also enables the compilation of the CAMX overlay for Kodiak rb3gen2 vision mezzanine board. Signed-off-by: Chandan Kumar Jha <cjha@qti.qualcomm.com>
Add CAMX overlay dts file for Monaco boards. This change also enables the compilation of the CAMX overlay for Monaco boards. Signed-off-by: Chandan Kumar Jha <cjha@qti.qualcomm.com>
The camera firmware size for IoT variant qcs8300 SoC is more than 5MB. Update the PIL memory region size of camera to 7MB to accomodate the same. Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
- Fix the indentation issue. Signed-off-by: Chandan Kumar Jha <cjha@qti.qualcomm.com>
- Fix the indentation issue. - Update DT clock property name after clock. - Short DT nodes. - Fix indexing issue. - Update gpios shared pin. Signed-off-by: Chandan Kumar Jha <cjha@qti.qualcomm.com>
- Fix the indentation issue. - Update DT clock property name after clock. - Shorted DT nodes. Signed-off-by: Chandan Kumar Jha <cjha@qti.qualcomm.com>
# Conflicts: # arch/arm64/boot/dts/qcom/Makefile # arch/arm64/boot/dts/qcom/talos.dtsi
# Conflicts: # include/linux/firmware/qcom/qcom_scm.h
Adding merge log file and topic_SHA1 file Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
sgaud-quic
pushed a commit
that referenced
this pull request
Jan 20, 2026
When loading guest XSAVE state via KVM_SET_XSAVE, and when updating XFD in response to a guest WRMSR, clear XFD-disabled features in the saved (or to be restored) XSTATE_BV to ensure KVM doesn't attempt to load state for features that are disabled via the guest's XFD. Because the kernel executes XRSTOR with the guest's XFD, saving XSTATE_BV[i]=1 with XFD[i]=1 will cause XRSTOR to #NM and panic the kernel. E.g. if fpu_update_guest_xfd() sets XFD without clearing XSTATE_BV: ------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#29: amx_test/848 Modules linked in: kvm_intel kvm irqbypass CPU: 29 UID: 1000 PID: 848 Comm: amx_test Not tainted 6.19.0-rc2-ffa07f7fd437-x86_amx_nm_xfd_non_init-vm #171 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:exc_device_not_available+0x101/0x110 Call Trace: <TASK> asm_exc_device_not_available+0x1a/0x20 RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90 switch_fpu_return+0x4a/0xb0 kvm_arch_vcpu_ioctl_run+0x1245/0x1e40 [kvm] kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x62/0x940 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]--- This can happen if the guest executes WRMSR(MSR_IA32_XFD) to set XFD[18] = 1, and a host IRQ triggers kernel_fpu_begin() prior to the vmexit handler's call to fpu_update_guest_xfd(). and if userspace stuffs XSTATE_BV[i]=1 via KVM_SET_XSAVE: ------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#14: amx_test/867 Modules linked in: kvm_intel kvm irqbypass CPU: 14 UID: 1000 PID: 867 Comm: amx_test Not tainted 6.19.0-rc2-2dace9faccd6-x86_amx_nm_xfd_non_init-vm #168 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:exc_device_not_available+0x101/0x110 Call Trace: <TASK> asm_exc_device_not_available+0x1a/0x20 RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90 fpu_swap_kvm_fpstate+0x6b/0x120 kvm_load_guest_fpu+0x30/0x80 [kvm] kvm_arch_vcpu_ioctl_run+0x85/0x1e40 [kvm] kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x62/0x940 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]--- The new behavior is consistent with the AMX architecture. Per Intel's SDM, XSAVE saves XSTATE_BV as '0' for components that are disabled via XFD (and non-compacted XSAVE saves the initial configuration of the state component): If XSAVE, XSAVEC, XSAVEOPT, or XSAVES is saving the state component i, the instruction does not generate #NM when XCR0[i] = IA32_XFD[i] = 1; instead, it operates as if XINUSE[i] = 0 (and the state component was in its initial state): it saves bit i of XSTATE_BV field of the XSAVE header as 0; in addition, XSAVE saves the initial configuration of the state component (the other instructions do not save state component i). Alternatively, KVM could always do XRSTOR with XFD=0, e.g. by using a constant XFD based on the set of enabled features when XSAVEing for a struct fpu_guest. However, having XSTATE_BV[i]=1 for XFD-disabled features can only happen in the above interrupt case, or in similar scenarios involving preemption on preemptible kernels, because fpu_swap_kvm_fpstate()'s call to save_fpregs_to_fpstate() saves the outgoing FPU state with the current XFD; and that is (on all but the first WRMSR to XFD) the guest XFD. Therefore, XFD can only go out of sync with XSTATE_BV in the above interrupt case, or in similar scenarios involving preemption on preemptible kernels, and it we can consider it (de facto) part of KVM ABI that KVM_GET_XSAVE returns XSTATE_BV[i]=0 for XFD-disabled features. Reported-by: Paolo Bonzini <pbonzini@redhat.com> Cc: stable@vger.kernel.org Fixes: 820a6ee ("kvm: x86: Add emulation for IA32_XFD", 2022-01-14) Signed-off-by: Sean Christopherson <seanjc@google.com> [Move clearing of XSTATE_BV from fpu_copy_uabi_to_guest_fpstate to kvm_vcpu_ioctl_x86_set_xsave. - Paolo] Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
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 567d776 19
tech/security/firmware-smc a50984a 2
tech/bsp/soc-infra 2949741 9
tech/bsp/remoteproc 27311a4 15
tech/bus/peripherals 486bcf7 1
tech/bus/pci/all 2fdd372 9
tech/bus/usb/dwc 49ac8e0 2
tech/bus/usb/phy 9e7d778 13
tech/debug/hwtracing 88c50d8 27
tech/pmic/misc 91e88b9 16
tech/pmic/regulator 81fc8fb 6
tech/mem/iommu 486a41c 2
tech/mm/audio/all ce10fd3 4
tech/mm/camss d1d2c38 3
tech/mm/drm 9bb86be 28
tech/mm/fastrpc 844e24f 4
tech/mm/video 4871417 16
tech/mm/gpu 1651b6d 5
tech/mproc/rpmsg c3875d9 1
tech/net/ath dd2aee0 20
tech/net/eth c280d7e 1
tech/net/bluetooth ee968c9 3
tech/pm/power 7b7e779 7
tech/pm/thermal 363f414 3
tech/security/crypto fa6b06a 11
tech/storage/all ba8c93d 6
tech/all/dt/qcs6490 87b5b8c 7
tech/all/dt/qcs9100 d8bc255 14
tech/all/dt/qcs8300 03de422 27
tech/all/dt/qcs615 648a531 11
tech/all/dt/hamoa 4c89453 11
tech/all/dt/glymur b6ddb1f 27
tech/all/dt/kaanapali 15ce26e 6
tech/all/dt/pakala b4ebc9f 9
tech/all/config d2f2062 35
tech/overlay/dt 50f2b36 15
tech/all/workaround ec47ebe 3
tech/mproc/all d19a4c1 5
tech/noup/debug/all 1c86d19 5