Changelog in Linux kernel 6.12.32

 
ALSA: hda/realtek - restore auto-mute mode for Dell Chrome platform [+ + +]
Author: Kailang Yang <kailang@realtek.com>
Date:   Fri May 16 14:53:37 2025 +0800

    ALSA: hda/realtek - restore auto-mute mode for Dell Chrome platform
    
    [ Upstream commit 5ad8a4ddc45048bc2fe23b75357b6bf185db004f ]
    
    This board need to shutdown Class-D amp to avoid EMI issue.
    Restore the Auto-Mute mode item will off pin control when Auto-mute mode was enable.
    
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Links: https://lore.kernel.org/ee8bbe5236464c369719d96269ba8ef8@realtek.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
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: 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: 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-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: 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: 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>

 
can: kvaser_pciefd: Force IRQ edge in case of nested IRQ [+ + +]
Author: Axel Forsman <axfo@kvaser.com>
Date:   Tue May 20 13:43:30 2025 +0200

    can: kvaser_pciefd: Force IRQ edge in case of nested IRQ
    
    commit 9176bd205ee0b2cd35073a9973c2a0936bcb579e upstream.
    
    Avoid the driver missing IRQs by temporarily masking IRQs in the ISR
    to enforce an edge even if a different IRQ is signalled before handled
    IRQs are cleared.
    
    Fixes: 48f827d4f48f ("can: kvaser_pciefd: Move reset of DMA RX buffers to the end of the ISR")
    Cc: stable@vger.kernel.org
    Signed-off-by: Axel Forsman <axfo@kvaser.com>
    Tested-by: Jimmy Assarsson <extja@kvaser.com>
    Reviewed-by: Jimmy Assarsson <extja@kvaser.com>
    Link: https://patch.msgid.link/20250520114332.8961-2-axfo@kvaser.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 
char: tpm: tpm-buf: Add sanity check fallback in read helpers [+ + +]
Author: Purva Yeshi <purvayeshi550@gmail.com>
Date:   Thu Apr 10 16:04:42 2025 +0530

    char: tpm: tpm-buf: Add sanity check fallback in read helpers
    
    [ Upstream commit 32d495b384a2db7d23c2295e03e6b6edb1c0db8d ]
    
    Fix Smatch-detected issue:
    
    drivers/char/tpm/tpm-buf.c:208 tpm_buf_read_u8() error:
    uninitialized symbol 'value'.
    drivers/char/tpm/tpm-buf.c:225 tpm_buf_read_u16() error:
    uninitialized symbol 'value'.
    drivers/char/tpm/tpm-buf.c:242 tpm_buf_read_u32() error:
    uninitialized symbol 'value'.
    
    Zero-initialize the return values in tpm_buf_read_u8(), tpm_buf_read_u16(),
    and tpm_buf_read_u32() to guard against uninitialized data in case of a
    boundary overflow.
    
    Add defensive initialization ensures the return values are always defined,
    preventing undefined behavior if the unexpected happens.
    
    Signed-off-by: Purva Yeshi <purvayeshi550@gmail.com>
    Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
    Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.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.
    
    [brauner: This is a backport for the v6.12 series. The upstream kernel
    has changed pidfs_alloc_file() to set O_RDWR implicitly instead of
    forcing callers to set it. Let's minimize the churn and just let the
    coredump umh handler raise O_RDWR.]
    
    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>

 
