Test PR: Make UFS Static - #61
Open
sgaud-quic wants to merge 634 commits into
Open
Conversation
This reverts commit 09ed0b6. Issue is observed with this commit 09ed0b6 leading to crash, with following call stack [ 19.706310][ T73] Call trace: [ 19.706312][ T73] usb_role_switch_unregister+0x28/0x70 (P) [ 19.706319][ T73] eud_role_switch_release+0x30/0x78 [qcom_eud] [ 19.884972][ T73] devm_action_release+0x1c/0x30 [ 19.884981][ T73] release_nodes+0x70/0x120 [ 19.884987][ T73] devres_release_all+0x98/0xf0 [ 19.884995][ T73] device_unbind_cleanup+0x20/0x98 [ 19.885000][ T73] really_probe+0x184/0x3f0 [ 19.885005][ T73] __driver_probe_device+0x88/0x190 [ 19.885010][ T73] driver_probe_device+0x44/0x120 [ 19.885015][ T73] __device_attach_driver+0xc4/0x178 [ 19.885020][ T73] bus_for_each_drv+0x90/0xf8 [ 19.885027][ T73] __device_attach+0xa8/0x1d8 [ 19.885032][ T73] device_initial_probe+0x58/0x68 [ 19.885037][ T73] bus_probe_device+0x40/0xb8 [ 19.885041][ T73] deferred_probe_work_func+0xbc/0x128 [ 19.885046][ T73] process_one_work+0x180/0x450 [ 19.885055][ T73] worker_thread+0x26c/0x388 [ 19.885062][ T73] kthread+0x120/0x140 [ 19.885068][ T73] ret_from_fork+0x10/0x20 [ 19.885079][ T73] Code: f9000bf3 aa0003f3 b140041f 54000168 (390c901f) [ 19.885083][ T73] ---[ end trace 0000000000000000 ]--- [ 19.885088][ T73] Kernel panic - not syncing: Oops: Fatal exception [ 19.885091][ T73] SMP: stopping secondary CPUs Revert commit for now. Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
… block The APSS debug block is built with CoreSight devices like ETM, replicator, funnel and TMC ETF. Add dt nodes for these devices to enable ETM trace. Link: https://lore.kernel.org/all/20251218-cpu_cluster_component_pm-v2-12-2335a6ae62a0@oss.qualcomm.com/ Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com> Co-developed-by: Yuanfang Zhang <yuanfang.zhang@oss.qualcomm.com> Signed-off-by: Yuanfang Zhang <yuanfang.zhang@oss.qualcomm.com>
Embedded Trace Router(ETR) is working as a DDR memory sink to collect tracing data from source device. The CTCU serves as the control unit for the ETR device, managing its behavior to determine how trace data is collected. Link: https://lore.kernel.org/all/20260204-enable-ctcu-and-etr-v3-2-0bb95c590ae1@oss.qualcomm.com/ Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
Document the device tree bindings for the PURWA-IOT-EVK board, which uses the Qualcomm X1P42100 SoC. Link: https://lore.kernel.org/all/20260202073555.1345260-1-yijie.yang@oss.qualcomm.com/ Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
Add the Purwa-IoT-EVK board to the list to enable access to EFI variables. Guarantee that subsystems relying on SCM services can access secure-world features. This change improves reliability and prevents missing functionality or boot-time issues by making service availability explicit. Link: https://lore.kernel.org/all/20260202073555.1345260-2-yijie.yang@oss.qualcomm.com/ Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
The PURWA-IOT-SOM is a compact computing module that integrates a System on Chip (SoC) — specifically the x1p42100 — along with essential components optimized for IoT applications. It is designed to be mounted on carrier boards, enabling the development of complete embedded systems. Purwa uses a slightly different Iris HW revision (8.1.2 on Hamoa, 8.1.11 on Purwa). Support will be added later. Make the following peripherals on the SOM enabled: - Regulators on the SOM - Reserved memory regions - PCIe3, PCIe4, PCIe5, PCIe6a - USB0 through USB6 and their PHYs - ADSP, CDSP - Graphic Link: https://lore.kernel.org/all/20260202073555.1345260-3-yijie.yang@oss.qualcomm.com/ Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
The PURWA-IOT-EVK is an evaluation platform for IoT products, composed of the Purwa IoT SoM and a carrier board. Together, they form a complete embedded system capable of booting to UART. PURWA-IOT-EVK uses the PS8833 as a retimer for USB0, unlike HAMOA-IOT-EVK. Meanwhile, USB0 bypasses the SBU selector FSUSB42. Make the following peripherals on the carrier board enabled: - UART - On-board regulators - USB Type-C mux - Pinctrl - Embedded USB (EUSB) repeaters - NVMe - pmic-glink - USB DisplayPorts - Bluetooth - WLAN - Audio - PCIe ports for PCIe3 through PCIe6a - TPM Link: https://lore.kernel.org/all/20260202073555.1345260-4-yijie.yang@oss.qualcomm.com/ Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
Add UFS host controller and PHY nodes for x1e80100 SoC. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Pradeep P V K <pradeep.pragallapati@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260211132926.3716716-1-pradeep.pragallapati@oss.qualcomm.com
Enable UFS for HAMOA-IOT-EVK board. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Pradeep P V K <pradeep.pragallapati@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260211132926.3716716-1-pradeep.pragallapati@oss.qualcomm.com
…t evk board Enable SD Card host controller for hamoa iot evk board. Link: https://lore.kernel.org/all/20260211093045.2595126-1-sarthak.garg@oss.qualcomm.com/ Signed-off-by: Sarthak Garg <sarthak.garg@oss.qualcomm.com> Signed-off-by: Pradeep P V K <pradeep.pragallapati@oss.qualcomm.com>
Add DAI links for DP0 and DP1 playback and set sound-name-prefix for both DisplayPort endpoints in the hamoa-evk DTS. Link: https://lore.kernel.org/all/20260209091139.622756-1-le.qi@oss.qualcomm.com/ Signed-off-by: Le Qi <le.qi@oss.qualcomm.com> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
Add the CAMCC block for x1e80100. The x1e80100 CAMCC block is an iteration of previous CAMCC blocks with the exception of having two required power-domains not just one. Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260128-purwa-videocc-camcc-v1-6-b23de57df5ba@oss.qualcomm.com
…odes on purwa Update the compatible for videocc and camcc nodes to match with their respective purwa(X1P42100) specific drivers. Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260128-purwa-videocc-camcc-v1-7-b23de57df5ba@oss.qualcomm.com
Enable passive cooling for CPUs in the X1E80100 SoC by adding the '#cooling-cells' property. This will allow the OS to mitigate the CPU power dissipation with the help of SCMI DVFS. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Tested-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260210070321.17033-1-manivannan.sadhasivam@oss.qualcomm.com
Add support for SYSTEM_RESET2 vendor-specific resets as reboot-modes in the psci node. Describe the resets: "bootloader" will cause device to reboot and stop in the bootloader's fastboot mode. "edl" will cause device to reboot into "emergency download mode", which permits loading images via the Firehose protocol. Signed-off-by: Xin Liu <xin.liu@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260226054113.4156874-1-xin.liu@oss.qualcomm.com/
Add support for building an EL2 combined DTB for the hamoa-evk in the Qualcomm DTS Makefile. The new hamoa-iot-evk-el2.dtb is generated by combining the base hamoa-iot-evk.dtb with the x1-el2.dtbo overlay, enabling EL2-specific configurations required by the platform. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Xin Liu <xin.liu@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260127062425.1084673-1-xin.liu@oss.qualcomm.com/
…e trees All the existing variants Hamoa boards are using Gunyah hypervisor which means that, so far, Linux-based OS could only boot in EL1 on those devices. However, it is possible for us to boot Linux at EL2 on these devices [1]. When running under Gunyah, the remote processor firmware IOMMU streams are controlled by Gunyah. However, without Gunyah, the IOMMU is managed by the consumer of this DeviceTree. Therefore, describe the firmware streams for each remote processor. Add remoteproc IOMMUS to the EL2 device trees to generate the corresponding -el2.dtb files. [1] https://docs.qualcomm.com/bundle/publicresource/topics/80-70020-4/boot-developer-touchpoints.html#uefi Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Xin Liu <xin.liu@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260203063244.1498699-1-xin.liu@oss.qualcomm.com/
Add in two CCI buses. One bus has two CCI bus master pinouts: cci_i2c_sda0 = gpio101 cci_i2c_scl0 = gpio102 cci_i2c_sda1 = gpio103 cci_i2c_scl1 = gpio104 The second bus has two CCI bus master pinouts: cci_i2c_sda2 = gpio105 cci_i2c_scl2 = gpio106 aon_cci_i2c_sda3 = gpio235 aon_cci_i2c_scl3 = gpio236 Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org> Tested-by: Christopher Obbard <christopher.obbard@linaro.org> Link: https://lore.kernel.org/all/20260226-x1e-camss-csi2-phy-dtsi-v1-2-f3f7ddfbf849@linaro.org/
Add csiphy nodes for - csiphy0 - csiphy1 - csiphy2 - csiphy4 The irregular naming of the PHYs comes directly from the hardware which for whatever reason skipped csiphy3. Separating the nodes from CAMSS as we have done with the sensor I2C bus aka the CCI interface is justified since the CSIPHYs have their own pinouts and voltage rails. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org> Tested-by: Christopher Obbard <christopher.obbard@linaro.org> Link: https://lore.kernel.org/all/20260226-x1e-camss-csi2-phy-dtsi-v1-3-f3f7ddfbf849@linaro.org/
Add dtsi to describe the xe180100 CAMSS block 4 x CSIPHY 3 x TPG 2 x CSID 2 x CSID Lite 2 x IFE 2 x IFE Lite Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/all/20260226-x1e-camss-csi2-phy-dtsi-v1-4-f3f7ddfbf849@linaro.org/
…gulators Add pmic,id = m rpmh to regulator definitions. This regulator set provides vreg_l3m_1p8 the regulator for the ov08x40 RGB sensor on the CRD. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org> Link: https://lore.kernel.org/all/20260226-x1e-camss-csi2-phy-dtsi-v1-5-f3f7ddfbf849@linaro.org/
…SIPHY4 Define ov08x40 on cci1_i2c1. The RGB sensor appears on the AON CCI pins connected to CSIPHY4 in four lane mode. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org> Link: https://lore.kernel.org/all/20260226-x1e-camss-csi2-phy-dtsi-v1-6-f3f7ddfbf849@linaro.org/
…h voltage levels for IR and RGB camera Add the PM8010 PMIC providing the following voltage rails: vreg_l1m_r @ 1v2 IR sensor vreg_l2m_r @ 1v2 RGB sensor vreg_l3m_r @ 1v8 IR sensor vreg_l4m_r @ 1v8 RGB sensor vreg_l5m_r @ 2v8 IR sensor vreg_l7m_r @ 2v8 RGB sensor Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/all/20260226-x1e-camss-csi2-phy-dtsi-v1-7-f3f7ddfbf849@linaro.org/
…on CSIPHY4 Switch on the ov02c10 RGB sensor on CSIPHY4. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org> Tested-by: Christopher Obbard <christopher.obbard@linaro.org> Link: https://lore.kernel.org/all/20260226-x1e-camss-csi2-phy-dtsi-v1-8-f3f7ddfbf849@linaro.org/
…amera PMIC with voltage levels for IR and RGB camera Add voltage regulators-8 for Camera on slim7x including: - vreg_l7m_2p8 - vreg_l2m_1p2 - vreg_l4m_1p8 Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Christopher Obbard <christopher.obbard@linaro.or> Link: https://lore.kernel.org/all/20260226-x1e-camss-csi2-phy-dtsi-v1-9-f3f7ddfbf849@linaro.org/
Add pm8010 L4M regulator which is used by Camera I2C pull-up. Signed-off-by: Tingguo Cheng <tingguo.cheng@oss.qualcomm.com> Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260227-hamoa_evk-v1-1-36f895a24d8f@oss.qualcomm.com/
Enable IMX577 via CCI on Hamoa EVK Core Kit. The Hamoa EVK board does not include a camera sensor by default, this DTSO has enabled the Arducam 12.3MP IMX577 Mini Camera Module on the CSI-1 interface. Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260227-hamoa_evk-v1-2-36f895a24d8f@oss.qualcomm.com/
…configuration Hamoa IOT boards support a different thermal junction temperature specification compared to the base Hamoa platform due to package level differences. Update the passive trip thresholds to 105°C to align with the higher temperature specification. Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/linux-devicetree/20260302-higher_tj-v1-1-4c0d288f8e7f@oss.qualcomm.com/
Add CoreSight nodes to enable trace paths like TPDM->ETF/STM->ETF. These devices are part of the AOSS, CDSP, QDSS, PCIe5, TraceNoc and some small subsystems, such as GCC, IPCC, PMU and so on. Link: https://lore.kernel.org/all/20260318-add-coresight-dt-nodes-for-glymur-v2-1-d76e08f21fa5@oss.qualcomm.com/ Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
Add device configuration to enable DCC on Glymur platform. Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
# Conflicts: # arch/arm64/boot/dts/qcom/talos.dtsi
# Conflicts: # drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
# Conflicts: # arch/arm64/configs/defconfig
Adding merge log file and topic_SHA1 file Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
…g/pub/scm/linux/kernel/git/torvalds/linux.git Merge qcom-next based on tag 'Linux 7.0-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git: tech/bsp/clk 90af1d3 12 tech/bsp/interconnect 7d3a72c 5 tech/security/firmware-smc a50984a 2 tech/bsp/soc-infra c793ce5 5 tech/bsp/pinctrl 28c2b80 1 tech/bsp/remoteproc abb91ae 5 tech/bus/peripherals 8c19ed7 2 tech/bus/pci/all 6a697f8 6 tech/bus/pci/mhi fb9c163 1 tech/bus/pci/phy aaf8ef1 4 tech/bus/usb/dwc 49ac8e0 2 tech/bus/usb/phy 8c7f91d 35 tech/debug/hwtracing 87ae82d 31 tech/pmic/misc e6525e3 9 tech/pmic/regulator 81fc8fb 6 tech/mem/iommu 43dfdd1 4 tech/mm/audio/all d38b67b 14 tech/mm/camss ef80fad 20 tech/mm/drm b17e723 12 tech/mm/fastrpc c29b2a8 5 tech/mm/video fa0e482 4 tech/mm/gpu 9c8e55d 2 tech/net/ath f8562ba 2 tech/net/eth 49b156f 1 tech/net/qrtr 64d75f7 1 tech/net/phy a3602e9 1 tech/net/bluetooth 229e73e 3 tech/pm/power 25fc1b7 9 tech/pm/thermal d174ed3 6 tech/security/crypto a6ce790 12 tech/security/ice 5184a0e 15 tech/storage/all e254dae 1 tech/all/dt/qcs6490 5fb16ec 16 tech/all/dt/qcs9100 5586aac 19 tech/all/dt/qcs8300 37ae346 21 tech/all/dt/qcs615 367314f 27 tech/all/dt/agatti c828f10 1 tech/all/dt/hamoa 49fad94 32 tech/all/dt/glymur 3aa6f05 23 tech/all/dt/kaanapali 70486f2 23 tech/all/dt/pakala 86103bc 6 tech/all/config 9050b95 53 tech/overlay/dt bbed7cf 24 tech/all/workaround c3f9d3b 13 tech/mproc/all eabd91e 4 tech/noup/debug/all 342aeb8 15 tech/hwe/unoq 7d981fe 16 early/hwe/shikra/drivers 347ed44 25 early/hwe/shikra/dt 6ae20ad 15
… SM8650 G4 fix Commit 81af9e4 ("phy: qcom: qmp-ufs: Fix SM8650 PCS table for Gear 4") moved QPHY_V6_PCS_UFS_PLL_CNTL register configuration from the shared sm8650_ufsphy_g5_pcs table to the SM8650-specific sm8650_ufsphy_pcs base table to fix Gear 4 operation on SM8650. However, this change inadvertently broke kaanapali and SM8750 SoCs which also rely on the shared sm8650_ufsphy_g5_pcs table for Gear 5 configuration but use their own sm8750_ufsphy_pcs base table. After the change, kaanapali PHYs are left without the required PLL_CNTL = 0x33 setting, causing the PHY PLL to remain at its hardware reset default value, preventing PLL lock and resulting in DME_LINKSTARTUP timeouts. Fix this by adding the missing QPHY_V6_PCS_UFS_PLL_CNTL = 0x33 entry to the sm8750_ufsphy_pcs table, mirroring what the original commit already did for sm8650_ufsphy_pcs. Cc: stable@vger.kernel.org # v6.10 Fixes: 81af9e4 ("phy: qcom: qmp-ufs: Fix SM8650 PCS table for Gear 4") Signed-off-by: Nitin Rawat <nitin.rawat@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260415104851.2763238-1-nitin.rawat@oss.qualcomm.com/ Signed-off-by: Pradeep P V K <pradeep.pragallapati@oss.qualcomm.com>
…nto shared dtsi The monaco-ac EVK is a new board variant which shares the majority of its hardware description with the existing monaco-evk board. In preparation for adding this variant, extract the common hardware nodes from monaco-evk.dts into a new shared monaco-evk-common.dtsi include file, and update monaco-evk.dts to include it and keep only board-specific overrides. No functional change intended. Link: https://lore.kernel.org/lkml/20260413114819.3894307-2-umang.chheda@oss.qualcomm.com/ Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
Introduce bindings for the monaco-ac-evk IoT board, which is based on the monaco-ac (QCS8300-AC) SoC variant. Link: https://lore.kernel.org/lkml/20260413114819.3894307-3-umang.chheda@oss.qualcomm.com/ Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Add initial device tree support for monaco-ac EVK board, based on Qualcomm's monaco-ac (QCS8300-AC) variant SoC. Compared to the existing monaco-evk board, which is based on the QCS8300-AA SKU and uses a four-PMIC power delivery network (2x PM8650AU, Maxim MAX20018, TI TPS6594) to support higher power requirements, the monaco-ac EVK uses QCS8300-AC SKU (with 20 TOPS NPU capability) and a simplified two-PMIC power delivery network (2x PM8650AU). Apart from the SoC SKU and PDN differences, the board layout and peripherals are equivalent to the monaco-evk design and are reused accordingly. Link: https://lore.kernel.org/lkml/20260413114819.3894307-4-umang.chheda@oss.qualcomm.com/ Co-developed-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com> Signed-off-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com> Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
The recent refactoring of monaco-evk and monaco-ac-evk did not carry over the required Bluetooth workaround changes, resulting in broken BT functionality. Proper, upstream-aligned Bluetooth support is currently under development. Until those clean fixes are ready, revert this change to restore the existing working behavior. The refactoring can be reintroduced once the Bluetooth changes are finalized and ready for upstream submission. This reverts commit 845dd9a(arm64/dts/qcom/monaco:Add monaco-ac EVK board) Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
The recent refactoring of monaco-evk and monaco-ac-evk did not carry over the required Bluetooth workaround changes, resulting in broken BT functionality. Proper, upstream-aligned Bluetooth support is currently under development. Until those clean fixes are ready, revert this change to restore the existing working behavior. The refactoring can be reintroduced once the Bluetooth changes are finalized and ready for upstream submission. This reverts commit 0a355dd(dt-bindings/arm/qcom: Add monaco-ac-evk support) Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
…rdware into shared dtsi" The recent refactoring of monaco-evk and monaco-ac-evk did not carry over the required Bluetooth workaround changes, resulting in broken BT functionality. Proper, upstream-aligned Bluetooth support is currently under development. Until those clean fixes are ready, revert this change to restore the existing working behavior. The refactoring can be reintroduced once the Bluetooth changes are finalized and ready for upstream submission. This reverts commit fb3be22(arm64/dts/qcom/monaco-evk: Extract common EVK hardware into shared dtsi) Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
Add an overlay devicetree for Lemans EVK for temporary enablement of the QPS615 PCIE switch's 10GbE and 2.5Gbe ethernet ports. Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Add an overlay devicetree for Monaco EVK for temporary enablement of the QPS615 PCIE switch's 10GbE and 2.5Gbe ethernet ports. Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Add an overlay devicetree for Rb3Gen2 for temporary enablement of the QPS615 PCIE switch's 10GbE and 2.5Gbe ethernet ports. Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
… phy-vreg
The staging overlay used a bare "/ {" root node block to define the
qep_vreg and aqr_vreg fixed regulators. In a DT overlay, a bare "/ {"
creates a new root fragment that is not merged into the base tree's
root node; as a result the regulator nodes are never instantiated and
the tc956x driver cannot resolve the phy-supply phandle, leading to a
failed MDIO probe:
tc956x_pci-eth 0001:05:00.1: No PHY found
Replace "/ {" with the overlay-correct "&{/} {" syntax so that the
fragment is properly applied as an amendment to the base device-tree
root node. This ensures the regulator nodes are present at boot and
the PHY powers up correctly.
Fixes: 00ba37e ("PENDING: arm64: dts: qcom: rb3gen2: add overlay for QPS615 ethernet")
Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
Collaborator
Collaborator
Tests-kaanapali-mtp
Tests-qcs6490-rb3gen2
|
Collaborator
Test Matrix
|
Collaborator
Author
|
7.0
Kernel Test Team Report: Base Build :
Overlay Build :
|
sgaud-quic
pushed a commit
that referenced
this pull request
Jul 25, 2026
syzbot reported a soft lockup in mptcp_recvmsg() [0]. When receiving data with MSG_PEEK | MSG_WAITALL flags, the skb is not removed from the sk_receive_queue. This causes sk_wait_data() to always find available data and never perform actual waiting, leading to a soft lockup. Fix this by adding a 'last' parameter to track the last peeked skb. This allows sk_wait_data() to make informed waiting decisions and prevent infinite loops when MSG_PEEK is used. [0]: watchdog: BUG: soft lockup - CPU#2 stuck for 156s! [server:1963] Modules linked in: CPU: 2 UID: 0 PID: 1963 Comm: server Not tainted 6.19.0-rc8 #61 PREEMPT(none) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:sk_wait_data+0x15/0x190 Code: 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 41 56 41 55 41 54 49 89 f4 55 48 89 d5 53 48 89 fb <48> 83 ec 30 65 48 8b 05 17 a4 6b 01 48 89 44 24 28 31 c0 65 48 8b RSP: 0018:ffffc90000603ca0 EFLAGS: 00000246 RAX: 0000000000000000 RBX: ffff888102bf0800 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ffffc90000603d18 RDI: ffff888102bf0800 RBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000101 R10: 0000000000000000 R11: 0000000000000075 R12: ffffc90000603d18 R13: ffff888102bf0800 R14: ffff888102bf0800 R15: 0000000000000000 FS: 00007f6e38b8c4c0(0000) GS:ffff8881b877e000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055aa7bff1680 CR3: 0000000105cbe000 CR4: 00000000000006f0 Call Trace: <TASK> mptcp_recvmsg+0x547/0x8c0 net/mptcp/protocol.c:2329 inet_recvmsg+0x11f/0x130 net/ipv4/af_inet.c:891 sock_recvmsg+0x94/0xc0 net/socket.c:1100 __sys_recvfrom+0xb2/0x130 net/socket.c:2256 __x64_sys_recvfrom+0x1f/0x30 net/socket.c:2267 do_syscall_64+0x59/0x2d0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S:131 RIP: 0033:0x7f6e386a4a1d Code: 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8d 05 f1 de 2c 00 41 89 ca 8b 00 85 c0 75 20 45 31 c9 45 31 c0 b8 2d 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 6b f3 c3 66 0f 1f 84 00 00 00 00 00 41 56 41 RSP: 002b:00007ffc3c4bb078 EFLAGS: 00000246 ORIG_RAX: 000000000000002d RAX: ffffffffffffffda RBX: 000000000000861e RCX: 00007f6e386a4a1d RDX: 00000000000003ff RSI: 00007ffc3c4bb150 RDI: 0000000000000004 RBP: 00007ffc3c4bb570 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000103 R11: 0000000000000246 R12: 00005605dbc00be0 R13: 00007ffc3c4bb650 R14: 0000000000000000 R15: 0000000000000000 </TASK> Fixes: 8e04ce4 ("mptcp: fix MSG_PEEK stream corruption") Signed-off-by: Li Xiasong <lixiasong1@huawei.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260330120335.659027-1-lixiasong1@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
sgaud-quic
force-pushed
the
qcom-next-staging
branch
from
August 1, 2026 07:35
e98c034 to
8d5dbc1
Compare
sgaud-quic
force-pushed
the
qcom-next-staging
branch
3 times, most recently
from
August 23, 2026 10:54
4020a6e to
8d3ae59
Compare
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.
No description provided.