Changelog in Linux kernel 6.15.1

 
arm64: dts: qcom: ipq9574: Add missing properties for cryptobam [+ + +]
Author: Stephan Gerhold <stephan.gerhold@linaro.org>
Date:   Wed Feb 12 18:03:52 2025 +0100

    arm64: dts: qcom: ipq9574: Add missing properties for cryptobam
    
    commit b4cd966edb2deb5c75fe356191422e127445b830 upstream.
    
    num-channels and qcom,num-ees are required for BAM nodes without clock,
    because the driver cannot ensure the hardware is powered on when trying to
    obtain the information from the hardware registers. Specifying the node
    without these properties is unsafe and has caused early boot crashes for
    other SoCs before [1, 2].
    
    Add the missing information from the hardware registers to ensure the
    driver can probe successfully without causing crashes.
    
    [1]: https://lore.kernel.org/r/CY01EKQVWE36.B9X5TDXAREPF@fairphone.com/
    [2]: https://lore.kernel.org/r/20230626145959.646747-1-krzysztof.kozlowski@linaro.org/
    
    Cc: stable@vger.kernel.org
    Tested-by: Md Sadre Alam <quic_mdalam@quicinc.com>
    Fixes: ffadc79ed99f ("arm64: dts: qcom: ipq9574: Enable crypto nodes")
    Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
    Link: https://lore.kernel.org/r/20250212-bam-dma-fixes-v1-6-f560889e65d8@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: sa8775p: Add missing properties for cryptobam [+ + +]
Author: Stephan Gerhold <stephan.gerhold@linaro.org>
Date:   Wed Feb 12 18:03:51 2025 +0100

    arm64: dts: qcom: sa8775p: Add missing properties for cryptobam
    
    commit a2517331f11bd22cded60e791a8818cec3e7597a upstream.
    
    num-channels and qcom,num-ees are required for BAM nodes without clock,
    because the driver cannot ensure the hardware is powered on when trying to
    obtain the information from the hardware registers. Specifying the node
    without these properties is unsafe and has caused early boot crashes for
    other SoCs before [1, 2].
    
    Add the missing information from the hardware registers to ensure the
    driver can probe successfully without causing crashes.
    
    [1]: https://lore.kernel.org/r/CY01EKQVWE36.B9X5TDXAREPF@fairphone.com/
    [2]: https://lore.kernel.org/r/20230626145959.646747-1-krzysztof.kozlowski@linaro.org/
    
    Cc: stable@vger.kernel.org
    Fixes: 7ff3da43ef44 ("arm64: dts: qcom: sa8775p: add QCrypto nodes")
    Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
    Link: https://lore.kernel.org/r/20250212-bam-dma-fixes-v1-5-f560889e65d8@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: sa8775p: Remove cdsp compute-cb@10 [+ + +]
Author: Karthik Sanagavarapu <quic_kartsana@quicinc.com>
Date:   Tue Feb 11 13:44:15 2025 +0530

    arm64: dts: qcom: sa8775p: Remove cdsp compute-cb@10
    
    commit d180c2bd3b43d55f30c9b99de68bc6bb8420d1c1 upstream.
    
    Remove the context bank compute-cb@10 because these SMMU ids are S2-only
    which is not used for S1 transaction.
    
    Fixes: f7b01bfb4b47 ("arm64: qcom: sa8775p: Add ADSP and CDSP0 fastrpc nodes")
    Cc: stable@kernel.org
    Signed-off-by: Karthik Sanagavarapu <quic_kartsana@quicinc.com>
    Signed-off-by: Ling Xu <quic_lxu5@quicinc.com>
    Link: https://lore.kernel.org/r/4c9de858fda7848b77ea8c528c9b9d53600ad21a.1739260973.git.quic_lxu5@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: sa8775p: Remove extra entries from the iommus property [+ + +]
Author: Ling Xu <quic_lxu5@quicinc.com>
Date:   Tue Feb 11 13:44:14 2025 +0530

    arm64: dts: qcom: sa8775p: Remove extra entries from the iommus property
    
    commit eb73f500548a3205741330cbd7d0e209a7a6a9af upstream.
    
    There are some items come out to be same value if we do SID & ~MASK.
    Remove extra entries from the iommus property for sa8775p to simplify.
    
    Fixes: f7b01bfb4b47 ("arm64: qcom: sa8775p: Add ADSP and CDSP0 fastrpc nodes")
    Cc: stable@kernel.org
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Ling Xu <quic_lxu5@quicinc.com>
    Link: https://lore.kernel.org/r/49f463415c8fa2b08fbc2317e31493362056f403.1739260973.git.quic_lxu5@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: sm8350: Fix typo in pil_camera_mem node [+ + +]
Author: Alok Tiwari <alok.a.tiwari@oracle.com>
Date:   Wed May 14 04:46:51 2025 -0700

    arm64: dts: qcom: sm8350: Fix typo in pil_camera_mem node
    
    commit 295217420a44403a33c30f99d8337fe7b07eb02b upstream.
    
    There is a typo in sm8350.dts where the node label
    mmeory@85200000 should be memory@85200000.
    This patch corrects the typo for clarity and consistency.
    
    Fixes: b7e8f433a673 ("arm64: dts: qcom: Add basic devicetree support for SM8350 SoC")
    Cc: stable@vger.kernel.org
    Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
    Link: https://lore.kernel.org/r/20250514114656.2307828-1-alok.a.tiwari@oracle.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: sm8450: Add missing properties for cryptobam [+ + +]
Author: Stephan Gerhold <stephan.gerhold@linaro.org>
Date:   Wed Feb 12 18:03:48 2025 +0100

    arm64: dts: qcom: sm8450: Add missing properties for cryptobam
    
    commit 0fe6357229cb15a64b6413c62f1c3d4de68ce55f upstream.
    
    num-channels and qcom,num-ees are required for BAM nodes without clock,
    because the driver cannot ensure the hardware is powered on when trying to
    obtain the information from the hardware registers. Specifying the node
    without these properties is unsafe and has caused early boot crashes for
    other SoCs before [1, 2].
    
    Add the missing information from the hardware registers to ensure the
    driver can probe successfully without causing crashes.
    
    [1]: https://lore.kernel.org/r/CY01EKQVWE36.B9X5TDXAREPF@fairphone.com/
    [2]: https://lore.kernel.org/r/20230626145959.646747-1-krzysztof.kozlowski@linaro.org/
    
    Cc: stable@vger.kernel.org
    Fixes: b92b0d2f7582 ("arm64: dts: qcom: sm8450: add crypto nodes")
    Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
    Link: https://lore.kernel.org/r/20250212-bam-dma-fixes-v1-2-f560889e65d8@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: sm8550: Add missing properties for cryptobam [+ + +]