dmaengine: idxd: cdev: Fix uninitialized use of sva in idxd_cdev_open [+ + +]
Author: Purva Yeshi <purvayeshi550@gmail.com>
Date:   Thu Apr 10 16:32:16 2025 +0530

    dmaengine: idxd: cdev: Fix uninitialized use of sva in idxd_cdev_open
    
    [ Upstream commit 97994333de2b8062d2df4e6ce0dc65c2dc0f40dc ]
    
    Fix Smatch-detected issue:
    drivers/dma/idxd/cdev.c:321 idxd_cdev_open() error:
    uninitialized symbol 'sva'.
    
    'sva' pointer may be used uninitialized in error handling paths.
    Specifically, if PASID support is enabled and iommu_sva_bind_device()
    returns an error, the code jumps to the cleanup label and attempts to
    call iommu_sva_unbind_device(sva) without ensuring that sva was
    successfully assigned. This triggers a Smatch warning about an
    uninitialized symbol.
    
    Initialize sva to NULL at declaration and add a check using
    IS_ERR_OR_NULL() before unbinding the device. This ensures the
    function does not use an invalid or uninitialized pointer during
    cleanup.
    
    Signed-off-by: Purva Yeshi <purvayeshi550@gmail.com>
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
    Link: https://lore.kernel.org/r/20250410110216.21592-1-purvayeshi550@gmail.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/display: check stream id dml21 wrapper to get plane_id [+ + +]