Author: Stephan Gerhold <stephan.gerhold@linaro.org>
Date:   Wed Feb 12 18:03:49 2025 +0100

    arm64: dts: qcom: sm8550: Add missing properties for cryptobam
    
    commit 663cd2cad36da23cf1a3db7868fce9f1a19b2d61 upstream.
    
    num-channels and qcom,num-ees are required for BAM nodes without clock,
    because the driver cannot ensure the hardware is powered on when trying to
    obtain the information from the hardware registers. Specifying the node
    without these properties is unsafe and has caused early boot crashes for
    other SoCs before [1, 2].
    
    Add the missing information from the hardware registers to ensure the
    driver can probe successfully without causing crashes.
    
    [1]: https://lore.kernel.org/r/CY01EKQVWE36.B9X5TDXAREPF@fairphone.com/
    [2]: https://lore.kernel.org/r/20230626145959.646747-1-krzysztof.kozlowski@linaro.org/
    
    Cc: stable@vger.kernel.org
    Fixes: 433477c3bf0b ("arm64: dts: qcom: sm8550: add QCrypto nodes")
    Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
    Link: https://lore.kernel.org/r/20250212-bam-dma-fixes-v1-3-f560889e65d8@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: sm8650: Add missing properties for cryptobam [+ + +]
Author: Stephan Gerhold <stephan.gerhold@linaro.org>
Date:   Wed Feb 12 18:03:50 2025 +0100

    arm64: dts: qcom: sm8650: Add missing properties for cryptobam
    
    commit 38b88722bce07b6a5927f45fbf7a9a85e834572c upstream.
    
    num-channels and qcom,num-ees are required for BAM nodes without clock,
    because the driver cannot ensure the hardware is powered on when trying to
    obtain the information from the hardware registers. Specifying the node
    without these properties is unsafe and has caused early boot crashes for
    other SoCs before [1, 2].
    
    Add the missing information from the hardware registers to ensure the
    driver can probe successfully without causing crashes.
    
    [1]: https://lore.kernel.org/r/CY01EKQVWE36.B9X5TDXAREPF@fairphone.com/
    [2]: https://lore.kernel.org/r/20230626145959.646747-1-krzysztof.kozlowski@linaro.org/
    
    Cc: stable@vger.kernel.org
    Fixes: 10e024671295 ("arm64: dts: qcom: sm8650: add interconnect dependent device nodes")
    Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
    Link: https://lore.kernel.org/r/20250212-bam-dma-fixes-v1-4-f560889e65d8@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: x1e001de-devkit: Fix vreg_l2j_1p2 voltage [+ + +]
Author: Stephan Gerhold <stephan.gerhold@linaro.org>
Date:   Wed Apr 23 09:30:08 2025 +0200

    arm64: dts: qcom: x1e001de-devkit: Fix vreg_l2j_1p2 voltage
    
    commit 3ed2a9e03abfeece9e30ebc746f935536f661414 upstream.
    
    In the ACPI DSDT table, PPP_RESOURCE_ID_LDO2_J is configured with 1256000
    uV instead of the 1200000 uV we have currently in the device tree. Use the
    same for consistency and correctness.
    
    Cc: stable@vger.kernel.org
    Fixes: 7b8a31e82b87 ("arm64: dts: qcom: Add X1E001DE Snapdragon Devkit for Windows")
    Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
    Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
    Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Link: https://lore.kernel.org/r/20250423-x1e-vreg-l2j-voltage-v1-2-24b6a2043025@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: x1e001de-devkit: mark l12b and l15b always-on [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Fri Mar 14 15:54:35 2025 +0100

    arm64: dts: qcom: x1e001de-devkit: mark l12b and l15b always-on
    
    commit 7d328cc134f7db1e062f616a30cffe96fbc43abb upstream.
    
    The l12b and l15b supplies are used by components that are not (fully)
    described (and some never will be) and must never be disabled.
    
    Mark the regulators as always-on to prevent them from being disabled,
    for example, when consumers probe defer or suspend.
    
    Fixes: 7b8a31e82b87 ("arm64: dts: qcom: Add X1E001DE Snapdragon Devkit for Windows")
    Cc: stable@vger.kernel.org      # 6.14
    Cc: Sibi Sankar <quic_sibis@quicinc.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20250314145440.11371-4-johan+linaro@kernel.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: x1e80100-asus-vivobook-s15: Fix vreg_l2j_1p2 voltage [+ + +]
Author: Stephan Gerhold <stephan.gerhold@linaro.org>
Date:   Wed Apr 23 09:30:09 2025 +0200

    arm64: dts: qcom: x1e80100-asus-vivobook-s15: Fix vreg_l2j_1p2 voltage
    
    commit 0fb9ecf8713a7a458f7378c86e0703467db2ad22 upstream.
    
    In the ACPI DSDT table, PPP_RESOURCE_ID_LDO2_J is configured with 1256000
    uV instead of the 1200000 uV we have currently in the device tree. Use the
    same for consistency and correctness.
    
    Cc: stable@vger.kernel.org
    Fixes: d0e2f8f62dff ("arm64: dts: qcom: Add device tree for ASUS Vivobook S 15")
    Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
    Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
    Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Link: https://lore.kernel.org/r/20250423-x1e-vreg-l2j-voltage-v1-3-24b6a2043025@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: x1e80100-dell-xps13-9345: mark l12b and l15b always-on [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Fri Mar 14 15:54:36 2025 +0100

    arm64: dts: qcom: x1e80100-dell-xps13-9345: mark l12b and l15b always-on
    
    commit 63169c07d74031c5e10a9f91229dabade880cf0f upstream.
    
    The l12b and l15b supplies are used by components that are not (fully)
    described (and some never will be) and must never be disabled.
    
    Mark the regulators as always-on to prevent them from being disabled,
    for example, when consumers probe defer or suspend.
    
    Note that these supplies currently have no consumers described in
    mainline.
    
    Fixes: f5b788d0e8cd ("arm64: dts: qcom: Add support for X1-based Dell XPS 13 9345")
    Cc: stable@vger.kernel.org      # 6.13
    Reviewed-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
    Tested-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20250314145440.11371-5-johan+linaro@kernel.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: x1e80100-hp-omnibook-x14: Enable SMB2360 0 and 1 [+ + +]