Author: Aurabindo Pillai <aurabindo.pillai@amd.com>
Date:   Tue Apr 29 05:03:30 2025 +0800

    drm/amd/display: check stream id dml21 wrapper to get plane_id
    
    [ Upstream commit 2ddac70fed50485aa4ae49cdb7478ce41d8d4715 ]
    
    [Why & How]
    Fix a false positive warning which occurs due to lack of correct checks
    when querying plane_id in DML21. This fixes the warning when performing a
    mode1 reset (cat /sys/kernel/debug/dri/1/amdgpu_gpu_recover):
    
    [   35.751250] WARNING: CPU: 11 PID: 326 at /tmp/amd.PHpyAl7v/amd/amdgpu/../display/dc/dml2/dml2_dc_resource_mgmt.c:91 dml2_map_dc_pipes+0x243d/0x3f40 [amdgpu]
    [   35.751434] Modules linked in: amdgpu(OE) amddrm_ttm_helper(OE) amdttm(OE) amddrm_buddy(OE) amdxcp(OE) amddrm_exec(OE) amd_sched(OE) amdkcl(OE) drm_suballoc_helper drm_ttm_helper ttm drm_display_helper cec rc_core i2c_algo_bit rfcomm qrtr cmac algif_hash algif_skcipher af_alg bnep amd_atl intel_rapl_msr intel_rapl_common snd_hda_codec_hdmi snd_hda_intel edac_mce_amd snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec kvm_amd snd_hda_core snd_hwdep snd_pcm kvm snd_seq_midi snd_seq_midi_event snd_rawmidi crct10dif_pclmul polyval_clmulni polyval_generic btusb ghash_clmulni_intel sha256_ssse3 btrtl sha1_ssse3 snd_seq btintel aesni_intel btbcm btmtk snd_seq_device crypto_simd sunrpc cryptd bluetooth snd_timer ccp binfmt_misc rapl snd i2c_piix4 wmi_bmof gigabyte_wmi k10temp i2c_smbus soundcore gpio_amdpt mac_hid sch_fq_codel msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs ip_tables x_tables autofs4 hid_generic usbhid hid crc32_pclmul igc ahci xhci_pci libahci xhci_pci_renesas video wmi
    [   35.751501] CPU: 11 UID: 0 PID: 326 Comm: kworker/u64:9 Tainted: G           OE      6.11.0-21-generic #21~24.04.1-Ubuntu
    [   35.751504] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
    [   35.751505] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F30 05/22/2024
    [   35.751506] Workqueue: amdgpu-reset-dev amdgpu_debugfs_reset_work [amdgpu]
    [   35.751638] RIP: 0010:dml2_map_dc_pipes+0x243d/0x3f40 [amdgpu]
    [   35.751794] Code: 6d 0c 00 00 8b 84 24 88 00 00 00 41 3b 44 9c 20 0f 84 fc 07 00 00 48 83 c3 01 48 83 fb 06 75 b3 4c 8b 64 24 68 4c 8b 6c 24 40 <0f> 0b b8 06 00 00 00 49 8b 94 24 a0 49 00 00 89 c3 83 f8 07 0f 87
    [   35.751796] RSP: 0018:ffffbfa3805d7680 EFLAGS: 00010246
    [   35.751798] RAX: 0000000000010000 RBX: 0000000000000006 RCX: 0000000000000000
    [   35.751799] RDX: 0000000000000000 RSI: 0000000000000005 RDI: 0000000000000000
    [   35.751800] RBP: ffffbfa3805d78f0 R08: 0000000000000000 R09: 0000000000000000
    [   35.751801] R10: 0000000000000000 R11: 0000000000000000 R12: ffffbfa383249000
    [   35.751802] R13: ffffa0e68f280000 R14: ffffbfa383249658 R15: 0000000000000000
    [   35.751803] FS:  0000000000000000(0000) GS:ffffa0edbe580000(0000) knlGS:0000000000000000
    [   35.751804] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   35.751805] CR2: 00005d847ef96c58 CR3: 000000041de3e000 CR4: 0000000000f50ef0
    [   35.751806] PKRU: 55555554
    [   35.751807] Call Trace:
    [   35.751810]  <TASK>
    [   35.751816]  ? show_regs+0x6c/0x80
    [   35.751820]  ? __warn+0x88/0x140
    [   35.751822]  ? dml2_map_dc_pipes+0x243d/0x3f40 [amdgpu]
    [   35.751964]  ? report_bug+0x182/0x1b0
    [   35.751969]  ? handle_bug+0x6e/0xb0
    [   35.751972]  ? exc_invalid_op+0x18/0x80
    [   35.751974]  ? asm_exc_invalid_op+0x1b/0x20
    [   35.751978]  ? dml2_map_dc_pipes+0x243d/0x3f40 [amdgpu]
    [   35.752117]  ? math_pow+0x48/0xa0 [amdgpu]
    [   35.752256]  ? srso_alias_return_thunk+0x5/0xfbef5
    [   35.752260]  ? math_pow+0x48/0xa0 [amdgpu]
    [   35.752400]  ? srso_alias_return_thunk+0x5/0xfbef5
    [   35.752403]  ? math_pow+0x11/0xa0 [amdgpu]
    [   35.752524]  ? srso_alias_return_thunk+0x5/0xfbef5
    [   35.752526]  ? core_dcn4_mode_programming+0xe4d/0x20d0 [amdgpu]
    [   35.752663]  ? srso_alias_return_thunk+0x5/0xfbef5
    [   35.752669]  dml21_validate+0x3d4/0x980 [amdgpu]
    
    Reviewed-by: Austin Zheng <austin.zheng@amd.com>
    Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Signed-off-by: Ray Wu <ray.wu@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit f8ad62c0a93e5dd94243e10f1b742232e4d6411e)
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: fix link_set_dpms_off multi-display MST corner case [+ + +]
Author: George Shen <george.shen@amd.com>
Date:   Thu Apr 24 10:02:59 2025 -0400

    drm/amd/display: fix link_set_dpms_off multi-display MST corner case
    
    [ Upstream commit 3c1a467372e0c356b1d3c59f6d199ed5a6612dd1 ]
    
    [Why & How]
    When MST config is unplugged/replugged too quickly, it can potentially
    result in a scenario where previous DC state has not been reset before
    the HPD link detection sequence begins. In this case, driver will
    disable the streams/link prior to re-enabling the link for link
    training.
    
    There is a bug in the current logic that does not account for the fact
    that current_state can be released and cleared prior to swapping to a
    new state (resulting in the pipe_ctx stream pointers to be cleared) in
    between disabling streams.
    
    To resolve this, cache the original streams prior to committing any
    stream updates.
    
    Reviewed-by: Wenjing Liu <wenjing.liu@amd.com>
    Signed-off-by: George Shen <george.shen@amd.com>
    Signed-off-by: Ray Wu <ray.wu@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit 1561782686ccc36af844d55d31b44c938dd412dc)
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/xe/xe2hpg: Add Wa_22021007897 [+ + +]
Author: Aradhya Bhatia <aradhya.bhatia@intel.com>
Date:   Mon May 12 06:50:04 2025 +0000

    drm/xe/xe2hpg: Add Wa_22021007897
    
    [ Upstream commit b1f704107cf27906a9cea542b626b96019104663 ]
    
    Add Wa_22021007897 for the Xe2_HPG (graphics version: 20.01) IP. It is
    a permanent workaround, and applicable on all the steppings.
    
    Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
    Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
    Signed-off-by: Aradhya Bhatia <aradhya.bhatia@intel.com>
    Link: https://lore.kernel.org/r/20250512065004.2576-1-aradhya.bhatia@intel.com
    Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
    (cherry picked from commit e5c13e2c505b73a8667ef9a0fd5cbd4227e483e6)
    Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/xe: Save the gt pointer in lrc and drop the tile [+ + +]
Author: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Date:   Fri May 9 09:12:02 2025 -0700

    drm/xe: Save the gt pointer in lrc and drop the tile
    
    [ Upstream commit ce15563e49fb0b5c802564433ff8468acd1339eb ]
    
    Save the gt pointer in the lrc so that it can used for gt based helpers.
    
    Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
    Reviewed-by: Matthew Brost <matthew.brost@intel.com>
    Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
    Link: https://lore.kernel.org/r/20250509161159.2173069-7-umesh.nerlige.ramappa@intel.com
    (cherry picked from commit 741d3ef8b8b88fab2729ca89de1180e49bc9cef0)
    Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
gpio: virtuser: fix potential out-of-bound write [+ + +]
Author: Markus Burri <markus.burri@mt.com>
Date:   Fri May 9 17:04:59 2025 +0200

    gpio: virtuser: fix potential out-of-bound write
    
    [ Upstream commit 7118be7c6072f40391923543fdd1563b8d56377c ]
    
    If the caller wrote more characters, count is truncated to the max
    available space in "simple_write_to_buffer". Check that the input
    size does not exceed the buffer size. Write a zero termination
    afterwards.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202505091754.285hHbr2-lkp@intel.com/
    Signed-off-by: Markus Burri <markus.burri@mt.com>
    Link: https://lore.kernel.org/r/20250509150459.115489-1-markus.burri@mt.com
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
HID: quirks: Add ADATA XPG alpha wireless mouse support [+ + +]
Author: Milton Barrera <miltonjosue2001@gmail.com>
Date:   Wed Apr 9 00:04:28 2025 -0600

    HID: quirks: Add ADATA XPG alpha wireless mouse support
    
    [ Upstream commit fa9fdeea1b7d6440c22efa6d59a769eae8bc89f1 ]
    
    This patch adds HID_QUIRK_ALWAYS_POLL for the ADATA XPG wireless gaming mouse (USB ID 125f:7505) and its USB dongle (USB ID 125f:7506). Without this quirk, the device does not generate input events properly.
    
    Signed-off-by: Milton Barrera <miltonjosue2001@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ksmbd: use list_first_entry_or_null for opinfo_get_list() [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Tue May 20 09:25:03 2025 +0900

    ksmbd: use list_first_entry_or_null for opinfo_get_list()
    
    [ Upstream commit 10379171f346e6f61d30d9949500a8de4336444a ]
    
    The list_first_entry() macro never returns NULL.  If the list is
    empty then it returns an invalid pointer.  Use list_first_entry_or_null()
    to check if the list is empty.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Closes: https://lore.kernel.org/r/202505080231.7OXwq4Te-lkp@intel.com/
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

    Linux 6.12.32
    
    Link: https://lore.kernel.org/r/20250602134238.271281478@linuxfoundation.org
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Peter Schneider <pschneider1968@googlemail.com>
    Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Mark Brown <broonie@kernel.org>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Brett Mastbergen <bmastbergen@ciq.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Hardik Garg <hargar@linux.microsoft.com>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net: ethernet: ti: am65-cpsw: Lower random mac address error print to info [+ + +]
Author: Nishanth Menon <nm@ti.com>
Date:   Fri May 16 07:26:55 2025 -0500

    net: ethernet: ti: am65-cpsw: Lower random mac address error print to info
    
    [ Upstream commit 50980d8da71a0c2e045e85bba93c0099ab73a209 ]
    
    Using random mac address is not an error since the driver continues to
    function, it should be informative that the system has not assigned
    a MAC address. This is inline with other drivers such as ax88796c,
    dm9051 etc. Drop the error level to info level.
    
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Reviewed-by: Roger Quadros <rogerq@kernel.org>
    Link: https://patch.msgid.link/20250516122655.442808-1-nm@ti.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.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>

 
NFS: Avoid flushing data while holding directory locks in nfs_rename() [+ + +]
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Sun Apr 27 18:21:06 2025 -0400

    NFS: Avoid flushing data while holding directory locks in nfs_rename()
    
    [ Upstream commit dcd21b609d4abc7303f8683bce4f35d78d7d6830 ]
    
    The Linux client assumes that all filehandles are non-volatile for
    renames within the same directory (otherwise sillyrename cannot work).
    However, the existence of the Linux 'subtree_check' export option has
    meant that nfs_rename() has always assumed it needs to flush writes
    before attempting to rename.
    
    Since NFSv4 does allow the client to query whether or not the server
    exhibits this behaviour, and since knfsd does actually set the
    appropriate flag when 'subtree_check' is enabled on an export, it
    should be OK to optimise away the write flushing behaviour in the cases
    where it is clearly not needed.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nfs: don't share pNFS DS connections between net namespaces [+ + +]
Author: Jeff Layton <jlayton@kernel.org>
Date:   Thu Apr 10 16:42:03 2025 -0400

    nfs: don't share pNFS DS connections between net namespaces
    
    [ Upstream commit 6b9785dc8b13d9fb75ceec8cf4ea7ec3f3b1edbc ]
    
    Currently, different NFS clients can share the same DS connections, even
    when they are in different net namespaces. If a containerized client
    creates a DS connection, another container can find and use it. When the
    first client exits, the connection will close which can lead to stalls
    in other clients.
    
    Add a net namespace pointer to struct nfs4_pnfs_ds, and compare those
    value to the caller's netns in _data_server_lookup_locked() when
    searching for a nfs4_pnfs_ds to match.
    
    Reported-by: Omar Sandoval <osandov@osandov.com>
    Reported-by: Sargun Dillon <sargun@sargun.me>
    Closes: https://lore.kernel.org/linux-nfs/Z_ArpQC_vREh_hEA@telecaster/
    Tested-by: Sargun Dillon <sargun@sargun.me>
    Signed-off-by: Jeff Layton <jlayton@kernel.org>
    Reviewed-by: Benjamin Coddington <bcodding@redhat.com>
    Link: https://lore.kernel.org/r/20250410-nfs-ds-netns-v2-1-f80b7979ba80@kernel.org
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvme-pci: add NVME_QUIRK_NO_DEEPEST_PS quirk for SOLIDIGM P44 Pro [+ + +]
Author: Ilya Guterman <amfernusus@gmail.com>
Date:   Sat May 10 19:21:30 2025 +0900

    nvme-pci: add NVME_QUIRK_NO_DEEPEST_PS quirk for SOLIDIGM P44 Pro
    
    [ Upstream commit e765bf89f42b5c82132a556b630affeb82b2a21f ]
    
    This commit adds the NVME_QUIRK_NO_DEEPEST_PS quirk for device
    [126f:2262], which belongs to device SOLIDIGM P44 Pro SSDPFKKW020X7
    
    The device frequently have trouble exiting the deepest power state (5),
    resulting in the entire disk being unresponsive.
    
    Verified by setting nvme_core.default_ps_max_latency_us=10000 and
    observing the expected behavior.
    
    Signed-off-by: Ilya Guterman <amfernusus@gmail.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.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>

 
phy: phy-rockchip-samsung-hdptx: Fix PHY PLL output 50.25MHz error [+ + +]
Author: Algea Cao <algea.cao@rock-chips.com>
Date:   Sun Apr 27 17:51:24 2025 +0800

    phy: phy-rockchip-samsung-hdptx: Fix PHY PLL output 50.25MHz error
    
    [ Upstream commit f9475055b11c0c70979bd1667a76b2ebae638eb7 ]
    
    When using HDMI PLL frequency division coefficient at 50.25MHz
    that is calculated by rk_hdptx_phy_clk_pll_calc(), it fails to
    get PHY LANE lock. Although the calculated values are within the
    allowable range of PHY PLL configuration.
    
    In order to fix the PHY LANE lock error and provide the expected
    50.25MHz output, manually compute the required PHY PLL frequency
    division coefficient and add it to ropll_tmds_cfg configuration
    table.
    
    Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
    Reviewed-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
    Acked-by: Heiko Stuebner <heiko@sntech.de>
    Link: https://lore.kernel.org/r/20250427095124.3354439-1-algea.cao@rock-chips.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

phy: starfive: jh7110-usb: Fix USB 2.0 host occasional detection failure [+ + +]
Author: Hal Feng <hal.feng@starfivetech.com>
Date:   Tue Apr 22 18:12:44 2025 +0800

    phy: starfive: jh7110-usb: Fix USB 2.0 host occasional detection failure
    
    [ Upstream commit 3f097adb9b6c804636bcf8d01e0e7bc037bee0d3 ]
    
    JH7110 USB 2.0 host fails to detect USB 2.0 devices occasionally. With a
    long time of debugging and testing, we found that setting Rx clock gating
    control signal to normal power consumption mode can solve this problem.
    
    Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
    Link: https://lore.kernel.org/r/20250422101244.51686-1-hal.feng@starfivetech.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform/x86: fujitsu-laptop: Support Lifebook S2110 hotkeys [+ + +]
Author: Valtteri Koskivuori <vkoskiv@gmail.com>
Date:   Fri May 9 21:42:49 2025 +0300

    platform/x86: fujitsu-laptop: Support Lifebook S2110 hotkeys
    
    [ Upstream commit a7e255ff9fe4d9b8b902023aaf5b7a673786bb50 ]
    
    The S2110 has an additional set of media playback control keys enabled
    by a hardware toggle button that switches the keys between "Application"
    and "Player" modes. Toggling "Player" mode just shifts the scancode of
    each hotkey up by 4.
    
    Add defines for new scancodes, and a keymap and dmi id for the S2110.
    
    Tested on a Fujitsu Lifebook S2110.
    
    Signed-off-by: Valtteri Koskivuori <vkoskiv@gmail.com>
    Acked-by: Jonathan Woithe <jwoithe@just42.net>
    Link: https://lore.kernel.org/r/20250509184251.713003-1-vkoskiv@gmail.com
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86: thinkpad_acpi: Ignore battery threshold change event notification [+ + +]
Author: Mark Pearson <mpearson-lenovo@squebb.ca>
Date:   Fri May 16 22:33:37 2025 -0400

    platform/x86: thinkpad_acpi: Ignore battery threshold change event notification
    
    [ Upstream commit 29e4e6b4235fefa5930affb531fe449cac330a72 ]
    
    If user modifies the battery charge threshold an ACPI event is generated.
    Confirmed with Lenovo FW team this is only generated on user event. As no
    action is needed, ignore the event and prevent spurious kernel logs.
    
    Reported-by: Derek Barbosa <debarbos@redhat.com>
    Closes: https://lore.kernel.org/platform-driver-x86/7e9a1c47-5d9c-4978-af20-3949d53fb5dc@app.fastmail.com/T/#m5f5b9ae31d3fbf30d7d9a9d76c15fb3502dfd903
    Signed-off-by: Mark Pearson <mpearson-lenovo@squebb.ca>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Armin Wolf <W_Armin@gmx.de>
    Link: https://lore.kernel.org/r/20250517023348.2962591-1-mpearson-lenovo@squebb.ca
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86: thinkpad_acpi: Support also NEC Lavie X1475JAS [+ + +]
Author: John Chau <johnchau@0atlas.com>
Date:   Mon May 5 01:55:13 2025 +0900

    platform/x86: thinkpad_acpi: Support also NEC Lavie X1475JAS
    
    [ Upstream commit a032f29a15412fab9f4352e0032836d51420a338 ]
    
    Change get_thinkpad_model_data() to check for additional vendor name
    "NEC" in order to support NEC Lavie X1475JAS notebook (and perhaps
    more).
    
    The reason of this works with minimal changes is because NEC Lavie
    X1475JAS is a Thinkpad inside. ACPI dumps reveals its OEM ID to be
    "LENOVO", BIOS version "R2PET30W" matches typical Lenovo BIOS version,
    the existence of HKEY of LEN0268, with DMI fw string is "R2PHT24W".
    
    I compiled and tested with my own machine, attached the dmesg
    below as proof of work:
    [    6.288932] thinkpad_acpi: ThinkPad ACPI Extras v0.26
    [    6.288937] thinkpad_acpi: http://ibm-acpi.sf.net/
    [    6.288938] thinkpad_acpi: ThinkPad BIOS R2PET30W (1.11 ), EC R2PHT24W
    [    6.307000] thinkpad_acpi: radio switch found; radios are enabled
    [    6.307030] thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness control, supported by the ACPI video driver
    [    6.307033] thinkpad_acpi: Disabling thinkpad-acpi brightness events by default...
    [    6.320322] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked
    [    6.371963] thinkpad_acpi: secondary fan control detected & enabled
    [    6.391922] thinkpad_acpi: battery 1 registered (start 0, stop 85, behaviours: 0x7)
    [    6.398375] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input13
    
    Signed-off-by: John Chau <johnchau@0atlas.com>
    Link: https://lore.kernel.org/r/20250504165513.295135-1-johnchau@0atlas.com
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
spi: spi-sun4i: fix early activation [+ + +]
Author: Alessandro Grassi <alessandro.grassi@mailbox.org>
Date:   Fri May 2 11:55:20 2025 +0200

    spi: spi-sun4i: fix early activation
    
    [ Upstream commit fb98bd0a13de2c9d96cb5c00c81b5ca118ac9d71 ]
    
    The SPI interface is activated before the CPOL setting is applied. In
    that moment, the clock idles high and CS goes low. After a short delay,
    CPOL and other settings are applied, which may cause the clock to change
    state and idle low. This transition is not part of a clock cycle, and it
    can confuse the receiving device.
    
    To prevent this unexpected transition, activate the interface while CPOL
    and the other settings are being applied.
    
    Signed-off-by: Alessandro Grassi <alessandro.grassi@mailbox.org>
    Link: https://patch.msgid.link/20250502095520.13825-1-alessandro.grassi@mailbox.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
um: let 'make clean' properly clean underlying SUBARCH as well [+ + +]
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Wed May 7 16:49:33 2025 +0900

    um: let 'make clean' properly clean underlying SUBARCH as well
    
    [ Upstream commit ab09da75700e9d25c7dfbc7f7934920beb5e39b9 ]
    
    Building the kernel with O= is affected by stale in-tree build artifacts.
    
    So, if the source tree is not clean, Kbuild displays the following:
    
      $ make ARCH=um O=build defconfig
      make[1]: Entering directory '/.../linux/build'
      ***
      *** The source tree is not clean, please run 'make ARCH=um mrproper'
      *** in /.../linux
      ***
      make[2]: *** [/.../linux/Makefile:673: outputmakefile] Error 1
      make[1]: *** [/.../linux/Makefile:248: __sub-make] Error 2
      make[1]: Leaving directory '/.../linux/build'
      make: *** [Makefile:248: __sub-make] Error 2
    
    Usually, running 'make mrproper' is sufficient for cleaning the source
    tree for out-of-tree builds.
    
    However, building UML generates build artifacts not only in arch/um/,
    but also in the SUBARCH directory (i.e., arch/x86/). If in-tree stale
    files remain under arch/x86/, Kbuild will reuse them instead of creating
    new ones under the specified build directory.
    
    This commit makes 'make ARCH=um clean' recurse into the SUBARCH directory.
    
    Reported-by: Shuah Khan <skhan@linuxfoundation.org>
    Closes: https://lore.kernel.org/lkml/20250502172459.14175-1-skhan@linuxfoundation.org/
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Acked-by: Johannes Berg <johannes@sipsolutions.net>
    Reviewed-by: David Gow <davidgow@google.com>
    Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>