Author: Juerg Haefliger <juerg.haefliger@canonical.com>
Date:   Wed Mar 19 17:05:09 2025 +0100

    arm64: dts: qcom: x1e80100-hp-omnibook-x14: Enable SMB2360 0 and 1
    
    commit 48274b40a3719a950b1062f8125c972a2df5c083 upstream.
    
    Commit d37e2646c8a5 ("arm64: dts: qcom: x1e80100-pmics: Enable all SMB2360
    separately") disables all SMB2360s and let the board DTS explicitly enable
    them. The HP OmniBook DTS is from before this change and is missing the
    explicit enabling. Add that to get all USB root ports.
    
    Fixes: 6f18b8d4142c ("arm64: dts: qcom: x1e80100-hp-x14: dt for HP Omnibook X Laptop 14")
    Cc: stable@vger.kernel.org      # 6.14
    Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Link: https://lore.kernel.org/r/20250319160509.1812805-1-juerg.haefliger@canonical.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: x1e80100-hp-omnibook-x14: Fix vreg_l2j_1p2 voltage [+ + +]
Author: Stephan Gerhold <stephan.gerhold@linaro.org>
Date:   Wed Apr 23 09:30:10 2025 +0200

    arm64: dts: qcom: x1e80100-hp-omnibook-x14: Fix vreg_l2j_1p2 voltage
    
    commit 4a09dad9d437a13e9cd4383ff7791a816a6e1652 upstream.
    
    In the ACPI DSDT table, PPP_RESOURCE_ID_LDO2_J is configured with 1256000
    uV instead of the 1200000 uV we have currently in the device tree. Use the
    same for consistency and correctness.
    
    Cc: stable@vger.kernel.org
    Fixes: 6f18b8d4142c ("arm64: dts: qcom: x1e80100-hp-x14: dt for HP Omnibook X Laptop 14")
    Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
    Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
    Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Link: https://lore.kernel.org/r/20250423-x1e-vreg-l2j-voltage-v1-4-24b6a2043025@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: x1e80100-hp-x14: mark l12b and l15b always-on [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Fri Mar 14 15:54:37 2025 +0100

    arm64: dts: qcom: x1e80100-hp-x14: mark l12b and l15b always-on
    
    commit 3ab4e212a41c46668adf93c8d10d0d3d6de8f0e4 upstream.
    
    The l12b and l15b supplies are used by components that are not (fully)
    described (and some never will be) and must never be disabled.
    
    Mark the regulators as always-on to prevent them from being disabled,
    for example, when consumers probe defer or suspend.
    
    Fixes: 6f18b8d4142c ("arm64: dts: qcom: x1e80100-hp-x14: dt for HP Omnibook X Laptop 14")
    Cc: stable@vger.kernel.org      # 6.14
    Cc: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20250314145440.11371-6-johan+linaro@kernel.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: x1e80100-lenovo-yoga-slim7x: Fix vreg_l2j_1p2 voltage [+ + +]
Author: Stephan Gerhold <stephan.gerhold@linaro.org>
Date:   Wed Apr 23 09:30:11 2025 +0200

    arm64: dts: qcom: x1e80100-lenovo-yoga-slim7x: Fix vreg_l2j_1p2 voltage
    
    commit 4f27ede34ca3369cdcde80c5a4ca84cdb28edbbb upstream.
    
    In the ACPI DSDT table, PPP_RESOURCE_ID_LDO2_J is configured with 1256000
    uV instead of the 1200000 uV we have currently in the device tree. Use the
    same for consistency and correctness.
    
    Cc: stable@vger.kernel.org
    Fixes: 45247fe17db2 ("arm64: dts: qcom: x1e80100: add Lenovo Thinkpad Yoga slim 7x devicetree")
    Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
    Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
    Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Link: https://lore.kernel.org/r/20250423-x1e-vreg-l2j-voltage-v1-5-24b6a2043025@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: x1e80100-qcp: Fix vreg_l2j_1p2 voltage [+ + +]
Author: Stephan Gerhold <stephan.gerhold@linaro.org>
Date:   Wed Apr 23 09:30:12 2025 +0200

    arm64: dts: qcom: x1e80100-qcp: Fix vreg_l2j_1p2 voltage
    
    commit efdbeae860bf0278b050c6c9ad5921afba4596d0 upstream.
    
    In the ACPI DSDT table, PPP_RESOURCE_ID_LDO2_J is configured with 1256000
    uV instead of the 1200000 uV we have currently in the device tree. Use the
    same for consistency and correctness.
    
    Cc: stable@vger.kernel.org
    Fixes: af16b00578a7 ("arm64: dts: qcom: Add base X1E80100 dtsi and the QCP dts")
    Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
    Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
    Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Link: https://lore.kernel.org/r/20250423-x1e-vreg-l2j-voltage-v1-6-24b6a2043025@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: x1e80100-qcp: mark l12b and l15b always-on [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Fri Mar 14 15:54:39 2025 +0100

    arm64: dts: qcom: x1e80100-qcp: mark l12b and l15b always-on
    
    commit ff6ba96378367133b66587bd3ee9f068a39ff3a9 upstream.
    
    The l12b and l15b supplies are used by components that are not (fully)
    described (and some never will be) and must never be disabled.
    
    Mark the regulators as always-on to prevent them from being disabled,
    for example, when consumers probe defer or suspend.
    
    Fixes: af16b00578a7 ("arm64: dts: qcom: Add base X1E80100 dtsi and the QCP dts")
    Cc: stable@vger.kernel.org      # 6.8
    Cc: Rajendra Nayak <quic_rjendra@quicinc.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20250314145440.11371-8-johan+linaro@kernel.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: x1e80100-yoga-slim7x: mark l12b and l15b always-on [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Fri Mar 14 15:54:38 2025 +0100

    arm64: dts: qcom: x1e80100-yoga-slim7x: mark l12b and l15b always-on
    
    commit f43a71dc6d8d8378af587675eec77c06e0298c79 upstream.
    
    The l12b and l15b supplies are used by components that are not (fully)
    described (and some never will be) and must never be disabled.
    
    Mark the regulators as always-on to prevent them from being disabled,
    for example, when consumers probe defer or suspend.
    
    Fixes: 45247fe17db2 ("arm64: dts: qcom: x1e80100: add Lenovo Thinkpad Yoga slim 7x devicetree")
    Cc: stable@vger.kernel.org      # 6.11
    Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20250314145440.11371-7-johan+linaro@kernel.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: x1e80100: Add GPU cooling [+ + +]
Author: Stephan Gerhold <stephan.gerhold@linaro.org>
Date:   Wed Feb 19 12:36:20 2025 +0100

    arm64: dts: qcom: x1e80100: Add GPU cooling
    
    commit 5ba21fa11f473c9827f378ace8c9f983de9e0287 upstream.
    
    Unlike the CPU, the GPU does not throttle its speed automatically when it
    reaches high temperatures. With certain high GPU loads it is possible to
    reach the critical hardware shutdown temperature of 120°C, endangering the
    hardware and making it impossible to run certain applications.
    
    Set up GPU cooling similar to the ACPI tables, by throttling the GPU speed
    when reaching 95°C and polling every 200ms.
    
    Cc: stable@vger.kernel.org
    Fixes: 721e38301b79 ("arm64: dts: qcom: x1e80100: Add gpu support")
    Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
    Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Link: https://lore.kernel.org/r/20250219-x1e80100-thermal-fixes-v1-3-d110e44ac3f9@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: x1e80100: Apply consistent critical thermal shutdown [+ + +]
Author: Stephan Gerhold <stephan.gerhold@linaro.org>
Date:   Wed Feb 19 12:36:19 2025 +0100

    arm64: dts: qcom: x1e80100: Apply consistent critical thermal shutdown
    
    commit 03f2b8eed73418269a158ccebad5d8d8f2f6daa1 upstream.
    
    The firmware configures the TSENS controller with a maximum temperature of
    120°C. When reaching that temperature, the hardware automatically triggers
    a reset of the entire platform. Some of the thermal zones in x1e80100.dtsi
    use a critical trip point of 125°C. It's impossible to reach those.
    
    It's preferable to shut down the system cleanly before reaching the
    hardware trip point. Make the critical temperature trip points consistent
    by setting all of them to 115°C and apply a consistent hysteresis.
    The ACPI tables also specify 115°C as critical shutdown temperature.
    
    Cc: stable@vger.kernel.org
    Fixes: 4e915987ff5b ("arm64: dts: qcom: x1e80100: Enable tsens and thermal zone nodes")
    Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
    Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Link: https://lore.kernel.org/r/20250219-x1e80100-thermal-fixes-v1-2-d110e44ac3f9@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: x1e80100: Fix PCIe 3rd controller DBI size [+ + +]
Author: Abel Vesa <abel.vesa@linaro.org>
Date:   Tue Apr 22 14:03:16 2025 +0300

    arm64: dts: qcom: x1e80100: Fix PCIe 3rd controller DBI size
    
    commit 181faec4cc9d90dad0ec7f7c8124269c0ba2e107 upstream.
    
    According to documentation, the DBI range size is 0xf20. So fix it.
    
    Cc: stable@vger.kernel.org # 6.14
    Fixes: f8af195beeb0 ("arm64: dts: qcom: x1e80100: Add support for PCIe3 on x1e80100")
    Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Link: https://lore.kernel.org/r/20250422-x1e80100-dts-fix-pcie3-dbi-size-v1-1-c197701fd7e4@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: x1e80100: Fix video thermal zone [+ + +]
Author: Stephan Gerhold <stephan.gerhold@linaro.org>
Date:   Wed Feb 19 12:36:18 2025 +0100

    arm64: dts: qcom: x1e80100: Fix video thermal zone
    
    commit 801befff4c827aa72e3698367c5afc18987a6a3f upstream.
    
    A passive trip point at 125°C is pretty high, this is usually the
    temperature for the critical shutdown trip point. Also, we don't have any
    passive cooling devices attached to the video thermal zone.
    
    Change this to be a critical trip point, and add a "hot" trip point at
    90°C for consistency with the other thermal zones.
    
    Cc: stable@vger.kernel.org
    Fixes: 4e915987ff5b ("arm64: dts: qcom: x1e80100: Enable tsens and thermal zone nodes")
    Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
    Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Link: https://lore.kernel.org/r/20250219-x1e80100-thermal-fixes-v1-1-d110e44ac3f9@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: rockchip: Add missing SFC power-domains to rk3576 [+ + +]
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date:   Tue May 20 13:14:27 2025 +0200

    arm64: dts: rockchip: Add missing SFC power-domains to rk3576
    
    commit ede1fa1384c230c9823f6bf1849cf50c5fc8a83e upstream.
    
    Add the power-domains for the RK3576 SFC nodes according to the
    TRM part 1. This fixes potential SErrors when accessing the SFC
    registers without other peripherals (e.g. eMMC) doing a prior
    power-domain enable. For example this is easy to trigger on the
    Rock 4D, which enables the SFC0 interface, but does not enable
    the eMMC interface at the moment.
    
    Cc: stable@vger.kernel.org
    Fixes: 36299757129c8 ("arm64: dts: rockchip: Add SFC nodes for rk3576")
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Link: https://lore.kernel.org/r/20250520-rk3576-fix-fspi-pmdomain-v1-1-f07c6e62dadd@kernel.org
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: rockchip: fix internal USB hub instability on RK3399 Puma [+ + +]
Author: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>
Date:   Fri Apr 25 17:18:08 2025 +0200

    arm64: dts: rockchip: fix internal USB hub instability on RK3399 Puma
    
    commit d7cc532df95f7f159e40595440e4e4b99481457b upstream.
    
    Currently, the onboard Cypress CYUSB3304 USB hub is not defined in
    the device tree, and hub reset pin is provided as vcc5v0_host
    regulator to usb phy. This causes instability issues, as a result
    of improper reset duration.
    
    The fixed regulator device requests the GPIO during probe in its
    inactive state (except if regulator-boot-on property is set, in
    which case it is requested in the active state). Considering gpio
    is GPIO_ACTIVE_LOW for Puma, it means it’s driving it high. Then
    the regulator gets enabled (because regulator-always-on property),
    which drives it to its active state, meaning driving it low.
    
    The Cypress CYUSB3304 USB hub actually requires the reset to be
    asserted for at least 5 ms, which we cannot guarantee right now
    since there's no delay in the current config, meaning the hub may
    sometimes work or not. We could add delay as offered by
    fixed-regulator but let's rather fix this by using the proper way
    to model onboard USB hubs.
    
    Define hub_2_0 and hub_3_0 nodes, as the onboard Cypress hub
    consist of two 'logical' hubs, for USB2.0 and USB3.0.
    Use the 'reset-gpios' property of hub to assign reset pin instead
    of using regulator. Rename the vcc5v0_host regulator to
    cy3304_reset to be more meaningful. Pin is configured to
    output-high by default, which sets the hub in reset state
    during pin controller initialization. This allows to avoid double
    enumeration of devices in case the bootloader has setup the USB
    hub before the kernel.
    The vdd-supply and vdd2-supply properties in hub nodes are
    added to provide correct dt-bindings, although power supplies are
    always enabled based on HW design.
    
    Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM")
    Cc: stable@vger.kernel.org # 6.6
    Cc: stable@vger.kernel.org # Backport of the patch in this series fixing product ID in onboard_dev_id_table in drivers/usb/misc/onboard_usb_dev.c driver
    Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>
    Link: https://lore.kernel.org/r/20250425-onboard_usb_dev-v2-3-4a76a474a010@thaumatec.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: socfpga: agilex5: fix gpio0 address [+ + +]
Author: Niravkumar L Rabara <niravkumar.l.rabara@intel.com>
Date:   Thu Feb 13 18:50:36 2025 +0800

    arm64: dts: socfpga: agilex5: fix gpio0 address
    
    commit a6c9896e65e555d679a4bc71c3cdfce6df4b2343 upstream.
    
    Use the correct gpio0 address for Agilex5.
    
    Fixes: 3f7c869e143a ("arm64: dts: socfpga: agilex5: Add gpio0 node and spi dma handshake id")
    Cc: stable@vger.kernel.org
    Signed-off-by: Niravkumar L Rabara <niravkumar.l.rabara@intel.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
arm64: dts: ti: k3-am62-main: Set eMMC clock parent to default [+ + +]
Author: Judith Mendez <jm@ti.com>
Date:   Tue Apr 29 11:33:35 2025 -0500

    arm64: dts: ti: k3-am62-main: Set eMMC clock parent to default
    
    commit 3a71cdfec94436079513d9adf4b1d4f7a7edd917 upstream.
    
    Set eMMC clock parents to the defaults which is MAIN_PLL0_HSDIV5_CLKOUT
    for eMMC. This change is necessary since DM is not implementing the
    correct procedure to switch PLL clock source for eMMC and MMC CLK mux is
    not glich-free. As a preventative action, lets switch back to the defaults.
    
    Fixes: c37c58fdeb8a ("arm64: dts: ti: k3-am62: Add more peripheral nodes")
    Cc: stable@vger.kernel.org
    Signed-off-by: Judith Mendez <jm@ti.com>
    Acked-by: Udit Kumar <u-kumar1@ti.com>
    Acked-by: Bryan Brattlof <bb@ti.com>
    Link: https://lore.kernel.org/r/20250429163337.15634-2-jm@ti.com
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: ti: k3-am62a-main: Set eMMC clock parent to default [+ + +]
Author: Judith Mendez <jm@ti.com>
Date:   Tue Apr 29 11:33:36 2025 -0500

    arm64: dts: ti: k3-am62a-main: Set eMMC clock parent to default
    
    commit 6af731c5de59cc4e7cce193d446f1fe872ac711b upstream.
    
    Set eMMC clock parents to the defaults which is MAIN_PLL0_HSDIV5_CLKOUT
    for eMMC. This change is necessary since DM is not implementing the
    correct procedure to switch PLL clock source for eMMC and MMC CLK mux is
    not glich-free. As a preventative action, lets switch back to the defaults.
    
    Fixes: d3ae4e8d8b6a ("arm64: dts: ti: k3-am62a-main: Add sdhci0 instance")
    Cc: stable@vger.kernel.org
    Signed-off-by: Judith Mendez <jm@ti.com>
    Acked-by: Udit Kumar <u-kumar1@ti.com>
    Acked-by: Bryan Brattlof <bb@ti.com>
    Link: https://lore.kernel.org/r/20250429163337.15634-3-jm@ti.com
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: ti: k3-am62p-j722s-common-main: Set eMMC clock parent to default [+ + +]
Author: Judith Mendez <jm@ti.com>
Date:   Tue Apr 29 11:33:37 2025 -0500

    arm64: dts: ti: k3-am62p-j722s-common-main: Set eMMC clock parent to default
    
    commit 9c6b73fc72e19c449147233587833ce20f84b660 upstream.
    
    Set eMMC clock parents to the defaults which is MAIN_PLL0_HSDIV5_CLKOUT
    for eMMC. This change is necessary since DM is not implementing the
    correct procedure to switch PLL clock source for eMMC and MMC CLK mux is
    not glich-free. As a preventative action, lets switch back to the defaults.
    
    Fixes: b5080c7c1f7e ("arm64: dts: ti: k3-am62p: Add nodes for more IPs")
    Cc: stable@vger.kernel.org
    Signed-off-by: Judith Mendez <jm@ti.com>
    Acked-by: Udit Kumar <u-kumar1@ti.com>
    Acked-by: Bryan Brattlof <bb@ti.com>
    Link: https://lore.kernel.org/r/20250429163337.15634-4-jm@ti.com
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: ti: k3-am62x: Remove clock-names property from IMX219 overlay [+ + +]
Author: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
Date:   Tue Apr 15 16:43:26 2025 +0530

    arm64: dts: ti: k3-am62x: Remove clock-names property from IMX219 overlay
    
    commit c68ab54a89a8c935732589a35ea2596e2329f167 upstream.
    
    The IMX219 sensor device tree bindings do not include a clock-names
    property. Remove the incorrectly added clock-names entry to avoid
    dtbs_check warnings.
    
    Fixes: 4111db03dc05 ("arm64: dts: ti: k3-am62x: Add overlay for IMX219")
    Cc: stable@vger.kernel.org
    Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
    Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
    Reviewed-by: Jai Luthra <jai.luthra@linux.dev>
    Link: https://lore.kernel.org/r/20250415111328.3847502-6-y-abhilashchandra@ti.com
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: ti: k3-am62x: Rename I2C switch to I2C mux in IMX219 overlay [+ + +]
Author: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
Date:   Tue Apr 15 16:43:27 2025 +0530

    arm64: dts: ti: k3-am62x: Rename I2C switch to I2C mux in IMX219 overlay
    
    commit 7b75dd2029ee01a8c11fcf4d97f3ccebbef9f8eb upstream.
    
    The IMX219 device tree overlay incorrectly defined an I2C switch
    instead of an I2C mux. According to the DT bindings, the correct
    terminology and node definition should use "i2c-mux" instead of
    "i2c-switch". Hence, update the same to avoid dtbs_check warnings.
    
    Fixes: 4111db03dc05 ("arm64: dts: ti: k3-am62x: Add overlay for IMX219")
    Cc: stable@vger.kernel.org
    Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
    Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
    Reviewed-by: Jai Luthra <jai.luthra@linux.dev>
    Link: https://lore.kernel.org/r/20250415111328.3847502-7-y-abhilashchandra@ti.com
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: ti: k3-am62x: Rename I2C switch to I2C mux in OV5640 overlay [+ + +]
Author: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
Date:   Tue Apr 15 16:43:28 2025 +0530

    arm64: dts: ti: k3-am62x: Rename I2C switch to I2C mux in OV5640 overlay
    
    commit b22cc402d38774ccc552d18e762c25dde02f7be0 upstream.
    
    The OV5640 device tree overlay incorrectly defined an I2C switch
    instead of an I2C mux. According to the DT bindings, the correct
    terminology and node definition should use "i2c-mux" instead of
    "i2c-switch". Hence, update the same to avoid dtbs_check warnings.
    
    Fixes: 635ed9715194 ("arm64: dts: ti: k3-am62x: Add overlays for OV5640")
    Cc: stable@vger.kernel.org
    Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
    Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
    Reviewed-by: Jai Luthra <jai.luthra@linux.dev>
    Link: https://lore.kernel.org/r/20250415111328.3847502-8-y-abhilashchandra@ti.com
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: ti: k3-am65-main: Add missing taps to sdhci0 [+ + +]
Author: Judith Mendez <jm@ti.com>
Date:   Tue Apr 29 12:30:08 2025 -0500

    arm64: dts: ti: k3-am65-main: Add missing taps to sdhci0
    
    commit f55c9f087cc2e2252d44ffd9d58def2066fc176e upstream.
    
    For am65x, add missing ITAPDLYSEL values for Default Speed and High
    Speed SDR modes to sdhci0 node according to the device datasheet [0].
    
    [0] https://www.ti.com/lit/gpn/am6548
    
    Fixes: eac99d38f861 ("arm64: dts: ti: k3-am654-main: Update otap-del-sel values")
    Cc: stable@vger.kernel.org
    Signed-off-by: Judith Mendez <jm@ti.com>
    Reviewed-by: Moteen Shah <m-shah@ti.com>
    Link: https://lore.kernel.org/r/20250429173009.33994-1-jm@ti.com
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: ti: k3-am68-sk: Fix regulator hierarchy [+ + +]
Author: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
Date:   Tue Apr 15 16:43:23 2025 +0530

    arm64: dts: ti: k3-am68-sk: Fix regulator hierarchy
    
    commit 7edf0a4d3bb7f5cd84f172b76c380c4259bb4ef8 upstream.
    
    Update the vin-supply of the TLV71033 regulator from LM5141 (vsys_3v3)
    to LM61460 (vsys_5v0) to match the schematics. Add a fixed regulator
    node for the LM61460 5V supply to support this change.
    
    AM68-SK schematics: https://www.ti.com/lit/zip/sprr463
    
    Fixes: a266c180b398 ("arm64: dts: ti: k3-am68-sk: Add support for AM68 SK base board")
    Cc: stable@vger.kernel.org
    Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
    Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
    Reviewed-by: Udit Kumar <u-kumar1@ti.com>
    Link: https://lore.kernel.org/r/20250415111328.3847502-3-y-abhilashchandra@ti.com
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: ti: k3-j721e-sk: Add DT nodes for power regulators [+ + +]
Author: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
Date:   Tue Apr 15 16:43:22 2025 +0530

    arm64: dts: ti: k3-j721e-sk: Add DT nodes for power regulators
    
    commit 97b67cc102dc2cc8aa39a569c22a196e21af5a21 upstream.
    
    Add device tree nodes for two power regulators on the J721E SK board.
    vsys_5v0: A fixed regulator representing the 5V supply output from the
    LM61460 and vdd_sd_dv: A GPIO-controlled TLV71033 regulator.
    
    J721E-SK schematics: https://www.ti.com/lit/zip/sprr438
    
    Fixes: 1bfda92a3a36 ("arm64: dts: ti: Add support for J721E SK")
    Cc: stable@vger.kernel.org
    Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
    Reviewed-by: Udit Kumar <u-kumar1@ti.com>
    Link: https://lore.kernel.org/r/20250415111328.3847502-2-y-abhilashchandra@ti.com
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: ti: k3-j721e-sk: Add requiried voltage supplies for IMX219 [+ + +]
Author: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
Date:   Tue Apr 15 16:43:25 2025 +0530

    arm64: dts: ti: k3-j721e-sk: Add requiried voltage supplies for IMX219
    
    commit c6a20a250200da6fcaf80fe945b7b92cba8cfe0f upstream.
    
    The device tree overlay for the IMX219 sensor requires three voltage
    supplies to be defined: VANA (analog), VDIG (digital core), and VDDL
    (digital I/O). Add the corresponding voltage supply definitions to
    avoid dtbs_check warnings.
    
    Fixes: f767eb918096 ("arm64: dts: ti: k3-j721e-sk: Add overlay for IMX219")
    Cc: stable@vger.kernel.org
    Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
    Link: https://lore.kernel.org/r/20250415111328.3847502-5-y-abhilashchandra@ti.com
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: ti: k3-j721e-sk: Remove clock-names property from IMX219 overlay [+ + +]
Author: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
Date:   Tue Apr 15 16:43:24 2025 +0530

    arm64: dts: ti: k3-j721e-sk: Remove clock-names property from IMX219 overlay
    
    commit 24ab76e55ef15450c6681a2b5db4d78f45200939 upstream.
    
    The IMX219 sensor device tree bindings do not include a clock-names
    property. Remove the incorrectly added clock-names entry to avoid
    dtbs_check warnings.
    
    Fixes: f767eb918096 ("arm64: dts: ti: k3-j721e-sk: Add overlay for IMX219")
    Cc: stable@vger.kernel.org
    Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
    Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
    Reviewed-by: Jai Luthra <jai.luthra@linux.dev>
    Link: https://lore.kernel.org/r/20250415111328.3847502-4-y-abhilashchandra@ti.com
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: ti: k3-j722s-evm: Enable "serdes_wiz0" and "serdes_wiz1" [+ + +]
Author: Siddharth Vadapalli <s-vadapalli@ti.com>
Date:   Thu Apr 17 18:02:43 2025 +0530

    arm64: dts: ti: k3-j722s-evm: Enable "serdes_wiz0" and "serdes_wiz1"
    
    commit 9d76be5828be44ed7a104cc21b4f875be4a63322 upstream.
    
    In preparation for disabling "serdes_wiz0" and "serdes_wiz1" device-tree
    nodes in the SoC file, enable them in the board file. The motivation for
    this change is that of following the existing convention of disabling
    nodes in the SoC file and only enabling the required ones in the board
    file.
    
    Fixes: 485705df5d5f ("arm64: dts: ti: k3-j722s: Enable PCIe and USB support on J722S-EVM")
    Cc: stable@vger.kernel.org
    Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
    Reviewed-by: Udit Kumar <u-kumar1@ti.com>
    Link: https://lore.kernel.org/r/20250417123246.2733923-2-s-vadapalli@ti.com
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: ti: k3-j722s-main: Disable "serdes_wiz0" and "serdes_wiz1" [+ + +]
Author: Siddharth Vadapalli <s-vadapalli@ti.com>
Date:   Thu Apr 17 18:02:44 2025 +0530

    arm64: dts: ti: k3-j722s-main: Disable "serdes_wiz0" and "serdes_wiz1"
    
    commit 320d8a84f6f045dc876d4c2983f9024c7ac9d6df upstream.
    
    Since "serdes0" and "serdes1" which are the sub-nodes of "serdes_wiz0"
    and "serdes_wiz1" respectively, have been disabled in the SoC file already,
    and, given that these sub-nodes will only be enabled in a board file if the
    board utilizes any of the SERDES instances and the peripherals bound to
    them, we end up in a situation where the board file doesn't explicitly
    disable "serdes_wiz0" and "serdes_wiz1". As a consequence of this, the
    following errors show up when booting Linux:
    
      wiz bus@f0000:phy@f000000: probe with driver wiz failed with error -12
      ...
      wiz bus@f0000:phy@f010000: probe with driver wiz failed with error -12
    
    To not only fix the above, but also, in order to follow the convention of
    disabling device-tree nodes in the SoC file and enabling them in the board
    files for those boards which require them, disable "serdes_wiz0" and
    "serdes_wiz1" device-tree nodes.
    
    Fixes: 628e0a0118e6 ("arm64: dts: ti: k3-j722s-main: Add SERDES and PCIe support")
    Cc: stable@vger.kernel.org
    Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
    Reviewed-by: Udit Kumar <u-kumar1@ti.com>
    Link: https://lore.kernel.org/r/20250417123246.2733923-3-s-vadapalli@ti.com
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: ti: k3-j784s4-j742s2-main-common: Fix length of serdes_ln_ctrl [+ + +]
Author: Siddharth Vadapalli <s-vadapalli@ti.com>
Date:   Wed Apr 23 20:46:12 2025 +0530

    arm64: dts: ti: k3-j784s4-j742s2-main-common: Fix length of serdes_ln_ctrl
    
    commit 3b62bd1fde50d54cc59015e14869e6cc3d6899e0 upstream.
    
    Commit under Fixes corrected the "mux-reg-masks" property but did not
    update the "length" field of the "reg" property to account for the
    newly added register offsets which extend the region. Fix this.
    
    Fixes: 38e7f9092efb ("arm64: dts: ti: k3-j784s4-j742s2-main-common: Fix serdes_ln_ctrl reg-masks")
    Cc: stable@vger.kernel.org
    Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
    Reviewed-by: Udit Kumar <u-kumar1@ti.com>
    Link: https://lore.kernel.org/r/20250423151612.48848-1-s-vadapalli@ti.com
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
coredump: fix error handling for replace_fd() [+ + +]
Author: Christian Brauner <brauner@kernel.org>
Date:   Mon Apr 14 15:55:06 2025 +0200

    coredump: fix error handling for replace_fd()
    
    commit 95c5f43181fe9c1b5e5a4bd3281c857a5259991f upstream.
    
    The replace_fd() helper returns the file descriptor number on success
    and a negative error code on failure. The current error handling in
    umh_pipe_setup() only works because the file descriptor that is replaced
    is zero but that's pretty volatile. Explicitly check for a negative
    error code.
    
    Link: https://lore.kernel.org/20250414-work-coredump-v2-2-685bf231f828@kernel.org
    Tested-by: Luca Boccassi <luca.boccassi@gmail.com>
    Reviewed-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

coredump: hand a pidfd to the usermode coredump helper [+ + +]
Author: Christian Brauner <brauner@kernel.org>
Date:   Mon Apr 14 15:55:07 2025 +0200

    coredump: hand a pidfd to the usermode coredump helper
    
    commit b5325b2a270fcaf7b2a9a0f23d422ca8a5a8bdea upstream.
    
    Give userspace a way to instruct the kernel to install a pidfd into the
    usermode helper process. This makes coredump handling a lot more
    reliable for userspace. In parallel with this commit we already have
    systemd adding support for this in [1].
    
    We create a pidfs file for the coredumping process when we process the
    corename pattern. When the usermode helper process is forked we then
    install the pidfs file as file descriptor three into the usermode
    helpers file descriptor table so it's available to the exec'd program.
    
    Since usermode helpers are either children of the system_unbound_wq
    workqueue or kthreadd we know that the file descriptor table is empty
    and can thus always use three as the file descriptor number.
    
    Note, that we'll install a pidfd for the thread-group leader even if a
    subthread is calling do_coredump(). We know that task linkage hasn't
    been removed due to delay_group_leader() and even if this @current isn't
    the actual thread-group leader we know that the thread-group leader
    cannot be reaped until @current has exited.
    
    Link: https://github.com/systemd/systemd/pull/37125 [1]
    Link: https://lore.kernel.org/20250414-work-coredump-v2-3-685bf231f828@kernel.org
    Tested-by: Luca Boccassi <luca.boccassi@gmail.com>
    Reviewed-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
iommu: Avoid introducing more races [+ + +]
Author: Robin Murphy <robin.murphy@arm.com>
Date:   Tue Mar 11 15:19:25 2025 +0000

    iommu: Avoid introducing more races
    
    commit 0c8e9c148e29a983e67060fb4944a8ca79d4362a upstream.
    
    Although the lock-juggling is only a temporary workaround, we don't want
    it to make things avoidably worse. Jason was right to be nervous, since
    bus_iommu_probe() doesn't care *which* IOMMU instance it's probing for,
    so it probably is possible for one walk to finish a probe which a
    different walk started, thus we do want to check for that.
    
    Also there's no need to drop the lock just to have of_iommu_configure()
    do nothing when a fwspec already exists; check that directly and avoid
    opening a window at all in that (still somewhat likely) case.
    
    Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Robin Murphy <robin.murphy@arm.com>
    Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
    Link: https://lore.kernel.org/r/09d901ad11b3a410fbb6e27f7d04ad4609c3fe4a.1741706365.git.robin.murphy@arm.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iommu: Handle yet another race around registration [+ + +]
Author: Robin Murphy <robin.murphy@arm.com>
Date:   Thu Apr 24 18:41:28 2025 +0100

    iommu: Handle yet another race around registration
    
    commit da33e87bd2bfc63531cf7448a3cd7a3d42182f08 upstream.
    
    Next up on our list of race windows to close is another one during
    iommu_device_register() - it's now OK again for multiple instances to
    run their bus_iommu_probe() in parallel, but an iommu_probe_device() can
    still also race against a running bus_iommu_probe(). As Johan has
    managed to prove, this has now become a lot more visible on DT platforms
    wth driver_async_probe where a client driver is attempting to probe in
    parallel with its IOMMU driver - although commit b46064a18810 ("iommu:
    Handle race with default domain setup") resolves this from the client
    driver's point of view, this isn't before of_iommu_configure() has had
    the chance to attempt to "replay" a probe that the bus walk hasn't even
    tried yet, and so still cause the out-of-order group allocation
    behaviour that we're trying to clean up (and now warning about).
    
    The most reliable thing to do here is to explicitly keep track of the
    "iommu_device_register() is still running" state, so we can then
    special-case the ops lookup for the replay path (based on dev->iommu
    again) to let that think it's still waiting for the IOMMU driver to
    appear at all. This still leaves the longstanding theoretical case of
    iommu_bus_notifier() being triggered during bus_iommu_probe(), but it's
    not so simple to defer a notifier, and nobody's ever reported that being
    a visible issue, so let's quietly kick that can down the road for now...
    
    Reported-by: Johan Hovold <johan@kernel.org>
    Fixes: bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper probe path")
    Signed-off-by: Robin Murphy <robin.murphy@arm.com>
    Link: https://lore.kernel.org/r/88d54c1b48fed8279aa47d30f3d75173685bb26a.1745516488.git.robin.murphy@arm.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: Linux 6.15.1 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Jun 4 14:46:27 2025 +0200

    Linux 6.15.1
    
    Link: https://lore.kernel.org/r/20250602134237.940995114@linuxfoundation.org
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Peter Schneider <pschneider1968@googlemail.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Mark Brown <broonie@kernel.org>
    Tested-by: Christian Heusel <christian@heusel.eu>
    Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net_sched: hfsc: Address reentrant enqueue adding class to eltree twice [+ + +]
Author: Pedro Tammela <pctammela@mojatatu.com>
Date:   Thu May 22 15:14:47 2025 -0300

    net_sched: hfsc: Address reentrant enqueue adding class to eltree twice
    
    commit ac9fe7dd8e730a103ae4481147395cc73492d786 upstream.
    
    Savino says:
        "We are writing to report that this recent patch
        (141d34391abbb315d68556b7c67ad97885407547) [1]
        can be bypassed, and a UAF can still occur when HFSC is utilized with
        NETEM.
    
        The patch only checks the cl->cl_nactive field to determine whether
        it is the first insertion or not [2], but this field is only
        incremented by init_vf [3].
    
        By using HFSC_RSC (which uses init_ed) [4], it is possible to bypass the
        check and insert the class twice in the eltree.
        Under normal conditions, this would lead to an infinite loop in
        hfsc_dequeue for the reasons we already explained in this report [5].
    
        However, if TBF is added as root qdisc and it is configured with a
        very low rate,
        it can be utilized to prevent packets from being dequeued.
        This behavior can be exploited to perform subsequent insertions in the
        HFSC eltree and cause a UAF."
    
    To fix both the UAF and the infinite loop, with netem as an hfsc child,
    check explicitly in hfsc_enqueue whether the class is already in the eltree
    whenever the HFSC_RSC flag is set.
    
    [1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547
    [2] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1572
    [3] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L677
    [4] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1574
    [5] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/T/#u
    
    Fixes: 37d9cf1a3ce3 ("sched: Fix detection of empty queues in child qdiscs")
    Reported-by: Savino Dicanosa <savy@syst3mfailure.io>
    Reported-by: William Liu <will@willsroot.io>
    Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Tested-by: Victor Nogueira <victor@mojatatu.com>
    Signed-off-by: Pedro Tammela <pctammela@mojatatu.com>
    Link: https://patch.msgid.link/20250522181448.1439717-2-pctammela@mojatatu.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
perf/arm-cmn: Add CMN S3 ACPI binding [+ + +]
Author: Robin Murphy <robin.murphy@arm.com>
Date:   Mon May 19 11:56:04 2025 +0100

    perf/arm-cmn: Add CMN S3 ACPI binding
    
    commit 8c138a189f6db295ceb32258d46ac061df0823e5 upstream.
    
    An ACPI binding for CMN S3 was not yet finalised when the driver support
    was originally written, but v1.2 of DEN0093 "ACPI for Arm Components"
    has at last been published; support ACPI systems using the proper HID.
    
    Cc: stable@vger.kernel.org
    Fixes: 0dc2f4963f7e ("perf/arm-cmn: Support CMN S3")
    Signed-off-by: Robin Murphy <robin.murphy@arm.com>
    Link: https://lore.kernel.org/r/7dafe147f186423020af49d7037552ee59c60e97.1747652164.git.robin.murphy@arm.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

perf/arm-cmn: Fix REQ2/SNP2 mixup [+ + +]
Author: Robin Murphy <robin.murphy@arm.com>
Date:   Thu May 8 16:16:40 2025 +0100

    perf/arm-cmn: Fix REQ2/SNP2 mixup
    
    commit 11b0f576e0cbde6a12258f2af6753b17b8df342b upstream.
    
    Somehow the encodings for REQ2/SNP2 channels in XP events
    got mixed up... Unmix them.
    
    CC: stable@vger.kernel.org
    Fixes: 23760a014417 ("perf/arm-cmn: Add CMN-700 support")
    Signed-off-by: Robin Murphy <robin.murphy@arm.com>
    Link: https://lore.kernel.org/r/087023e9737ac93d7ec7a841da904758c254cb01.1746717400.git.robin.murphy@arm.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

perf/arm-cmn: Initialise cmn->cpu earlier [+ + +]
Author: Robin Murphy <robin.murphy@arm.com>
Date:   Mon May 12 18:11:54 2025 +0100

    perf/arm-cmn: Initialise cmn->cpu earlier
    
    commit 597704e201068db3d104de3c7a4d447ff8209127 upstream.
    
    For all the complexity of handling affinity for CPU hotplug, what we've
    apparently managed to overlook is that arm_cmn_init_irqs() has in fact
    always been setting the *initial* affinity of all IRQs to CPU 0, not the
    CPU we subsequently choose for event scheduling. Oh dear.
    
    Cc: stable@vger.kernel.org
    Fixes: 0ba64770a2f2 ("perf: Add Arm CMN-600 PMU driver")
    Signed-off-by: Robin Murphy <robin.murphy@arm.com>
    Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com>
    Link: https://lore.kernel.org/r/b12fccba6b5b4d2674944f59e4daad91cd63420b.1747069914.git.robin.murphy@arm.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
pidfs: move O_RDWR into pidfs_alloc_file() [+ + +]
Author: Christian Brauner <brauner@kernel.org>
Date:   Mon Apr 14 15:55:05 2025 +0200

    pidfs: move O_RDWR into pidfs_alloc_file()
    
    commit c57f07b235871c9e5bffaccd458dca2d9a62b164 upstream.
    
    Since all pidfds must be O_RDWR currently enfore that directly in the
    file allocation function itself instead of letting callers specify it.
    
    Link: https://lore.kernel.org/20250414-work-coredump-v2-1-685bf231f828@kernel.org
    Tested-by: Luca Boccassi <luca.boccassi@gmail.com>
    Reviewed-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>