--- /dev/null
+From f2bc2afe34c107a02ce829a4039e85514feafe55 Mon Sep 17 00:00:00 2001
+From: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
+Date: Wed, 29 Jan 2025 13:40:08 +0100
+Subject: accel/ivpu: Clear runtime_error after pm_runtime_resume_and_get() fails
+
+From: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
+
+commit f2bc2afe34c107a02ce829a4039e85514feafe55 upstream.
+
+pm_runtime_resume_and_get() sets dev->power.runtime_error that causes
+all subsequent pm_runtime_get_sync() calls to fail.
+Clear the runtime_error using pm_runtime_set_suspended(), so the driver
+doesn't have to be reloaded to recover when the NPU fails to boot during
+runtime resume.
+
+Fixes: 7d4b4c74432d ("accel/ivpu: Remove suspend_reschedule_counter")
+Cc: stable@vger.kernel.org # v6.11+
+Reviewed-by: Maciej Falkowski <maciej.falkowski@linux.intel.com>
+Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
+Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20250129124009.1039982-3-jacek.lawrynowicz@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/accel/ivpu/ivpu_pm.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/accel/ivpu/ivpu_pm.c
++++ b/drivers/accel/ivpu/ivpu_pm.c
+@@ -295,7 +295,10 @@ int ivpu_rpm_get(struct ivpu_device *vde
+ int ret;
+
+ ret = pm_runtime_resume_and_get(vdev->drm.dev);
+- drm_WARN_ON(&vdev->drm, ret < 0);
++ if (ret < 0) {
++ ivpu_err(vdev, "Failed to resume NPU: %d\n", ret);
++ pm_runtime_set_suspended(vdev->drm.dev);
++ }
+
+ return ret;
+ }
--- /dev/null
+From 7f5704b6a143b8eca640cba820968e798d065e91 Mon Sep 17 00:00:00 2001
+From: Aubrey Li <aubrey.li@linux.intel.com>
+Date: Sun, 26 Jan 2025 10:22:50 +0800
+Subject: ACPI: PRM: Remove unnecessary strict handler address checks
+
+From: Aubrey Li <aubrey.li@linux.intel.com>
+
+commit 7f5704b6a143b8eca640cba820968e798d065e91 upstream.
+
+Commit 088984c8d54c ("ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM
+handler and context") added unnecessary strict handler address checks,
+causing the PRM module to fail in translating memory error addresses.
+
+Both static data buffer address and ACPI parameter buffer address may
+be NULL if they are not needed, as described in section 4.1.2 PRM Handler
+Information Structure of Platform Runtime Mechanism specification [1].
+
+Here are two examples from real hardware:
+
+----PRMT.dsl----
+
+- staic data address is not used
+[10Ch 0268 2] Revision : 0000
+[10Eh 0270 2] Length : 002C
+[110h 0272 16] Handler GUID : F6A58D47-E04F-4F5A-86B8-2A50D4AA109B
+[120h 0288 8] Handler address : 0000000065CE51F4
+[128h 0296 8] Satic Data Address : 0000000000000000
+[130h 0304 8] ACPI Parameter Address : 000000006522A718
+
+- ACPI parameter address is not used
+[1B0h 0432 2] Revision : 0000
+[1B2h 0434 2] Length : 002C
+[1B4h 0436 16] Handler GUID : 657E8AE6-A8FC-4877-BB28-42E7DE1899A5
+[1C4h 0452 8] Handler address : 0000000065C567C8
+[1CCh 0460 8] Satic Data Address : 000000006113FB98
+[1D4h 0468 8] ACPI Parameter Address : 0000000000000000
+
+Fixes: 088984c8d54c ("ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context")
+Reported-and-tested-by: Shi Liu <aurelianliu@tencent.com>
+Cc: All applicable <stable@vger.kernel.org>
+Signed-off-by: Aubrey Li <aubrey.li@linux.intel.com>
+Link: https://uefi.org/sites/default/files/resources/Platform%20Runtime%20Mechanism%20-%20with%20legal%20notice.pdf # [1]
+Reviewed-by: Koba Ko <kobak@nvidia.com>
+Acked-by: Ard Biesheuvel <ardb@kernel.org>
+Link: https://patch.msgid.link/20250126022250.3014210-1-aubrey.li@linux.intel.com
+[ rjw: Minor changelog edits ]
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/prmt.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/drivers/acpi/prmt.c
++++ b/drivers/acpi/prmt.c
+@@ -287,9 +287,7 @@ static acpi_status acpi_platformrt_space
+ if (!handler || !module)
+ goto invalid_guid;
+
+- if (!handler->handler_addr ||
+- !handler->static_data_buffer_addr ||
+- !handler->acpi_param_buffer_addr) {
++ if (!handler->handler_addr) {
+ buffer->prm_status = PRM_HANDLER_ERROR;
+ return AE_OK;
+ }
--- /dev/null
+From c1472ec1dc4419d0bae663c1a1e6cb98dc7881ad Mon Sep 17 00:00:00 2001
+From: Romain Naour <romain.naour@skf.com>
+Date: Fri, 15 Nov 2024 11:25:37 +0100
+Subject: ARM: dts: dra7: Add bus_dma_limit for l4 cfg bus
+
+From: Romain Naour <romain.naour@skf.com>
+
+commit c1472ec1dc4419d0bae663c1a1e6cb98dc7881ad upstream.
+
+A bus_dma_limit was added for l3 bus by commit cfb5d65f2595
+("ARM: dts: dra7: Add bus_dma_limit for L3 bus") to fix an issue
+observed only with SATA on DRA7-EVM with 4GB RAM and CONFIG_ARM_LPAE
+enabled.
+
+Since kernel 5.13, the SATA issue can be reproduced again following
+the SATA node move from L3 bus to L4_cfg in commit 8af15365a368
+("ARM: dts: Configure interconnect target module for dra7 sata").
+
+Fix it by adding an empty dma-ranges property to l4_cfg and
+segment@100000 nodes (parent device tree node of SATA controller) to
+inherit the 2GB dma ranges limit from l3 bus node.
+
+Note: A similar fix was applied for PCIe controller by commit
+90d4d3f4ea45 ("ARM: dts: dra7: Fix bus_dma_limit for PCIe").
+
+Fixes: 8af15365a368 ("ARM: dts: Configure interconnect target module for dra7 sata").
+Link: https://lore.kernel.org/linux-omap/c583e1bb-f56b-4489-8012-ce742e85f233@smile.fr/
+Cc: stable@vger.kernel.org # 5.13
+Signed-off-by: Romain Naour <romain.naour@skf.com>
+Link: https://lore.kernel.org/r/20241115102537.1330300-1-romain.naour@smile.fr
+Signed-off-by: Kevin Hilman <khilman@baylibre.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm/boot/dts/ti/omap/dra7-l4.dtsi | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi
++++ b/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi
+@@ -12,6 +12,7 @@
+ ranges = <0x00000000 0x4a000000 0x100000>, /* segment 0 */
+ <0x00100000 0x4a100000 0x100000>, /* segment 1 */
+ <0x00200000 0x4a200000 0x100000>; /* segment 2 */
++ dma-ranges;
+
+ segment@0 { /* 0x4a000000 */
+ compatible = "simple-pm-bus";
+@@ -557,6 +558,7 @@
+ <0x0007e000 0x0017e000 0x001000>, /* ap 124 */
+ <0x00059000 0x00159000 0x001000>, /* ap 125 */
+ <0x0005a000 0x0015a000 0x001000>; /* ap 126 */
++ dma-ranges;
+
+ target-module@2000 { /* 0x4a102000, ap 27 3c.0 */
+ compatible = "ti,sysc";
--- /dev/null
+From 0cfbd7805fe13406500e6a6f2aa08f198d5db4bd Mon Sep 17 00:00:00 2001
+From: Andreas Kemnade <andreas@kemnade.info>
+Date: Wed, 4 Dec 2024 18:41:52 +0100
+Subject: ARM: dts: ti/omap: gta04: fix pm issues caused by spi module
+
+From: Andreas Kemnade <andreas@kemnade.info>
+
+commit 0cfbd7805fe13406500e6a6f2aa08f198d5db4bd upstream.
+
+Despite CM_IDLEST1_CORE and CM_FCLKEN1_CORE behaving normal,
+disabling SPI leads to messages like when suspending:
+Powerdomain (core_pwrdm) didn't enter target state 0
+and according to /sys/kernel/debug/pm_debug/count off state is not
+entered. That was not connected to SPI during the discussion
+of disabling SPI. See:
+https://lore.kernel.org/linux-omap/20230122100852.32ae082c@aktux/
+
+The reason is that SPI is per default in slave mode. Linux driver
+will turn it to master per default. It slave mode, the powerdomain seems to
+be kept active if active chip select input is sensed.
+
+Fix that by explicitly disabling the SPI3 pins which used to be muxed by
+the bootloader since they are available on an optionally fitted header
+which would require dtb overlays anyways.
+
+Fixes: a622310f7f01 ("ARM: dts: gta04: fix excess dma channel usage")
+CC: stable@vger.kernel.org
+Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
+Reviewed-by: Roger Quadros <rogerq@kernel.org>
+Link: https://lore.kernel.org/r/20241204174152.2360431-1-andreas@kemnade.info
+Signed-off-by: Kevin Hilman <khilman@baylibre.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi
++++ b/arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi
+@@ -446,6 +446,7 @@
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &hsusb2_2_pins
++ &mcspi3hog_pins
+ >;
+
+ hsusb2_2_pins: hsusb2-2-pins {
+@@ -459,6 +460,15 @@
+ >;
+ };
+
++ mcspi3hog_pins: mcspi3hog-pins {
++ pinctrl-single,pins = <
++ OMAP3630_CORE2_IOPAD(0x25dc, PIN_OUTPUT_PULLDOWN | MUX_MODE4) /* etk_d0 */
++ OMAP3630_CORE2_IOPAD(0x25de, PIN_OUTPUT_PULLDOWN | MUX_MODE4) /* etk_d1 */
++ OMAP3630_CORE2_IOPAD(0x25e0, PIN_OUTPUT_PULLDOWN | MUX_MODE4) /* etk_d2 */
++ OMAP3630_CORE2_IOPAD(0x25e2, PIN_OUTPUT_PULLDOWN | MUX_MODE4) /* etk_d3 */
++ >;
++ };
++
+ spi_gpio_pins: spi-gpio-pinmux-pins {
+ pinctrl-single,pins = <
+ OMAP3630_CORE2_IOPAD(0x25d8, PIN_OUTPUT | MUX_MODE4) /* clk */
--- /dev/null
+From 93a680af46436780fd64f4e856a4cfa8b393be6e Mon Sep 17 00:00:00 2001
+From: Chen-Yu Tsai <wenst@chromium.org>
+Date: Fri, 25 Oct 2024 15:56:27 +0800
+Subject: arm64: dts: mediatek: mt8183: Disable DPI display output by default
+
+From: Chen-Yu Tsai <wenst@chromium.org>
+
+commit 93a680af46436780fd64f4e856a4cfa8b393be6e upstream.
+
+This reverts commit 377548f05bd0905db52a1d50e5b328b9b4eb049d.
+
+Most SoC dtsi files have the display output interfaces disabled by
+default, and only enabled on boards that utilize them. The MT8183
+has it backwards: the display outputs are left enabled by default,
+and only disabled at the board level.
+
+Reverse the situation for the DPI output so that it follows the
+normal scheme. For ease of backporting the DSI output is handled
+in a separate patch.
+
+Fixes: 009d855a26fd ("arm64: dts: mt8183: add dpi node to mt8183")
+Fixes: 377548f05bd0 ("arm64: dts: mediatek: mt8183-kukui: Disable DPI display interface")
+Cc: stable@vger.kernel.org
+Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
+Reviewed-by: Fei Shao <fshao@chromium.org>
+Link: https://lore.kernel.org/r/20241025075630.3917458-1-wenst@chromium.org
+Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 5 -----
+ arch/arm64/boot/dts/mediatek/mt8183.dtsi | 1 +
+ 2 files changed, 1 insertion(+), 5 deletions(-)
+
+--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
++++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
+@@ -290,11 +290,6 @@
+ };
+ };
+
+-&dpi0 {
+- /* TODO Re-enable after DP to Type-C port muxing can be described */
+- status = "disabled";
+-};
+-
+ &gic {
+ mediatek,broken-save-restore-fw;
+ };
+--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
++++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+@@ -1846,6 +1846,7 @@
+ <&mmsys CLK_MM_DPI_MM>,
+ <&apmixedsys CLK_APMIXED_TVDPLL>;
+ clock-names = "pixel", "engine", "pll";
++ status = "disabled";
+
+ port {
+ dpi_out: endpoint { };
--- /dev/null
+From 9a27f0e1869e992e4107e2af8ec348e1a3b9d4d5 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Fri, 13 Dec 2024 15:54:09 +0100
+Subject: arm64: dts: qcom: sdx75: Fix MPSS memory length
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit 9a27f0e1869e992e4107e2af8ec348e1a3b9d4d5 upstream.
+
+The address space in MPSS/Modem PAS (Peripheral Authentication Service)
+remoteproc node should point to the QDSP PUB address space
+(QDSP6...SS_PUB) which has a length of 0x10000. Value of 0x4040 was
+copied from older DTS, but it grew since then.
+
+This should have no functional impact on Linux users, because PAS loader
+does not use this address space at all.
+
+Cc: stable@vger.kernel.org
+Fixes: 41c72f36b286 ("arm64: dts: qcom: sdx75: Add remoteproc node")
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-20-2e0036fccd8d@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sdx75.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/arm64/boot/dts/qcom/sdx75.dtsi b/arch/arm64/boot/dts/qcom/sdx75.dtsi
+index 06d956f5cd4e..b0a8a0fe5f39 100644
+--- a/arch/arm64/boot/dts/qcom/sdx75.dtsi
++++ b/arch/arm64/boot/dts/qcom/sdx75.dtsi
+@@ -893,7 +893,7 @@ tcsr: syscon@1fc0000 {
+
+ remoteproc_mpss: remoteproc@4080000 {
+ compatible = "qcom,sdx75-mpss-pas";
+- reg = <0 0x04080000 0 0x4040>;
++ reg = <0 0x04080000 0 0x10000>;
+
+ interrupts-extended = <&intc GIC_SPI 250 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_modem_in 0 IRQ_TYPE_EDGE_RISING>,
+--
+2.48.1
+
--- /dev/null
+From 47d178caac3ec13f5f472afda25fcfdfaa00d0da Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Fri, 13 Dec 2024 15:54:12 +0100
+Subject: arm64: dts: qcom: sm6115: Fix ADSP memory base and length
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit 47d178caac3ec13f5f472afda25fcfdfaa00d0da upstream.
+
+The address space in ADSP PAS (Peripheral Authentication Service)
+remoteproc node should point to the QDSP PUB address space
+(QDSP6...SS_PUB): 0x0a40_0000 with length of 0x4040.
+
+0x0ab0_0000, value used so far, is the SSC_QUPV3 block, so entierly
+unrelated.
+
+Correct the base address and length, which should have no functional
+impact on Linux users, because PAS loader does not use this address
+space at all.
+
+Cc: stable@vger.kernel.org
+Fixes: 96ce9227fdbc ("arm64: dts: qcom: sm6115: Add remoteproc nodes")
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-23-2e0036fccd8d@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sm6115.dtsi | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/arm64/boot/dts/qcom/sm6115.dtsi
++++ b/arch/arm64/boot/dts/qcom/sm6115.dtsi
+@@ -2670,9 +2670,9 @@
+ };
+ };
+
+- remoteproc_adsp: remoteproc@ab00000 {
++ remoteproc_adsp: remoteproc@a400000 {
+ compatible = "qcom,sm6115-adsp-pas";
+- reg = <0x0 0x0ab00000 0x0 0x100>;
++ reg = <0x0 0x0a400000 0x0 0x4040>;
+
+ interrupts-extended = <&intc GIC_SPI 282 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
--- /dev/null
+From 846f49c3f01680f4af3043bf5b7abc9cf71bb42d Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Fri, 13 Dec 2024 15:54:11 +0100
+Subject: arm64: dts: qcom: sm6115: Fix CDSP memory length
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit 846f49c3f01680f4af3043bf5b7abc9cf71bb42d upstream.
+
+The address space in MPSS/Modem PAS (Peripheral Authentication Service)
+remoteproc node should point to the QDSP PUB address space
+(QDSP6...SS_PUB) which has a length of 0x4040. Value of 0x100000 covers
+entire Touring/CDSP memory block seems to big here.
+
+This should have no functional impact on Linux users, because PAS loader
+does not use this address space at all.
+
+Cc: stable@vger.kernel.org
+Fixes: 96ce9227fdbc ("arm64: dts: qcom: sm6115: Add remoteproc nodes")
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-22-2e0036fccd8d@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sm6115.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/qcom/sm6115.dtsi
++++ b/arch/arm64/boot/dts/qcom/sm6115.dtsi
+@@ -2744,7 +2744,7 @@
+
+ remoteproc_cdsp: remoteproc@b300000 {
+ compatible = "qcom,sm6115-cdsp-pas";
+- reg = <0x0 0x0b300000 0x0 0x100000>;
++ reg = <0x0 0x0b300000 0x0 0x4040>;
+
+ interrupts-extended = <&intc GIC_SPI 265 IRQ_TYPE_EDGE_RISING>,
+ <&cdsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
--- /dev/null
+From 472d65e7cb591c8379dd6f40561f96be73a46f0f Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Fri, 13 Dec 2024 15:54:10 +0100
+Subject: arm64: dts: qcom: sm6115: Fix MPSS memory length
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit 472d65e7cb591c8379dd6f40561f96be73a46f0f upstream.
+
+The address space in MPSS/Modem PAS (Peripheral Authentication Service)
+remoteproc node should point to the QDSP PUB address space
+(QDSP6...SS_PUB) which has a length of 0x10000. Value of 0x100 was
+copied from older DTS, but it grew since then.
+
+This should have no functional impact on Linux users, because PAS loader
+does not use this address space at all.
+
+Cc: stable@vger.kernel.org
+Fixes: 96ce9227fdbc ("arm64: dts: qcom: sm6115: Add remoteproc nodes")
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-21-2e0036fccd8d@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sm6115.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/qcom/sm6115.dtsi
++++ b/arch/arm64/boot/dts/qcom/sm6115.dtsi
+@@ -2027,7 +2027,7 @@
+
+ remoteproc_mpss: remoteproc@6080000 {
+ compatible = "qcom,sm6115-mpss-pas";
+- reg = <0x0 0x06080000 0x0 0x100>;
++ reg = <0x0 0x06080000 0x0 0x10000>;
+
+ interrupts-extended = <&intc GIC_SPI 307 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
--- /dev/null
+From b0805a864459a29831577d2a47165afebe338faf Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Fri, 13 Dec 2024 15:54:04 +0100
+Subject: arm64: dts: qcom: sm6350: Fix ADSP memory length
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit b0805a864459a29831577d2a47165afebe338faf upstream.
+
+The address space in ADSP (Peripheral Authentication Service) remoteproc
+node should point to the QDSP PUB address space (QDSP6...SS_PUB) which
+has a length of 0x10000.
+
+This should have no functional impact on Linux users, because PAS loader
+does not use this address space at all.
+
+Fixes: efc33c969f23 ("arm64: dts: qcom: sm6350: Add ADSP nodes")
+Cc: stable@vger.kernel.org
+Tested-by: Luca Weiss <luca.weiss@fairphone.com>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-15-2e0036fccd8d@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sm6350.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/qcom/sm6350.dtsi
++++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi
+@@ -1283,7 +1283,7 @@
+
+ adsp: remoteproc@3000000 {
+ compatible = "qcom,sm6350-adsp-pas";
+- reg = <0 0x03000000 0 0x100>;
++ reg = <0x0 0x03000000 0x0 0x10000>;
+
+ interrupts-extended = <&pdc 6 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 0 IRQ_TYPE_EDGE_RISING>,
--- /dev/null
+From cd8d83de9cc9ecfb1f9a12bc838041c4eb4d10bd Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Fri, 13 Dec 2024 15:54:05 +0100
+Subject: arm64: dts: qcom: sm6350: Fix MPSS memory length
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit cd8d83de9cc9ecfb1f9a12bc838041c4eb4d10bd upstream.
+
+The address space in MPSS/Modem PAS (Peripheral Authentication Service)
+remoteproc node should point to the QDSP PUB address space
+(QDSP6...SS_PUB) which has a length of 0x10000. Value of 0x4040 was
+copied from older DTS, but it grew since then.
+
+This should have no functional impact on Linux users, because PAS loader
+does not use this address space at all.
+
+Fixes: 489be59b635b ("arm64: dts: qcom: sm6350: Add MPSS nodes")
+Cc: stable@vger.kernel.org
+Tested-by: Luca Weiss <luca.weiss@fairphone.com>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-16-2e0036fccd8d@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sm6350.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/qcom/sm6350.dtsi
++++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi
+@@ -1503,7 +1503,7 @@
+
+ mpss: remoteproc@4080000 {
+ compatible = "qcom,sm6350-mpss-pas";
+- reg = <0x0 0x04080000 0x0 0x4040>;
++ reg = <0x0 0x04080000 0x0 0x10000>;
+
+ interrupts-extended = <&intc GIC_SPI 136 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
--- /dev/null
+From be2f81eaa2c8e81d3de5b73dca5e133f63384cb3 Mon Sep 17 00:00:00 2001
+From: Luca Weiss <luca.weiss@fairphone.com>
+Date: Fri, 20 Dec 2024 09:59:50 +0100
+Subject: arm64: dts: qcom: sm6350: Fix uart1 interconnect path
+
+From: Luca Weiss <luca.weiss@fairphone.com>
+
+commit be2f81eaa2c8e81d3de5b73dca5e133f63384cb3 upstream.
+
+The path MASTER_QUP_0 to SLAVE_EBI_CH0 would be qup-memory path and not
+qup-config. Since the qup-memory path is not part of the qcom,geni-uart
+bindings, just replace that path with the correct path for qup-config.
+
+Fixes: b179f35b887b ("arm64: dts: qcom: sm6350: add uart1 node")
+Cc: stable@vger.kernel.org
+Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Link: https://lore.kernel.org/r/20241220-sm6350-uart1-icc-v1-1-f4f10fd91adf@fairphone.com
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sm6350.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/qcom/sm6350.dtsi
++++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi
+@@ -936,7 +936,7 @@
+ power-domains = <&rpmhpd SM6350_CX>;
+ operating-points-v2 = <&qup_opp_table>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_0 0 &clk_virt SLAVE_QUP_CORE_0 0>,
+- <&aggre1_noc MASTER_QUP_0 0 &clk_virt SLAVE_EBI_CH0 0>;
++ <&gem_noc MASTER_AMPSS_M0 0 &config_noc SLAVE_QUP_0 0>;
+ interconnect-names = "qup-core", "qup-config";
+ status = "disabled";
+ };
--- /dev/null
+From bf4dda83da27b7efc49326ebb82cbd8b3e637c38 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Fri, 13 Dec 2024 15:54:06 +0100
+Subject: arm64: dts: qcom: sm6375: Fix ADSP memory length
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit bf4dda83da27b7efc49326ebb82cbd8b3e637c38 upstream.
+
+The address space in ADSP (Peripheral Authentication Service) remoteproc
+node should point to the QDSP PUB address space (QDSP6...SS_PUB) which
+has a length of 0x10000.
+
+This should have no functional impact on Linux users, because PAS loader
+does not use this address space at all.
+
+Fixes: fe6fd26aeddf ("arm64: dts: qcom: sm6375: Add ADSP&CDSP")
+Cc: stable@vger.kernel.org
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-17-2e0036fccd8d@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sm6375.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/qcom/sm6375.dtsi
++++ b/arch/arm64/boot/dts/qcom/sm6375.dtsi
+@@ -1559,7 +1559,7 @@
+
+ remoteproc_adsp: remoteproc@a400000 {
+ compatible = "qcom,sm6375-adsp-pas";
+- reg = <0 0x0a400000 0 0x100>;
++ reg = <0 0x0a400000 0 0x10000>;
+
+ interrupts-extended = <&intc GIC_SPI 282 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 0 IRQ_TYPE_EDGE_RISING>,
--- /dev/null
+From c9f7f341e896836c99709421a23bae5f53039aab Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Fri, 13 Dec 2024 15:54:07 +0100
+Subject: arm64: dts: qcom: sm6375: Fix CDSP memory base and length
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit c9f7f341e896836c99709421a23bae5f53039aab upstream.
+
+The address space in CDSP PAS (Peripheral Authentication Service)
+remoteproc node should point to the QDSP PUB address space
+(QDSP6...SS_PUB): 0x0b30_0000 with length of 0x10000.
+
+0x0b00_0000, value used so far, is the main region of CDSP.
+
+Correct the base address and length, which should have no functional
+impact on Linux users, because PAS loader does not use this address
+space at all.
+
+Fixes: fe6fd26aeddf ("arm64: dts: qcom: sm6375: Add ADSP&CDSP")
+Cc: stable@vger.kernel.org
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-18-2e0036fccd8d@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sm6375.dtsi | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/arm64/boot/dts/qcom/sm6375.dtsi
++++ b/arch/arm64/boot/dts/qcom/sm6375.dtsi
+@@ -1595,9 +1595,9 @@
+ };
+ };
+
+- remoteproc_cdsp: remoteproc@b000000 {
++ remoteproc_cdsp: remoteproc@b300000 {
+ compatible = "qcom,sm6375-cdsp-pas";
+- reg = <0x0 0x0b000000 0x0 0x100000>;
++ reg = <0x0 0x0b300000 0x0 0x10000>;
+
+ interrupts-extended = <&intc GIC_SPI 265 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_cdsp_in 0 IRQ_TYPE_EDGE_RISING>,
--- /dev/null
+From 918e71ba0c08c3d609ad69067854b0f675c4a253 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Fri, 13 Dec 2024 15:54:08 +0100
+Subject: arm64: dts: qcom: sm6375: Fix MPSS memory base and length
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit 918e71ba0c08c3d609ad69067854b0f675c4a253 upstream.
+
+The address space in MPSS/Modem PAS (Peripheral Authentication Service)
+remoteproc node should point to the QDSP PUB address space
+(QDSP6...SS_PUB): 0x0608_0000 with length of 0x10000.
+
+0x0600_0000, value used so far, is the main region of Modem.
+
+Correct the base address and length, which should have no functional
+impact on Linux users, because PAS loader does not use this address
+space at all.
+
+Fixes: 31cc61104f68 ("arm64: dts: qcom: sm6375: Add modem nodes")
+Cc: stable@vger.kernel.org
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-19-2e0036fccd8d@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sm6375.dtsi | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/arm64/boot/dts/qcom/sm6375.dtsi
++++ b/arch/arm64/boot/dts/qcom/sm6375.dtsi
+@@ -1516,9 +1516,9 @@
+ #power-domain-cells = <1>;
+ };
+
+- remoteproc_mss: remoteproc@6000000 {
++ remoteproc_mss: remoteproc@6080000 {
+ compatible = "qcom,sm6375-mpss-pas";
+- reg = <0 0x06000000 0 0x4040>;
++ reg = <0x0 0x06080000 0x0 0x10000>;
+
+ interrupts-extended = <&intc GIC_SPI 307 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_modem_in 0 IRQ_TYPE_EDGE_RISING>,
--- /dev/null
+From f9ba85566ddd5a3db8fa291aaecd70c4e55a3732 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Fri, 13 Dec 2024 15:53:50 +0100
+Subject: arm64: dts: qcom: sm8350: Fix ADSP memory base and length
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit f9ba85566ddd5a3db8fa291aaecd70c4e55a3732 upstream.
+
+The address space in ADSP PAS (Peripheral Authentication Service)
+remoteproc node should point to the QDSP PUB address space
+(QDSP6...SS_PUB): 0x0300_0000 with length of 0x10000. 0x1730_0000,
+value used so far, was copied from downstream DTS, is in the middle of
+unused space and downstream DTS describes the PIL loader, which is a bit
+different interface.
+
+Assume existing value (thus downstream DTS) is not really describing the
+intended ADSP PAS region.
+
+Correct the base address and length, which also moves the node to
+different place to keep things sorted by unit address. The diff looks
+big, but only the unit address and "reg" property were changed. This
+should have no functional impact on Linux users, because PAS loader does
+not use this address space at all.
+
+Fixes: 177fcf0aeda2 ("arm64: dts: qcom: sm8350: Add remoteprocs")
+Cc: stable@vger.kernel.org
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-1-2e0036fccd8d@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sm8350.dtsi | 272 +++++++++++++++++------------------
+ 1 file changed, 136 insertions(+), 136 deletions(-)
+
+--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
++++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
+@@ -1876,6 +1876,142 @@
+ reg = <0x0 0x1fc0000 0x0 0x30000>;
+ };
+
++ adsp: remoteproc@3000000 {
++ compatible = "qcom,sm8350-adsp-pas";
++ reg = <0x0 0x03000000 0x0 0x10000>;
++
++ interrupts-extended = <&pdc 6 IRQ_TYPE_EDGE_RISING>,
++ <&smp2p_adsp_in 0 IRQ_TYPE_EDGE_RISING>,
++ <&smp2p_adsp_in 1 IRQ_TYPE_EDGE_RISING>,
++ <&smp2p_adsp_in 2 IRQ_TYPE_EDGE_RISING>,
++ <&smp2p_adsp_in 3 IRQ_TYPE_EDGE_RISING>;
++ interrupt-names = "wdog", "fatal", "ready",
++ "handover", "stop-ack";
++
++ clocks = <&rpmhcc RPMH_CXO_CLK>;
++ clock-names = "xo";
++
++ power-domains = <&rpmhpd RPMHPD_LCX>,
++ <&rpmhpd RPMHPD_LMX>;
++ power-domain-names = "lcx", "lmx";
++
++ memory-region = <&pil_adsp_mem>;
++
++ qcom,qmp = <&aoss_qmp>;
++
++ qcom,smem-states = <&smp2p_adsp_out 0>;
++ qcom,smem-state-names = "stop";
++
++ status = "disabled";
++
++ glink-edge {
++ interrupts-extended = <&ipcc IPCC_CLIENT_LPASS
++ IPCC_MPROC_SIGNAL_GLINK_QMP
++ IRQ_TYPE_EDGE_RISING>;
++ mboxes = <&ipcc IPCC_CLIENT_LPASS
++ IPCC_MPROC_SIGNAL_GLINK_QMP>;
++
++ label = "lpass";
++ qcom,remote-pid = <2>;
++
++ apr {
++ compatible = "qcom,apr-v2";
++ qcom,glink-channels = "apr_audio_svc";
++ qcom,domain = <APR_DOMAIN_ADSP>;
++ #address-cells = <1>;
++ #size-cells = <0>;
++
++ service@3 {
++ reg = <APR_SVC_ADSP_CORE>;
++ compatible = "qcom,q6core";
++ qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd";
++ };
++
++ q6afe: service@4 {
++ compatible = "qcom,q6afe";
++ reg = <APR_SVC_AFE>;
++ qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd";
++
++ q6afedai: dais {
++ compatible = "qcom,q6afe-dais";
++ #address-cells = <1>;
++ #size-cells = <0>;
++ #sound-dai-cells = <1>;
++ };
++
++ q6afecc: clock-controller {
++ compatible = "qcom,q6afe-clocks";
++ #clock-cells = <2>;
++ };
++ };
++
++ q6asm: service@7 {
++ compatible = "qcom,q6asm";
++ reg = <APR_SVC_ASM>;
++ qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd";
++
++ q6asmdai: dais {
++ compatible = "qcom,q6asm-dais";
++ #address-cells = <1>;
++ #size-cells = <0>;
++ #sound-dai-cells = <1>;
++ iommus = <&apps_smmu 0x1801 0x0>;
++
++ dai@0 {
++ reg = <0>;
++ };
++
++ dai@1 {
++ reg = <1>;
++ };
++
++ dai@2 {
++ reg = <2>;
++ };
++ };
++ };
++
++ q6adm: service@8 {
++ compatible = "qcom,q6adm";
++ reg = <APR_SVC_ADM>;
++ qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd";
++
++ q6routing: routing {
++ compatible = "qcom,q6adm-routing";
++ #sound-dai-cells = <0>;
++ };
++ };
++ };
++
++ fastrpc {
++ compatible = "qcom,fastrpc";
++ qcom,glink-channels = "fastrpcglink-apps-dsp";
++ label = "adsp";
++ qcom,non-secure-domain;
++ #address-cells = <1>;
++ #size-cells = <0>;
++
++ compute-cb@3 {
++ compatible = "qcom,fastrpc-compute-cb";
++ reg = <3>;
++ iommus = <&apps_smmu 0x1803 0x0>;
++ };
++
++ compute-cb@4 {
++ compatible = "qcom,fastrpc-compute-cb";
++ reg = <4>;
++ iommus = <&apps_smmu 0x1804 0x0>;
++ };
++
++ compute-cb@5 {
++ compatible = "qcom,fastrpc-compute-cb";
++ reg = <5>;
++ iommus = <&apps_smmu 0x1805 0x0>;
++ };
++ };
++ };
++ };
++
+ lpass_tlmm: pinctrl@33c0000 {
+ compatible = "qcom,sm8350-lpass-lpi-pinctrl";
+ reg = <0 0x033c0000 0 0x20000>,
+@@ -3284,142 +3420,6 @@
+ <GIC_SPI 707 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+- adsp: remoteproc@17300000 {
+- compatible = "qcom,sm8350-adsp-pas";
+- reg = <0 0x17300000 0 0x100>;
+-
+- interrupts-extended = <&pdc 6 IRQ_TYPE_EDGE_RISING>,
+- <&smp2p_adsp_in 0 IRQ_TYPE_EDGE_RISING>,
+- <&smp2p_adsp_in 1 IRQ_TYPE_EDGE_RISING>,
+- <&smp2p_adsp_in 2 IRQ_TYPE_EDGE_RISING>,
+- <&smp2p_adsp_in 3 IRQ_TYPE_EDGE_RISING>;
+- interrupt-names = "wdog", "fatal", "ready",
+- "handover", "stop-ack";
+-
+- clocks = <&rpmhcc RPMH_CXO_CLK>;
+- clock-names = "xo";
+-
+- power-domains = <&rpmhpd RPMHPD_LCX>,
+- <&rpmhpd RPMHPD_LMX>;
+- power-domain-names = "lcx", "lmx";
+-
+- memory-region = <&pil_adsp_mem>;
+-
+- qcom,qmp = <&aoss_qmp>;
+-
+- qcom,smem-states = <&smp2p_adsp_out 0>;
+- qcom,smem-state-names = "stop";
+-
+- status = "disabled";
+-
+- glink-edge {
+- interrupts-extended = <&ipcc IPCC_CLIENT_LPASS
+- IPCC_MPROC_SIGNAL_GLINK_QMP
+- IRQ_TYPE_EDGE_RISING>;
+- mboxes = <&ipcc IPCC_CLIENT_LPASS
+- IPCC_MPROC_SIGNAL_GLINK_QMP>;
+-
+- label = "lpass";
+- qcom,remote-pid = <2>;
+-
+- apr {
+- compatible = "qcom,apr-v2";
+- qcom,glink-channels = "apr_audio_svc";
+- qcom,domain = <APR_DOMAIN_ADSP>;
+- #address-cells = <1>;
+- #size-cells = <0>;
+-
+- service@3 {
+- reg = <APR_SVC_ADSP_CORE>;
+- compatible = "qcom,q6core";
+- qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd";
+- };
+-
+- q6afe: service@4 {
+- compatible = "qcom,q6afe";
+- reg = <APR_SVC_AFE>;
+- qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd";
+-
+- q6afedai: dais {
+- compatible = "qcom,q6afe-dais";
+- #address-cells = <1>;
+- #size-cells = <0>;
+- #sound-dai-cells = <1>;
+- };
+-
+- q6afecc: clock-controller {
+- compatible = "qcom,q6afe-clocks";
+- #clock-cells = <2>;
+- };
+- };
+-
+- q6asm: service@7 {
+- compatible = "qcom,q6asm";
+- reg = <APR_SVC_ASM>;
+- qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd";
+-
+- q6asmdai: dais {
+- compatible = "qcom,q6asm-dais";
+- #address-cells = <1>;
+- #size-cells = <0>;
+- #sound-dai-cells = <1>;
+- iommus = <&apps_smmu 0x1801 0x0>;
+-
+- dai@0 {
+- reg = <0>;
+- };
+-
+- dai@1 {
+- reg = <1>;
+- };
+-
+- dai@2 {
+- reg = <2>;
+- };
+- };
+- };
+-
+- q6adm: service@8 {
+- compatible = "qcom,q6adm";
+- reg = <APR_SVC_ADM>;
+- qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd";
+-
+- q6routing: routing {
+- compatible = "qcom,q6adm-routing";
+- #sound-dai-cells = <0>;
+- };
+- };
+- };
+-
+- fastrpc {
+- compatible = "qcom,fastrpc";
+- qcom,glink-channels = "fastrpcglink-apps-dsp";
+- label = "adsp";
+- qcom,non-secure-domain;
+- #address-cells = <1>;
+- #size-cells = <0>;
+-
+- compute-cb@3 {
+- compatible = "qcom,fastrpc-compute-cb";
+- reg = <3>;
+- iommus = <&apps_smmu 0x1803 0x0>;
+- };
+-
+- compute-cb@4 {
+- compatible = "qcom,fastrpc-compute-cb";
+- reg = <4>;
+- iommus = <&apps_smmu 0x1804 0x0>;
+- };
+-
+- compute-cb@5 {
+- compatible = "qcom,fastrpc-compute-cb";
+- reg = <5>;
+- iommus = <&apps_smmu 0x1805 0x0>;
+- };
+- };
+- };
+- };
+-
+ intc: interrupt-controller@17a00000 {
+ compatible = "arm,gic-v3";
+ #interrupt-cells = <3>;
--- /dev/null
+From f4afd8ba453b6e82245b9068868c72c831aec84e Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Fri, 13 Dec 2024 15:53:51 +0100
+Subject: arm64: dts: qcom: sm8350: Fix CDSP memory base and length
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit f4afd8ba453b6e82245b9068868c72c831aec84e upstream.
+
+The address space in CDSP PAS (Peripheral Authentication Service)
+remoteproc node should point to the QDSP PUB address space
+(QDSP6...SS_PUB): 0x0a30_0000 with length of 0x10000. 0x9890_0000,
+value used so far, was copied from downstream DTS, is in the middle of
+RAM/DDR space and downstream DTS describes the PIL loader, which is a
+bit different interface. Datasheet says that one of the main CDSP
+address spaces is 0x0980_0000, which is oddly similar to 0x9890_0000,
+but quite different.
+
+Assume existing value (thus downstream DTS) is not really describing the
+intended CDSP PAS region.
+
+Correct the base address and length, which also moves the node to
+different place to keep things sorted by unit address. The diff looks
+big, but only the unit address and "reg" property were changed. This
+should have no functional impact on Linux users, because PAS loader does
+not use this address space at all.
+
+Fixes: 177fcf0aeda2 ("arm64: dts: qcom: sm8350: Add remoteprocs")
+Cc: stable@vger.kernel.org
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-2-2e0036fccd8d@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sm8350.dtsi | 218 +++++++++++++++++------------------
+ 1 file changed, 109 insertions(+), 109 deletions(-)
+
+--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
++++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
+@@ -2496,6 +2496,115 @@
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
+
++ cdsp: remoteproc@a300000 {
++ compatible = "qcom,sm8350-cdsp-pas";
++ reg = <0x0 0x0a300000 0x0 0x10000>;
++
++ interrupts-extended = <&intc GIC_SPI 578 IRQ_TYPE_EDGE_RISING>,
++ <&smp2p_cdsp_in 0 IRQ_TYPE_EDGE_RISING>,
++ <&smp2p_cdsp_in 1 IRQ_TYPE_EDGE_RISING>,
++ <&smp2p_cdsp_in 2 IRQ_TYPE_EDGE_RISING>,
++ <&smp2p_cdsp_in 3 IRQ_TYPE_EDGE_RISING>;
++ interrupt-names = "wdog", "fatal", "ready",
++ "handover", "stop-ack";
++
++ clocks = <&rpmhcc RPMH_CXO_CLK>;
++ clock-names = "xo";
++
++ power-domains = <&rpmhpd RPMHPD_CX>,
++ <&rpmhpd RPMHPD_MXC>;
++ power-domain-names = "cx", "mxc";
++
++ interconnects = <&compute_noc MASTER_CDSP_PROC 0 &mc_virt SLAVE_EBI1 0>;
++
++ memory-region = <&pil_cdsp_mem>;
++
++ qcom,qmp = <&aoss_qmp>;
++
++ qcom,smem-states = <&smp2p_cdsp_out 0>;
++ qcom,smem-state-names = "stop";
++
++ status = "disabled";
++
++ glink-edge {
++ interrupts-extended = <&ipcc IPCC_CLIENT_CDSP
++ IPCC_MPROC_SIGNAL_GLINK_QMP
++ IRQ_TYPE_EDGE_RISING>;
++ mboxes = <&ipcc IPCC_CLIENT_CDSP
++ IPCC_MPROC_SIGNAL_GLINK_QMP>;
++
++ label = "cdsp";
++ qcom,remote-pid = <5>;
++
++ fastrpc {
++ compatible = "qcom,fastrpc";
++ qcom,glink-channels = "fastrpcglink-apps-dsp";
++ label = "cdsp";
++ qcom,non-secure-domain;
++ #address-cells = <1>;
++ #size-cells = <0>;
++
++ compute-cb@1 {
++ compatible = "qcom,fastrpc-compute-cb";
++ reg = <1>;
++ iommus = <&apps_smmu 0x2161 0x0400>,
++ <&apps_smmu 0x1181 0x0420>;
++ };
++
++ compute-cb@2 {
++ compatible = "qcom,fastrpc-compute-cb";
++ reg = <2>;
++ iommus = <&apps_smmu 0x2162 0x0400>,
++ <&apps_smmu 0x1182 0x0420>;
++ };
++
++ compute-cb@3 {
++ compatible = "qcom,fastrpc-compute-cb";
++ reg = <3>;
++ iommus = <&apps_smmu 0x2163 0x0400>,
++ <&apps_smmu 0x1183 0x0420>;
++ };
++
++ compute-cb@4 {
++ compatible = "qcom,fastrpc-compute-cb";
++ reg = <4>;
++ iommus = <&apps_smmu 0x2164 0x0400>,
++ <&apps_smmu 0x1184 0x0420>;
++ };
++
++ compute-cb@5 {
++ compatible = "qcom,fastrpc-compute-cb";
++ reg = <5>;
++ iommus = <&apps_smmu 0x2165 0x0400>,
++ <&apps_smmu 0x1185 0x0420>;
++ };
++
++ compute-cb@6 {
++ compatible = "qcom,fastrpc-compute-cb";
++ reg = <6>;
++ iommus = <&apps_smmu 0x2166 0x0400>,
++ <&apps_smmu 0x1186 0x0420>;
++ };
++
++ compute-cb@7 {
++ compatible = "qcom,fastrpc-compute-cb";
++ reg = <7>;
++ iommus = <&apps_smmu 0x2167 0x0400>,
++ <&apps_smmu 0x1187 0x0420>;
++ };
++
++ compute-cb@8 {
++ compatible = "qcom,fastrpc-compute-cb";
++ reg = <8>;
++ iommus = <&apps_smmu 0x2168 0x0400>,
++ <&apps_smmu 0x1188 0x0420>;
++ };
++
++ /* note: secure cb9 in downstream */
++ };
++ };
++ };
++
+ usb_1: usb@a6f8800 {
+ compatible = "qcom,sm8350-dwc3", "qcom,dwc3";
+ reg = <0 0x0a6f8800 0 0x400>;
+@@ -3588,115 +3697,6 @@
+ #freq-domain-cells = <1>;
+ #clock-cells = <1>;
+ };
+-
+- cdsp: remoteproc@98900000 {
+- compatible = "qcom,sm8350-cdsp-pas";
+- reg = <0 0x98900000 0 0x1400000>;
+-
+- interrupts-extended = <&intc GIC_SPI 578 IRQ_TYPE_EDGE_RISING>,
+- <&smp2p_cdsp_in 0 IRQ_TYPE_EDGE_RISING>,
+- <&smp2p_cdsp_in 1 IRQ_TYPE_EDGE_RISING>,
+- <&smp2p_cdsp_in 2 IRQ_TYPE_EDGE_RISING>,
+- <&smp2p_cdsp_in 3 IRQ_TYPE_EDGE_RISING>;
+- interrupt-names = "wdog", "fatal", "ready",
+- "handover", "stop-ack";
+-
+- clocks = <&rpmhcc RPMH_CXO_CLK>;
+- clock-names = "xo";
+-
+- power-domains = <&rpmhpd RPMHPD_CX>,
+- <&rpmhpd RPMHPD_MXC>;
+- power-domain-names = "cx", "mxc";
+-
+- interconnects = <&compute_noc MASTER_CDSP_PROC 0 &mc_virt SLAVE_EBI1 0>;
+-
+- memory-region = <&pil_cdsp_mem>;
+-
+- qcom,qmp = <&aoss_qmp>;
+-
+- qcom,smem-states = <&smp2p_cdsp_out 0>;
+- qcom,smem-state-names = "stop";
+-
+- status = "disabled";
+-
+- glink-edge {
+- interrupts-extended = <&ipcc IPCC_CLIENT_CDSP
+- IPCC_MPROC_SIGNAL_GLINK_QMP
+- IRQ_TYPE_EDGE_RISING>;
+- mboxes = <&ipcc IPCC_CLIENT_CDSP
+- IPCC_MPROC_SIGNAL_GLINK_QMP>;
+-
+- label = "cdsp";
+- qcom,remote-pid = <5>;
+-
+- fastrpc {
+- compatible = "qcom,fastrpc";
+- qcom,glink-channels = "fastrpcglink-apps-dsp";
+- label = "cdsp";
+- qcom,non-secure-domain;
+- #address-cells = <1>;
+- #size-cells = <0>;
+-
+- compute-cb@1 {
+- compatible = "qcom,fastrpc-compute-cb";
+- reg = <1>;
+- iommus = <&apps_smmu 0x2161 0x0400>,
+- <&apps_smmu 0x1181 0x0420>;
+- };
+-
+- compute-cb@2 {
+- compatible = "qcom,fastrpc-compute-cb";
+- reg = <2>;
+- iommus = <&apps_smmu 0x2162 0x0400>,
+- <&apps_smmu 0x1182 0x0420>;
+- };
+-
+- compute-cb@3 {
+- compatible = "qcom,fastrpc-compute-cb";
+- reg = <3>;
+- iommus = <&apps_smmu 0x2163 0x0400>,
+- <&apps_smmu 0x1183 0x0420>;
+- };
+-
+- compute-cb@4 {
+- compatible = "qcom,fastrpc-compute-cb";
+- reg = <4>;
+- iommus = <&apps_smmu 0x2164 0x0400>,
+- <&apps_smmu 0x1184 0x0420>;
+- };
+-
+- compute-cb@5 {
+- compatible = "qcom,fastrpc-compute-cb";
+- reg = <5>;
+- iommus = <&apps_smmu 0x2165 0x0400>,
+- <&apps_smmu 0x1185 0x0420>;
+- };
+-
+- compute-cb@6 {
+- compatible = "qcom,fastrpc-compute-cb";
+- reg = <6>;
+- iommus = <&apps_smmu 0x2166 0x0400>,
+- <&apps_smmu 0x1186 0x0420>;
+- };
+-
+- compute-cb@7 {
+- compatible = "qcom,fastrpc-compute-cb";
+- reg = <7>;
+- iommus = <&apps_smmu 0x2167 0x0400>,
+- <&apps_smmu 0x1187 0x0420>;
+- };
+-
+- compute-cb@8 {
+- compatible = "qcom,fastrpc-compute-cb";
+- reg = <8>;
+- iommus = <&apps_smmu 0x2168 0x0400>,
+- <&apps_smmu 0x1188 0x0420>;
+- };
+-
+- /* note: secure cb9 in downstream */
+- };
+- };
+- };
+ };
+
+ thermal_zones: thermal-zones {
--- /dev/null
+From da1937dec9cd986e685b6a429b528a4cbc7b1603 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Fri, 13 Dec 2024 15:53:52 +0100
+Subject: arm64: dts: qcom: sm8350: Fix MPSS memory length
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit da1937dec9cd986e685b6a429b528a4cbc7b1603 upstream.
+
+The address space in MPSS/Modem PAS (Peripheral Authentication Service)
+remoteproc node should point to the QDSP PUB address space
+(QDSP6...SS_PUB) which has a length of 0x10000. Value of 0x4040 was
+copied from older DTS, but it grew since then.
+
+This should have no functional impact on Linux users, because PAS loader
+does not use this address space at all.
+
+Fixes: 177fcf0aeda2 ("arm64: dts: qcom: sm8350: Add remoteprocs")
+Cc: stable@vger.kernel.org
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-3-2e0036fccd8d@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sm8350.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
++++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
+@@ -2214,7 +2214,7 @@
+
+ mpss: remoteproc@4080000 {
+ compatible = "qcom,sm8350-mpss-pas";
+- reg = <0x0 0x04080000 0x0 0x4040>;
++ reg = <0x0 0x04080000 0x0 0x10000>;
+
+ interrupts-extended = <&intc GIC_SPI 264 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_modem_in 0 IRQ_TYPE_EDGE_RISING>,
--- /dev/null
+From 13c96bee5d5e5b61a9d8d000c9bb37bb9a2a0551 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Fri, 13 Dec 2024 15:53:53 +0100
+Subject: arm64: dts: qcom: sm8450: Fix ADSP memory base and length
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit 13c96bee5d5e5b61a9d8d000c9bb37bb9a2a0551 upstream.
+
+The address space in ADSP PAS (Peripheral Authentication Service)
+remoteproc node should point to the QDSP PUB address space
+(QDSP6...SS_PUB): 0x0300_0000 with length of 0x10000, which also matches
+downstream DTS. 0x3000_0000, value used so far, was in datasheet is the
+region of CDSP.
+
+Correct the base address and length, which also moves the node to
+different place to keep things sorted by unit address. The diff looks
+big, but only the unit address and "reg" property were changed. This
+should have no functional impact on Linux users, because PAS loader does
+not use this address space at all.
+
+Fixes: 1172729576fb ("arm64: dts: qcom: sm8450: Add remoteproc enablers and instances")
+Cc: stable@vger.kernel.org
+Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-4-2e0036fccd8d@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sm8450.dtsi | 212 +++++++++++++++++------------------
+ 1 file changed, 106 insertions(+), 106 deletions(-)
+
+--- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
++++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
+@@ -2492,6 +2492,112 @@
+ };
+ };
+
++ remoteproc_adsp: remoteproc@3000000 {
++ compatible = "qcom,sm8450-adsp-pas";
++ reg = <0x0 0x03000000 0x0 0x10000>;
++
++ interrupts-extended = <&pdc 6 IRQ_TYPE_EDGE_RISING>,
++ <&smp2p_adsp_in 0 IRQ_TYPE_EDGE_RISING>,
++ <&smp2p_adsp_in 1 IRQ_TYPE_EDGE_RISING>,
++ <&smp2p_adsp_in 2 IRQ_TYPE_EDGE_RISING>,
++ <&smp2p_adsp_in 3 IRQ_TYPE_EDGE_RISING>;
++ interrupt-names = "wdog", "fatal", "ready",
++ "handover", "stop-ack";
++
++ clocks = <&rpmhcc RPMH_CXO_CLK>;
++ clock-names = "xo";
++
++ power-domains = <&rpmhpd RPMHPD_LCX>,
++ <&rpmhpd RPMHPD_LMX>;
++ power-domain-names = "lcx", "lmx";
++
++ memory-region = <&adsp_mem>;
++
++ qcom,qmp = <&aoss_qmp>;
++
++ qcom,smem-states = <&smp2p_adsp_out 0>;
++ qcom,smem-state-names = "stop";
++
++ status = "disabled";
++
++ remoteproc_adsp_glink: glink-edge {
++ interrupts-extended = <&ipcc IPCC_CLIENT_LPASS
++ IPCC_MPROC_SIGNAL_GLINK_QMP
++ IRQ_TYPE_EDGE_RISING>;
++ mboxes = <&ipcc IPCC_CLIENT_LPASS
++ IPCC_MPROC_SIGNAL_GLINK_QMP>;
++
++ label = "lpass";
++ qcom,remote-pid = <2>;
++
++ gpr {
++ compatible = "qcom,gpr";
++ qcom,glink-channels = "adsp_apps";
++ qcom,domain = <GPR_DOMAIN_ID_ADSP>;
++ qcom,intents = <512 20>;
++ #address-cells = <1>;
++ #size-cells = <0>;
++
++ q6apm: service@1 {
++ compatible = "qcom,q6apm";
++ reg = <GPR_APM_MODULE_IID>;
++ #sound-dai-cells = <0>;
++ qcom,protection-domain = "avs/audio",
++ "msm/adsp/audio_pd";
++
++ q6apmdai: dais {
++ compatible = "qcom,q6apm-dais";
++ iommus = <&apps_smmu 0x1801 0x0>;
++ };
++
++ q6apmbedai: bedais {
++ compatible = "qcom,q6apm-lpass-dais";
++ #sound-dai-cells = <1>;
++ };
++ };
++
++ q6prm: service@2 {
++ compatible = "qcom,q6prm";
++ reg = <GPR_PRM_MODULE_IID>;
++ qcom,protection-domain = "avs/audio",
++ "msm/adsp/audio_pd";
++
++ q6prmcc: clock-controller {
++ compatible = "qcom,q6prm-lpass-clocks";
++ #clock-cells = <2>;
++ };
++ };
++ };
++
++ fastrpc {
++ compatible = "qcom,fastrpc";
++ qcom,glink-channels = "fastrpcglink-apps-dsp";
++ label = "adsp";
++ qcom,non-secure-domain;
++ #address-cells = <1>;
++ #size-cells = <0>;
++
++ compute-cb@3 {
++ compatible = "qcom,fastrpc-compute-cb";
++ reg = <3>;
++ iommus = <&apps_smmu 0x1803 0x0>;
++ };
++
++ compute-cb@4 {
++ compatible = "qcom,fastrpc-compute-cb";
++ reg = <4>;
++ iommus = <&apps_smmu 0x1804 0x0>;
++ };
++
++ compute-cb@5 {
++ compatible = "qcom,fastrpc-compute-cb";
++ reg = <5>;
++ iommus = <&apps_smmu 0x1805 0x0>;
++ };
++ };
++ };
++ };
++
+ wsa2macro: codec@31e0000 {
+ compatible = "qcom,sm8450-lpass-wsa-macro";
+ reg = <0 0x031e0000 0 0x1000>;
+@@ -2688,112 +2794,6 @@
+ status = "disabled";
+ };
+
+- remoteproc_adsp: remoteproc@30000000 {
+- compatible = "qcom,sm8450-adsp-pas";
+- reg = <0 0x30000000 0 0x100>;
+-
+- interrupts-extended = <&pdc 6 IRQ_TYPE_EDGE_RISING>,
+- <&smp2p_adsp_in 0 IRQ_TYPE_EDGE_RISING>,
+- <&smp2p_adsp_in 1 IRQ_TYPE_EDGE_RISING>,
+- <&smp2p_adsp_in 2 IRQ_TYPE_EDGE_RISING>,
+- <&smp2p_adsp_in 3 IRQ_TYPE_EDGE_RISING>;
+- interrupt-names = "wdog", "fatal", "ready",
+- "handover", "stop-ack";
+-
+- clocks = <&rpmhcc RPMH_CXO_CLK>;
+- clock-names = "xo";
+-
+- power-domains = <&rpmhpd RPMHPD_LCX>,
+- <&rpmhpd RPMHPD_LMX>;
+- power-domain-names = "lcx", "lmx";
+-
+- memory-region = <&adsp_mem>;
+-
+- qcom,qmp = <&aoss_qmp>;
+-
+- qcom,smem-states = <&smp2p_adsp_out 0>;
+- qcom,smem-state-names = "stop";
+-
+- status = "disabled";
+-
+- remoteproc_adsp_glink: glink-edge {
+- interrupts-extended = <&ipcc IPCC_CLIENT_LPASS
+- IPCC_MPROC_SIGNAL_GLINK_QMP
+- IRQ_TYPE_EDGE_RISING>;
+- mboxes = <&ipcc IPCC_CLIENT_LPASS
+- IPCC_MPROC_SIGNAL_GLINK_QMP>;
+-
+- label = "lpass";
+- qcom,remote-pid = <2>;
+-
+- gpr {
+- compatible = "qcom,gpr";
+- qcom,glink-channels = "adsp_apps";
+- qcom,domain = <GPR_DOMAIN_ID_ADSP>;
+- qcom,intents = <512 20>;
+- #address-cells = <1>;
+- #size-cells = <0>;
+-
+- q6apm: service@1 {
+- compatible = "qcom,q6apm";
+- reg = <GPR_APM_MODULE_IID>;
+- #sound-dai-cells = <0>;
+- qcom,protection-domain = "avs/audio",
+- "msm/adsp/audio_pd";
+-
+- q6apmdai: dais {
+- compatible = "qcom,q6apm-dais";
+- iommus = <&apps_smmu 0x1801 0x0>;
+- };
+-
+- q6apmbedai: bedais {
+- compatible = "qcom,q6apm-lpass-dais";
+- #sound-dai-cells = <1>;
+- };
+- };
+-
+- q6prm: service@2 {
+- compatible = "qcom,q6prm";
+- reg = <GPR_PRM_MODULE_IID>;
+- qcom,protection-domain = "avs/audio",
+- "msm/adsp/audio_pd";
+-
+- q6prmcc: clock-controller {
+- compatible = "qcom,q6prm-lpass-clocks";
+- #clock-cells = <2>;
+- };
+- };
+- };
+-
+- fastrpc {
+- compatible = "qcom,fastrpc";
+- qcom,glink-channels = "fastrpcglink-apps-dsp";
+- label = "adsp";
+- qcom,non-secure-domain;
+- #address-cells = <1>;
+- #size-cells = <0>;
+-
+- compute-cb@3 {
+- compatible = "qcom,fastrpc-compute-cb";
+- reg = <3>;
+- iommus = <&apps_smmu 0x1803 0x0>;
+- };
+-
+- compute-cb@4 {
+- compatible = "qcom,fastrpc-compute-cb";
+- reg = <4>;
+- iommus = <&apps_smmu 0x1804 0x0>;
+- };
+-
+- compute-cb@5 {
+- compatible = "qcom,fastrpc-compute-cb";
+- reg = <5>;
+- iommus = <&apps_smmu 0x1805 0x0>;
+- };
+- };
+- };
+- };
+-
+ remoteproc_cdsp: remoteproc@32300000 {
+ compatible = "qcom,sm8450-cdsp-pas";
+ reg = <0 0x32300000 0 0x1400000>;
--- /dev/null
+From 3751fe2cba2a9fba2204ef62102bc4bb027cec7b Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Fri, 13 Dec 2024 15:53:54 +0100
+Subject: arm64: dts: qcom: sm8450: Fix CDSP memory length
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit 3751fe2cba2a9fba2204ef62102bc4bb027cec7b upstream.
+
+The address space in CDSP PAS (Peripheral Authentication Service)
+remoteproc node should point to the QDSP PUB address space
+(QDSP6...SS_PUB) which has a length of 0x10000. Value of 0x1400000 was
+copied from older DTS, but it does not look accurate at all.
+
+This should have no functional impact on Linux users, because PAS loader
+does not use this address space at all.
+
+Fixes: 1172729576fb ("arm64: dts: qcom: sm8450: Add remoteproc enablers and instances")
+Cc: stable@vger.kernel.org
+Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-5-2e0036fccd8d@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sm8450.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
++++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
+@@ -2796,7 +2796,7 @@
+
+ remoteproc_cdsp: remoteproc@32300000 {
+ compatible = "qcom,sm8450-cdsp-pas";
+- reg = <0 0x32300000 0 0x1400000>;
++ reg = <0 0x32300000 0 0x10000>;
+
+ interrupts-extended = <&intc GIC_SPI 578 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_cdsp_in 0 IRQ_TYPE_EDGE_RISING>,
--- /dev/null
+From fa6442e87ab7c4a58c0b5fc64aab1aacc8034712 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Fri, 13 Dec 2024 15:53:55 +0100
+Subject: arm64: dts: qcom: sm8450: Fix MPSS memory length
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit fa6442e87ab7c4a58c0b5fc64aab1aacc8034712 upstream.
+
+The address space in MPSS/Modem PAS (Peripheral Authentication Service)
+remoteproc node should point to the QDSP PUB address space
+(QDSP6...SS_PUB) which has a length of 0x10000. Value of 0x4040 was
+copied from older DTS, but it grew since then.
+
+This should have no functional impact on Linux users, because PAS loader
+does not use this address space at all.
+
+Fixes: 1172729576fb ("arm64: dts: qcom: sm8450: Add remoteproc enablers and instances")
+Cc: stable@vger.kernel.org
+Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-6-2e0036fccd8d@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sm8450.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
++++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
+@@ -2903,7 +2903,7 @@
+
+ remoteproc_mpss: remoteproc@4080000 {
+ compatible = "qcom,sm8450-mpss-pas";
+- reg = <0x0 0x04080000 0x0 0x4040>;
++ reg = <0x0 0x04080000 0x0 0x10000>;
+
+ interrupts-extended = <&intc GIC_SPI 264 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_modem_in 0 IRQ_TYPE_EDGE_RISING>,
--- /dev/null
+From b8591df49cde459e3b84cdc0517d7bf92053d244 Mon Sep 17 00:00:00 2001
+From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+Date: Sat, 26 Oct 2024 20:59:40 +0300
+Subject: arm64: dts: qcom: sm8550: correct MDSS interconnects
+
+From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+
+commit b8591df49cde459e3b84cdc0517d7bf92053d244 upstream.
+
+SM8550 lists two interconnects for the display subsystem, mdp0-mem
+(between MDP and LLCC) and mdp1-mem (between LLCC and EBI, memory).
+The second interconnect is a misuse. mdpN-mem paths should be used for
+several outboud MDP interconnects rather than the path between LLCC and
+memory. This kind of misuse can result in bandwidth underflows, possibly
+degrading picture quality as the required memory bandwidth is divided
+between all mdpN-mem paths (and LLCC-EBI should not be a part of such
+division).
+
+Drop the second path and use direct MDP-EBI path for mdp0-mem until we
+support separate MDP-LLCC and LLCC-EBI paths.
+
+Fixes: d7da51db5b81 ("arm64: dts: qcom: sm8550: add display hardware devices")
+Cc: stable@kernel.org
+Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Link: https://lore.kernel.org/r/20241026-fix-sm8x50-mdp-icc-v2-1-fd8ddf755acc@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sm8550.dtsi | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
++++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
+@@ -3002,9 +3002,8 @@
+
+ power-domains = <&dispcc MDSS_GDSC>;
+
+- interconnects = <&mmss_noc MASTER_MDP 0 &gem_noc SLAVE_LLCC 0>,
+- <&mc_virt MASTER_LLCC 0 &mc_virt SLAVE_EBI1 0>;
+- interconnect-names = "mdp0-mem", "mdp1-mem";
++ interconnects = <&mmss_noc MASTER_MDP 0 &mc_virt SLAVE_EBI1 0>;
++ interconnect-names = "mdp0-mem";
+
+ iommus = <&apps_smmu 0x1c00 0x2>;
+
--- /dev/null
+From a6a8f54bc2af555738322783ba1e990c2ae7f443 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Fri, 13 Dec 2024 15:53:56 +0100
+Subject: arm64: dts: qcom: sm8550: Fix ADSP memory base and length
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit a6a8f54bc2af555738322783ba1e990c2ae7f443 upstream.
+
+The address space in ADSP PAS (Peripheral Authentication Service)
+remoteproc node should point to the QDSP PUB address space
+(QDSP6...SS_PUB): 0x0680_0000 with length of 0x10000.
+
+0x3000_0000, value used so far, is the main region of CDSP. Downstream
+DTS uses 0x0300_0000, which is oddly similar to 0x3000_0000, yet quite
+different and points to unused area.
+
+Correct the base address and length, which also moves the node to
+different place to keep things sorted by unit address. The diff looks
+big, but only the unit address and "reg" property were changed. This
+should have no functional impact on Linux users, because PAS loader does
+not use this address space at all.
+
+Fixes: d0c061e366ed ("arm64: dts: qcom: sm8550: add adsp, cdsp & mdss nodes")
+Cc: stable@vger.kernel.org
+Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-7-2e0036fccd8d@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sm8550.dtsi | 262 +++++++++++++++++------------------
+ 1 file changed, 131 insertions(+), 131 deletions(-)
+
+--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
++++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
+@@ -2353,6 +2353,137 @@
+ };
+ };
+
++ remoteproc_adsp: remoteproc@6800000 {
++ compatible = "qcom,sm8550-adsp-pas";
++ reg = <0x0 0x06800000 0x0 0x10000>;
++
++ interrupts-extended = <&pdc 6 IRQ_TYPE_EDGE_RISING>,
++ <&smp2p_adsp_in 0 IRQ_TYPE_EDGE_RISING>,
++ <&smp2p_adsp_in 1 IRQ_TYPE_EDGE_RISING>,
++ <&smp2p_adsp_in 2 IRQ_TYPE_EDGE_RISING>,
++ <&smp2p_adsp_in 3 IRQ_TYPE_EDGE_RISING>;
++ interrupt-names = "wdog", "fatal", "ready",
++ "handover", "stop-ack";
++
++ clocks = <&rpmhcc RPMH_CXO_CLK>;
++ clock-names = "xo";
++
++ power-domains = <&rpmhpd RPMHPD_LCX>,
++ <&rpmhpd RPMHPD_LMX>;
++ power-domain-names = "lcx", "lmx";
++
++ interconnects = <&lpass_lpicx_noc MASTER_LPASS_PROC 0 &mc_virt SLAVE_EBI1 0>;
++
++ memory-region = <&adspslpi_mem>, <&q6_adsp_dtb_mem>;
++
++ qcom,qmp = <&aoss_qmp>;
++
++ qcom,smem-states = <&smp2p_adsp_out 0>;
++ qcom,smem-state-names = "stop";
++
++ status = "disabled";
++
++ remoteproc_adsp_glink: glink-edge {
++ interrupts-extended = <&ipcc IPCC_CLIENT_LPASS
++ IPCC_MPROC_SIGNAL_GLINK_QMP
++ IRQ_TYPE_EDGE_RISING>;
++ mboxes = <&ipcc IPCC_CLIENT_LPASS
++ IPCC_MPROC_SIGNAL_GLINK_QMP>;
++
++ label = "lpass";
++ qcom,remote-pid = <2>;
++
++ fastrpc {
++ compatible = "qcom,fastrpc";
++ qcom,glink-channels = "fastrpcglink-apps-dsp";
++ label = "adsp";
++ qcom,non-secure-domain;
++ #address-cells = <1>;
++ #size-cells = <0>;
++
++ compute-cb@3 {
++ compatible = "qcom,fastrpc-compute-cb";
++ reg = <3>;
++ iommus = <&apps_smmu 0x1003 0x80>,
++ <&apps_smmu 0x1063 0x0>;
++ dma-coherent;
++ };
++
++ compute-cb@4 {
++ compatible = "qcom,fastrpc-compute-cb";
++ reg = <4>;
++ iommus = <&apps_smmu 0x1004 0x80>,
++ <&apps_smmu 0x1064 0x0>;
++ dma-coherent;
++ };
++
++ compute-cb@5 {
++ compatible = "qcom,fastrpc-compute-cb";
++ reg = <5>;
++ iommus = <&apps_smmu 0x1005 0x80>,
++ <&apps_smmu 0x1065 0x0>;
++ dma-coherent;
++ };
++
++ compute-cb@6 {
++ compatible = "qcom,fastrpc-compute-cb";
++ reg = <6>;
++ iommus = <&apps_smmu 0x1006 0x80>,
++ <&apps_smmu 0x1066 0x0>;
++ dma-coherent;
++ };
++
++ compute-cb@7 {
++ compatible = "qcom,fastrpc-compute-cb";
++ reg = <7>;
++ iommus = <&apps_smmu 0x1007 0x80>,
++ <&apps_smmu 0x1067 0x0>;
++ dma-coherent;
++ };
++ };
++
++ gpr {
++ compatible = "qcom,gpr";
++ qcom,glink-channels = "adsp_apps";
++ qcom,domain = <GPR_DOMAIN_ID_ADSP>;
++ qcom,intents = <512 20>;
++ #address-cells = <1>;
++ #size-cells = <0>;
++
++ q6apm: service@1 {
++ compatible = "qcom,q6apm";
++ reg = <GPR_APM_MODULE_IID>;
++ #sound-dai-cells = <0>;
++ qcom,protection-domain = "avs/audio",
++ "msm/adsp/audio_pd";
++
++ q6apmdai: dais {
++ compatible = "qcom,q6apm-dais";
++ iommus = <&apps_smmu 0x1001 0x80>,
++ <&apps_smmu 0x1061 0x0>;
++ };
++
++ q6apmbedai: bedais {
++ compatible = "qcom,q6apm-lpass-dais";
++ #sound-dai-cells = <1>;
++ };
++ };
++
++ q6prm: service@2 {
++ compatible = "qcom,q6prm";
++ reg = <GPR_PRM_MODULE_IID>;
++ qcom,protection-domain = "avs/audio",
++ "msm/adsp/audio_pd";
++
++ q6prmcc: clock-controller {
++ compatible = "qcom,q6prm-lpass-clocks";
++ #clock-cells = <2>;
++ };
++ };
++ };
++ };
++ };
++
+ lpass_wsa2macro: codec@6aa0000 {
+ compatible = "qcom,sm8550-lpass-wsa-macro";
+ reg = <0 0x06aa0000 0 0x1000>;
+@@ -4575,137 +4706,6 @@
+ interrupts = <GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+- remoteproc_adsp: remoteproc@30000000 {
+- compatible = "qcom,sm8550-adsp-pas";
+- reg = <0x0 0x30000000 0x0 0x100>;
+-
+- interrupts-extended = <&pdc 6 IRQ_TYPE_EDGE_RISING>,
+- <&smp2p_adsp_in 0 IRQ_TYPE_EDGE_RISING>,
+- <&smp2p_adsp_in 1 IRQ_TYPE_EDGE_RISING>,
+- <&smp2p_adsp_in 2 IRQ_TYPE_EDGE_RISING>,
+- <&smp2p_adsp_in 3 IRQ_TYPE_EDGE_RISING>;
+- interrupt-names = "wdog", "fatal", "ready",
+- "handover", "stop-ack";
+-
+- clocks = <&rpmhcc RPMH_CXO_CLK>;
+- clock-names = "xo";
+-
+- power-domains = <&rpmhpd RPMHPD_LCX>,
+- <&rpmhpd RPMHPD_LMX>;
+- power-domain-names = "lcx", "lmx";
+-
+- interconnects = <&lpass_lpicx_noc MASTER_LPASS_PROC 0 &mc_virt SLAVE_EBI1 0>;
+-
+- memory-region = <&adspslpi_mem>, <&q6_adsp_dtb_mem>;
+-
+- qcom,qmp = <&aoss_qmp>;
+-
+- qcom,smem-states = <&smp2p_adsp_out 0>;
+- qcom,smem-state-names = "stop";
+-
+- status = "disabled";
+-
+- remoteproc_adsp_glink: glink-edge {
+- interrupts-extended = <&ipcc IPCC_CLIENT_LPASS
+- IPCC_MPROC_SIGNAL_GLINK_QMP
+- IRQ_TYPE_EDGE_RISING>;
+- mboxes = <&ipcc IPCC_CLIENT_LPASS
+- IPCC_MPROC_SIGNAL_GLINK_QMP>;
+-
+- label = "lpass";
+- qcom,remote-pid = <2>;
+-
+- fastrpc {
+- compatible = "qcom,fastrpc";
+- qcom,glink-channels = "fastrpcglink-apps-dsp";
+- label = "adsp";
+- qcom,non-secure-domain;
+- #address-cells = <1>;
+- #size-cells = <0>;
+-
+- compute-cb@3 {
+- compatible = "qcom,fastrpc-compute-cb";
+- reg = <3>;
+- iommus = <&apps_smmu 0x1003 0x80>,
+- <&apps_smmu 0x1063 0x0>;
+- dma-coherent;
+- };
+-
+- compute-cb@4 {
+- compatible = "qcom,fastrpc-compute-cb";
+- reg = <4>;
+- iommus = <&apps_smmu 0x1004 0x80>,
+- <&apps_smmu 0x1064 0x0>;
+- dma-coherent;
+- };
+-
+- compute-cb@5 {
+- compatible = "qcom,fastrpc-compute-cb";
+- reg = <5>;
+- iommus = <&apps_smmu 0x1005 0x80>,
+- <&apps_smmu 0x1065 0x0>;
+- dma-coherent;
+- };
+-
+- compute-cb@6 {
+- compatible = "qcom,fastrpc-compute-cb";
+- reg = <6>;
+- iommus = <&apps_smmu 0x1006 0x80>,
+- <&apps_smmu 0x1066 0x0>;
+- dma-coherent;
+- };
+-
+- compute-cb@7 {
+- compatible = "qcom,fastrpc-compute-cb";
+- reg = <7>;
+- iommus = <&apps_smmu 0x1007 0x80>,
+- <&apps_smmu 0x1067 0x0>;
+- dma-coherent;
+- };
+- };
+-
+- gpr {
+- compatible = "qcom,gpr";
+- qcom,glink-channels = "adsp_apps";
+- qcom,domain = <GPR_DOMAIN_ID_ADSP>;
+- qcom,intents = <512 20>;
+- #address-cells = <1>;
+- #size-cells = <0>;
+-
+- q6apm: service@1 {
+- compatible = "qcom,q6apm";
+- reg = <GPR_APM_MODULE_IID>;
+- #sound-dai-cells = <0>;
+- qcom,protection-domain = "avs/audio",
+- "msm/adsp/audio_pd";
+-
+- q6apmdai: dais {
+- compatible = "qcom,q6apm-dais";
+- iommus = <&apps_smmu 0x1001 0x80>,
+- <&apps_smmu 0x1061 0x0>;
+- };
+-
+- q6apmbedai: bedais {
+- compatible = "qcom,q6apm-lpass-dais";
+- #sound-dai-cells = <1>;
+- };
+- };
+-
+- q6prm: service@2 {
+- compatible = "qcom,q6prm";
+- reg = <GPR_PRM_MODULE_IID>;
+- qcom,protection-domain = "avs/audio",
+- "msm/adsp/audio_pd";
+-
+- q6prmcc: clock-controller {
+- compatible = "qcom,q6prm-lpass-clocks";
+- #clock-cells = <2>;
+- };
+- };
+- };
+- };
+- };
+-
+ nsp_noc: interconnect@320c0000 {
+ compatible = "qcom,sm8550-nsp-noc";
+ reg = <0 0x320c0000 0 0xe080>;
--- /dev/null
+From 6b2570e1e43e4acd0fcb98c6489736fe1c67b222 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Fri, 13 Dec 2024 15:53:57 +0100
+Subject: arm64: dts: qcom: sm8550: Fix CDSP memory length
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit 6b2570e1e43e4acd0fcb98c6489736fe1c67b222 upstream.
+
+The address space in CDSP PAS (Peripheral Authentication Service)
+remoteproc node should point to the QDSP PUB address space
+(QDSP6...SS_PUB) which has a length of 0x10000. Value of 0x1400000 was
+copied from older DTS, but it does not look accurate at all.
+
+This should have no functional impact on Linux users, because PAS loader
+does not use this address space at all.
+
+Fixes: d0c061e366ed ("arm64: dts: qcom: sm8550: add adsp, cdsp & mdss nodes")
+Cc: stable@vger.kernel.org
+Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-8-2e0036fccd8d@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sm8550.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
++++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
+@@ -4715,7 +4715,7 @@
+
+ remoteproc_cdsp: remoteproc@32300000 {
+ compatible = "qcom,sm8550-cdsp-pas";
+- reg = <0x0 0x32300000 0x0 0x1400000>;
++ reg = <0x0 0x32300000 0x0 0x10000>;
+
+ interrupts-extended = <&intc GIC_SPI 578 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_cdsp_in 0 IRQ_TYPE_EDGE_RISING>,
--- /dev/null
+From 8ef227e93a513d431f9345f23cd4d2d65607b985 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Fri, 13 Dec 2024 15:53:58 +0100
+Subject: arm64: dts: qcom: sm8550: Fix MPSS memory length
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit 8ef227e93a513d431f9345f23cd4d2d65607b985 upstream.
+
+The address space in MPSS/Modem PAS (Peripheral Authentication Service)
+remoteproc node should point to the QDSP PUB address space
+(QDSP6...SS_PUB) which has a length of 0x10000. Value of 0x4040 was
+copied from older DTS, but it grew since then.
+
+This should have no functional impact on Linux users, because PAS loader
+does not use this address space at all.
+
+Fixes: d0c061e366ed ("arm64: dts: qcom: sm8550: add adsp, cdsp & mdss nodes")
+Cc: stable@vger.kernel.org
+Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-9-2e0036fccd8d@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sm8550.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
++++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
+@@ -2313,7 +2313,7 @@
+
+ remoteproc_mpss: remoteproc@4080000 {
+ compatible = "qcom,sm8550-mpss-pas";
+- reg = <0x0 0x04080000 0x0 0x4040>;
++ reg = <0x0 0x04080000 0x0 0x10000>;
+
+ interrupts-extended = <&intc GIC_SPI 264 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_modem_in 0 IRQ_TYPE_EDGE_RISING>,
--- /dev/null
+From 9fa33cbca3d2842f1f47ed4e5f6574e611dae32b Mon Sep 17 00:00:00 2001
+From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+Date: Sat, 26 Oct 2024 20:59:41 +0300
+Subject: arm64: dts: qcom: sm8650: correct MDSS interconnects
+
+From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+
+commit 9fa33cbca3d2842f1f47ed4e5f6574e611dae32b upstream.
+
+SM8650 lists two interconnects for the display subsystem, mdp0-mem
+(between MDP and LLCC) and mdp1-mem (between LLCC and EBI, memory).
+The second interconnect is a misuse. mdpN-mem paths should be used for
+several outboud MDP interconnects rather than the path between LLCC and
+memory. This kind of misuse can result in bandwidth underflows, possibly
+degrading picture quality as the required memory bandwidth is divided
+between all mdpN-mem paths (and LLCC-EBI should not be a part of such
+division).
+
+Drop the second path and use direct MDP-EBI path for mdp0-mem until we
+support separate MDP-LLCC and LLCC-EBI paths.
+
+Fixes: 10e024671295 ("arm64: dts: qcom: sm8650: add interconnect dependent device nodes")
+Cc: stable@kernel.org
+Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+Link: https://lore.kernel.org/r/20241026-fix-sm8x50-mdp-icc-v2-2-fd8ddf755acc@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sm8650.dtsi | 5 +----
+ 1 file changed, 1 insertion(+), 4 deletions(-)
+
+--- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
++++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
+@@ -3603,11 +3603,8 @@
+ resets = <&dispcc DISP_CC_MDSS_CORE_BCR>;
+
+ interconnects = <&mmss_noc MASTER_MDP QCOM_ICC_TAG_ALWAYS
+- &gem_noc SLAVE_LLCC QCOM_ICC_TAG_ALWAYS>,
+- <&mc_virt MASTER_LLCC QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+- interconnect-names = "mdp0-mem",
+- "mdp1-mem";
++ interconnect-names = "mdp0-mem";
+
+ power-domains = <&dispcc MDSS_GDSC>;
+
--- /dev/null
+From b6ddc5c37323f7875c2533cc4949be58d15e430a Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Fri, 13 Dec 2024 15:53:59 +0100
+Subject: arm64: dts: qcom: sm8650: Fix ADSP memory base and length
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit b6ddc5c37323f7875c2533cc4949be58d15e430a upstream.
+
+The address space in ADSP PAS (Peripheral Authentication Service)
+remoteproc node should point to the QDSP PUB address space
+(QDSP6...SS_PUB): 0x0680_0000 with length of 0x10000.
+
+0x3000_0000, value used so far, is the main region of CDSP. Downstream
+DTS uses 0x0300_0000, which is oddly similar to 0x3000_0000, yet quite
+different and points to unused area.
+
+Correct the base address and length, which also moves the node to
+different place to keep things sorted by unit address. The diff looks
+big, but only the unit address and "reg" property were changed. This
+should have no functional impact on Linux users, because PAS loader does
+not use this address space at all.
+
+Fixes: 10e024671295 ("arm64: dts: qcom: sm8650: add interconnect dependent device nodes")
+Cc: stable@vger.kernel.org
+Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-10-2e0036fccd8d@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sm8650.dtsi | 296 +++++++++++++++++------------------
+ 1 file changed, 148 insertions(+), 148 deletions(-)
+
+--- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
++++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
+@@ -2904,6 +2904,154 @@
+ };
+ };
+
++ remoteproc_adsp: remoteproc@6800000 {
++ compatible = "qcom,sm8650-adsp-pas";
++ reg = <0x0 0x06800000 0x0 0x10000>;
++
++ interrupts-extended = <&pdc 6 IRQ_TYPE_EDGE_RISING>,
++ <&smp2p_adsp_in 0 IRQ_TYPE_EDGE_RISING>,
++ <&smp2p_adsp_in 1 IRQ_TYPE_EDGE_RISING>,
++ <&smp2p_adsp_in 2 IRQ_TYPE_EDGE_RISING>,
++ <&smp2p_adsp_in 3 IRQ_TYPE_EDGE_RISING>;
++ interrupt-names = "wdog",
++ "fatal",
++ "ready",
++ "handover",
++ "stop-ack";
++
++ clocks = <&rpmhcc RPMH_CXO_CLK>;
++ clock-names = "xo";
++
++ interconnects = <&lpass_lpicx_noc MASTER_LPASS_PROC QCOM_ICC_TAG_ALWAYS
++ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
++
++ power-domains = <&rpmhpd RPMHPD_LCX>,
++ <&rpmhpd RPMHPD_LMX>;
++ power-domain-names = "lcx",
++ "lmx";
++
++ memory-region = <&adspslpi_mem>, <&q6_adsp_dtb_mem>;
++
++ qcom,qmp = <&aoss_qmp>;
++
++ qcom,smem-states = <&smp2p_adsp_out 0>;
++ qcom,smem-state-names = "stop";
++
++ status = "disabled";
++
++ remoteproc_adsp_glink: glink-edge {
++ interrupts-extended = <&ipcc IPCC_CLIENT_LPASS
++ IPCC_MPROC_SIGNAL_GLINK_QMP
++ IRQ_TYPE_EDGE_RISING>;
++
++ mboxes = <&ipcc IPCC_CLIENT_LPASS
++ IPCC_MPROC_SIGNAL_GLINK_QMP>;
++
++ qcom,remote-pid = <2>;
++
++ label = "lpass";
++
++ fastrpc {
++ compatible = "qcom,fastrpc";
++
++ qcom,glink-channels = "fastrpcglink-apps-dsp";
++
++ label = "adsp";
++
++ qcom,non-secure-domain;
++
++ #address-cells = <1>;
++ #size-cells = <0>;
++
++ compute-cb@3 {
++ compatible = "qcom,fastrpc-compute-cb";
++ reg = <3>;
++
++ iommus = <&apps_smmu 0x1003 0x80>,
++ <&apps_smmu 0x1043 0x20>;
++ dma-coherent;
++ };
++
++ compute-cb@4 {
++ compatible = "qcom,fastrpc-compute-cb";
++ reg = <4>;
++
++ iommus = <&apps_smmu 0x1004 0x80>,
++ <&apps_smmu 0x1044 0x20>;
++ dma-coherent;
++ };
++
++ compute-cb@5 {
++ compatible = "qcom,fastrpc-compute-cb";
++ reg = <5>;
++
++ iommus = <&apps_smmu 0x1005 0x80>,
++ <&apps_smmu 0x1045 0x20>;
++ dma-coherent;
++ };
++
++ compute-cb@6 {
++ compatible = "qcom,fastrpc-compute-cb";
++ reg = <6>;
++
++ iommus = <&apps_smmu 0x1006 0x80>,
++ <&apps_smmu 0x1046 0x20>;
++ dma-coherent;
++ };
++
++ compute-cb@7 {
++ compatible = "qcom,fastrpc-compute-cb";
++ reg = <7>;
++
++ iommus = <&apps_smmu 0x1007 0x40>,
++ <&apps_smmu 0x1067 0x0>,
++ <&apps_smmu 0x1087 0x0>;
++ dma-coherent;
++ };
++ };
++
++ gpr {
++ compatible = "qcom,gpr";
++ qcom,glink-channels = "adsp_apps";
++ qcom,domain = <GPR_DOMAIN_ID_ADSP>;
++ qcom,intents = <512 20>;
++ #address-cells = <1>;
++ #size-cells = <0>;
++
++ q6apm: service@1 {
++ compatible = "qcom,q6apm";
++ reg = <GPR_APM_MODULE_IID>;
++ #sound-dai-cells = <0>;
++ qcom,protection-domain = "avs/audio",
++ "msm/adsp/audio_pd";
++
++ q6apmbedai: bedais {
++ compatible = "qcom,q6apm-lpass-dais";
++ #sound-dai-cells = <1>;
++ };
++
++ q6apmdai: dais {
++ compatible = "qcom,q6apm-dais";
++ iommus = <&apps_smmu 0x1001 0x80>,
++ <&apps_smmu 0x1061 0x0>;
++ };
++ };
++
++ q6prm: service@2 {
++ compatible = "qcom,q6prm";
++ reg = <GPR_PRM_MODULE_IID>;
++ qcom,protection-domain = "avs/audio",
++ "msm/adsp/audio_pd";
++
++ q6prmcc: clock-controller {
++ compatible = "qcom,q6prm-lpass-clocks";
++ #clock-cells = <2>;
++ };
++ };
++ };
++ };
++ };
++
+ lpass_wsa2macro: codec@6aa0000 {
+ compatible = "qcom,sm8650-lpass-wsa-macro", "qcom,sm8550-lpass-wsa-macro";
+ reg = <0 0x06aa0000 0 0x1000>;
+@@ -5324,154 +5472,6 @@
+ interrupts = <GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+- remoteproc_adsp: remoteproc@30000000 {
+- compatible = "qcom,sm8650-adsp-pas";
+- reg = <0 0x30000000 0 0x100>;
+-
+- interrupts-extended = <&pdc 6 IRQ_TYPE_EDGE_RISING>,
+- <&smp2p_adsp_in 0 IRQ_TYPE_EDGE_RISING>,
+- <&smp2p_adsp_in 1 IRQ_TYPE_EDGE_RISING>,
+- <&smp2p_adsp_in 2 IRQ_TYPE_EDGE_RISING>,
+- <&smp2p_adsp_in 3 IRQ_TYPE_EDGE_RISING>;
+- interrupt-names = "wdog",
+- "fatal",
+- "ready",
+- "handover",
+- "stop-ack";
+-
+- clocks = <&rpmhcc RPMH_CXO_CLK>;
+- clock-names = "xo";
+-
+- interconnects = <&lpass_lpicx_noc MASTER_LPASS_PROC QCOM_ICC_TAG_ALWAYS
+- &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+-
+- power-domains = <&rpmhpd RPMHPD_LCX>,
+- <&rpmhpd RPMHPD_LMX>;
+- power-domain-names = "lcx",
+- "lmx";
+-
+- memory-region = <&adspslpi_mem>, <&q6_adsp_dtb_mem>;
+-
+- qcom,qmp = <&aoss_qmp>;
+-
+- qcom,smem-states = <&smp2p_adsp_out 0>;
+- qcom,smem-state-names = "stop";
+-
+- status = "disabled";
+-
+- remoteproc_adsp_glink: glink-edge {
+- interrupts-extended = <&ipcc IPCC_CLIENT_LPASS
+- IPCC_MPROC_SIGNAL_GLINK_QMP
+- IRQ_TYPE_EDGE_RISING>;
+-
+- mboxes = <&ipcc IPCC_CLIENT_LPASS
+- IPCC_MPROC_SIGNAL_GLINK_QMP>;
+-
+- qcom,remote-pid = <2>;
+-
+- label = "lpass";
+-
+- fastrpc {
+- compatible = "qcom,fastrpc";
+-
+- qcom,glink-channels = "fastrpcglink-apps-dsp";
+-
+- label = "adsp";
+-
+- qcom,non-secure-domain;
+-
+- #address-cells = <1>;
+- #size-cells = <0>;
+-
+- compute-cb@3 {
+- compatible = "qcom,fastrpc-compute-cb";
+- reg = <3>;
+-
+- iommus = <&apps_smmu 0x1003 0x80>,
+- <&apps_smmu 0x1043 0x20>;
+- dma-coherent;
+- };
+-
+- compute-cb@4 {
+- compatible = "qcom,fastrpc-compute-cb";
+- reg = <4>;
+-
+- iommus = <&apps_smmu 0x1004 0x80>,
+- <&apps_smmu 0x1044 0x20>;
+- dma-coherent;
+- };
+-
+- compute-cb@5 {
+- compatible = "qcom,fastrpc-compute-cb";
+- reg = <5>;
+-
+- iommus = <&apps_smmu 0x1005 0x80>,
+- <&apps_smmu 0x1045 0x20>;
+- dma-coherent;
+- };
+-
+- compute-cb@6 {
+- compatible = "qcom,fastrpc-compute-cb";
+- reg = <6>;
+-
+- iommus = <&apps_smmu 0x1006 0x80>,
+- <&apps_smmu 0x1046 0x20>;
+- dma-coherent;
+- };
+-
+- compute-cb@7 {
+- compatible = "qcom,fastrpc-compute-cb";
+- reg = <7>;
+-
+- iommus = <&apps_smmu 0x1007 0x40>,
+- <&apps_smmu 0x1067 0x0>,
+- <&apps_smmu 0x1087 0x0>;
+- dma-coherent;
+- };
+- };
+-
+- gpr {
+- compatible = "qcom,gpr";
+- qcom,glink-channels = "adsp_apps";
+- qcom,domain = <GPR_DOMAIN_ID_ADSP>;
+- qcom,intents = <512 20>;
+- #address-cells = <1>;
+- #size-cells = <0>;
+-
+- q6apm: service@1 {
+- compatible = "qcom,q6apm";
+- reg = <GPR_APM_MODULE_IID>;
+- #sound-dai-cells = <0>;
+- qcom,protection-domain = "avs/audio",
+- "msm/adsp/audio_pd";
+-
+- q6apmbedai: bedais {
+- compatible = "qcom,q6apm-lpass-dais";
+- #sound-dai-cells = <1>;
+- };
+-
+- q6apmdai: dais {
+- compatible = "qcom,q6apm-dais";
+- iommus = <&apps_smmu 0x1001 0x80>,
+- <&apps_smmu 0x1061 0x0>;
+- };
+- };
+-
+- q6prm: service@2 {
+- compatible = "qcom,q6prm";
+- reg = <GPR_PRM_MODULE_IID>;
+- qcom,protection-domain = "avs/audio",
+- "msm/adsp/audio_pd";
+-
+- q6prmcc: clock-controller {
+- compatible = "qcom,q6prm-lpass-clocks";
+- #clock-cells = <2>;
+- };
+- };
+- };
+- };
+- };
+-
+ nsp_noc: interconnect@320c0000 {
+ compatible = "qcom,sm8650-nsp-noc";
+ reg = <0 0x320c0000 0 0xf080>;
--- /dev/null
+From aca0053f051625a224c2e802a0e88755770819e4 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Fri, 13 Dec 2024 15:54:00 +0100
+Subject: arm64: dts: qcom: sm8650: Fix CDSP memory length
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit aca0053f051625a224c2e802a0e88755770819e4 upstream.
+
+The address space in CDSP PAS (Peripheral Authentication Service)
+remoteproc node should point to the QDSP PUB address space
+(QDSP6...SS_PUB) which has a length of 0x10000. Value of 0x1400000 was
+copied from older DTS, but it does not look accurate at all.
+
+This should have no functional impact on Linux users, because PAS loader
+does not use this address space at all.
+
+Fixes: 10e024671295 ("arm64: dts: qcom: sm8650: add interconnect dependent device nodes")
+Cc: stable@vger.kernel.org
+Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-11-2e0036fccd8d@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sm8650.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
++++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
+@@ -5483,7 +5483,7 @@
+
+ remoteproc_cdsp: remoteproc@32300000 {
+ compatible = "qcom,sm8650-cdsp-pas";
+- reg = <0 0x32300000 0 0x1400000>;
++ reg = <0x0 0x32300000 0x0 0x10000>;
+
+ interrupts-extended = <&intc GIC_SPI 578 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_cdsp_in 0 IRQ_TYPE_EDGE_RISING>,
--- /dev/null
+From d4fa87daf3dd39d6bd4b69613e22bfb43c737831 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Fri, 13 Dec 2024 15:54:01 +0100
+Subject: arm64: dts: qcom: sm8650: Fix MPSS memory length
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit d4fa87daf3dd39d6bd4b69613e22bfb43c737831 upstream.
+
+The address space in MPSS/Modem PAS (Peripheral Authentication Service)
+remoteproc node should point to the QDSP PUB address space
+(QDSP6...SS_PUB) which has a length of 0x10000. Value of 0x4040 was
+copied from older DTS, but it grew since then.
+
+This should have no functional impact on Linux users, because PAS loader
+does not use this address space at all.
+
+Fixes: 10e024671295 ("arm64: dts: qcom: sm8650: add interconnect dependent device nodes")
+Cc: stable@vger.kernel.org
+Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-12-2e0036fccd8d@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sm8650.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
++++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
+@@ -2853,7 +2853,7 @@
+
+ remoteproc_mpss: remoteproc@4080000 {
+ compatible = "qcom,sm8650-mpss-pas";
+- reg = <0 0x04080000 0 0x4040>;
++ reg = <0x0 0x04080000 0x0 0x10000>;
+
+ interrupts-extended = <&intc GIC_SPI 264 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_modem_in 0 IRQ_TYPE_EDGE_RISING>,
--- /dev/null
+From 7a003077366946a5ed1adab6d177efb2ab59e815 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Fri, 13 Dec 2024 15:54:02 +0100
+Subject: arm64: dts: qcom: x1e80100: Fix ADSP memory base and length
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit 7a003077366946a5ed1adab6d177efb2ab59e815 upstream.
+
+The address space in ADSP PAS (Peripheral Authentication Service)
+remoteproc node should point to the QDSP PUB address space
+(QDSP6...SS_PUB): 0x0680_0000 with length of 0x10000.
+
+0x3000_0000, value used so far, is the main region of CDSP and was
+simply copied from other/older DTS.
+
+Correct the base address and length, which also moves the node to
+different place to keep things sorted by unit address. The diff looks
+big, but only the unit address and "reg" property were changed. This
+should have no functional impact on Linux users, because PAS loader does
+not use this address space at all.
+
+Fixes: 5f2a9cd4b104 ("arm64: dts: qcom: x1e80100: Add ADSP/CDSP remoteproc nodes")
+Cc: stable@vger.kernel.org
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
+Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-13-2e0036fccd8d@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/x1e80100.dtsi | 274 ++++++++++++++++-----------------
+ 1 file changed, 137 insertions(+), 137 deletions(-)
+
+--- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
++++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
+@@ -3515,6 +3515,143 @@
+ #interconnect-cells = <2>;
+ };
+
++ remoteproc_adsp: remoteproc@6800000 {
++ compatible = "qcom,x1e80100-adsp-pas";
++ reg = <0x0 0x06800000 0x0 0x10000>;
++
++ interrupts-extended = <&pdc 6 IRQ_TYPE_EDGE_RISING>,
++ <&smp2p_adsp_in 0 IRQ_TYPE_EDGE_RISING>,
++ <&smp2p_adsp_in 1 IRQ_TYPE_EDGE_RISING>,
++ <&smp2p_adsp_in 2 IRQ_TYPE_EDGE_RISING>,
++ <&smp2p_adsp_in 3 IRQ_TYPE_EDGE_RISING>;
++ interrupt-names = "wdog",
++ "fatal",
++ "ready",
++ "handover",
++ "stop-ack";
++
++ clocks = <&rpmhcc RPMH_CXO_CLK>;
++ clock-names = "xo";
++
++ power-domains = <&rpmhpd RPMHPD_LCX>,
++ <&rpmhpd RPMHPD_LMX>;
++ power-domain-names = "lcx",
++ "lmx";
++
++ interconnects = <&lpass_lpicx_noc MASTER_LPASS_PROC QCOM_ICC_TAG_ALWAYS
++ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
++
++ memory-region = <&adspslpi_mem>,
++ <&q6_adsp_dtb_mem>;
++
++ qcom,qmp = <&aoss_qmp>;
++
++ qcom,smem-states = <&smp2p_adsp_out 0>;
++ qcom,smem-state-names = "stop";
++
++ status = "disabled";
++
++ glink-edge {
++ interrupts-extended = <&ipcc IPCC_CLIENT_LPASS
++ IPCC_MPROC_SIGNAL_GLINK_QMP
++ IRQ_TYPE_EDGE_RISING>;
++ mboxes = <&ipcc IPCC_CLIENT_LPASS
++ IPCC_MPROC_SIGNAL_GLINK_QMP>;
++
++ label = "lpass";
++ qcom,remote-pid = <2>;
++
++ fastrpc {
++ compatible = "qcom,fastrpc";
++ qcom,glink-channels = "fastrpcglink-apps-dsp";
++ label = "adsp";
++ qcom,non-secure-domain;
++ #address-cells = <1>;
++ #size-cells = <0>;
++
++ compute-cb@3 {
++ compatible = "qcom,fastrpc-compute-cb";
++ reg = <3>;
++ iommus = <&apps_smmu 0x1003 0x80>,
++ <&apps_smmu 0x1063 0x0>;
++ dma-coherent;
++ };
++
++ compute-cb@4 {
++ compatible = "qcom,fastrpc-compute-cb";
++ reg = <4>;
++ iommus = <&apps_smmu 0x1004 0x80>,
++ <&apps_smmu 0x1064 0x0>;
++ dma-coherent;
++ };
++
++ compute-cb@5 {
++ compatible = "qcom,fastrpc-compute-cb";
++ reg = <5>;
++ iommus = <&apps_smmu 0x1005 0x80>,
++ <&apps_smmu 0x1065 0x0>;
++ dma-coherent;
++ };
++
++ compute-cb@6 {
++ compatible = "qcom,fastrpc-compute-cb";
++ reg = <6>;
++ iommus = <&apps_smmu 0x1006 0x80>,
++ <&apps_smmu 0x1066 0x0>;
++ dma-coherent;
++ };
++
++ compute-cb@7 {
++ compatible = "qcom,fastrpc-compute-cb";
++ reg = <7>;
++ iommus = <&apps_smmu 0x1007 0x80>,
++ <&apps_smmu 0x1067 0x0>;
++ dma-coherent;
++ };
++ };
++
++ gpr {
++ compatible = "qcom,gpr";
++ qcom,glink-channels = "adsp_apps";
++ qcom,domain = <GPR_DOMAIN_ID_ADSP>;
++ qcom,intents = <512 20>;
++ #address-cells = <1>;
++ #size-cells = <0>;
++
++ q6apm: service@1 {
++ compatible = "qcom,q6apm";
++ reg = <GPR_APM_MODULE_IID>;
++ #sound-dai-cells = <0>;
++ qcom,protection-domain = "avs/audio",
++ "msm/adsp/audio_pd";
++
++ q6apmbedai: bedais {
++ compatible = "qcom,q6apm-lpass-dais";
++ #sound-dai-cells = <1>;
++ };
++
++ q6apmdai: dais {
++ compatible = "qcom,q6apm-dais";
++ iommus = <&apps_smmu 0x1001 0x80>,
++ <&apps_smmu 0x1061 0x0>;
++ };
++ };
++
++ q6prm: service@2 {
++ compatible = "qcom,q6prm";
++ reg = <GPR_PRM_MODULE_IID>;
++ qcom,protection-domain = "avs/audio",
++ "msm/adsp/audio_pd";
++
++ q6prmcc: clock-controller {
++ compatible = "qcom,q6prm-lpass-clocks";
++ #clock-cells = <2>;
++ };
++ };
++ };
++ };
++ };
++
+ lpass_wsa2macro: codec@6aa0000 {
+ compatible = "qcom,x1e80100-lpass-wsa-macro", "qcom,sm8550-lpass-wsa-macro";
+ reg = <0 0x06aa0000 0 0x1000>;
+@@ -6108,143 +6245,6 @@
+ interrupts = <GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+- remoteproc_adsp: remoteproc@30000000 {
+- compatible = "qcom,x1e80100-adsp-pas";
+- reg = <0 0x30000000 0 0x100>;
+-
+- interrupts-extended = <&pdc 6 IRQ_TYPE_EDGE_RISING>,
+- <&smp2p_adsp_in 0 IRQ_TYPE_EDGE_RISING>,
+- <&smp2p_adsp_in 1 IRQ_TYPE_EDGE_RISING>,
+- <&smp2p_adsp_in 2 IRQ_TYPE_EDGE_RISING>,
+- <&smp2p_adsp_in 3 IRQ_TYPE_EDGE_RISING>;
+- interrupt-names = "wdog",
+- "fatal",
+- "ready",
+- "handover",
+- "stop-ack";
+-
+- clocks = <&rpmhcc RPMH_CXO_CLK>;
+- clock-names = "xo";
+-
+- power-domains = <&rpmhpd RPMHPD_LCX>,
+- <&rpmhpd RPMHPD_LMX>;
+- power-domain-names = "lcx",
+- "lmx";
+-
+- interconnects = <&lpass_lpicx_noc MASTER_LPASS_PROC QCOM_ICC_TAG_ALWAYS
+- &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+-
+- memory-region = <&adspslpi_mem>,
+- <&q6_adsp_dtb_mem>;
+-
+- qcom,qmp = <&aoss_qmp>;
+-
+- qcom,smem-states = <&smp2p_adsp_out 0>;
+- qcom,smem-state-names = "stop";
+-
+- status = "disabled";
+-
+- glink-edge {
+- interrupts-extended = <&ipcc IPCC_CLIENT_LPASS
+- IPCC_MPROC_SIGNAL_GLINK_QMP
+- IRQ_TYPE_EDGE_RISING>;
+- mboxes = <&ipcc IPCC_CLIENT_LPASS
+- IPCC_MPROC_SIGNAL_GLINK_QMP>;
+-
+- label = "lpass";
+- qcom,remote-pid = <2>;
+-
+- fastrpc {
+- compatible = "qcom,fastrpc";
+- qcom,glink-channels = "fastrpcglink-apps-dsp";
+- label = "adsp";
+- qcom,non-secure-domain;
+- #address-cells = <1>;
+- #size-cells = <0>;
+-
+- compute-cb@3 {
+- compatible = "qcom,fastrpc-compute-cb";
+- reg = <3>;
+- iommus = <&apps_smmu 0x1003 0x80>,
+- <&apps_smmu 0x1063 0x0>;
+- dma-coherent;
+- };
+-
+- compute-cb@4 {
+- compatible = "qcom,fastrpc-compute-cb";
+- reg = <4>;
+- iommus = <&apps_smmu 0x1004 0x80>,
+- <&apps_smmu 0x1064 0x0>;
+- dma-coherent;
+- };
+-
+- compute-cb@5 {
+- compatible = "qcom,fastrpc-compute-cb";
+- reg = <5>;
+- iommus = <&apps_smmu 0x1005 0x80>,
+- <&apps_smmu 0x1065 0x0>;
+- dma-coherent;
+- };
+-
+- compute-cb@6 {
+- compatible = "qcom,fastrpc-compute-cb";
+- reg = <6>;
+- iommus = <&apps_smmu 0x1006 0x80>,
+- <&apps_smmu 0x1066 0x0>;
+- dma-coherent;
+- };
+-
+- compute-cb@7 {
+- compatible = "qcom,fastrpc-compute-cb";
+- reg = <7>;
+- iommus = <&apps_smmu 0x1007 0x80>,
+- <&apps_smmu 0x1067 0x0>;
+- dma-coherent;
+- };
+- };
+-
+- gpr {
+- compatible = "qcom,gpr";
+- qcom,glink-channels = "adsp_apps";
+- qcom,domain = <GPR_DOMAIN_ID_ADSP>;
+- qcom,intents = <512 20>;
+- #address-cells = <1>;
+- #size-cells = <0>;
+-
+- q6apm: service@1 {
+- compatible = "qcom,q6apm";
+- reg = <GPR_APM_MODULE_IID>;
+- #sound-dai-cells = <0>;
+- qcom,protection-domain = "avs/audio",
+- "msm/adsp/audio_pd";
+-
+- q6apmbedai: bedais {
+- compatible = "qcom,q6apm-lpass-dais";
+- #sound-dai-cells = <1>;
+- };
+-
+- q6apmdai: dais {
+- compatible = "qcom,q6apm-dais";
+- iommus = <&apps_smmu 0x1001 0x80>,
+- <&apps_smmu 0x1061 0x0>;
+- };
+- };
+-
+- q6prm: service@2 {
+- compatible = "qcom,q6prm";
+- reg = <GPR_PRM_MODULE_IID>;
+- qcom,protection-domain = "avs/audio",
+- "msm/adsp/audio_pd";
+-
+- q6prmcc: clock-controller {
+- compatible = "qcom,q6prm-lpass-clocks";
+- #clock-cells = <2>;
+- };
+- };
+- };
+- };
+- };
+-
+ remoteproc_cdsp: remoteproc@32300000 {
+ compatible = "qcom,x1e80100-cdsp-pas";
+ reg = <0 0x32300000 0 0x1400000>;
--- /dev/null
+From 3de1bf12c6bfb9a92f0803941ecae39b08470446 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Fri, 13 Dec 2024 15:54:03 +0100
+Subject: arm64: dts: qcom: x1e80100: Fix CDSP memory length
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit 3de1bf12c6bfb9a92f0803941ecae39b08470446 upstream.
+
+The address space in CDSP PAS (Peripheral Authentication Service)
+remoteproc node should point to the QDSP PUB address space
+(QDSP6...SS_PUB) which has a length of 0x10000. Value of 0x1400000 was
+copied from older DTS, but it does not look accurate at all.
+
+This should have no functional impact on Linux users, because PAS loader
+does not use this address space at all.
+
+Fixes: 5f2a9cd4b104 ("arm64: dts: qcom: x1e80100: Add ADSP/CDSP remoteproc nodes")
+Cc: stable@vger.kernel.org
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
+Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-14-2e0036fccd8d@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/x1e80100.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
++++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
+@@ -6247,7 +6247,7 @@
+
+ remoteproc_cdsp: remoteproc@32300000 {
+ compatible = "qcom,x1e80100-cdsp-pas";
+- reg = <0 0x32300000 0 0x1400000>;
++ reg = <0x0 0x32300000 0x0 0x10000>;
+
+ interrupts-extended = <&intc GIC_SPI 578 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_cdsp_in 0 IRQ_TYPE_EDGE_RISING>,
--- /dev/null
+From a5e6fc0a10fe280989f1367a3b4f8047c7d00ea6 Mon Sep 17 00:00:00 2001
+From: Sumit Gupta <sumitg@nvidia.com>
+Date: Wed, 18 Dec 2024 00:07:37 +0000
+Subject: arm64: tegra: Disable Tegra234 sce-fabric node
+
+From: Sumit Gupta <sumitg@nvidia.com>
+
+commit a5e6fc0a10fe280989f1367a3b4f8047c7d00ea6 upstream.
+
+Access to safety cluster engine (SCE) fabric registers was blocked
+by firewall after the introduction of Functional Safety Island in
+Tegra234. After that, any access by software to SCE registers is
+correctly resulting in the internal bus error. However, when CPUs
+try accessing the SCE-fabric registers to print error info,
+another firewall error occurs as the fabric registers are also
+firewall protected. This results in a second error to be printed.
+Disable the SCE fabric node to avoid printing the misleading error.
+The first error info will be printed by the interrupt from the
+fabric causing the actual access.
+
+Cc: stable@vger.kernel.org
+Fixes: 302e154000ec ("arm64: tegra: Add node for CBB 2.0 on Tegra234")
+Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
+Signed-off-by: Ivy Huang <yijuh@nvidia.com>
+Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
+Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
+Link: https://lore.kernel.org/r/20241218000737.1789569-3-yijuh@nvidia.com
+Signed-off-by: Thierry Reding <treding@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/nvidia/tegra234.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/nvidia/tegra234.dtsi
++++ b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
+@@ -3815,7 +3815,7 @@
+ compatible = "nvidia,tegra234-sce-fabric";
+ reg = <0x0 0xb600000 0x0 0x40000>;
+ interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
+- status = "okay";
++ status = "disabled";
+ };
+
+ rce-fabric@be00000 {
--- /dev/null
+From 604120fd9e9df50ee0e803d3c6e77a1f45d2c58e Mon Sep 17 00:00:00 2001
+From: Sumit Gupta <sumitg@nvidia.com>
+Date: Wed, 18 Dec 2024 00:07:36 +0000
+Subject: arm64: tegra: Fix typo in Tegra234 dce-fabric compatible
+
+From: Sumit Gupta <sumitg@nvidia.com>
+
+commit 604120fd9e9df50ee0e803d3c6e77a1f45d2c58e upstream.
+
+The compatible string for the Tegra DCE fabric is currently defined as
+'nvidia,tegra234-sce-fabric' but this is incorrect because this is the
+compatible string for SCE fabric. Update the compatible for the DCE
+fabric to correct the compatible string.
+
+This compatible needs to be correct in order for the interconnect
+to catch things such as improper data accesses.
+
+Cc: stable@vger.kernel.org
+Fixes: 302e154000ec ("arm64: tegra: Add node for CBB 2.0 on Tegra234")
+Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
+Signed-off-by: Ivy Huang <yijuh@nvidia.com>
+Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
+Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
+Link: https://lore.kernel.org/r/20241218000737.1789569-2-yijuh@nvidia.com
+Signed-off-by: Thierry Reding <treding@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/nvidia/tegra234.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/nvidia/tegra234.dtsi
++++ b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
+@@ -3995,7 +3995,7 @@
+ };
+
+ dce-fabric@de00000 {
+- compatible = "nvidia,tegra234-sce-fabric";
++ compatible = "nvidia,tegra234-dce-fabric";
+ reg = <0x0 0xde00000 0x0 0x40000>;
+ interrupts = <GIC_SPI 381 IRQ_TYPE_LEVEL_HIGH>;
+ status = "okay";
--- /dev/null
+From 49b9258b05b97c6464e1964b6a2fddb3ddb65d17 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Tue, 3 Dec 2024 10:05:53 -0800
+Subject: crypto: qce - fix priority to be less than ARMv8 CE
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit 49b9258b05b97c6464e1964b6a2fddb3ddb65d17 upstream.
+
+As QCE is an order of magnitude slower than the ARMv8 Crypto Extensions
+on the CPU, and is also less well tested, give it a lower priority.
+Previously the QCE SHA algorithms had higher priority than the ARMv8 CE
+equivalents, and the ciphers such as AES-XTS had the same priority which
+meant the QCE versions were chosen if they happened to be loaded later.
+
+Fixes: ec8f5d8f6f76 ("crypto: qce - Qualcomm crypto engine driver")
+Cc: stable@vger.kernel.org
+Cc: Bartosz Golaszewski <brgl@bgdev.pl>
+Cc: Neil Armstrong <neil.armstrong@linaro.org>
+Cc: Thara Gopinath <thara.gopinath@gmail.com>
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/crypto/qce/aead.c | 2 +-
+ drivers/crypto/qce/sha.c | 2 +-
+ drivers/crypto/qce/skcipher.c | 2 +-
+ 3 files changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/crypto/qce/aead.c
++++ b/drivers/crypto/qce/aead.c
+@@ -786,7 +786,7 @@ static int qce_aead_register_one(const s
+ alg->init = qce_aead_init;
+ alg->exit = qce_aead_exit;
+
+- alg->base.cra_priority = 300;
++ alg->base.cra_priority = 275;
+ alg->base.cra_flags = CRYPTO_ALG_ASYNC |
+ CRYPTO_ALG_ALLOCATES_MEMORY |
+ CRYPTO_ALG_KERN_DRIVER_ONLY |
+--- a/drivers/crypto/qce/sha.c
++++ b/drivers/crypto/qce/sha.c
+@@ -482,7 +482,7 @@ static int qce_ahash_register_one(const
+
+ base = &alg->halg.base;
+ base->cra_blocksize = def->blocksize;
+- base->cra_priority = 300;
++ base->cra_priority = 175;
+ base->cra_flags = CRYPTO_ALG_ASYNC | CRYPTO_ALG_KERN_DRIVER_ONLY;
+ base->cra_ctxsize = sizeof(struct qce_sha_ctx);
+ base->cra_alignmask = 0;
+--- a/drivers/crypto/qce/skcipher.c
++++ b/drivers/crypto/qce/skcipher.c
+@@ -461,7 +461,7 @@ static int qce_skcipher_register_one(con
+ alg->encrypt = qce_skcipher_encrypt;
+ alg->decrypt = qce_skcipher_decrypt;
+
+- alg->base.cra_priority = 300;
++ alg->base.cra_priority = 275;
+ alg->base.cra_flags = CRYPTO_ALG_ASYNC |
+ CRYPTO_ALG_ALLOCATES_MEMORY |
+ CRYPTO_ALG_KERN_DRIVER_ONLY;
--- /dev/null
+From 53dac345395c0d2493cbc2f4c85fe38aef5b63f5 Mon Sep 17 00:00:00 2001
+From: Frederic Weisbecker <frederic@kernel.org>
+Date: Sat, 18 Jan 2025 00:24:33 +0100
+Subject: hrtimers: Force migrate away hrtimers queued after CPUHP_AP_HRTIMERS_DYING
+
+From: Frederic Weisbecker <frederic@kernel.org>
+
+commit 53dac345395c0d2493cbc2f4c85fe38aef5b63f5 upstream.
+
+hrtimers are migrated away from the dying CPU to any online target at
+the CPUHP_AP_HRTIMERS_DYING stage in order not to delay bandwidth timers
+handling tasks involved in the CPU hotplug forward progress.
+
+However wakeups can still be performed by the outgoing CPU after
+CPUHP_AP_HRTIMERS_DYING. Those can result again in bandwidth timers being
+armed. Depending on several considerations (crystal ball power management
+based election, earliest timer already enqueued, timer migration enabled or
+not), the target may eventually be the current CPU even if offline. If that
+happens, the timer is eventually ignored.
+
+The most notable example is RCU which had to deal with each and every of
+those wake-ups by deferring them to an online CPU, along with related
+workarounds:
+
+_ e787644caf76 (rcu: Defer RCU kthreads wakeup when CPU is dying)
+_ 9139f93209d1 (rcu/nocb: Fix RT throttling hrtimer armed from offline CPU)
+_ f7345ccc62a4 (rcu/nocb: Fix rcuog wake-up from offline softirq)
+
+The problem isn't confined to RCU though as the stop machine kthread
+(which runs CPUHP_AP_HRTIMERS_DYING) reports its completion at the end
+of its work through cpu_stop_signal_done() and performs a wake up that
+eventually arms the deadline server timer:
+
+ WARNING: CPU: 94 PID: 588 at kernel/time/hrtimer.c:1086 hrtimer_start_range_ns+0x289/0x2d0
+ CPU: 94 UID: 0 PID: 588 Comm: migration/94 Not tainted
+ Stopper: multi_cpu_stop+0x0/0x120 <- stop_machine_cpuslocked+0x66/0xc0
+ RIP: 0010:hrtimer_start_range_ns+0x289/0x2d0
+ Call Trace:
+ <TASK>
+ start_dl_timer
+ enqueue_dl_entity
+ dl_server_start
+ enqueue_task_fair
+ enqueue_task
+ ttwu_do_activate
+ try_to_wake_up
+ complete
+ cpu_stopper_thread
+
+Instead of providing yet another bandaid to work around the situation, fix
+it in the hrtimers infrastructure instead: always migrate away a timer to
+an online target whenever it is enqueued from an offline CPU.
+
+This will also allow to revert all the above RCU disgraceful hacks.
+
+Fixes: 5c0930ccaad5 ("hrtimers: Push pending hrtimers away from outgoing CPU earlier")
+Reported-by: Vlad Poenaru <vlad.wing@gmail.com>
+Reported-by: Usama Arif <usamaarif642@gmail.com>
+Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
+Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Tested-by: Paul E. McKenney <paulmck@kernel.org>
+Link: https://lore.kernel.org/all/20250117232433.24027-1-frederic@kernel.org
+Closes: 20241213203739.1519801-1-usamaarif642@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/hrtimer_defs.h | 1
+ kernel/time/hrtimer.c | 103 ++++++++++++++++++++++++++++++++++---------
+ 2 files changed, 83 insertions(+), 21 deletions(-)
+
+--- a/include/linux/hrtimer_defs.h
++++ b/include/linux/hrtimer_defs.h
+@@ -125,6 +125,7 @@ struct hrtimer_cpu_base {
+ ktime_t softirq_expires_next;
+ struct hrtimer *softirq_next_timer;
+ struct hrtimer_clock_base clock_base[HRTIMER_MAX_CLOCK_BASES];
++ call_single_data_t csd;
+ } ____cacheline_aligned;
+
+
+--- a/kernel/time/hrtimer.c
++++ b/kernel/time/hrtimer.c
+@@ -58,6 +58,8 @@
+ #define HRTIMER_ACTIVE_SOFT (HRTIMER_ACTIVE_HARD << MASK_SHIFT)
+ #define HRTIMER_ACTIVE_ALL (HRTIMER_ACTIVE_SOFT | HRTIMER_ACTIVE_HARD)
+
++static void retrigger_next_event(void *arg);
++
+ /*
+ * The timer bases:
+ *
+@@ -111,7 +113,8 @@ DEFINE_PER_CPU(struct hrtimer_cpu_base,
+ .clockid = CLOCK_TAI,
+ .get_time = &ktime_get_clocktai,
+ },
+- }
++ },
++ .csd = CSD_INIT(retrigger_next_event, NULL)
+ };
+
+ static const int hrtimer_clock_to_base_table[MAX_CLOCKS] = {
+@@ -124,6 +127,14 @@ static const int hrtimer_clock_to_base_t
+ [CLOCK_TAI] = HRTIMER_BASE_TAI,
+ };
+
++static inline bool hrtimer_base_is_online(struct hrtimer_cpu_base *base)
++{
++ if (!IS_ENABLED(CONFIG_HOTPLUG_CPU))
++ return true;
++ else
++ return likely(base->online);
++}
++
+ /*
+ * Functions and macros which are different for UP/SMP systems are kept in a
+ * single place
+@@ -183,27 +194,54 @@ struct hrtimer_clock_base *lock_hrtimer_
+ }
+
+ /*
+- * We do not migrate the timer when it is expiring before the next
+- * event on the target cpu. When high resolution is enabled, we cannot
+- * reprogram the target cpu hardware and we would cause it to fire
+- * late. To keep it simple, we handle the high resolution enabled and
+- * disabled case similar.
++ * Check if the elected target is suitable considering its next
++ * event and the hotplug state of the current CPU.
++ *
++ * If the elected target is remote and its next event is after the timer
++ * to queue, then a remote reprogram is necessary. However there is no
++ * guarantee the IPI handling the operation would arrive in time to meet
++ * the high resolution deadline. In this case the local CPU becomes a
++ * preferred target, unless it is offline.
++ *
++ * High and low resolution modes are handled the same way for simplicity.
+ *
+ * Called with cpu_base->lock of target cpu held.
+ */
+-static int
+-hrtimer_check_target(struct hrtimer *timer, struct hrtimer_clock_base *new_base)
++static bool hrtimer_suitable_target(struct hrtimer *timer, struct hrtimer_clock_base *new_base,
++ struct hrtimer_cpu_base *new_cpu_base,
++ struct hrtimer_cpu_base *this_cpu_base)
+ {
+ ktime_t expires;
+
++ /*
++ * The local CPU clockevent can be reprogrammed. Also get_target_base()
++ * guarantees it is online.
++ */
++ if (new_cpu_base == this_cpu_base)
++ return true;
++
++ /*
++ * The offline local CPU can't be the default target if the
++ * next remote target event is after this timer. Keep the
++ * elected new base. An IPI will we issued to reprogram
++ * it as a last resort.
++ */
++ if (!hrtimer_base_is_online(this_cpu_base))
++ return true;
++
+ expires = ktime_sub(hrtimer_get_expires(timer), new_base->offset);
+- return expires < new_base->cpu_base->expires_next;
++
++ return expires >= new_base->cpu_base->expires_next;
+ }
+
+-static inline
+-struct hrtimer_cpu_base *get_target_base(struct hrtimer_cpu_base *base,
+- int pinned)
++static inline struct hrtimer_cpu_base *get_target_base(struct hrtimer_cpu_base *base, int pinned)
+ {
++ if (!hrtimer_base_is_online(base)) {
++ int cpu = cpumask_any_and(cpu_online_mask, housekeeping_cpumask(HK_TYPE_TIMER));
++
++ return &per_cpu(hrtimer_bases, cpu);
++ }
++
+ #if defined(CONFIG_SMP) && defined(CONFIG_NO_HZ_COMMON)
+ if (static_branch_likely(&timers_migration_enabled) && !pinned)
+ return &per_cpu(hrtimer_bases, get_nohz_timer_target());
+@@ -254,8 +292,8 @@ again:
+ raw_spin_unlock(&base->cpu_base->lock);
+ raw_spin_lock(&new_base->cpu_base->lock);
+
+- if (new_cpu_base != this_cpu_base &&
+- hrtimer_check_target(timer, new_base)) {
++ if (!hrtimer_suitable_target(timer, new_base, new_cpu_base,
++ this_cpu_base)) {
+ raw_spin_unlock(&new_base->cpu_base->lock);
+ raw_spin_lock(&base->cpu_base->lock);
+ new_cpu_base = this_cpu_base;
+@@ -264,8 +302,7 @@ again:
+ }
+ WRITE_ONCE(timer->base, new_base);
+ } else {
+- if (new_cpu_base != this_cpu_base &&
+- hrtimer_check_target(timer, new_base)) {
++ if (!hrtimer_suitable_target(timer, new_base, new_cpu_base, this_cpu_base)) {
+ new_cpu_base = this_cpu_base;
+ goto again;
+ }
+@@ -725,8 +762,6 @@ static inline int hrtimer_is_hres_enable
+ return hrtimer_hres_enabled;
+ }
+
+-static void retrigger_next_event(void *arg);
+-
+ /*
+ * Switch to high resolution mode
+ */
+@@ -1215,6 +1250,7 @@ static int __hrtimer_start_range_ns(stru
+ u64 delta_ns, const enum hrtimer_mode mode,
+ struct hrtimer_clock_base *base)
+ {
++ struct hrtimer_cpu_base *this_cpu_base = this_cpu_ptr(&hrtimer_bases);
+ struct hrtimer_clock_base *new_base;
+ bool force_local, first;
+
+@@ -1226,10 +1262,16 @@ static int __hrtimer_start_range_ns(stru
+ * and enforce reprogramming after it is queued no matter whether
+ * it is the new first expiring timer again or not.
+ */
+- force_local = base->cpu_base == this_cpu_ptr(&hrtimer_bases);
++ force_local = base->cpu_base == this_cpu_base;
+ force_local &= base->cpu_base->next_timer == timer;
+
+ /*
++ * Don't force local queuing if this enqueue happens on a unplugged
++ * CPU after hrtimer_cpu_dying() has been invoked.
++ */
++ force_local &= this_cpu_base->online;
++
++ /*
+ * Remove an active timer from the queue. In case it is not queued
+ * on the current CPU, make sure that remove_hrtimer() updates the
+ * remote data correctly.
+@@ -1258,8 +1300,27 @@ static int __hrtimer_start_range_ns(stru
+ }
+
+ first = enqueue_hrtimer(timer, new_base, mode);
+- if (!force_local)
+- return first;
++ if (!force_local) {
++ /*
++ * If the current CPU base is online, then the timer is
++ * never queued on a remote CPU if it would be the first
++ * expiring timer there.
++ */
++ if (hrtimer_base_is_online(this_cpu_base))
++ return first;
++
++ /*
++ * Timer was enqueued remote because the current base is
++ * already offline. If the timer is the first to expire,
++ * kick the remote CPU to reprogram the clock event.
++ */
++ if (first) {
++ struct hrtimer_cpu_base *new_cpu_base = new_base->cpu_base;
++
++ smp_call_function_single_async(new_cpu_base->cpu, &new_cpu_base->csd);
++ }
++ return 0;
++ }
+
+ /*
+ * Timer was forced to stay on the current CPU to avoid
--- /dev/null
+From ab09c6cfe01b317f515bcd944668697241a54b9d Mon Sep 17 00:00:00 2001
+From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+Date: Sat, 14 Dec 2024 23:55:50 +0100
+Subject: iio: light: as73211: fix channel handling in only-color triggered buffer
+
+From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+commit ab09c6cfe01b317f515bcd944668697241a54b9d upstream.
+
+The channel index is off by one unit if AS73211_SCAN_MASK_ALL is not
+set (optimized path for color channel readings), and it must be shifted
+instead of leaving an empty channel for the temperature when it is off.
+
+Once the channel index is fixed, the uninitialized channel must be set
+to zero to avoid pushing uninitialized data.
+
+Add available_scan_masks for all channels and only-color channels to let
+the IIO core demux and repack the enabled channels.
+
+Cc: stable@vger.kernel.org
+Fixes: 403e5586b52e ("iio: light: as73211: New driver")
+Tested-by: Christian Eggers <ceggers@arri.de>
+Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+Link: https://patch.msgid.link/20241214-iio_memset_scan_holes-v4-1-260b395b8ed5@gmail.com
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/light/as73211.c | 24 ++++++++++++++++++++----
+ 1 file changed, 20 insertions(+), 4 deletions(-)
+
+--- a/drivers/iio/light/as73211.c
++++ b/drivers/iio/light/as73211.c
+@@ -177,6 +177,12 @@ struct as73211_data {
+ BIT(AS73211_SCAN_INDEX_TEMP) | \
+ AS73211_SCAN_MASK_COLOR)
+
++static const unsigned long as73211_scan_masks[] = {
++ AS73211_SCAN_MASK_COLOR,
++ AS73211_SCAN_MASK_ALL,
++ 0
++};
++
+ static const struct iio_chan_spec as73211_channels[] = {
+ {
+ .type = IIO_TEMP,
+@@ -672,9 +678,12 @@ static irqreturn_t as73211_trigger_handl
+
+ /* AS73211 starts reading at address 2 */
+ ret = i2c_master_recv(data->client,
+- (char *)&scan.chan[1], 3 * sizeof(scan.chan[1]));
++ (char *)&scan.chan[0], 3 * sizeof(scan.chan[0]));
+ if (ret < 0)
+ goto done;
++
++ /* Avoid pushing uninitialized data */
++ scan.chan[3] = 0;
+ }
+
+ if (data_result) {
+@@ -682,9 +691,15 @@ static irqreturn_t as73211_trigger_handl
+ * Saturate all channels (in case of overflows). Temperature channel
+ * is not affected by overflows.
+ */
+- scan.chan[1] = cpu_to_le16(U16_MAX);
+- scan.chan[2] = cpu_to_le16(U16_MAX);
+- scan.chan[3] = cpu_to_le16(U16_MAX);
++ if (*indio_dev->active_scan_mask == AS73211_SCAN_MASK_ALL) {
++ scan.chan[1] = cpu_to_le16(U16_MAX);
++ scan.chan[2] = cpu_to_le16(U16_MAX);
++ scan.chan[3] = cpu_to_le16(U16_MAX);
++ } else {
++ scan.chan[0] = cpu_to_le16(U16_MAX);
++ scan.chan[1] = cpu_to_le16(U16_MAX);
++ scan.chan[2] = cpu_to_le16(U16_MAX);
++ }
+ }
+
+ iio_push_to_buffers_with_timestamp(indio_dev, &scan, iio_get_time_ns(indio_dev));
+@@ -758,6 +773,7 @@ static int as73211_probe(struct i2c_clie
+ indio_dev->channels = data->spec_dev->channels;
+ indio_dev->num_channels = data->spec_dev->num_channels;
+ indio_dev->modes = INDIO_DIRECT_MODE;
++ indio_dev->available_scan_masks = as73211_scan_masks;
+
+ ret = i2c_smbus_read_byte_data(data->client, AS73211_REG_OSR);
+ if (ret < 0)
--- /dev/null
+From e94dc6ddda8dd3770879a132d577accd2cce25f9 Mon Sep 17 00:00:00 2001
+From: Nicolin Chen <nicolinc@nvidia.com>
+Date: Wed, 18 Dec 2024 21:14:21 -0800
+Subject: iommu/tegra241-cmdqv: Read SMMU IDR1.CMDQS instead of hardcoding
+
+From: Nicolin Chen <nicolinc@nvidia.com>
+
+commit e94dc6ddda8dd3770879a132d577accd2cce25f9 upstream.
+
+The hardware limitation "max=19" actually comes from SMMU Command Queue.
+So, it'd be more natural for tegra241-cmdqv driver to read it out rather
+than hardcoding it itself.
+
+This is not an issue yet for a kernel on a baremetal system, but a guest
+kernel setting the queue base/size in form of IPA/gPA might result in a
+noncontiguous queue in the physical address space, if underlying physical
+pages backing up the guest RAM aren't contiguous entirely: e.g. 2MB-page
+backed guest RAM cannot guarantee a contiguous queue if it is 8MB (capped
+to VCMDQ_LOG2SIZE_MAX=19). This might lead to command errors when HW does
+linear-read from a noncontiguous queue memory.
+
+Adding this extra IDR1.CMDQS cap (in the guest kernel) allows VMM to set
+SMMU's IDR1.CMDQS=17 for the case mentioned above, so a guest-level queue
+will be capped to maximum 2MB, ensuring a contiguous queue memory.
+
+Fixes: a3799717b881 ("iommu/tegra241-cmdqv: Fix alignment failure at max_n_shift")
+Reported-by: Ian Kalinowski <ikalinowski@nvidia.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
+Link: https://lore.kernel.org/r/20241219051421.1850267-1-nicolinc@nvidia.com
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c | 8 +++++---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c b/drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c
+index c8ec74f089f3..dc7af970e9d0 100644
+--- a/drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c
++++ b/drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c
+@@ -79,7 +79,6 @@
+ #define TEGRA241_VCMDQ_PAGE1(q) (TEGRA241_VCMDQ_PAGE1_BASE + 0x80*(q))
+ #define VCMDQ_ADDR GENMASK(47, 5)
+ #define VCMDQ_LOG2SIZE GENMASK(4, 0)
+-#define VCMDQ_LOG2SIZE_MAX 19
+
+ #define TEGRA241_VCMDQ_BASE 0x00000
+ #define TEGRA241_VCMDQ_CONS_INDX_BASE 0x00008
+@@ -505,12 +504,15 @@ static int tegra241_vcmdq_alloc_smmu_cmdq(struct tegra241_vcmdq *vcmdq)
+ struct arm_smmu_cmdq *cmdq = &vcmdq->cmdq;
+ struct arm_smmu_queue *q = &cmdq->q;
+ char name[16];
++ u32 regval;
+ int ret;
+
+ snprintf(name, 16, "vcmdq%u", vcmdq->idx);
+
+- /* Queue size, capped to ensure natural alignment */
+- q->llq.max_n_shift = min_t(u32, CMDQ_MAX_SZ_SHIFT, VCMDQ_LOG2SIZE_MAX);
++ /* Cap queue size to SMMU's IDR1.CMDQS and ensure natural alignment */
++ regval = readl_relaxed(smmu->base + ARM_SMMU_IDR1);
++ q->llq.max_n_shift =
++ min_t(u32, CMDQ_MAX_SZ_SHIFT, FIELD_GET(IDR1_CMDQS, regval));
+
+ /* Use the common helper to init the VCMDQ, and then... */
+ ret = arm_smmu_init_one_queue(smmu, q, vcmdq->page0,
+--
+2.48.1
+
--- /dev/null
+From 3f4818ec139030f425476bf8a10b616bab53a7b5 Mon Sep 17 00:00:00 2001
+From: Nicolin Chen <nicolinc@nvidia.com>
+Date: Tue, 14 Jan 2025 22:55:59 -0800
+Subject: iommufd/fault: Destroy response and mutex in iommufd_fault_destroy()
+
+From: Nicolin Chen <nicolinc@nvidia.com>
+
+commit 3f4818ec139030f425476bf8a10b616bab53a7b5 upstream.
+
+Both were missing in the initial patch.
+
+Fixes: 07838f7fd529 ("iommufd: Add iommufd fault object")
+Link: https://patch.msgid.link/r/bc8bb13e215af27e62ee51bdba3648dd4ed2dce3.1736923732.git.nicolinc@nvidia.com
+Cc: stable@vger.kernel.org
+Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
+Reviewed-by: Kevin Tian <kevin.tian@intel.com>
+Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
+Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iommu/iommufd/fault.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/iommu/iommufd/fault.c
++++ b/drivers/iommu/iommufd/fault.c
+@@ -208,6 +208,7 @@ void iommufd_fault_destroy(struct iommuf
+ {
+ struct iommufd_fault *fault = container_of(obj, struct iommufd_fault, obj);
+ struct iopf_group *group, *next;
++ unsigned long index;
+
+ /*
+ * The iommufd object's reference count is zero at this point.
+@@ -220,6 +221,13 @@ void iommufd_fault_destroy(struct iommuf
+ iopf_group_response(group, IOMMU_PAGE_RESP_INVALID);
+ iopf_free_group(group);
+ }
++ xa_for_each(&fault->response, index, group) {
++ xa_erase(&fault->response, index);
++ iopf_group_response(group, IOMMU_PAGE_RESP_INVALID);
++ iopf_free_group(group);
++ }
++ xa_destroy(&fault->response);
++ mutex_destroy(&fault->mutex);
+ }
+
+ static void iommufd_compose_fault_message(struct iommu_fault *fault,
--- /dev/null
+From 3d49020a327cd7d069059317c11df24e407ccfa3 Mon Sep 17 00:00:00 2001
+From: Nicolin Chen <nicolinc@nvidia.com>
+Date: Fri, 17 Jan 2025 11:29:01 -0800
+Subject: iommufd/fault: Use a separate spinlock to protect fault->deliver list
+
+From: Nicolin Chen <nicolinc@nvidia.com>
+
+commit 3d49020a327cd7d069059317c11df24e407ccfa3 upstream.
+
+The fault->mutex serializes the fault read()/write() fops and the
+iommufd_fault_auto_response_faults(), mainly for fault->response. Also, it
+was conveniently used to fence the fault->deliver in poll() fop and
+iommufd_fault_iopf_handler().
+
+However, copy_from/to_user() may sleep if pagefaults are enabled. Thus,
+they could take a long time to wait for user pages to swap in, blocking
+iommufd_fault_iopf_handler() and its caller that is typically a shared IRQ
+handler of an IOMMU driver, resulting in a potential global DOS.
+
+Instead of reusing the mutex to protect the fault->deliver list, add a
+separate spinlock, nested under the mutex, to do the job.
+iommufd_fault_iopf_handler() would no longer be blocked by
+copy_from/to_user().
+
+Add a free_list in iommufd_auto_response_faults(), so the spinlock can
+simply fence a fast list_for_each_entry_safe routine.
+
+Provide two deliver list helpers for iommufd_fault_fops_read() to use:
+ - Fetch the first iopf_group out of the fault->deliver list
+ - Restore an iopf_group back to the head of the fault->deliver list
+
+Lastly, move the mutex closer to the response in the fault structure,
+and update its kdoc accordingly.
+
+Fixes: 07838f7fd529 ("iommufd: Add iommufd fault object")
+Link: https://patch.msgid.link/r/20250117192901.79491-1-nicolinc@nvidia.com
+Cc: stable@vger.kernel.org
+Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
+Reviewed-by: Kevin Tian <kevin.tian@intel.com>
+Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
+Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iommu/iommufd/fault.c | 34 ++++++++++++++++++++------------
+ drivers/iommu/iommufd/iommufd_private.h | 29 +++++++++++++++++++++++++--
+ 2 files changed, 49 insertions(+), 14 deletions(-)
+
+--- a/drivers/iommu/iommufd/fault.c
++++ b/drivers/iommu/iommufd/fault.c
+@@ -98,15 +98,23 @@ static void iommufd_auto_response_faults
+ {
+ struct iommufd_fault *fault = hwpt->fault;
+ struct iopf_group *group, *next;
++ struct list_head free_list;
+ unsigned long index;
+
+ if (!fault)
+ return;
++ INIT_LIST_HEAD(&free_list);
+
+ mutex_lock(&fault->mutex);
++ spin_lock(&fault->lock);
+ list_for_each_entry_safe(group, next, &fault->deliver, node) {
+ if (group->attach_handle != &handle->handle)
+ continue;
++ list_move(&group->node, &free_list);
++ }
++ spin_unlock(&fault->lock);
++
++ list_for_each_entry_safe(group, next, &free_list, node) {
+ list_del(&group->node);
+ iopf_group_response(group, IOMMU_PAGE_RESP_INVALID);
+ iopf_free_group(group);
+@@ -261,17 +269,19 @@ static ssize_t iommufd_fault_fops_read(s
+ return -ESPIPE;
+
+ mutex_lock(&fault->mutex);
+- while (!list_empty(&fault->deliver) && count > done) {
+- group = list_first_entry(&fault->deliver,
+- struct iopf_group, node);
+-
+- if (group->fault_count * fault_size > count - done)
++ while ((group = iommufd_fault_deliver_fetch(fault))) {
++ if (done >= count ||
++ group->fault_count * fault_size > count - done) {
++ iommufd_fault_deliver_restore(fault, group);
+ break;
++ }
+
+ rc = xa_alloc(&fault->response, &group->cookie, group,
+ xa_limit_32b, GFP_KERNEL);
+- if (rc)
++ if (rc) {
++ iommufd_fault_deliver_restore(fault, group);
+ break;
++ }
+
+ idev = to_iommufd_handle(group->attach_handle)->idev;
+ list_for_each_entry(iopf, &group->faults, list) {
+@@ -280,13 +290,12 @@ static ssize_t iommufd_fault_fops_read(s
+ group->cookie);
+ if (copy_to_user(buf + done, &data, fault_size)) {
+ xa_erase(&fault->response, group->cookie);
++ iommufd_fault_deliver_restore(fault, group);
+ rc = -EFAULT;
+ break;
+ }
+ done += fault_size;
+ }
+-
+- list_del(&group->node);
+ }
+ mutex_unlock(&fault->mutex);
+
+@@ -344,10 +353,10 @@ static __poll_t iommufd_fault_fops_poll(
+ __poll_t pollflags = EPOLLOUT;
+
+ poll_wait(filep, &fault->wait_queue, wait);
+- mutex_lock(&fault->mutex);
++ spin_lock(&fault->lock);
+ if (!list_empty(&fault->deliver))
+ pollflags |= EPOLLIN | EPOLLRDNORM;
+- mutex_unlock(&fault->mutex);
++ spin_unlock(&fault->lock);
+
+ return pollflags;
+ }
+@@ -389,6 +398,7 @@ int iommufd_fault_alloc(struct iommufd_u
+ INIT_LIST_HEAD(&fault->deliver);
+ xa_init_flags(&fault->response, XA_FLAGS_ALLOC1);
+ mutex_init(&fault->mutex);
++ spin_lock_init(&fault->lock);
+ init_waitqueue_head(&fault->wait_queue);
+
+ filep = anon_inode_getfile("[iommufd-pgfault]", &iommufd_fault_fops,
+@@ -437,9 +447,9 @@ int iommufd_fault_iopf_handler(struct io
+ hwpt = group->attach_handle->domain->fault_data;
+ fault = hwpt->fault;
+
+- mutex_lock(&fault->mutex);
++ spin_lock(&fault->lock);
+ list_add_tail(&group->node, &fault->deliver);
+- mutex_unlock(&fault->mutex);
++ spin_unlock(&fault->lock);
+
+ wake_up_interruptible(&fault->wait_queue);
+
+--- a/drivers/iommu/iommufd/iommufd_private.h
++++ b/drivers/iommu/iommufd/iommufd_private.h
+@@ -462,14 +462,39 @@ struct iommufd_fault {
+ struct iommufd_ctx *ictx;
+ struct file *filep;
+
+- /* The lists of outstanding faults protected by below mutex. */
+- struct mutex mutex;
++ spinlock_t lock; /* protects the deliver list */
+ struct list_head deliver;
++ struct mutex mutex; /* serializes response flows */
+ struct xarray response;
+
+ struct wait_queue_head wait_queue;
+ };
+
++/* Fetch the first node out of the fault->deliver list */
++static inline struct iopf_group *
++iommufd_fault_deliver_fetch(struct iommufd_fault *fault)
++{
++ struct list_head *list = &fault->deliver;
++ struct iopf_group *group = NULL;
++
++ spin_lock(&fault->lock);
++ if (!list_empty(list)) {
++ group = list_first_entry(list, struct iopf_group, node);
++ list_del(&group->node);
++ }
++ spin_unlock(&fault->lock);
++ return group;
++}
++
++/* Restore a node back to the head of the fault->deliver list */
++static inline void iommufd_fault_deliver_restore(struct iommufd_fault *fault,
++ struct iopf_group *group)
++{
++ spin_lock(&fault->lock);
++ list_add(&group->node, &fault->deliver);
++ spin_unlock(&fault->lock);
++}
++
+ struct iommufd_attach_handle {
+ struct iommu_attach_handle handle;
+ struct iommufd_device *idev;
--- /dev/null
+From e721f619e3ec9bae08bf419c3944cf1e6966c821 Mon Sep 17 00:00:00 2001
+From: Nicolin Chen <nicolinc@nvidia.com>
+Date: Mon, 20 Jan 2025 11:50:51 -0800
+Subject: iommufd: Fix struct iommu_hwpt_pgfault init and padding
+
+From: Nicolin Chen <nicolinc@nvidia.com>
+
+commit e721f619e3ec9bae08bf419c3944cf1e6966c821 upstream.
+
+The iommu_hwpt_pgfault is used to report IO page fault data to userspace,
+but iommufd_fault_fops_read was never zeroing its padding. This leaks the
+content of the kernel stack memory to userspace.
+
+Also, the iommufd uAPI requires explicit padding and use of __aligned_u64
+to ensure ABI compatibility's with 32 bit.
+
+pahole result, before:
+struct iommu_hwpt_pgfault {
+ __u32 flags; /* 0 4 */
+ __u32 dev_id; /* 4 4 */
+ __u32 pasid; /* 8 4 */
+ __u32 grpid; /* 12 4 */
+ __u32 perm; /* 16 4 */
+
+ /* XXX 4 bytes hole, try to pack */
+
+ __u64 addr; /* 24 8 */
+ __u32 length; /* 32 4 */
+ __u32 cookie; /* 36 4 */
+
+ /* size: 40, cachelines: 1, members: 8 */
+ /* sum members: 36, holes: 1, sum holes: 4 */
+ /* last cacheline: 40 bytes */
+};
+
+pahole result, after:
+struct iommu_hwpt_pgfault {
+ __u32 flags; /* 0 4 */
+ __u32 dev_id; /* 4 4 */
+ __u32 pasid; /* 8 4 */
+ __u32 grpid; /* 12 4 */
+ __u32 perm; /* 16 4 */
+ __u32 __reserved; /* 20 4 */
+ __u64 addr __attribute__((__aligned__(8))); /* 24 8 */
+ __u32 length; /* 32 4 */
+ __u32 cookie; /* 36 4 */
+
+ /* size: 40, cachelines: 1, members: 9 */
+ /* forced alignments: 1 */
+ /* last cacheline: 40 bytes */
+} __attribute__((__aligned__(8)));
+
+Fixes: c714f15860fc ("iommufd: Add fault and response message definitions")
+Link: https://patch.msgid.link/r/20250120195051.2450-1-nicolinc@nvidia.com
+Cc: stable@vger.kernel.org
+Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
+Reviewed-by: Kevin Tian <kevin.tian@intel.com>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iommu/iommufd/fault.c | 2 +-
+ include/uapi/linux/iommufd.h | 4 +++-
+ 2 files changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/iommu/iommufd/fault.c
++++ b/drivers/iommu/iommufd/fault.c
+@@ -242,7 +242,7 @@ static ssize_t iommufd_fault_fops_read(s
+ {
+ size_t fault_size = sizeof(struct iommu_hwpt_pgfault);
+ struct iommufd_fault *fault = filep->private_data;
+- struct iommu_hwpt_pgfault data;
++ struct iommu_hwpt_pgfault data = {};
+ struct iommufd_device *idev;
+ struct iopf_group *group;
+ struct iopf_fault *iopf;
+--- a/include/uapi/linux/iommufd.h
++++ b/include/uapi/linux/iommufd.h
+@@ -737,6 +737,7 @@ enum iommu_hwpt_pgfault_perm {
+ * @pasid: Process Address Space ID
+ * @grpid: Page Request Group Index
+ * @perm: Combination of enum iommu_hwpt_pgfault_perm
++ * @__reserved: Must be 0.
+ * @addr: Fault address
+ * @length: a hint of how much data the requestor is expecting to fetch. For
+ * example, if the PRI initiator knows it is going to do a 10MB
+@@ -752,7 +753,8 @@ struct iommu_hwpt_pgfault {
+ __u32 pasid;
+ __u32 grpid;
+ __u32 perm;
+- __u64 addr;
++ __u32 __reserved;
++ __aligned_u64 addr;
+ __u32 length;
+ __u32 cookie;
+ };
--- /dev/null
+From e64f81946adf68cd75e2207dd9a51668348a4af8 Mon Sep 17 00:00:00 2001
+From: Marco Elver <elver@google.com>
+Date: Fri, 24 Jan 2025 13:01:38 +0100
+Subject: kfence: skip __GFP_THISNODE allocations on NUMA systems
+
+From: Marco Elver <elver@google.com>
+
+commit e64f81946adf68cd75e2207dd9a51668348a4af8 upstream.
+
+On NUMA systems, __GFP_THISNODE indicates that an allocation _must_ be on
+a particular node, and failure to allocate on the desired node will result
+in a failed allocation.
+
+Skip __GFP_THISNODE allocations if we are running on a NUMA system, since
+KFENCE can't guarantee which node its pool pages are allocated on.
+
+Link: https://lkml.kernel.org/r/20250124120145.410066-1-elver@google.com
+Fixes: 236e9f153852 ("kfence: skip all GFP_ZONEMASK allocations")
+Signed-off-by: Marco Elver <elver@google.com>
+Reported-by: Vlastimil Babka <vbabka@suse.cz>
+Acked-by: Vlastimil Babka <vbabka@suse.cz>
+Cc: Christoph Lameter <cl@linux.com>
+Cc: Alexander Potapenko <glider@google.com>
+Cc: Chistoph Lameter <cl@linux.com>
+Cc: Dmitriy Vyukov <dvyukov@google.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/kfence/core.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/mm/kfence/core.c
++++ b/mm/kfence/core.c
+@@ -21,6 +21,7 @@
+ #include <linux/log2.h>
+ #include <linux/memblock.h>
+ #include <linux/moduleparam.h>
++#include <linux/nodemask.h>
+ #include <linux/notifier.h>
+ #include <linux/panic_notifier.h>
+ #include <linux/random.h>
+@@ -1084,6 +1085,7 @@ void *__kfence_alloc(struct kmem_cache *
+ * properties (e.g. reside in DMAable memory).
+ */
+ if ((flags & GFP_ZONEMASK) ||
++ ((flags & __GFP_THISNODE) && num_online_nodes() > 1) ||
+ (s->flags & (SLAB_CACHE_DMA | SLAB_CACHE_DMA32))) {
+ atomic_long_inc(&counters[KFENCE_COUNTER_SKIP_INCOMPAT]);
+ return NULL;
--- /dev/null
+From da73efa8e675a2b58f1c7ae61201acfe57714bf7 Mon Sep 17 00:00:00 2001
+From: Sakari Ailus <sakari.ailus@linux.intel.com>
+Date: Tue, 3 Dec 2024 12:23:01 +0200
+Subject: media: ccs: Clean up parsed CCS static data on parse failure
+
+From: Sakari Ailus <sakari.ailus@linux.intel.com>
+
+commit da73efa8e675a2b58f1c7ae61201acfe57714bf7 upstream.
+
+ccs_data_parse() releases the allocated in-memory data structure when the
+parser fails, but it does not clean up parsed metadata that is there to
+help access the actual data. Do that, in order to return the data
+structure in a sane state.
+
+Fixes: a6b396f410b1 ("media: ccs: Add CCS static data parser library")
+Cc: stable@vger.kernel.org
+Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/i2c/ccs/ccs-data.c | 12 +++++++-----
+ 1 file changed, 7 insertions(+), 5 deletions(-)
+
+--- a/drivers/media/i2c/ccs/ccs-data.c
++++ b/drivers/media/i2c/ccs/ccs-data.c
+@@ -10,6 +10,7 @@
+ #include <linux/limits.h>
+ #include <linux/mm.h>
+ #include <linux/slab.h>
++#include <linux/string.h>
+
+ #include "ccs-data-defs.h"
+
+@@ -948,15 +949,15 @@ int ccs_data_parse(struct ccs_data_conta
+
+ rval = __ccs_data_parse(&bin, ccsdata, data, len, dev, verbose);
+ if (rval)
+- return rval;
++ goto out_cleanup;
+
+ rval = bin_backing_alloc(&bin);
+ if (rval)
+- return rval;
++ goto out_cleanup;
+
+ rval = __ccs_data_parse(&bin, ccsdata, data, len, dev, false);
+ if (rval)
+- goto out_free;
++ goto out_cleanup;
+
+ if (verbose && ccsdata->version)
+ print_ccs_data_version(dev, ccsdata->version);
+@@ -965,15 +966,16 @@ int ccs_data_parse(struct ccs_data_conta
+ rval = -EPROTO;
+ dev_dbg(dev, "parsing mismatch; base %p; now %p; end %p\n",
+ bin.base, bin.now, bin.end);
+- goto out_free;
++ goto out_cleanup;
+ }
+
+ ccsdata->backing = bin.base;
+
+ return 0;
+
+-out_free:
++out_cleanup:
+ kvfree(bin.base);
++ memset(ccsdata, 0, sizeof(*ccsdata));
+
+ return rval;
+ }
--- /dev/null
+From 82b696750f0b60e7513082a10ad42786854f59f8 Mon Sep 17 00:00:00 2001
+From: Sakari Ailus <sakari.ailus@linux.intel.com>
+Date: Tue, 3 Dec 2024 10:10:23 +0200
+Subject: media: ccs: Fix CCS static data parsing for large block sizes
+
+From: Sakari Ailus <sakari.ailus@linux.intel.com>
+
+commit 82b696750f0b60e7513082a10ad42786854f59f8 upstream.
+
+The length field of the CCS static data blocks was mishandled, leading to
+wrong interpretation of the length header for blocks that are 16 kiB in
+size. Such large blocks are very, very rare and so this wasn't found
+earlier.
+
+As the length is used as part of input validation, the issue has no
+security implications.
+
+Fixes: a6b396f410b1 ("media: ccs: Add CCS static data parser library")
+Cc: stable@vger.kernel.org
+Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/i2c/ccs/ccs-data.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/media/i2c/ccs/ccs-data.c
++++ b/drivers/media/i2c/ccs/ccs-data.c
+@@ -98,7 +98,7 @@ ccs_data_parse_length_specifier(const st
+ plen = ((size_t)
+ (__len3->length[0] &
+ ((1 << CCS_DATA_LENGTH_SPECIFIER_SIZE_SHIFT) - 1))
+- << 16) + (__len3->length[0] << 8) + __len3->length[1];
++ << 16) + (__len3->length[1] << 8) + __len3->length[2];
+ break;
+ }
+ default:
--- /dev/null
+From 6fdbff0f54786e94f0f630ff200ec1d666b1633e Mon Sep 17 00:00:00 2001
+From: Mehdi Djait <mehdi.djait@linux.intel.com>
+Date: Wed, 11 Dec 2024 14:30:45 +0100
+Subject: media: ccs: Fix cleanup order in ccs_probe()
+
+From: Mehdi Djait <mehdi.djait@linux.intel.com>
+
+commit 6fdbff0f54786e94f0f630ff200ec1d666b1633e upstream.
+
+ccs_limits is allocated in ccs_read_all_limits() after the allocation of
+mdata.backing. Ensure that resources are freed in the reverse order of
+their allocation by moving out_free_ccs_limits up.
+
+Fixes: a11d3d6891f0 ("media: ccs: Read CCS static data from firmware binaries")
+Cc: stable@vger.kernel.org
+Signed-off-by: Mehdi Djait <mehdi.djait@linux.intel.com>
+Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/i2c/ccs/ccs-core.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/media/i2c/ccs/ccs-core.c
++++ b/drivers/media/i2c/ccs/ccs-core.c
+@@ -3566,15 +3566,15 @@ out_disable_runtime_pm:
+ out_cleanup:
+ ccs_cleanup(sensor);
+
++out_free_ccs_limits:
++ kfree(sensor->ccs_limits);
++
+ out_release_mdata:
+ kvfree(sensor->mdata.backing);
+
+ out_release_sdata:
+ kvfree(sensor->sdata.backing);
+
+-out_free_ccs_limits:
+- kfree(sensor->ccs_limits);
+-
+ out_power_off:
+ ccs_power_off(&client->dev);
+ mutex_destroy(&sensor->mutex);
--- /dev/null
+From 42d0ec194aa12e9b97f09a94fe565ba2e5f631a2 Mon Sep 17 00:00:00 2001
+From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+Date: Fri, 6 Dec 2024 10:26:40 +0200
+Subject: media: i2c: ds90ub960: Fix logging SP & EQ status only for UB9702
+
+From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+
+commit 42d0ec194aa12e9b97f09a94fe565ba2e5f631a2 upstream.
+
+UB9702 does not have SP and EQ registers, but the driver uses them in
+log_status(). Fix this by separating the SP and EQ related log_status()
+work into a separate function (for clarity) and calling that function
+only for UB960.
+
+Cc: stable@vger.kernel.org
+Fixes: afe267f2d368 ("media: i2c: add DS90UB960 driver")
+Reviewed-by: Jai Luthra <jai.luthra@ideasonboard.com>
+Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/i2c/ds90ub960.c | 90 +++++++++++++++++++++++-------------------
+ 1 file changed, 50 insertions(+), 40 deletions(-)
+
+--- a/drivers/media/i2c/ds90ub960.c
++++ b/drivers/media/i2c/ds90ub960.c
+@@ -2950,6 +2950,54 @@ static const struct v4l2_subdev_pad_ops
+ .set_fmt = ub960_set_fmt,
+ };
+
++static void ub960_log_status_ub960_sp_eq(struct ub960_data *priv,
++ unsigned int nport)
++{
++ struct device *dev = &priv->client->dev;
++ u8 eq_level;
++ s8 strobe_pos;
++ u8 v = 0;
++
++ /* Strobe */
++
++ ub960_read(priv, UB960_XR_AEQ_CTL1, &v);
++
++ dev_info(dev, "\t%s strobe\n",
++ (v & UB960_XR_AEQ_CTL1_AEQ_SFILTER_EN) ? "Adaptive" :
++ "Manual");
++
++ if (v & UB960_XR_AEQ_CTL1_AEQ_SFILTER_EN) {
++ ub960_read(priv, UB960_XR_SFILTER_CFG, &v);
++
++ dev_info(dev, "\tStrobe range [%d, %d]\n",
++ ((v >> UB960_XR_SFILTER_CFG_SFILTER_MIN_SHIFT) & 0xf) - 7,
++ ((v >> UB960_XR_SFILTER_CFG_SFILTER_MAX_SHIFT) & 0xf) - 7);
++ }
++
++ ub960_rxport_get_strobe_pos(priv, nport, &strobe_pos);
++
++ dev_info(dev, "\tStrobe pos %d\n", strobe_pos);
++
++ /* EQ */
++
++ ub960_rxport_read(priv, nport, UB960_RR_AEQ_BYPASS, &v);
++
++ dev_info(dev, "\t%s EQ\n",
++ (v & UB960_RR_AEQ_BYPASS_ENABLE) ? "Manual" :
++ "Adaptive");
++
++ if (!(v & UB960_RR_AEQ_BYPASS_ENABLE)) {
++ ub960_rxport_read(priv, nport, UB960_RR_AEQ_MIN_MAX, &v);
++
++ dev_info(dev, "\tEQ range [%u, %u]\n",
++ (v >> UB960_RR_AEQ_MIN_MAX_AEQ_FLOOR_SHIFT) & 0xf,
++ (v >> UB960_RR_AEQ_MIN_MAX_AEQ_MAX_SHIFT) & 0xf);
++ }
++
++ if (ub960_rxport_get_eq_level(priv, nport, &eq_level) == 0)
++ dev_info(dev, "\tEQ level %u\n", eq_level);
++}
++
+ static int ub960_log_status(struct v4l2_subdev *sd)
+ {
+ struct ub960_data *priv = sd_to_ub960(sd);
+@@ -2997,8 +3045,6 @@ static int ub960_log_status(struct v4l2_
+
+ for (nport = 0; nport < priv->hw_data->num_rxports; nport++) {
+ struct ub960_rxport *rxport = priv->rxports[nport];
+- u8 eq_level;
+- s8 strobe_pos;
+ unsigned int i;
+
+ dev_info(dev, "RX %u\n", nport);
+@@ -3034,44 +3080,8 @@ static int ub960_log_status(struct v4l2_
+ ub960_rxport_read(priv, nport, UB960_RR_CSI_ERR_COUNTER, &v);
+ dev_info(dev, "\tcsi_err_counter %u\n", v);
+
+- /* Strobe */
+-
+- ub960_read(priv, UB960_XR_AEQ_CTL1, &v);
+-
+- dev_info(dev, "\t%s strobe\n",
+- (v & UB960_XR_AEQ_CTL1_AEQ_SFILTER_EN) ? "Adaptive" :
+- "Manual");
+-
+- if (v & UB960_XR_AEQ_CTL1_AEQ_SFILTER_EN) {
+- ub960_read(priv, UB960_XR_SFILTER_CFG, &v);
+-
+- dev_info(dev, "\tStrobe range [%d, %d]\n",
+- ((v >> UB960_XR_SFILTER_CFG_SFILTER_MIN_SHIFT) & 0xf) - 7,
+- ((v >> UB960_XR_SFILTER_CFG_SFILTER_MAX_SHIFT) & 0xf) - 7);
+- }
+-
+- ub960_rxport_get_strobe_pos(priv, nport, &strobe_pos);
+-
+- dev_info(dev, "\tStrobe pos %d\n", strobe_pos);
+-
+- /* EQ */
+-
+- ub960_rxport_read(priv, nport, UB960_RR_AEQ_BYPASS, &v);
+-
+- dev_info(dev, "\t%s EQ\n",
+- (v & UB960_RR_AEQ_BYPASS_ENABLE) ? "Manual" :
+- "Adaptive");
+-
+- if (!(v & UB960_RR_AEQ_BYPASS_ENABLE)) {
+- ub960_rxport_read(priv, nport, UB960_RR_AEQ_MIN_MAX, &v);
+-
+- dev_info(dev, "\tEQ range [%u, %u]\n",
+- (v >> UB960_RR_AEQ_MIN_MAX_AEQ_FLOOR_SHIFT) & 0xf,
+- (v >> UB960_RR_AEQ_MIN_MAX_AEQ_MAX_SHIFT) & 0xf);
+- }
+-
+- if (ub960_rxport_get_eq_level(priv, nport, &eq_level) == 0)
+- dev_info(dev, "\tEQ level %u\n", eq_level);
++ if (!priv->hw_data->is_ub9702)
++ ub960_log_status_ub960_sp_eq(priv, nport);
+
+ /* GPIOs */
+ for (i = 0; i < UB960_NUM_BC_GPIOS; i++) {
--- /dev/null
+From 5dbbd0609b83f6eb72c005e2e5979d0cd25243c8 Mon Sep 17 00:00:00 2001
+From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+Date: Fri, 6 Dec 2024 10:26:41 +0200
+Subject: media: i2c: ds90ub960: Fix UB9702 VC map
+
+From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+
+commit 5dbbd0609b83f6eb72c005e2e5979d0cd25243c8 upstream.
+
+The driver uses a static CSI-2 virtual channel mapping where all virtual
+channels from an RX port are mapped to a virtual channel number matching
+the RX port number.
+
+The UB960 and UB9702 have different registers for the purpose, and the
+UB9702 version is not correct. Each of the VC_ID_MAP registers do not
+contain a single mapping, as the driver currently thinks, but two.
+
+This can cause received VCs other than 0 to be mapped in a wrong way.
+
+Fix this by writing both mappings to each register.
+
+Cc: stable@vger.kernel.org
+Fixes: afe267f2d368 ("media: i2c: add DS90UB960 driver")
+Reviewed-by: Jai Luthra <jai.luthra@ideasonboard.com>
+Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/i2c/ds90ub960.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/media/i2c/ds90ub960.c
++++ b/drivers/media/i2c/ds90ub960.c
+@@ -2533,7 +2533,7 @@ static int ub960_configure_ports_for_str
+ for (i = 0; i < 8; i++)
+ ub960_rxport_write(priv, nport,
+ UB960_RR_VC_ID_MAP(i),
+- nport);
++ (nport << 4) | nport);
+ }
+
+ break;
--- /dev/null
+From 698cf6df87ffa83f259703e7443c15a4c5ceae86 Mon Sep 17 00:00:00 2001
+From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+Date: Fri, 6 Dec 2024 10:26:39 +0200
+Subject: media: i2c: ds90ub960: Fix use of non-existing registers on UB9702
+
+From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+
+commit 698cf6df87ffa83f259703e7443c15a4c5ceae86 upstream.
+
+UB9702 doesn't have the registers for SP and EQ. Adjust the code in
+ub960_rxport_wait_locks() to not use those registers for UB9702. As
+these values are only used for a debug print here, there's no functional
+change.
+
+Cc: stable@vger.kernel.org
+Fixes: afe267f2d368 ("media: i2c: add DS90UB960 driver")
+Reviewed-by: Jai Luthra <jai.luthra@ideasonboard.com>
+Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/i2c/ds90ub960.c | 24 ++++++++++++++++--------
+ 1 file changed, 16 insertions(+), 8 deletions(-)
+
+--- a/drivers/media/i2c/ds90ub960.c
++++ b/drivers/media/i2c/ds90ub960.c
+@@ -1577,16 +1577,24 @@ static int ub960_rxport_wait_locks(struc
+
+ ub960_rxport_read16(priv, nport, UB960_RR_RX_FREQ_HIGH, &v);
+
+- ret = ub960_rxport_get_strobe_pos(priv, nport, &strobe_pos);
+- if (ret)
+- return ret;
++ if (priv->hw_data->is_ub9702) {
++ dev_dbg(dev, "\trx%u: locked, freq %llu Hz\n",
++ nport, (v * 1000000ULL) >> 8);
++ } else {
++ ret = ub960_rxport_get_strobe_pos(priv, nport,
++ &strobe_pos);
++ if (ret)
++ return ret;
+
+- ret = ub960_rxport_get_eq_level(priv, nport, &eq_level);
+- if (ret)
+- return ret;
++ ret = ub960_rxport_get_eq_level(priv, nport, &eq_level);
++ if (ret)
++ return ret;
+
+- dev_dbg(dev, "\trx%u: locked, SP: %d, EQ: %u, freq %llu Hz\n",
+- nport, strobe_pos, eq_level, (v * 1000000ULL) >> 8);
++ dev_dbg(dev,
++ "\trx%u: locked, SP: %d, EQ: %u, freq %llu Hz\n",
++ nport, strobe_pos, eq_level,
++ (v * 1000000ULL) >> 8);
++ }
+ }
+
+ return 0;
--- /dev/null
+From 60b45ece41c5632a3a3274115a401cb244180646 Mon Sep 17 00:00:00 2001
+From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+Date: Fri, 6 Dec 2024 10:26:37 +0200
+Subject: media: i2c: ds90ub9x3: Fix extra fwnode_handle_put()
+
+From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+
+commit 60b45ece41c5632a3a3274115a401cb244180646 upstream.
+
+The ub913 and ub953 drivers call fwnode_handle_put(priv->sd.fwnode) as
+part of their remove process, and if the driver is removed multiple
+times, eventually leads to put "overflow", possibly causing memory
+corruption or crash.
+
+The fwnode_handle_put() is a leftover from commit 905f88ccebb1 ("media:
+i2c: ds90ub9x3: Fix sub-device matching"), which changed the code
+related to the sd.fwnode, but missed removing these fwnode_handle_put()
+calls.
+
+Cc: stable@vger.kernel.org
+Fixes: 905f88ccebb1 ("media: i2c: ds90ub9x3: Fix sub-device matching")
+Reviewed-by: Jai Luthra <jai.luthra@ideasonboard.com>
+Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/i2c/ds90ub913.c | 1 -
+ drivers/media/i2c/ds90ub953.c | 1 -
+ 2 files changed, 2 deletions(-)
+
+--- a/drivers/media/i2c/ds90ub913.c
++++ b/drivers/media/i2c/ds90ub913.c
+@@ -793,7 +793,6 @@ static void ub913_subdev_uninit(struct u
+ v4l2_async_unregister_subdev(&priv->sd);
+ ub913_v4l2_nf_unregister(priv);
+ v4l2_subdev_cleanup(&priv->sd);
+- fwnode_handle_put(priv->sd.fwnode);
+ media_entity_cleanup(&priv->sd.entity);
+ }
+
+--- a/drivers/media/i2c/ds90ub953.c
++++ b/drivers/media/i2c/ds90ub953.c
+@@ -1291,7 +1291,6 @@ static void ub953_subdev_uninit(struct u
+ v4l2_async_unregister_subdev(&priv->sd);
+ ub953_v4l2_notifier_unregister(priv);
+ v4l2_subdev_cleanup(&priv->sd);
+- fwnode_handle_put(priv->sd.fwnode);
+ media_entity_cleanup(&priv->sd.entity);
+ }
+
--- /dev/null
+From 57d10bcac67707caaa542e09dee86e13ea85defc Mon Sep 17 00:00:00 2001
+From: Naushir Patuck <naush@raspberrypi.com>
+Date: Fri, 15 Nov 2024 20:07:17 +0200
+Subject: media: imx296: Add standby delay during probe
+
+From: Naushir Patuck <naush@raspberrypi.com>
+
+commit 57d10bcac67707caaa542e09dee86e13ea85defc upstream.
+
+Add a 2-5ms delay when coming out of standby and before reading the
+sensor info register durning probe, as instructed by the datasheet. This
+standby delay is already present when the sensor starts streaming.
+
+During a cold-boot, reading the IMX296_SENSOR_INFO register would often
+return a value of 0x0000, if this delay is not present before.
+
+Fixes: cb33db2b6ccf ("media: i2c: IMX296 camera sensor driver")
+Cc: stable@vger.kernel.org
+Tested-by: Alexandru Ardelean <aardelean@baylibre.com>
+Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
+Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
+Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/i2c/imx296.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/media/i2c/imx296.c
++++ b/drivers/media/i2c/imx296.c
+@@ -954,6 +954,8 @@ static int imx296_identify_model(struct
+ return ret;
+ }
+
++ usleep_range(2000, 5000);
++
+ ret = imx296_read(sensor, IMX296_SENSOR_INFO);
+ if (ret < 0) {
+ dev_err(sensor->dev, "failed to read sensor information (%d)\n",
--- /dev/null
+From facb541ff0805314e0b56e508f7d3cbd07af513c Mon Sep 17 00:00:00 2001
+From: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
+Date: Wed, 11 Dec 2024 12:49:05 +0100
+Subject: media: intel/ipu6: remove cpu latency qos request on error
+
+From: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
+
+commit facb541ff0805314e0b56e508f7d3cbd07af513c upstream.
+
+Fix cpu latency qos list corruption like below. It happens when
+we do not remove cpu latency request on error path and free
+corresponding memory.
+
+[ 30.634378] l7 kernel: list_add corruption. prev->next should be next (ffffffff9645e960), but was 0000000100100001. (prev=ffff8e9e877e20a8).
+[ 30.634388] l7 kernel: WARNING: CPU: 2 PID: 2008 at lib/list_debug.c:32 __list_add_valid_or_report+0x83/0xa0
+<snip>
+[ 30.634640] l7 kernel: Call Trace:
+[ 30.634650] l7 kernel: <TASK>
+[ 30.634659] l7 kernel: ? __list_add_valid_or_report+0x83/0xa0
+[ 30.634669] l7 kernel: ? __warn.cold+0x93/0xf6
+[ 30.634678] l7 kernel: ? __list_add_valid_or_report+0x83/0xa0
+[ 30.634690] l7 kernel: ? report_bug+0xff/0x140
+[ 30.634702] l7 kernel: ? handle_bug+0x58/0x90
+[ 30.634712] l7 kernel: ? exc_invalid_op+0x17/0x70
+[ 30.634723] l7 kernel: ? asm_exc_invalid_op+0x1a/0x20
+[ 30.634733] l7 kernel: ? __list_add_valid_or_report+0x83/0xa0
+[ 30.634742] l7 kernel: plist_add+0xdd/0x140
+[ 30.634754] l7 kernel: pm_qos_update_target+0xa0/0x1f0
+[ 30.634764] l7 kernel: cpu_latency_qos_update_request+0x61/0xc0
+[ 30.634773] l7 kernel: intel_dp_aux_xfer+0x4c7/0x6e0 [i915 1f824655ed04687c2b0d23dbce759fa785f6d033]
+
+Reported-by: Genes Lists <lists@sapience.com>
+Closes: https://lore.kernel.org/linux-media/c0e94be466b367f1a3cfdc3cb7b1a4f47e5953ae.camel@sapience.com/
+Fixes: f50c4ca0a820 ("media: intel/ipu6: add the main input system driver")
+Cc: stable@vger.kernel.org
+Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
+Reviewed-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/pci/intel/ipu6/ipu6-isys.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/media/pci/intel/ipu6/ipu6-isys.c
++++ b/drivers/media/pci/intel/ipu6/ipu6-isys.c
+@@ -1133,6 +1133,7 @@ static int isys_probe(struct auxiliary_d
+ free_fw_msg_bufs:
+ free_fw_msg_bufs(isys);
+ out_remove_pkg_dir_shared_buffer:
++ cpu_latency_qos_remove_request(&isys->pm_qos);
+ if (!isp->secure_mode)
+ ipu6_cpd_free_pkg_dir(adev);
+ remove_shared_buffer:
--- /dev/null
+From fb2bd86270cd0ad004f4c614ba4f8c63a5720e25 Mon Sep 17 00:00:00 2001
+From: Cosmin Tanislav <demonsingur@gmail.com>
+Date: Fri, 22 Nov 2024 16:55:24 +0200
+Subject: media: mc: fix endpoint iteration
+
+From: Cosmin Tanislav <demonsingur@gmail.com>
+
+commit fb2bd86270cd0ad004f4c614ba4f8c63a5720e25 upstream.
+
+When creating links from a subdev to a sink, the current logic tries to
+iterate over the endpoints of dev's fwnode.
+
+This might not be correct when the subdev uses a different fwnode
+compared to the dev's fwnode.
+
+If, when registering, the subdev's fwnode is not set, the code inside
+v4l2_async_register_subdev will set it to the dev's fwnode.
+
+To fix this, just use the subdev's fwnode.
+
+Signed-off-by: Cosmin Tanislav <demonsingur@gmail.com>
+Fixes: 0d3c81e82da9 ("media: v4l2-mc: add v4l2_create_fwnode_links helpers")
+Cc: stable@vger.kernel.org
+Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
+Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/v4l2-core/v4l2-mc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/media/v4l2-core/v4l2-mc.c
++++ b/drivers/media/v4l2-core/v4l2-mc.c
+@@ -329,7 +329,7 @@ int v4l2_create_fwnode_links_to_pad(stru
+ if (!(sink->flags & MEDIA_PAD_FL_SINK))
+ return -EINVAL;
+
+- fwnode_graph_for_each_endpoint(dev_fwnode(src_sd->dev), endpoint) {
++ fwnode_graph_for_each_endpoint(src_sd->fwnode, endpoint) {
+ struct fwnode_handle *remote_ep;
+ int src_idx, sink_idx, ret;
+ struct media_pad *src;
--- /dev/null
+From fbb5298bf1a7b71723cd2bb193642429ceb0fb84 Mon Sep 17 00:00:00 2001
+From: Lubomir Rintel <lkundrak@v3.sk>
+Date: Tue, 31 Dec 2024 20:04:34 +0100
+Subject: media: mmp: Bring back registration of the device
+
+From: Lubomir Rintel <lkundrak@v3.sk>
+
+commit fbb5298bf1a7b71723cd2bb193642429ceb0fb84 upstream.
+
+In commit 4af65141e38e ("media: marvell: cafe: Register V4L2 device
+earlier"), a call to v4l2_device_register() was moved away from
+mccic_register() into its caller, marvell/cafe's cafe_pci_probe().
+This is not the only caller though -- there's also marvell/mmp.
+
+Add v4l2_device_register() into mmpcam_probe() to unbreak the MMP camera
+driver, in a fashion analogous to what's been done to the Cafe driver.
+Same for the teardown path.
+
+Fixes: 4af65141e38e ("media: marvell: cafe: Register V4L2 device earlier")
+Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
+Cc: stable@vger.kernel.org # v6.6+
+Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/platform/marvell/mmp-driver.c | 21 +++++++++++++++++----
+ 1 file changed, 17 insertions(+), 4 deletions(-)
+
+--- a/drivers/media/platform/marvell/mmp-driver.c
++++ b/drivers/media/platform/marvell/mmp-driver.c
+@@ -232,12 +232,22 @@ static int mmpcam_probe(struct platform_
+ mcam_init_clk(mcam);
+
+ /*
++ * Register with V4L.
++ */
++
++ ret = v4l2_device_register(mcam->dev, &mcam->v4l2_dev);
++ if (ret)
++ return ret;
++
++ /*
+ * Create a match of the sensor against its OF node.
+ */
+ ep = fwnode_graph_get_next_endpoint(of_fwnode_handle(pdev->dev.of_node),
+ NULL);
+- if (!ep)
+- return -ENODEV;
++ if (!ep) {
++ ret = -ENODEV;
++ goto out_v4l2_device_unregister;
++ }
+
+ v4l2_async_nf_init(&mcam->notifier, &mcam->v4l2_dev);
+
+@@ -246,7 +256,7 @@ static int mmpcam_probe(struct platform_
+ fwnode_handle_put(ep);
+ if (IS_ERR(asd)) {
+ ret = PTR_ERR(asd);
+- goto out;
++ goto out_v4l2_device_unregister;
+ }
+
+ /*
+@@ -254,7 +264,7 @@ static int mmpcam_probe(struct platform_
+ */
+ ret = mccic_register(mcam);
+ if (ret)
+- goto out;
++ goto out_v4l2_device_unregister;
+
+ /*
+ * Add OF clock provider.
+@@ -283,6 +293,8 @@ static int mmpcam_probe(struct platform_
+ return 0;
+ out:
+ mccic_shutdown(mcam);
++out_v4l2_device_unregister:
++ v4l2_device_unregister(&mcam->v4l2_dev);
+
+ return ret;
+ }
+@@ -293,6 +305,7 @@ static void mmpcam_remove(struct platfor
+ struct mcam_camera *mcam = &cam->mcam;
+
+ mccic_shutdown(mcam);
++ v4l2_device_unregister(&mcam->v4l2_dev);
+ pm_runtime_force_suspend(mcam->dev);
+ }
+
--- /dev/null
+From c4b7779abc6633677e6edb79e2809f4f61fde157 Mon Sep 17 00:00:00 2001
+From: Zhen Lei <thunder.leizhen@huawei.com>
+Date: Tue, 15 Oct 2024 09:40:53 +0800
+Subject: media: nuvoton: Fix an error check in npcm_video_ece_init()
+
+From: Zhen Lei <thunder.leizhen@huawei.com>
+
+commit c4b7779abc6633677e6edb79e2809f4f61fde157 upstream.
+
+When function of_find_device_by_node() fails, it returns NULL instead of
+an error code. So the corresponding error check logic should be modified
+to check whether the return value is NULL and set the error code to be
+returned as -ENODEV.
+
+Fixes: 46c15a4ff1f4 ("media: nuvoton: Add driver for NPCM video capture and encoding engine")
+Cc: stable@vger.kernel.org
+Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
+Link: https://lore.kernel.org/r/20241015014053.669-1-thunder.leizhen@huawei.com
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/platform/nuvoton/npcm-video.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/media/platform/nuvoton/npcm-video.c
++++ b/drivers/media/platform/nuvoton/npcm-video.c
+@@ -1667,9 +1667,9 @@ static int npcm_video_ece_init(struct np
+ dev_info(dev, "Support HEXTILE pixel format\n");
+
+ ece_pdev = of_find_device_by_node(ece_node);
+- if (IS_ERR(ece_pdev)) {
++ if (!ece_pdev) {
+ dev_err(dev, "Failed to find ECE device\n");
+- return PTR_ERR(ece_pdev);
++ return -ENODEV;
+ }
+ of_node_put(ece_node);
+
--- /dev/null
+From 001d3753538d26ddcbef011f5643cfff58a7f672 Mon Sep 17 00:00:00 2001
+From: Sam Bobrowicz <sam@elite-embedded.com>
+Date: Fri, 22 Nov 2024 09:28:01 +0100
+Subject: media: ov5640: fix get_light_freq on auto
+
+From: Sam Bobrowicz <sam@elite-embedded.com>
+
+commit 001d3753538d26ddcbef011f5643cfff58a7f672 upstream.
+
+Light frequency was not properly returned when in auto
+mode and the detected frequency was 60Hz.
+
+Fixes: 19a81c1426c1 ("[media] add Omnivision OV5640 sensor driver")
+Cc: stable@vger.kernel.org
+Signed-off-by: Sam Bobrowicz <sam@elite-embedded.com>
+Signed-off-by: Michal Simek <michal.simek@amd.com>
+Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/i2c/ov5640.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/media/i2c/ov5640.c
++++ b/drivers/media/i2c/ov5640.c
+@@ -1982,6 +1982,7 @@ static int ov5640_get_light_freq(struct
+ light_freq = 50;
+ } else {
+ /* 60Hz */
++ light_freq = 60;
+ }
+ }
+
--- /dev/null
+From b36077ba289b827b4e76e25e8d8e0cc90fa09186 Mon Sep 17 00:00:00 2001
+From: Alain Volmat <alain.volmat@foss.st.com>
+Date: Thu, 12 Dec 2024 10:17:25 +0100
+Subject: media: stm32: dcmipp: correct dma_set_mask_and_coherent mask value
+
+From: Alain Volmat <alain.volmat@foss.st.com>
+
+commit b36077ba289b827b4e76e25e8d8e0cc90fa09186 upstream.
+
+Correct the call to dma_set_mask_and_coherent which should be set
+to DMA_BIT_MASK(32).
+
+Fixes: 28e0f3772296 ("media: stm32-dcmipp: STM32 DCMIPP camera interface driver")
+Cc: stable@vger.kernel.org
+Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
+Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/platform/st/stm32/stm32-dcmipp/dcmipp-bytecap.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/media/platform/st/stm32/stm32-dcmipp/dcmipp-bytecap.c
++++ b/drivers/media/platform/st/stm32/stm32-dcmipp/dcmipp-bytecap.c
+@@ -893,7 +893,7 @@ struct dcmipp_ent_device *dcmipp_bytecap
+ q->dev = dev;
+
+ /* DCMIPP requires 16 bytes aligned buffers */
+- ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32) & ~0x0f);
++ ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
+ if (ret) {
+ dev_err(dev, "Failed to set DMA mask\n");
+ goto err_mutex_destroy;
--- /dev/null
+From a9ea1a3d88b7947ce8cadb2afceee7a54872bbc5 Mon Sep 17 00:00:00 2001
+From: Ricardo Ribalda <ribalda@chromium.org>
+Date: Wed, 6 Nov 2024 20:36:07 +0000
+Subject: media: uvcvideo: Fix crash during unbind if gpio unit is in use
+
+From: Ricardo Ribalda <ribalda@chromium.org>
+
+commit a9ea1a3d88b7947ce8cadb2afceee7a54872bbc5 upstream.
+
+We used the wrong device for the device managed functions. We used the
+usb device, when we should be using the interface device.
+
+If we unbind the driver from the usb interface, the cleanup functions
+are never called. In our case, the IRQ is never disabled.
+
+If an IRQ is triggered, it will try to access memory sections that are
+already free, causing an OOPS.
+
+We cannot use the function devm_request_threaded_irq here. The devm_*
+clean functions may be called after the main structure is released by
+uvc_delete.
+
+Luckily this bug has small impact, as it is only affected by devices
+with gpio units and the user has to unbind the device, a disconnect will
+not trigger this error.
+
+Cc: stable@vger.kernel.org
+Fixes: 2886477ff987 ("media: uvcvideo: Implement UVC_EXT_GPIO_UNIT")
+Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
+Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
+Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Link: https://lore.kernel.org/r/20241106-uvc-crashrmmod-v6-1-fbf9781c6e83@chromium.org
+Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/uvc/uvc_driver.c | 28 +++++++++++++++++++++-------
+ drivers/media/usb/uvc/uvcvideo.h | 1 +
+ 2 files changed, 22 insertions(+), 7 deletions(-)
+
+--- a/drivers/media/usb/uvc/uvc_driver.c
++++ b/drivers/media/usb/uvc/uvc_driver.c
+@@ -1280,14 +1280,14 @@ static int uvc_gpio_parse(struct uvc_dev
+ struct gpio_desc *gpio_privacy;
+ int irq;
+
+- gpio_privacy = devm_gpiod_get_optional(&dev->udev->dev, "privacy",
++ gpio_privacy = devm_gpiod_get_optional(&dev->intf->dev, "privacy",
+ GPIOD_IN);
+ if (IS_ERR_OR_NULL(gpio_privacy))
+ return PTR_ERR_OR_ZERO(gpio_privacy);
+
+ irq = gpiod_to_irq(gpio_privacy);
+ if (irq < 0)
+- return dev_err_probe(&dev->udev->dev, irq,
++ return dev_err_probe(&dev->intf->dev, irq,
+ "No IRQ for privacy GPIO\n");
+
+ unit = uvc_alloc_entity(UVC_EXT_GPIO_UNIT, UVC_EXT_GPIO_UNIT_ID, 0, 1);
+@@ -1313,15 +1313,27 @@ static int uvc_gpio_parse(struct uvc_dev
+ static int uvc_gpio_init_irq(struct uvc_device *dev)
+ {
+ struct uvc_entity *unit = dev->gpio_unit;
++ int ret;
+
+ if (!unit || unit->gpio.irq < 0)
+ return 0;
+
+- return devm_request_threaded_irq(&dev->udev->dev, unit->gpio.irq, NULL,
+- uvc_gpio_irq,
+- IRQF_ONESHOT | IRQF_TRIGGER_FALLING |
+- IRQF_TRIGGER_RISING,
+- "uvc_privacy_gpio", dev);
++ ret = request_threaded_irq(unit->gpio.irq, NULL, uvc_gpio_irq,
++ IRQF_ONESHOT | IRQF_TRIGGER_FALLING |
++ IRQF_TRIGGER_RISING,
++ "uvc_privacy_gpio", dev);
++
++ unit->gpio.initialized = !ret;
++
++ return ret;
++}
++
++static void uvc_gpio_deinit(struct uvc_device *dev)
++{
++ if (!dev->gpio_unit || !dev->gpio_unit->gpio.initialized)
++ return;
++
++ free_irq(dev->gpio_unit->gpio.irq, dev);
+ }
+
+ /* ------------------------------------------------------------------------
+@@ -1918,6 +1930,8 @@ static void uvc_unregister_video(struct
+ {
+ struct uvc_streaming *stream;
+
++ uvc_gpio_deinit(dev);
++
+ list_for_each_entry(stream, &dev->streams, list) {
+ /* Nothing to do here, continue. */
+ if (!video_is_registered(&stream->vdev))
+--- a/drivers/media/usb/uvc/uvcvideo.h
++++ b/drivers/media/usb/uvc/uvcvideo.h
+@@ -234,6 +234,7 @@ struct uvc_entity {
+ u8 *bmControls;
+ struct gpio_desc *gpio_privacy;
+ int irq;
++ bool initialized;
+ } gpio;
+ };
+
--- /dev/null
+From c31cffd5ae2c3d7ef21d9008977a9d117ce7a64e Mon Sep 17 00:00:00 2001
+From: Ricardo Ribalda <ribalda@chromium.org>
+Date: Thu, 14 Nov 2024 19:10:30 +0000
+Subject: media: uvcvideo: Fix event flags in uvc_ctrl_send_events
+
+From: Ricardo Ribalda <ribalda@chromium.org>
+
+commit c31cffd5ae2c3d7ef21d9008977a9d117ce7a64e upstream.
+
+If there is an event that needs the V4L2_EVENT_CTRL_CH_FLAGS flag, all
+the following events will have that flag, regardless if they need it or
+not.
+
+This is because we keep using the same variable all the time and we do
+not reset its original value.
+
+Cc: stable@vger.kernel.org
+Fixes: 805e9b4a06bf ("[media] uvcvideo: Send control change events for slave ctrls when the master changes")
+Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
+Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Link: https://lore.kernel.org/r/20241114-uvc-roi-v15-1-64cfeb56b6f8@chromium.org
+Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/uvc/uvc_ctrl.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/media/usb/uvc/uvc_ctrl.c
++++ b/drivers/media/usb/uvc/uvc_ctrl.c
+@@ -1673,13 +1673,13 @@ static void uvc_ctrl_send_events(struct
+ {
+ struct uvc_control_mapping *mapping;
+ struct uvc_control *ctrl;
+- u32 changes = V4L2_EVENT_CTRL_CH_VALUE;
+ unsigned int i;
+ unsigned int j;
+
+ for (i = 0; i < xctrls_count; ++i) {
+- ctrl = uvc_find_control(handle->chain, xctrls[i].id, &mapping);
++ u32 changes = V4L2_EVENT_CTRL_CH_VALUE;
+
++ ctrl = uvc_find_control(handle->chain, xctrls[i].id, &mapping);
+ if (ctrl->info.flags & UVC_CTRL_FLAG_ASYNCHRONOUS)
+ /* Notification will be sent from an Interrupt event. */
+ continue;
--- /dev/null
+From d9fecd096f67a4469536e040a8a10bbfb665918b Mon Sep 17 00:00:00 2001
+From: Ricardo Ribalda <ribalda@chromium.org>
+Date: Tue, 3 Dec 2024 21:20:08 +0000
+Subject: media: uvcvideo: Only save async fh if success
+
+From: Ricardo Ribalda <ribalda@chromium.org>
+
+commit d9fecd096f67a4469536e040a8a10bbfb665918b upstream.
+
+Now we keep a reference to the active fh for any call to uvc_ctrl_set,
+regardless if it is an actual set or if it is a just a try or if the
+device refused the operation.
+
+We should only keep the file handle if the device actually accepted
+applying the operation.
+
+Cc: stable@vger.kernel.org
+Fixes: e5225c820c05 ("media: uvcvideo: Send a control event when a Control Change interrupt arrives")
+Suggested-by: Hans de Goede <hdegoede@redhat.com>
+Reviewed-by: Hans de Goede <hdegoede@redhat.com>
+Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
+Link: https://lore.kernel.org/r/20241203-uvc-fix-async-v6-1-26c867231118@chromium.org
+Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/uvc/uvc_ctrl.c | 18 +++++++++++-------
+ 1 file changed, 11 insertions(+), 7 deletions(-)
+
+--- a/drivers/media/usb/uvc/uvc_ctrl.c
++++ b/drivers/media/usb/uvc/uvc_ctrl.c
+@@ -1811,7 +1811,10 @@ int uvc_ctrl_begin(struct uvc_video_chai
+ }
+
+ static int uvc_ctrl_commit_entity(struct uvc_device *dev,
+- struct uvc_entity *entity, int rollback, struct uvc_control **err_ctrl)
++ struct uvc_fh *handle,
++ struct uvc_entity *entity,
++ int rollback,
++ struct uvc_control **err_ctrl)
+ {
+ struct uvc_control *ctrl;
+ unsigned int i;
+@@ -1859,6 +1862,10 @@ static int uvc_ctrl_commit_entity(struct
+ *err_ctrl = ctrl;
+ return ret;
+ }
++
++ if (!rollback && handle &&
++ ctrl->info.flags & UVC_CTRL_FLAG_ASYNCHRONOUS)
++ ctrl->handle = handle;
+ }
+
+ return 0;
+@@ -1895,8 +1902,8 @@ int __uvc_ctrl_commit(struct uvc_fh *han
+
+ /* Find the control. */
+ list_for_each_entry(entity, &chain->entities, chain) {
+- ret = uvc_ctrl_commit_entity(chain->dev, entity, rollback,
+- &err_ctrl);
++ ret = uvc_ctrl_commit_entity(chain->dev, handle, entity,
++ rollback, &err_ctrl);
+ if (ret < 0) {
+ if (ctrls)
+ ctrls->error_idx =
+@@ -2046,9 +2053,6 @@ int uvc_ctrl_set(struct uvc_fh *handle,
+ mapping->set(mapping, value,
+ uvc_ctrl_data(ctrl, UVC_CTRL_DATA_CURRENT));
+
+- if (ctrl->info.flags & UVC_CTRL_FLAG_ASYNCHRONOUS)
+- ctrl->handle = handle;
+-
+ ctrl->dirty = 1;
+ ctrl->modified = 1;
+ return 0;
+@@ -2377,7 +2381,7 @@ int uvc_ctrl_restore_values(struct uvc_d
+ ctrl->dirty = 1;
+ }
+
+- ret = uvc_ctrl_commit_entity(dev, entity, 0, NULL);
++ ret = uvc_ctrl_commit_entity(dev, NULL, entity, 0, NULL);
+ if (ret < 0)
+ return ret;
+ }
--- /dev/null
+From 221cd51efe4565501a3dbf04cc011b537dcce7fb Mon Sep 17 00:00:00 2001
+From: Ricardo Ribalda <ribalda@chromium.org>
+Date: Tue, 3 Dec 2024 21:20:10 +0000
+Subject: media: uvcvideo: Remove dangling pointers
+
+From: Ricardo Ribalda <ribalda@chromium.org>
+
+commit 221cd51efe4565501a3dbf04cc011b537dcce7fb upstream.
+
+When an async control is written, we copy a pointer to the file handle
+that started the operation. That pointer will be used when the device is
+done. Which could be anytime in the future.
+
+If the user closes that file descriptor, its structure will be freed,
+and there will be one dangling pointer per pending async control, that
+the driver will try to use.
+
+Clean all the dangling pointers during release().
+
+To avoid adding a performance penalty in the most common case (no async
+operation), a counter has been introduced with some logic to make sure
+that it is properly handled.
+
+Cc: stable@vger.kernel.org
+Fixes: e5225c820c05 ("media: uvcvideo: Send a control event when a Control Change interrupt arrives")
+Reviewed-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
+Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Link: https://lore.kernel.org/r/20241203-uvc-fix-async-v6-3-26c867231118@chromium.org
+Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/uvc/uvc_ctrl.c | 59 +++++++++++++++++++++++++++++++++++++--
+ drivers/media/usb/uvc/uvc_v4l2.c | 2 +
+ drivers/media/usb/uvc/uvcvideo.h | 9 +++++
+ 3 files changed, 67 insertions(+), 3 deletions(-)
+
+--- a/drivers/media/usb/uvc/uvc_ctrl.c
++++ b/drivers/media/usb/uvc/uvc_ctrl.c
+@@ -1579,6 +1579,40 @@ static void uvc_ctrl_send_slave_event(st
+ uvc_ctrl_send_event(chain, handle, ctrl, mapping, val, changes);
+ }
+
++static void uvc_ctrl_set_handle(struct uvc_fh *handle, struct uvc_control *ctrl,
++ struct uvc_fh *new_handle)
++{
++ lockdep_assert_held(&handle->chain->ctrl_mutex);
++
++ if (new_handle) {
++ if (ctrl->handle)
++ dev_warn_ratelimited(&handle->stream->dev->udev->dev,
++ "UVC non compliance: Setting an async control with a pending operation.");
++
++ if (new_handle == ctrl->handle)
++ return;
++
++ if (ctrl->handle) {
++ WARN_ON(!ctrl->handle->pending_async_ctrls);
++ if (ctrl->handle->pending_async_ctrls)
++ ctrl->handle->pending_async_ctrls--;
++ }
++
++ ctrl->handle = new_handle;
++ handle->pending_async_ctrls++;
++ return;
++ }
++
++ /* Cannot clear the handle for a control not owned by us.*/
++ if (WARN_ON(ctrl->handle != handle))
++ return;
++
++ ctrl->handle = NULL;
++ if (WARN_ON(!handle->pending_async_ctrls))
++ return;
++ handle->pending_async_ctrls--;
++}
++
+ void uvc_ctrl_status_event(struct uvc_video_chain *chain,
+ struct uvc_control *ctrl, const u8 *data)
+ {
+@@ -1589,7 +1623,8 @@ void uvc_ctrl_status_event(struct uvc_vi
+ mutex_lock(&chain->ctrl_mutex);
+
+ handle = ctrl->handle;
+- ctrl->handle = NULL;
++ if (handle)
++ uvc_ctrl_set_handle(handle, ctrl, NULL);
+
+ list_for_each_entry(mapping, &ctrl->info.mappings, list) {
+ s32 value = __uvc_ctrl_get_value(mapping, data);
+@@ -1863,7 +1898,7 @@ static int uvc_ctrl_commit_entity(struct
+
+ if (!rollback && handle &&
+ ctrl->info.flags & UVC_CTRL_FLAG_ASYNCHRONOUS)
+- ctrl->handle = handle;
++ uvc_ctrl_set_handle(handle, ctrl, handle);
+ }
+
+ return 0;
+@@ -2772,6 +2807,26 @@ int uvc_ctrl_init_device(struct uvc_devi
+ return 0;
+ }
+
++void uvc_ctrl_cleanup_fh(struct uvc_fh *handle)
++{
++ struct uvc_entity *entity;
++
++ guard(mutex)(&handle->chain->ctrl_mutex);
++
++ if (!handle->pending_async_ctrls)
++ return;
++
++ list_for_each_entry(entity, &handle->chain->dev->entities, list) {
++ for (unsigned int i = 0; i < entity->ncontrols; ++i) {
++ if (entity->controls[i].handle != handle)
++ continue;
++ uvc_ctrl_set_handle(handle, &entity->controls[i], NULL);
++ }
++ }
++
++ WARN_ON(handle->pending_async_ctrls);
++}
++
+ /*
+ * Cleanup device controls.
+ */
+--- a/drivers/media/usb/uvc/uvc_v4l2.c
++++ b/drivers/media/usb/uvc/uvc_v4l2.c
+@@ -659,6 +659,8 @@ static int uvc_v4l2_release(struct file
+
+ uvc_dbg(stream->dev, CALLS, "%s\n", __func__);
+
++ uvc_ctrl_cleanup_fh(handle);
++
+ /* Only free resources if this is a privileged handle. */
+ if (uvc_has_privileges(handle))
+ uvc_queue_release(&stream->queue);
+--- a/drivers/media/usb/uvc/uvcvideo.h
++++ b/drivers/media/usb/uvc/uvcvideo.h
+@@ -338,7 +338,11 @@ struct uvc_video_chain {
+ struct uvc_entity *processing; /* Processing unit */
+ struct uvc_entity *selector; /* Selector unit */
+
+- struct mutex ctrl_mutex; /* Protects ctrl.info */
++ struct mutex ctrl_mutex; /*
++ * Protects ctrl.info,
++ * ctrl.handle and
++ * uvc_fh.pending_async_ctrls
++ */
+
+ struct v4l2_prio_state prio; /* V4L2 priority state */
+ u32 caps; /* V4L2 chain-wide caps */
+@@ -613,6 +617,7 @@ struct uvc_fh {
+ struct uvc_video_chain *chain;
+ struct uvc_streaming *stream;
+ enum uvc_handle_state state;
++ unsigned int pending_async_ctrls;
+ };
+
+ struct uvc_driver {
+@@ -796,6 +801,8 @@ int uvc_ctrl_is_accessible(struct uvc_vi
+ int uvc_xu_ctrl_query(struct uvc_video_chain *chain,
+ struct uvc_xu_control_query *xqry);
+
++void uvc_ctrl_cleanup_fh(struct uvc_fh *handle);
++
+ /* Utility functions */
+ struct usb_host_endpoint *uvc_find_endpoint(struct usb_host_interface *alts,
+ u8 epaddr);
--- /dev/null
+From 04d3398f66d2d31c4b8caea88f051a4257b7a161 Mon Sep 17 00:00:00 2001
+From: Ricardo Ribalda <ribalda@chromium.org>
+Date: Tue, 3 Dec 2024 21:20:09 +0000
+Subject: media: uvcvideo: Remove redundant NULL assignment
+
+From: Ricardo Ribalda <ribalda@chromium.org>
+
+commit 04d3398f66d2d31c4b8caea88f051a4257b7a161 upstream.
+
+ctrl->handle will only be different than NULL for controls that have
+mappings. This is because that assignment is only done inside
+uvc_ctrl_set() for mapped controls.
+
+Cc: stable@vger.kernel.org
+Fixes: e5225c820c05 ("media: uvcvideo: Send a control event when a Control Change interrupt arrives")
+Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Reviewed-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
+Link: https://lore.kernel.org/r/20241203-uvc-fix-async-v6-2-26c867231118@chromium.org
+Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/uvc/uvc_ctrl.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/drivers/media/usb/uvc/uvc_ctrl.c
++++ b/drivers/media/usb/uvc/uvc_ctrl.c
+@@ -1640,10 +1640,8 @@ bool uvc_ctrl_status_event_async(struct
+ struct uvc_device *dev = chain->dev;
+ struct uvc_ctrl_work *w = &dev->async_ctrl;
+
+- if (list_empty(&ctrl->info.mappings)) {
+- ctrl->handle = NULL;
++ if (list_empty(&ctrl->info.mappings))
+ return false;
+- }
+
+ w->data = data;
+ w->urb = urb;
--- /dev/null
+From f00ee2ca8da25ebccb8e19956d853c9055e2c8d0 Mon Sep 17 00:00:00 2001
+From: Ricardo Ribalda <ribalda@chromium.org>
+Date: Thu, 28 Nov 2024 20:53:41 +0000
+Subject: media: uvcvideo: Support partial control reads
+
+From: Ricardo Ribalda <ribalda@chromium.org>
+
+commit f00ee2ca8da25ebccb8e19956d853c9055e2c8d0 upstream.
+
+Some cameras, like the ELMO MX-P3, do not return all the bytes
+requested from a control if it can fit in less bytes.
+Eg: Returning 0xab instead of 0x00ab.
+usb 3-9: Failed to query (GET_DEF) UVC control 3 on unit 2: 1 (exp. 2).
+
+Extend the returned value from the camera and return it.
+
+Cc: stable@vger.kernel.org
+Fixes: a763b9fb58be ("media: uvcvideo: Do not return positive errors in uvc_query_ctrl()")
+Reviewed-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
+Link: https://lore.kernel.org/r/20241128-uvc-readless-v5-1-cf16ed282af8@chromium.org
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/uvc/uvc_video.c | 21 +++++++++++++++++++++
+ 1 file changed, 21 insertions(+)
+
+--- a/drivers/media/usb/uvc/uvc_video.c
++++ b/drivers/media/usb/uvc/uvc_video.c
+@@ -79,6 +79,27 @@ int uvc_query_ctrl(struct uvc_device *de
+ if (likely(ret == size))
+ return 0;
+
++ /*
++ * Some devices return shorter USB control packets than expected if the
++ * returned value can fit in less bytes. Zero all the bytes that the
++ * device has not written.
++ *
++ * This quirk is applied to all controls, regardless of their data type.
++ * Most controls are little-endian integers, in which case the missing
++ * bytes become 0 MSBs. For other data types, a different heuristic
++ * could be implemented if a device is found needing it.
++ *
++ * We exclude UVC_GET_INFO from the quirk. UVC_GET_LEN does not need
++ * to be excluded because its size is always 1.
++ */
++ if (ret > 0 && query != UVC_GET_INFO) {
++ memset(data + ret, 0, size - ret);
++ dev_warn_once(&dev->udev->dev,
++ "UVC non compliance: %s control %u on unit %u returned %d bytes when we expected %u.\n",
++ uvc_query_name(query), cs, unit, ret, size);
++ return 0;
++ }
++
+ if (ret != -EPIPE) {
+ dev_err(&dev->udev->dev,
+ "Failed to query (%s) UVC control %u on unit %u: %d (exp. %u).\n",
--- /dev/null
+From d1366e74342e75555af2648a2964deb2d5c92200 Mon Sep 17 00:00:00 2001
+From: Liu Shixin <liushixin2@huawei.com>
+Date: Thu, 23 Jan 2025 10:10:29 +0800
+Subject: mm/compaction: fix UBSAN shift-out-of-bounds warning
+
+From: Liu Shixin <liushixin2@huawei.com>
+
+commit d1366e74342e75555af2648a2964deb2d5c92200 upstream.
+
+syzkaller reported a UBSAN shift-out-of-bounds warning of (1UL << order)
+in isolate_freepages_block(). The bogus compound_order can be any value
+because it is union with flags. Add back the MAX_PAGE_ORDER check to fix
+the warning.
+
+Link: https://lkml.kernel.org/r/20250123021029.2826736-1-liushixin2@huawei.com
+Fixes: 3da0272a4c7d ("mm/compaction: correctly return failure with bogus compound_order in strict mode")
+Signed-off-by: Liu Shixin <liushixin2@huawei.com>
+Reviewed-by: Kemeng Shi <shikemeng@huaweicloud.com>
+Acked-by: David Hildenbrand <david@redhat.com>
+Reviewed-by: Oscar Salvador <osalvador@suse.de>
+Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
+Cc: David Hildenbrand <david@redhat.com>
+Cc: Kemeng Shi <shikemeng@huaweicloud.com>
+Cc: Matthew Wilcox <willy@infradead.org>
+Cc: Mel Gorman <mgorman@techsingularity.net>
+Cc: Nanyong Sun <sunnanyong@huawei.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/compaction.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/mm/compaction.c
++++ b/mm/compaction.c
+@@ -630,7 +630,8 @@ static unsigned long isolate_freepages_b
+ if (PageCompound(page)) {
+ const unsigned int order = compound_order(page);
+
+- if (blockpfn + (1UL << order) <= end_pfn) {
++ if ((order <= MAX_PAGE_ORDER) &&
++ (blockpfn + (1UL << order) <= end_pfn)) {
+ blockpfn += (1UL << order) - 1;
+ page += (1UL << order) - 1;
+ nr_scanned += (1UL << order) - 1;
--- /dev/null
+From 1aaf8c122918aa8897605a9aa1e8ed6600d6f930 Mon Sep 17 00:00:00 2001
+From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
+Date: Tue, 21 Jan 2025 10:01:59 +0800
+Subject: mm: gup: fix infinite loop within __get_longterm_locked
+
+From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
+
+commit 1aaf8c122918aa8897605a9aa1e8ed6600d6f930 upstream.
+
+We can run into an infinite loop in __get_longterm_locked() when
+collect_longterm_unpinnable_folios() finds only folios that are isolated
+from the LRU or were never added to the LRU. This can happen when all
+folios to be pinned are never added to the LRU, for example when
+vm_ops->fault allocated pages using cma_alloc() and never added them to
+the LRU.
+
+Fix it by simply taking a look at the list in the single caller, to see if
+anything was added.
+
+[zhaoyang.huang@unisoc.com: move definition of local]
+ Link: https://lkml.kernel.org/r/20250122012604.3654667-1-zhaoyang.huang@unisoc.com
+Link: https://lkml.kernel.org/r/20250121020159.3636477-1-zhaoyang.huang@unisoc.com
+Fixes: 67e139b02d99 ("mm/gup.c: refactor check_and_migrate_movable_pages()")
+Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
+Reviewed-by: John Hubbard <jhubbard@nvidia.com>
+Reviewed-by: David Hildenbrand <david@redhat.com>
+Suggested-by: David Hildenbrand <david@redhat.com>
+Acked-by: David Hildenbrand <david@redhat.com>
+Cc: Aijun Sun <aijun.sun@unisoc.com>
+Cc: Alistair Popple <apopple@nvidia.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/gup.c | 14 ++++----------
+ 1 file changed, 4 insertions(+), 10 deletions(-)
+
+--- a/mm/gup.c
++++ b/mm/gup.c
+@@ -2323,13 +2323,13 @@ static void pofs_unpin(struct pages_or_f
+ /*
+ * Returns the number of collected folios. Return value is always >= 0.
+ */
+-static unsigned long collect_longterm_unpinnable_folios(
++static void collect_longterm_unpinnable_folios(
+ struct list_head *movable_folio_list,
+ struct pages_or_folios *pofs)
+ {
+- unsigned long i, collected = 0;
+ struct folio *prev_folio = NULL;
+ bool drain_allow = true;
++ unsigned long i;
+
+ for (i = 0; i < pofs->nr_entries; i++) {
+ struct folio *folio = pofs_get_folio(pofs, i);
+@@ -2341,8 +2341,6 @@ static unsigned long collect_longterm_un
+ if (folio_is_longterm_pinnable(folio))
+ continue;
+
+- collected++;
+-
+ if (folio_is_device_coherent(folio))
+ continue;
+
+@@ -2364,8 +2362,6 @@ static unsigned long collect_longterm_un
+ NR_ISOLATED_ANON + folio_is_file_lru(folio),
+ folio_nr_pages(folio));
+ }
+-
+- return collected;
+ }
+
+ /*
+@@ -2442,11 +2438,9 @@ static long
+ check_and_migrate_movable_pages_or_folios(struct pages_or_folios *pofs)
+ {
+ LIST_HEAD(movable_folio_list);
+- unsigned long collected;
+
+- collected = collect_longterm_unpinnable_folios(&movable_folio_list,
+- pofs);
+- if (!collected)
++ collect_longterm_unpinnable_folios(&movable_folio_list, pofs);
++ if (list_empty(&movable_folio_list))
+ return 0;
+
+ return migrate_longterm_unpinnable_folios(&movable_folio_list, pofs);
--- /dev/null
+From 58db7c5fbe7daa42098d4965133a864f98ba90ba Mon Sep 17 00:00:00 2001
+From: Peter Xu <peterx@redhat.com>
+Date: Tue, 7 Jan 2025 15:39:56 -0500
+Subject: mm/hugetlb: fix avoid_reserve to allow taking folio from subpool
+
+From: Peter Xu <peterx@redhat.com>
+
+commit 58db7c5fbe7daa42098d4965133a864f98ba90ba upstream.
+
+Patch series "mm/hugetlb: Refactor hugetlb allocation resv accounting",
+v2.
+
+This is a follow up on Ackerley's series here as replacement:
+
+https://lore.kernel.org/r/cover.1728684491.git.ackerleytng@google.com
+
+The goal of this series is to cleanup hugetlb resv accounting, especially
+during folio allocation, to decouple a few things:
+
+ - Hugetlb folios v.s. Hugetlbfs: IOW, the hope is in the future hugetlb
+ folios can be allocated completely without hugetlbfs.
+
+ - Decouple VMA v.s. hugetlb folio allocations: allocating a hugetlb folio
+ should not always require a hugetlbfs VMA. For example, either it got
+ allocated from the inode level (see hugetlbfs_fallocate() where it used
+ a pesudo VMA for allocation), or it can be allocated by other kernel
+ subsystems.
+
+It paves way for other users to allocate hugetlb folios out of either
+system reservations, or subpools (instead of hugetlbfs, as a file system).
+For longer term, this prepares hugetlb as a separate concept versus
+hugetlbfs, so that hugetlb folios can be allocated by not only hugetlbfs
+and other things.
+
+Tests I've done:
+
+- I had a reproducer in patch 1 for the bug I found, this will start to
+ work after patch 1 or the whole set applied.
+
+- Hugetlb regression tests (on x86_64 2MBs), includes:
+
+ - All vmtests on hugetlbfs
+
+ - libhugetlbfs test suite (which may fail some tests, but no new failures
+ will be introduced by this series, so all such failures happen before
+ this series so shouldn't be relevant).
+
+
+This patch (of 7):
+
+Since commit 04f2cbe35699 ("hugetlb: guarantee that COW faults for a
+process that called mmap(MAP_PRIVATE) on hugetlbfs will succeed"),
+avoid_reserve was introduced for a special case of CoW on hugetlb private
+mappings, and only if the owner VMA is trying to allocate yet another
+hugetlb folio that is not reserved within the private vma reserved map.
+
+Later on, in commit d85f69b0b533 ("mm/hugetlb: alloc_huge_page handle
+areas hole punched by fallocate"), alloc_huge_page() enforced to not
+consume any global reservation as long as avoid_reserve=true. This
+operation doesn't look correct, because even if it will enforce the
+allocation to not use global reservation at all, it will still try to take
+one reservation from the spool (if the subpool existed). Then since the
+spool reserved pages take from global reservation, it'll also take one
+reservation globally.
+
+Logically it can cause global reservation to go wrong.
+
+I wrote a reproducer below, trigger this special path, and every run of
+such program will cause global reservation count to increment by one, until
+it hits the number of free pages:
+
+ #define _GNU_SOURCE /* See feature_test_macros(7) */
+ #include <stdio.h>
+ #include <fcntl.h>
+ #include <errno.h>
+ #include <unistd.h>
+ #include <stdlib.h>
+ #include <sys/mman.h>
+
+ #define MSIZE (2UL << 20)
+
+ int main(int argc, char *argv[])
+ {
+ const char *path;
+ int *buf;
+ int fd, ret;
+ pid_t child;
+
+ if (argc < 2) {
+ printf("usage: %s <hugetlb_file>\n", argv[0]);
+ return -1;
+ }
+
+ path = argv[1];
+
+ fd = open(path, O_RDWR | O_CREAT, 0666);
+ if (fd < 0) {
+ perror("open failed");
+ return -1;
+ }
+
+ ret = fallocate(fd, 0, 0, MSIZE);
+ if (ret != 0) {
+ perror("fallocate");
+ return -1;
+ }
+
+ buf = mmap(NULL, MSIZE, PROT_READ|PROT_WRITE,
+ MAP_PRIVATE, fd, 0);
+
+ if (buf == MAP_FAILED) {
+ perror("mmap() failed");
+ return -1;
+ }
+
+ /* Allocate a page */
+ *buf = 1;
+
+ child = fork();
+ if (child == 0) {
+ /* child doesn't need to do anything */
+ exit(0);
+ }
+
+ /* Trigger CoW from owner */
+ *buf = 2;
+
+ munmap(buf, MSIZE);
+ close(fd);
+ unlink(path);
+
+ return 0;
+ }
+
+It can only reproduce with a sub-mount when there're reserved pages on the
+spool, like:
+
+ # sysctl vm.nr_hugepages=128
+ # mkdir ./hugetlb-pool
+ # mount -t hugetlbfs -o min_size=8M,pagesize=2M none ./hugetlb-pool
+
+Then run the reproducer on the mountpoint:
+
+ # ./reproducer ./hugetlb-pool/test
+
+Fix it by taking the reservation from spool if available. In general,
+avoid_reserve is IMHO more about "avoid vma resv map", not spool's.
+
+I copied stable, however I have no intention for backporting if it's not a
+clean cherry-pick, because private hugetlb mapping, and then fork() on top
+is too rare to hit.
+
+Link: https://lkml.kernel.org/r/20250107204002.2683356-1-peterx@redhat.com
+Link: https://lkml.kernel.org/r/20250107204002.2683356-2-peterx@redhat.com
+Fixes: d85f69b0b533 ("mm/hugetlb: alloc_huge_page handle areas hole punched by fallocate")
+Signed-off-by: Peter Xu <peterx@redhat.com>
+Reviewed-by: Ackerley Tng <ackerleytng@google.com>
+Tested-by: Ackerley Tng <ackerleytng@google.com>
+Reviewed-by: Oscar Salvador <osalvador@suse.de>
+Cc: Breno Leitao <leitao@debian.org>
+Cc: Muchun Song <muchun.song@linux.dev>
+Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
+Cc: Rik van Riel <riel@surriel.com>
+Cc: Roman Gushchin <roman.gushchin@linux.dev>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/hugetlb.c | 22 +++-------------------
+ 1 file changed, 3 insertions(+), 19 deletions(-)
+
+--- a/mm/hugetlb.c
++++ b/mm/hugetlb.c
+@@ -1394,8 +1394,7 @@ static unsigned long available_huge_page
+
+ static struct folio *dequeue_hugetlb_folio_vma(struct hstate *h,
+ struct vm_area_struct *vma,
+- unsigned long address, int avoid_reserve,
+- long chg)
++ unsigned long address, long chg)
+ {
+ struct folio *folio = NULL;
+ struct mempolicy *mpol;
+@@ -1411,10 +1410,6 @@ static struct folio *dequeue_hugetlb_fol
+ if (!vma_has_reserves(vma, chg) && !available_huge_pages(h))
+ goto err;
+
+- /* If reserves cannot be used, ensure enough pages are in the pool */
+- if (avoid_reserve && !available_huge_pages(h))
+- goto err;
+-
+ gfp_mask = htlb_alloc_mask(h);
+ nid = huge_node(vma, address, gfp_mask, &mpol, &nodemask);
+
+@@ -1430,7 +1425,7 @@ static struct folio *dequeue_hugetlb_fol
+ folio = dequeue_hugetlb_folio_nodemask(h, gfp_mask,
+ nid, nodemask);
+
+- if (folio && !avoid_reserve && vma_has_reserves(vma, chg)) {
++ if (folio && vma_has_reserves(vma, chg)) {
+ folio_set_hugetlb_restore_reserve(folio);
+ h->resv_huge_pages--;
+ }
+@@ -3006,17 +3001,6 @@ struct folio *alloc_hugetlb_folio(struct
+ gbl_chg = hugepage_subpool_get_pages(spool, 1);
+ if (gbl_chg < 0)
+ goto out_end_reservation;
+-
+- /*
+- * Even though there was no reservation in the region/reserve
+- * map, there could be reservations associated with the
+- * subpool that can be used. This would be indicated if the
+- * return value of hugepage_subpool_get_pages() is zero.
+- * However, if avoid_reserve is specified we still avoid even
+- * the subpool reservations.
+- */
+- if (avoid_reserve)
+- gbl_chg = 1;
+ }
+
+ /* If this allocation is not consuming a reservation, charge it now.
+@@ -3039,7 +3023,7 @@ struct folio *alloc_hugetlb_folio(struct
+ * from the global free pool (global change). gbl_chg == 0 indicates
+ * a reservation exists for the allocation.
+ */
+- folio = dequeue_hugetlb_folio_vma(h, vma, addr, avoid_reserve, gbl_chg);
++ folio = dequeue_hugetlb_folio_vma(h, vma, addr, gbl_chg);
+ if (!folio) {
+ spin_unlock_irq(&hugetlb_lock);
+ folio = alloc_buddy_hugetlb_folio_with_mpol(h, vma, addr);
--- /dev/null
+From 76e961157e078bc5d3cd2df08317e00b00a829eb Mon Sep 17 00:00:00 2001
+From: "Ritesh Harjani (IBM)" <ritesh.list@gmail.com>
+Date: Sat, 11 Jan 2025 16:36:55 +0530
+Subject: mm/hugetlb: fix hugepage allocation for interleaved memory nodes
+
+From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
+
+commit 76e961157e078bc5d3cd2df08317e00b00a829eb upstream.
+
+gather_bootmem_prealloc() assumes the start nid as 0 and size as
+num_node_state(N_MEMORY). That means in case if memory attached numa
+nodes are interleaved, then gather_bootmem_prealloc_parallel() will fail
+to scan few of these nodes.
+
+Since memory attached numa nodes can be interleaved in any fashion, hence
+ensure that the current code checks for all numa node ids
+(.size = nr_node_ids). Let's still keep max_threads as N_MEMORY, so that
+it can distributes all nr_node_ids among the these many no. threads.
+
+e.g. qemu cmdline
+========================
+numa_cmd="-numa node,nodeid=1,memdev=mem1,cpus=2-3 -numa node,nodeid=0,cpus=0-1 -numa dist,src=0,dst=1,val=20"
+mem_cmd="-object memory-backend-ram,id=mem1,size=16G"
+
+w/o this patch for cmdline (default_hugepagesz=1GB hugepagesz=1GB hugepages=2):
+==========================
+~ # cat /proc/meminfo |grep -i huge
+AnonHugePages: 0 kB
+ShmemHugePages: 0 kB
+FileHugePages: 0 kB
+HugePages_Total: 0
+HugePages_Free: 0
+HugePages_Rsvd: 0
+HugePages_Surp: 0
+Hugepagesize: 1048576 kB
+Hugetlb: 0 kB
+
+with this patch for cmdline (default_hugepagesz=1GB hugepagesz=1GB hugepages=2):
+===========================
+~ # cat /proc/meminfo |grep -i huge
+AnonHugePages: 0 kB
+ShmemHugePages: 0 kB
+FileHugePages: 0 kB
+HugePages_Total: 2
+HugePages_Free: 2
+HugePages_Rsvd: 0
+HugePages_Surp: 0
+Hugepagesize: 1048576 kB
+Hugetlb: 2097152 kB
+
+Link: https://lkml.kernel.org/r/f8d8dad3a5471d284f54185f65d575a6aaab692b.1736592534.git.ritesh.list@gmail.com
+Fixes: b78b27d02930 ("hugetlb: parallelize 1G hugetlb initialization")
+Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
+Reported-by: Pavithra Prakash <pavrampu@linux.ibm.com>
+Suggested-by: Muchun Song <muchun.song@linux.dev>
+Tested-by: Sourabh Jain <sourabhjain@linux.ibm.com>
+Reviewed-by: Luiz Capitulino <luizcap@redhat.com>
+Acked-by: David Rientjes <rientjes@google.com>
+Cc: Donet Tom <donettom@linux.ibm.com>
+Cc: Gang Li <gang.li@linux.dev>
+Cc: Daniel Jordan <daniel.m.jordan@oracle.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/hugetlb.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/mm/hugetlb.c
++++ b/mm/hugetlb.c
+@@ -3271,7 +3271,7 @@ static void __init gather_bootmem_preall
+ .thread_fn = gather_bootmem_prealloc_parallel,
+ .fn_arg = NULL,
+ .start = 0,
+- .size = num_node_state(N_MEMORY),
++ .size = nr_node_ids,
+ .align = 1,
+ .min_chunk = 1,
+ .max_threads = num_node_state(N_MEMORY),
--- /dev/null
+From 488b5b9eca68497b533ced059be5eff19578bbca Mon Sep 17 00:00:00 2001
+From: Catalin Marinas <catalin.marinas@arm.com>
+Date: Mon, 27 Jan 2025 18:42:33 +0000
+Subject: mm: kmemleak: fix upper boundary check for physical address objects
+
+From: Catalin Marinas <catalin.marinas@arm.com>
+
+commit 488b5b9eca68497b533ced059be5eff19578bbca upstream.
+
+Memblock allocations are registered by kmemleak separately, based on their
+physical address. During the scanning stage, it checks whether an object
+is within the min_low_pfn and max_low_pfn boundaries and ignores it
+otherwise.
+
+With the recent addition of __percpu pointer leak detection (commit
+6c99d4eb7c5e ("kmemleak: enable tracking for percpu pointers")), kmemleak
+started reporting leaks in setup_zone_pageset() and
+setup_per_cpu_pageset(). These were caused by the node_data[0] object
+(initialised in alloc_node_data()) ending on the PFN_PHYS(max_low_pfn)
+boundary. The non-strict upper boundary check introduced by commit
+84c326299191 ("mm: kmemleak: check physical address when scan") causes the
+pg_data_t object to be ignored (not scanned) and the __percpu pointers it
+contains to be reported as leaks.
+
+Make the max_low_pfn upper boundary check strict when deciding whether to
+ignore a physical address object and not scan it.
+
+Link: https://lkml.kernel.org/r/20250127184233.2974311-1-catalin.marinas@arm.com
+Fixes: 84c326299191 ("mm: kmemleak: check physical address when scan")
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Reported-by: Jakub Kicinski <kuba@kernel.org>
+Tested-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Cc: Patrick Wang <patrick.wang.shcn@gmail.com>
+Cc: <stable@vger.kernel.org> [6.0.x]
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/kmemleak.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/mm/kmemleak.c
++++ b/mm/kmemleak.c
+@@ -1650,7 +1650,7 @@ static void kmemleak_scan(void)
+ unsigned long phys = object->pointer;
+
+ if (PHYS_PFN(phys) < min_low_pfn ||
+- PHYS_PFN(phys + object->size) >= max_low_pfn)
++ PHYS_PFN(phys + object->size) > max_low_pfn)
+ __paint_it(object, KMEMLEAK_BLACK);
+ }
+
--- /dev/null
+From a479b078fddb0ad7f9e3c6da22d9cf8f2b5c7799 Mon Sep 17 00:00:00 2001
+From: Li Zhijian <lizhijian@fujitsu.com>
+Date: Fri, 10 Jan 2025 20:21:32 +0800
+Subject: mm/vmscan: accumulate nr_demoted for accurate demotion statistics
+
+From: Li Zhijian <lizhijian@fujitsu.com>
+
+commit a479b078fddb0ad7f9e3c6da22d9cf8f2b5c7799 upstream.
+
+In shrink_folio_list(), demote_folio_list() can be called 2 times.
+Currently stat->nr_demoted will only store the last nr_demoted( the later
+nr_demoted is always zero, the former nr_demoted will get lost), as a
+result number of demoted pages is not accurate.
+
+Accumulate the nr_demoted count across multiple calls to
+demote_folio_list(), ensuring accurate reporting of demotion statistics.
+
+[lizhijian@fujitsu.com: introduce local nr_demoted to fix nr_reclaimed double counting]
+ Link: https://lkml.kernel.org/r/20250111015253.425693-1-lizhijian@fujitsu.com
+Link: https://lkml.kernel.org/r/20250110122133.423481-1-lizhijian@fujitsu.com
+Fixes: f77f0c751478 ("mm,memcg: provide per-cgroup counters for NUMA balancing operations")
+Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
+Acked-by: Kaiyang Zhao <kaiyang2@cs.cmu.edu>
+Tested-by: Donet Tom <donettom@linux.ibm.com>
+Reviewed-by: Donet Tom <donettom@linux.ibm.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/vmscan.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/mm/vmscan.c
++++ b/mm/vmscan.c
+@@ -1053,7 +1053,7 @@ static unsigned int shrink_folio_list(st
+ struct folio_batch free_folios;
+ LIST_HEAD(ret_folios);
+ LIST_HEAD(demote_folios);
+- unsigned int nr_reclaimed = 0;
++ unsigned int nr_reclaimed = 0, nr_demoted = 0;
+ unsigned int pgactivate = 0;
+ bool do_demote_pass;
+ struct swap_iocb *plug = NULL;
+@@ -1522,8 +1522,9 @@ keep:
+ /* 'folio_list' is always empty here */
+
+ /* Migrate folios selected for demotion */
+- stat->nr_demoted = demote_folio_list(&demote_folios, pgdat);
+- nr_reclaimed += stat->nr_demoted;
++ nr_demoted = demote_folio_list(&demote_folios, pgdat);
++ nr_reclaimed += nr_demoted;
++ stat->nr_demoted += nr_demoted;
+ /* Folios that could not be demoted are still in @demote_folios */
+ if (!list_empty(&demote_folios)) {
+ /* Folios which weren't demoted go back on @folio_list */
--- /dev/null
+From 3599bae489d86fbabe039f9a2ab5472ffb04f7f1 Mon Sep 17 00:00:00 2001
+From: Helge Deller <deller@kernel.org>
+Date: Thu, 16 Jan 2025 21:17:47 +0100
+Subject: parisc: Temporarily disable jump label support
+
+From: Helge Deller <deller@kernel.org>
+
+commit 3599bae489d86fbabe039f9a2ab5472ffb04f7f1 upstream.
+
+The 32-bit Debian kernel 6.12 fails to boot and crashes like this:
+
+ init (pid 65): Protection id trap (code 7)
+ CPU: 0 UID: 0 PID: 65 Comm: init Not tainted 6.12.9 #2
+ Hardware name: 9000/778/B160L
+
+ YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
+ PSW: 00000000000001000000000000001111 Not tainted
+ r00-03 0004000f 110d39d0 109a6558 12974400
+ r04-07 12a810e0 12a810e0 00000000 12a81144
+ r08-11 12a81174 00000007 00000000 00000002
+ r12-15 f8c55c08 0000006c 00000001 f8c55c08
+ r16-19 00000002 f8c58620 002da3a8 0000004e
+ r20-23 00001a46 0000000f 10754f84 00000000
+ r24-27 00000000 00000003 12ae6980 1127b9d0
+ r28-31 00000000 00000000 12974440 109a6558
+ sr00-03 00000000 00000000 00000000 00000010
+ sr04-07 00000000 00000000 00000000 00000000
+
+ IASQ: 00000000 00000000 IAOQ: 110d39d0 110d39d4
+ IIR: baadf00d ISR: 00000000 IOR: 110d39d0
+ CPU: 0 CR30: 128740c0 CR31: 00000000
+ ORIG_R28: 000003f3
+ IAOQ[0]: 0x110d39d0
+ IAOQ[1]: 0x110d39d4
+ RP(r2): security_sk_free+0x70/0x1a4
+ Backtrace:
+ [<10d8c844>] __sk_destruct+0x2bc/0x378
+ [<10d8e33c>] sk_destruct+0x68/0x8c
+ [<10d8e3dc>] __sk_free+0x7c/0x148
+ [<10d8e560>] sk_free+0xb8/0xf0
+ [<10f6420c>] unix_release_sock+0x3ac/0x50c
+ [<10f643b8>] unix_release+0x4c/0x7c
+ [<10d832f8>] __sock_release+0x5c/0xf8
+ [<10d833b4>] sock_close+0x20/0x44
+ [<107ba52c>] __fput+0xf8/0x468
+ [<107baa08>] __fput_sync+0xb4/0xd4
+ [<107b471c>] sys_close+0x44/0x94
+ [<10405334>] syscall_exit+0x0/0x10
+
+Bisecting points to this commit which triggers the issue:
+ commit 417c5643cd67a55f424b203b492082035d0236c3
+ Author: KP Singh <kpsingh@kernel.org>
+ Date: Fri Aug 16 17:43:07 2024 +0200
+ lsm: replace indirect LSM hook calls with static calls
+
+After more analysis it seems that we don't fully implement the static calls
+and jump tables yet. Additionally the functions which mark kernel memory
+read-only or read-write-executable needs to be further enhanced to be able to
+fully support static calls.
+
+Enabling CONFIG_SECURITY_YAMA=y was one possibility to trigger the issue,
+although YAMA isn't the reason for the fault.
+
+As a temporary solution disable JUMP_LABEL functionality to
+avoid the crashes.
+
+Signed-off-by: Helge Deller <deller@gmx.de>
+Cc: Guenter Roeck <linux@roeck-us.net>
+Reviewed-by: Guenter Roeck <linux@roeck-us.net>
+Cc: <stable@vger.kernel.org> # v6.12+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/parisc/Kconfig | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
+index aa6a3cad275d..fcc5973f7519 100644
+--- a/arch/parisc/Kconfig
++++ b/arch/parisc/Kconfig
+@@ -60,8 +60,8 @@ config PARISC
+ select HAVE_ARCH_MMAP_RND_BITS
+ select HAVE_ARCH_AUDITSYSCALL
+ select HAVE_ARCH_HASH
+- select HAVE_ARCH_JUMP_LABEL
+- select HAVE_ARCH_JUMP_LABEL_RELATIVE
++ # select HAVE_ARCH_JUMP_LABEL
++ # select HAVE_ARCH_JUMP_LABEL_RELATIVE
+ select HAVE_ARCH_KFENCE
+ select HAVE_ARCH_SECCOMP_FILTER
+ select HAVE_ARCH_TRACEHOOK
+--
+2.48.1
+
--- /dev/null
+From 752b6e3af374460a2de18f0c10bfa06bf844dbe8 Mon Sep 17 00:00:00 2001
+From: Conor Dooley <conor.dooley@microchip.com>
+Date: Wed, 22 Jan 2025 14:42:56 +0000
+Subject: pwm: microchip-core: fix incorrect comparison with max period
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Conor Dooley <conor.dooley@microchip.com>
+
+commit 752b6e3af374460a2de18f0c10bfa06bf844dbe8 upstream.
+
+In mchp_core_pwm_apply_locked(), if hw_period_steps is equal to its max,
+an error is reported and .apply fails. The max value is actually a
+permitted value however, and so this check can fail where multiple
+channels are enabled.
+
+For example, the first channel to be configured requests a period that
+sets hw_period_steps to the maximum value, and when a second channel
+is enabled the driver reads hw_period_steps back from the hardware and
+finds it to be the maximum possible value, triggering the warning on a
+permitted value. The value to be avoided is 255 (PERIOD_STEPS_MAX + 1),
+as that will produce undesired behaviour, so test for greater than,
+rather than equal to.
+
+Fixes: 2bf7ecf7b4ff ("pwm: add microchip soft ip corePWM driver")
+Cc: stable@vger.kernel.org
+Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
+Link: https://lore.kernel.org/r/20250122-pastor-fancied-0b993da2d2d2@spud
+Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pwm/pwm-microchip-core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/pwm/pwm-microchip-core.c
++++ b/drivers/pwm/pwm-microchip-core.c
+@@ -327,7 +327,7 @@ static int mchp_core_pwm_apply_locked(st
+ * mchp_core_pwm_calc_period().
+ * The period is locked and we cannot change this, so we abort.
+ */
+- if (hw_period_steps == MCHPCOREPWM_PERIOD_STEPS_MAX)
++ if (hw_period_steps > MCHPCOREPWM_PERIOD_STEPS_MAX)
+ return -EINVAL;
+
+ prescale = hw_prescale;
--- /dev/null
+From c21bdb3d8a850afdfa4afe77eea39ae9533629b0 Mon Sep 17 00:00:00 2001
+From: Miguel Ojeda <ojeda@kernel.org>
+Date: Tue, 21 Jan 2025 21:09:34 +0100
+Subject: rust: init: use explicit ABI to clean warning in future compilers
+
+From: Miguel Ojeda <ojeda@kernel.org>
+
+commit c21bdb3d8a850afdfa4afe77eea39ae9533629b0 upstream.
+
+Starting with Rust 1.86.0 (currently in nightly, to be released on
+2025-04-03), the `missing_abi` lint is warn-by-default [1]:
+
+ error: extern declarations without an explicit ABI are deprecated
+ --> rust/doctests_kernel_generated.rs:3158:1
+ |
+ 3158 | extern {
+ | ^^^^^^ help: explicitly specify the C ABI: `extern "C"`
+ |
+ = note: `-D missing-abi` implied by `-D warnings`
+ = help: to override `-D warnings` add `#[allow(missing_abi)]`
+
+Thus clean it up.
+
+Cc: <stable@vger.kernel.org> # Needed in 6.12.y and 6.13.y only (Rust is pinned in older LTSs).
+Fixes: 7f8977a7fe6d ("rust: init: add `{pin_}chain` functions to `{Pin}Init<T, E>`")
+Link: https://github.com/rust-lang/rust/pull/132397 [1]
+Reviewed-by: Gary Guo <gary@garyguo.net>
+Reviewed-by: Alice Ryhl <aliceryhl@google.com>
+Reviewed-by: Fiona Behrens <me@kloenk.dev>
+Link: https://lore.kernel.org/r/20250121200934.222075-1-ojeda@kernel.org
+[ Added 6.13.y to Cc: stable tag. - Miguel ]
+Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ rust/kernel/init.rs | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/rust/kernel/init.rs
++++ b/rust/kernel/init.rs
+@@ -858,7 +858,7 @@ pub unsafe trait PinInit<T: ?Sized, E =
+ /// use kernel::{types::Opaque, init::pin_init_from_closure};
+ /// #[repr(C)]
+ /// struct RawFoo([u8; 16]);
+- /// extern {
++ /// extern "C" {
+ /// fn init_foo(_: *mut RawFoo);
+ /// }
+ ///
--- /dev/null
+From 8259cb14a70680553d5e82d65d1302fe589e9b39 Mon Sep 17 00:00:00 2001
+From: Gabriele Monaco <gmonaco@redhat.com>
+Date: Wed, 15 Jan 2025 16:15:48 +0100
+Subject: rv: Reset per-task monitors also for idle tasks
+
+From: Gabriele Monaco <gmonaco@redhat.com>
+
+commit 8259cb14a70680553d5e82d65d1302fe589e9b39 upstream.
+
+RV per-task monitors are implemented through a monitor structure
+available for each task_struct. This structure is reset every time the
+monitor is (re-)started, to avoid inconsistencies if the monitor was
+activated previously.
+To do so, we reset the monitor on all threads using the macro
+for_each_process_thread. However, this macro excludes the idle tasks on
+each CPU. Idle tasks could be considered tasks on their own right and it
+should be up to the model whether to ignore them or not.
+
+Reset monitors also on the idle tasks for each present CPU whenever we
+reset all per-task monitors.
+
+Cc: stable@vger.kernel.org
+Cc: Juri Lelli <juri.lelli@redhat.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: John Kacur <jkacur@redhat.com>
+Link: https://lore.kernel.org/20250115151547.605750-2-gmonaco@redhat.com
+Fixes: 792575348ff7 ("rv/include: Add deterministic automata monitor definition via C macros")
+Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/rv/da_monitor.h | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/include/rv/da_monitor.h
++++ b/include/rv/da_monitor.h
+@@ -14,6 +14,7 @@
+ #include <rv/automata.h>
+ #include <linux/rv.h>
+ #include <linux/bug.h>
++#include <linux/sched.h>
+
+ #ifdef CONFIG_RV_REACTORS
+
+@@ -324,10 +325,13 @@ static inline struct da_monitor *da_get_
+ static void da_monitor_reset_all_##name(void) \
+ { \
+ struct task_struct *g, *p; \
++ int cpu; \
+ \
+ read_lock(&tasklist_lock); \
+ for_each_process_thread(g, p) \
+ da_monitor_reset_##name(da_get_monitor_##name(p)); \
++ for_each_present_cpu(cpu) \
++ da_monitor_reset_##name(da_get_monitor_##name(idle_task(cpu))); \
+ read_unlock(&tasklist_lock); \
+ } \
+ \
scsi-storvsc-set-correct-data-length-for-sending-scsi-command-without-payload.patch
scsi-core-do-not-retry-i-os-during-depopulation.patch
kbuild-move-wenum-enum-conversion-to-w-2.patch
+rust-init-use-explicit-abi-to-clean-warning-in-future-compilers.patch
+x86-rust-set-rustc-abi-x86-softfloat-on-rustc-1.86.0.patch
+x86-acpi-fix-lapic-x2apic-parsing-order.patch
+x86-boot-use-std-gnu11-to-fix-build-with-gcc-15.patch
+ubi-add-a-check-for-ubi_num.patch
+arm-dts-dra7-add-bus_dma_limit-for-l4-cfg-bus.patch
+arm-dts-ti-omap-gta04-fix-pm-issues-caused-by-spi-module.patch
+arm64-dts-mediatek-mt8183-disable-dpi-display-output-by-default.patch
+arm64-dts-qcom-sdx75-fix-mpss-memory-length.patch
+arm64-dts-qcom-x1e80100-fix-adsp-memory-base-and-length.patch
+arm64-dts-qcom-x1e80100-fix-cdsp-memory-length.patch
+arm64-dts-qcom-sm6115-fix-mpss-memory-length.patch
+arm64-dts-qcom-sm6115-fix-cdsp-memory-length.patch
+arm64-dts-qcom-sm6115-fix-adsp-memory-base-and-length.patch
+arm64-dts-qcom-sm6350-fix-adsp-memory-length.patch
+arm64-dts-qcom-sm6350-fix-mpss-memory-length.patch
+arm64-dts-qcom-sm6350-fix-uart1-interconnect-path.patch
+arm64-dts-qcom-sm6375-fix-adsp-memory-length.patch
+arm64-dts-qcom-sm6375-fix-cdsp-memory-base-and-length.patch
+arm64-dts-qcom-sm6375-fix-mpss-memory-base-and-length.patch
+arm64-dts-qcom-sm8350-fix-adsp-memory-base-and-length.patch
+arm64-dts-qcom-sm8350-fix-cdsp-memory-base-and-length.patch
+arm64-dts-qcom-sm8350-fix-mpss-memory-length.patch
+arm64-dts-qcom-sm8450-fix-adsp-memory-base-and-length.patch
+arm64-dts-qcom-sm8450-fix-cdsp-memory-length.patch
+arm64-dts-qcom-sm8450-fix-mpss-memory-length.patch
+arm64-dts-qcom-sm8550-fix-adsp-memory-base-and-length.patch
+arm64-dts-qcom-sm8550-fix-cdsp-memory-length.patch
+arm64-dts-qcom-sm8550-fix-mpss-memory-length.patch
+arm64-dts-qcom-sm8650-fix-adsp-memory-base-and-length.patch
+arm64-dts-qcom-sm8650-fix-cdsp-memory-length.patch
+arm64-dts-qcom-sm8650-fix-mpss-memory-length.patch
+arm64-dts-qcom-sm8550-correct-mdss-interconnects.patch
+arm64-dts-qcom-sm8650-correct-mdss-interconnects.patch
+crypto-qce-fix-priority-to-be-less-than-armv8-ce.patch
+arm64-tegra-fix-typo-in-tegra234-dce-fabric-compatible.patch
+arm64-tegra-disable-tegra234-sce-fabric-node.patch
+parisc-temporarily-disable-jump-label-support.patch
+pwm-microchip-core-fix-incorrect-comparison-with-max-period.patch
+xfs-don-t-call-remap_verify_area-with-sb-write-protection-held.patch
+xfs-propagate-errors-from-xfs_reflink_cancel_cow_range-in-xfs_dax_write_iomap_end.patch
+xfs-add-error-handling-for-xfs_reflink_cancel_cow_range.patch
+accel-ivpu-clear-runtime_error-after-pm_runtime_resume_and_get-fails.patch
+acpi-prm-remove-unnecessary-strict-handler-address-checks.patch
+tpm-change-to-kvalloc-in-eventlog-acpi.c.patch
+rv-reset-per-task-monitors-also-for-idle-tasks.patch
+hrtimers-force-migrate-away-hrtimers-queued-after-cpuhp_ap_hrtimers_dying.patch
+iommufd-fix-struct-iommu_hwpt_pgfault-init-and-padding.patch
+kfence-skip-__gfp_thisnode-allocations-on-numa-systems.patch
+media-ccs-clean-up-parsed-ccs-static-data-on-parse-failure.patch
+mm-hugetlb-fix-avoid_reserve-to-allow-taking-folio-from-subpool.patch
+iio-light-as73211-fix-channel-handling-in-only-color-triggered-buffer.patch
+iommu-tegra241-cmdqv-read-smmu-idr1.cmdqs-instead-of-hardcoding.patch
+iommufd-fault-destroy-response-and-mutex-in-iommufd_fault_destroy.patch
+iommufd-fault-use-a-separate-spinlock-to-protect-fault-deliver-list.patch
+soc-samsung-exynos-pmu-fix-uninitialized-ret-in-tensor_set_bits_atomic.patch
+soc-mediatek-mtk-devapc-fix-leaking-io-map-on-error-paths.patch
+soc-mediatek-mtk-devapc-fix-leaking-io-map-on-driver-remove.patch
+soc-qcom-llcc-enable-llcc_wrcache-at-boot-on-x1.patch
+soc-qcom-smem_state-fix-missing-of_node_put-in-error-path.patch
+media-mmp-bring-back-registration-of-the-device.patch
+media-mc-fix-endpoint-iteration.patch
+media-nuvoton-fix-an-error-check-in-npcm_video_ece_init.patch
+media-imx296-add-standby-delay-during-probe.patch
+media-intel-ipu6-remove-cpu-latency-qos-request-on-error.patch
+media-ov5640-fix-get_light_freq-on-auto.patch
+media-stm32-dcmipp-correct-dma_set_mask_and_coherent-mask-value.patch
+media-ccs-fix-ccs-static-data-parsing-for-large-block-sizes.patch
+media-ccs-fix-cleanup-order-in-ccs_probe.patch
+media-i2c-ds90ub9x3-fix-extra-fwnode_handle_put.patch
+media-i2c-ds90ub960-fix-use-of-non-existing-registers-on-ub9702.patch
+media-i2c-ds90ub960-fix-ub9702-vc-map.patch
+media-i2c-ds90ub960-fix-logging-sp-eq-status-only-for-ub9702.patch
+media-uvcvideo-fix-crash-during-unbind-if-gpio-unit-is-in-use.patch
+media-uvcvideo-fix-event-flags-in-uvc_ctrl_send_events.patch
+media-uvcvideo-support-partial-control-reads.patch
+media-uvcvideo-only-save-async-fh-if-success.patch
+media-uvcvideo-remove-redundant-null-assignment.patch
+media-uvcvideo-remove-dangling-pointers.patch
+mm-kmemleak-fix-upper-boundary-check-for-physical-address-objects.patch
+mm-gup-fix-infinite-loop-within-__get_longterm_locked.patch
+mm-vmscan-accumulate-nr_demoted-for-accurate-demotion-statistics.patch
+mm-hugetlb-fix-hugepage-allocation-for-interleaved-memory-nodes.patch
+mm-compaction-fix-ubsan-shift-out-of-bounds-warning.patch
--- /dev/null
+From c9c0036c1990da8d2dd33563e327e05a775fcf10 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Sat, 4 Jan 2025 15:20:12 +0100
+Subject: soc: mediatek: mtk-devapc: Fix leaking IO map on driver remove
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit c9c0036c1990da8d2dd33563e327e05a775fcf10 upstream.
+
+Driver removal should fully clean up - unmap the memory.
+
+Fixes: 0890beb22618 ("soc: mediatek: add mt6779 devapc driver")
+Cc: stable@vger.kernel.org
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Link: https://lore.kernel.org/r/20250104142012.115974-2-krzysztof.kozlowski@linaro.org
+Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/soc/mediatek/mtk-devapc.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/soc/mediatek/mtk-devapc.c
++++ b/drivers/soc/mediatek/mtk-devapc.c
+@@ -305,6 +305,7 @@ static void mtk_devapc_remove(struct pla
+ struct mtk_devapc_context *ctx = platform_get_drvdata(pdev);
+
+ stop_devapc(ctx);
++ iounmap(ctx->infra_base);
+ }
+
+ static struct platform_driver mtk_devapc_driver = {
--- /dev/null
+From c0eb059a4575ed57f265d9883a5203799c19982c Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Sat, 4 Jan 2025 15:20:11 +0100
+Subject: soc: mediatek: mtk-devapc: Fix leaking IO map on error paths
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit c0eb059a4575ed57f265d9883a5203799c19982c upstream.
+
+Error paths of mtk_devapc_probe() should unmap the memory. Reported by
+Smatch:
+
+ drivers/soc/mediatek/mtk-devapc.c:292 mtk_devapc_probe() warn: 'ctx->infra_base' from of_iomap() not released on lines: 277,281,286.
+
+Fixes: 0890beb22618 ("soc: mediatek: add mt6779 devapc driver")
+Cc: stable@vger.kernel.org
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Link: https://lore.kernel.org/r/20250104142012.115974-1-krzysztof.kozlowski@linaro.org
+Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/soc/mediatek/mtk-devapc.c | 18 +++++++++++++-----
+ 1 file changed, 13 insertions(+), 5 deletions(-)
+
+--- a/drivers/soc/mediatek/mtk-devapc.c
++++ b/drivers/soc/mediatek/mtk-devapc.c
+@@ -273,23 +273,31 @@ static int mtk_devapc_probe(struct platf
+ return -EINVAL;
+
+ devapc_irq = irq_of_parse_and_map(node, 0);
+- if (!devapc_irq)
+- return -EINVAL;
++ if (!devapc_irq) {
++ ret = -EINVAL;
++ goto err;
++ }
+
+ ctx->infra_clk = devm_clk_get_enabled(&pdev->dev, "devapc-infra-clock");
+- if (IS_ERR(ctx->infra_clk))
+- return -EINVAL;
++ if (IS_ERR(ctx->infra_clk)) {
++ ret = -EINVAL;
++ goto err;
++ }
+
+ ret = devm_request_irq(&pdev->dev, devapc_irq, devapc_violation_irq,
+ IRQF_TRIGGER_NONE, "devapc", ctx);
+ if (ret)
+- return ret;
++ goto err;
+
+ platform_set_drvdata(pdev, ctx);
+
+ start_devapc(ctx);
+
+ return 0;
++
++err:
++ iounmap(ctx->infra_base);
++ return ret;
+ }
+
+ static void mtk_devapc_remove(struct platform_device *pdev)
--- /dev/null
+From 35d8bc131de0f0f280f0db42499512d79f05f456 Mon Sep 17 00:00:00 2001
+From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Date: Thu, 19 Dec 2024 19:53:29 +0100
+Subject: soc: qcom: llcc: Enable LLCC_WRCACHE at boot on X1
+
+From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+
+commit 35d8bc131de0f0f280f0db42499512d79f05f456 upstream.
+
+The Last Level Cache is split into many slices, each one of which can
+be toggled on or off.
+
+Only certain slices are recommended to be turned on unconditionally,
+in order to reach optimal performance/latency/power levels.
+
+Enable WRCACHE on X1 at boot, in accordance with internal
+recommendations.
+
+No significant performance difference is expected.
+
+Fixes: b3cf69a43502 ("soc: qcom: llcc: Add configuration data for X1E80100")
+Cc: stable@vger.kernel.org
+Reviewed-by: Rajendra Nayak <quic_rjendra@quicinc.com>
+Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
+Tested-by: Johan Hovold <johan+linaro@kernel.org>
+Link: https://lore.kernel.org/r/20241219-topic-llcc_x1e_wrcache-v3-1-b9848d9c3d63@oss.qualcomm.com
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/soc/qcom/llcc-qcom.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/soc/qcom/llcc-qcom.c
++++ b/drivers/soc/qcom/llcc-qcom.c
+@@ -2511,6 +2511,7 @@ static const struct llcc_slice_config x1
+ .fixed_size = true,
+ .bonus_ways = 0xfff,
+ .cache_mode = 0,
++ .activate_on_init = true,
+ }, {
+ .usecase_id = LLCC_CAMEXP0,
+ .slice_id = 4,
--- /dev/null
+From 70096b4990848229d0784c5e51dc3c7c072f1111 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Thu, 22 Aug 2024 18:48:51 +0200
+Subject: soc: qcom: smem_state: fix missing of_node_put in error path
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit 70096b4990848229d0784c5e51dc3c7c072f1111 upstream.
+
+If of_parse_phandle_with_args() succeeds, the OF node reference should
+be dropped, regardless of number of phandle arguments.
+
+Cc: stable@vger.kernel.org
+Fixes: 9460ae2ff308 ("soc: qcom: Introduce common SMEM state machine code")
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+Link: https://lore.kernel.org/r/20240822164853.231087-2-krzysztof.kozlowski@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/soc/qcom/smem_state.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/soc/qcom/smem_state.c
++++ b/drivers/soc/qcom/smem_state.c
+@@ -116,7 +116,8 @@ struct qcom_smem_state *qcom_smem_state_
+
+ if (args.args_count != 1) {
+ dev_err(dev, "invalid #qcom,smem-state-cells\n");
+- return ERR_PTR(-EINVAL);
++ state = ERR_PTR(-EINVAL);
++ goto put;
+ }
+
+ state = of_node_to_state(args.np);
--- /dev/null
+From eca836dfd8386b32f1aae60f8e323218ac6a0b75 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Sat, 4 Jan 2025 14:56:05 +0100
+Subject: soc: samsung: exynos-pmu: Fix uninitialized ret in tensor_set_bits_atomic()
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit eca836dfd8386b32f1aae60f8e323218ac6a0b75 upstream.
+
+If tensor_set_bits_atomic() is called with a mask of 0 the function will
+just iterate over its bit, not perform any updates and return stack
+value of 'ret'.
+
+Also reported by smatch:
+
+ drivers/soc/samsung/exynos-pmu.c:129 tensor_set_bits_atomic() error: uninitialized symbol 'ret'.
+
+Fixes: 0b7c6075022c ("soc: samsung: exynos-pmu: Add regmap support for SoCs that protect PMU regs")
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20250104135605.109209-1-krzysztof.kozlowski@linaro.org
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/soc/samsung/exynos-pmu.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/soc/samsung/exynos-pmu.c
++++ b/drivers/soc/samsung/exynos-pmu.c
+@@ -126,7 +126,7 @@ static int tensor_set_bits_atomic(void *
+ if (ret)
+ return ret;
+ }
+- return ret;
++ return 0;
+ }
+
+ static bool tensor_is_atomic(unsigned int reg)
--- /dev/null
+From a3a860bc0fd6c07332e4911cf9a238d20de90173 Mon Sep 17 00:00:00 2001
+From: Jarkko Sakkinen <jarkko@kernel.org>
+Date: Fri, 27 Dec 2024 17:39:09 +0200
+Subject: tpm: Change to kvalloc() in eventlog/acpi.c
+
+From: Jarkko Sakkinen <jarkko@kernel.org>
+
+commit a3a860bc0fd6c07332e4911cf9a238d20de90173 upstream.
+
+The following failure was reported on HPE ProLiant D320:
+
+[ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0)
+[ 10.848132][ T1] ------------[ cut here ]------------
+[ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330
+[ 10.862827][ T1] Modules linked in:
+[ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375
+[ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024
+[ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330
+[ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1
+[ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246
+[ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000
+[ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0
+
+The above transcript shows that ACPI pointed a 16 MiB buffer for the log
+events because RSI maps to the 'order' parameter of __alloc_pages_noprof().
+Address the bug by moving from devm_kmalloc() to devm_add_action() and
+kvmalloc() and devm_add_action().
+
+Suggested-by: Ard Biesheuvel <ardb@kernel.org>
+Cc: stable@vger.kernel.org # v2.6.16+
+Fixes: 55a82ab3181b ("[PATCH] tpm: add bios measurement log")
+Reported-by: Andy Liang <andy.liang@hpe.com>
+Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219495
+Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
+Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
+Reviewed-by: Takashi Iwai <tiwai@suse.de>
+Tested-by: Andy Liang <andy.liang@hpe.com>
+Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/char/tpm/eventlog/acpi.c | 15 +++++++++++++--
+ 1 file changed, 13 insertions(+), 2 deletions(-)
+
+--- a/drivers/char/tpm/eventlog/acpi.c
++++ b/drivers/char/tpm/eventlog/acpi.c
+@@ -63,6 +63,11 @@ static bool tpm_is_tpm2_log(void *bios_e
+ return n == 0;
+ }
+
++static void tpm_bios_log_free(void *data)
++{
++ kvfree(data);
++}
++
+ /* read binary bios log */
+ int tpm_read_log_acpi(struct tpm_chip *chip)
+ {
+@@ -136,7 +141,7 @@ int tpm_read_log_acpi(struct tpm_chip *c
+ }
+
+ /* malloc EventLog space */
+- log->bios_event_log = devm_kmalloc(&chip->dev, len, GFP_KERNEL);
++ log->bios_event_log = kvmalloc(len, GFP_KERNEL);
+ if (!log->bios_event_log)
+ return -ENOMEM;
+
+@@ -161,10 +166,16 @@ int tpm_read_log_acpi(struct tpm_chip *c
+ goto err;
+ }
+
++ ret = devm_add_action(&chip->dev, tpm_bios_log_free, log->bios_event_log);
++ if (ret) {
++ log->bios_event_log = NULL;
++ goto err;
++ }
++
+ return format;
+
+ err:
+- devm_kfree(&chip->dev, log->bios_event_log);
++ tpm_bios_log_free(log->bios_event_log);
+ log->bios_event_log = NULL;
+ return ret;
+ }
--- /dev/null
+From 97bbf9e312c3fbaf0baa56120238825d2eb23b8a Mon Sep 17 00:00:00 2001
+From: Denis Arefev <arefev@swemel.ru>
+Date: Mon, 2 Dec 2024 12:36:52 +0300
+Subject: ubi: Add a check for ubi_num
+
+From: Denis Arefev <arefev@swemel.ru>
+
+commit 97bbf9e312c3fbaf0baa56120238825d2eb23b8a upstream.
+
+Added a check for ubi_num for negative numbers
+If the variable ubi_num takes negative values then we get:
+
+qemu-system-arm ... -append "ubi.mtd=0,0,0,-22222345" ...
+[ 0.745065] ubi_attach_mtd_dev from ubi_init+0x178/0x218
+[ 0.745230] ubi_init from do_one_initcall+0x70/0x1ac
+[ 0.745344] do_one_initcall from kernel_init_freeable+0x198/0x224
+[ 0.745474] kernel_init_freeable from kernel_init+0x18/0x134
+[ 0.745600] kernel_init from ret_from_fork+0x14/0x28
+[ 0.745727] Exception stack(0x90015fb0 to 0x90015ff8)
+
+Found by Linux Verification Center (linuxtesting.org) with SVACE.
+
+Fixes: 83ff59a06663 ("UBI: support ubi_num on mtd.ubi command line")
+Cc: stable@vger.kernel.org
+Signed-off-by: Denis Arefev <arefev@swemel.ru>
+Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/ubi/build.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/mtd/ubi/build.c
++++ b/drivers/mtd/ubi/build.c
+@@ -1537,7 +1537,7 @@ static int ubi_mtd_param_parse(const cha
+ if (token) {
+ int err = kstrtoint(token, 10, &p->ubi_num);
+
+- if (err) {
++ if (err || p->ubi_num < UBI_DEV_NUM_AUTO) {
+ pr_err("UBI error: bad value for ubi_num parameter: %s\n",
+ token);
+ return -EINVAL;
--- /dev/null
+From 0141978ae75bd48bac13fca6de131a5071c32011 Mon Sep 17 00:00:00 2001
+From: Zhang Rui <rui.zhang@intel.com>
+Date: Fri, 17 Jan 2025 16:14:20 +0800
+Subject: x86/acpi: Fix LAPIC/x2APIC parsing order
+
+From: Zhang Rui <rui.zhang@intel.com>
+
+commit 0141978ae75bd48bac13fca6de131a5071c32011 upstream.
+
+On some systems, the same CPU (with the same APIC ID) is assigned a
+different logical CPU id after commit ec9aedb2aa1a ("x86/acpi: Ignore
+invalid x2APIC entries").
+
+This means that Linux enumerates the CPUs in a different order, which
+violates ACPI specification[1] that states:
+
+ "OSPM should initialize processors in the order that they appear in
+ the MADT"
+
+The problematic commit parses all LAPIC entries before any x2APIC
+entries, aiming to ignore x2APIC entries with APIC ID < 255 when valid
+LAPIC entries exist. However, it disrupts the CPU enumeration order on
+systems where x2APIC entries precede LAPIC entries in the MADT.
+
+Fix this problem by:
+
+ 1) Parsing LAPIC entries first without registering them in the
+ topology to evaluate whether valid LAPIC entries exist.
+
+ 2) Restoring the MADT in order parser which invokes either the LAPIC
+ or the X2APIC parser function depending on the entry type.
+
+The X2APIC parser still ignores entries < 0xff in case that #1 found
+valid LAPIC entries independent of their position in the MADT table.
+
+Link: https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model.html#madt-processor-local-apic-sapic-structure-entry-order
+Cc: All applicable <stable@vger.kernel.org>
+Reported-by: Jim Mattson <jmattson@google.com>
+Closes: https://lore.kernel.org/all/20241010213136.668672-1-jmattson@google.com/
+Fixes: ec9aedb2aa1a ("x86/acpi: Ignore invalid x2APIC entries")
+Signed-off-by: Zhang Rui <rui.zhang@intel.com>
+Reviewed-by: Jim Mattson <jmattson@google.com>
+Tested-by: Jim Mattson <jmattson@google.com>
+Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
+Link: https://patch.msgid.link/20250117081420.4046737-1-rui.zhang@intel.com
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/acpi/boot.c | 50 +++++++++++++++++++++++++++++++++++++++-----
+ 1 file changed, 45 insertions(+), 5 deletions(-)
+
+--- a/arch/x86/kernel/acpi/boot.c
++++ b/arch/x86/kernel/acpi/boot.c
+@@ -227,6 +227,28 @@ acpi_parse_x2apic(union acpi_subtable_he
+ }
+
+ static int __init
++acpi_check_lapic(union acpi_subtable_headers *header, const unsigned long end)
++{
++ struct acpi_madt_local_apic *processor = NULL;
++
++ processor = (struct acpi_madt_local_apic *)header;
++
++ if (BAD_MADT_ENTRY(processor, end))
++ return -EINVAL;
++
++ /* Ignore invalid ID */
++ if (processor->id == 0xff)
++ return 0;
++
++ /* Ignore processors that can not be onlined */
++ if (!acpi_is_processor_usable(processor->lapic_flags))
++ return 0;
++
++ has_lapic_cpus = true;
++ return 0;
++}
++
++static int __init
+ acpi_parse_lapic(union acpi_subtable_headers * header, const unsigned long end)
+ {
+ struct acpi_madt_local_apic *processor = NULL;
+@@ -257,7 +279,6 @@ acpi_parse_lapic(union acpi_subtable_hea
+ processor->processor_id, /* ACPI ID */
+ processor->lapic_flags & ACPI_MADT_ENABLED);
+
+- has_lapic_cpus = true;
+ return 0;
+ }
+
+@@ -1029,6 +1050,8 @@ static int __init early_acpi_parse_madt_
+ static int __init acpi_parse_madt_lapic_entries(void)
+ {
+ int count, x2count = 0;
++ struct acpi_subtable_proc madt_proc[2];
++ int ret;
+
+ if (!boot_cpu_has(X86_FEATURE_APIC))
+ return -ENODEV;
+@@ -1037,10 +1060,27 @@ static int __init acpi_parse_madt_lapic_
+ acpi_parse_sapic, MAX_LOCAL_APIC);
+
+ if (!count) {
+- count = acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_APIC,
+- acpi_parse_lapic, MAX_LOCAL_APIC);
+- x2count = acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_X2APIC,
+- acpi_parse_x2apic, MAX_LOCAL_APIC);
++ /* Check if there are valid LAPIC entries */
++ acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_APIC, acpi_check_lapic, MAX_LOCAL_APIC);
++
++ /*
++ * Enumerate the APIC IDs in the order that they appear in the
++ * MADT, no matter LAPIC entry or x2APIC entry is used.
++ */
++ memset(madt_proc, 0, sizeof(madt_proc));
++ madt_proc[0].id = ACPI_MADT_TYPE_LOCAL_APIC;
++ madt_proc[0].handler = acpi_parse_lapic;
++ madt_proc[1].id = ACPI_MADT_TYPE_LOCAL_X2APIC;
++ madt_proc[1].handler = acpi_parse_x2apic;
++ ret = acpi_table_parse_entries_array(ACPI_SIG_MADT,
++ sizeof(struct acpi_table_madt),
++ madt_proc, ARRAY_SIZE(madt_proc), MAX_LOCAL_APIC);
++ if (ret < 0) {
++ pr_err("Error parsing LAPIC/X2APIC entries\n");
++ return ret;
++ }
++ count = madt_proc[0].count;
++ x2count = madt_proc[1].count;
+ }
+ if (!count && !x2count) {
+ pr_err("No LAPIC entries present\n");
--- /dev/null
+From ee2ab467bddfb2d7f68d996dbab94d7b88f8eaf7 Mon Sep 17 00:00:00 2001
+From: Nathan Chancellor <nathan@kernel.org>
+Date: Tue, 21 Jan 2025 18:11:33 -0700
+Subject: x86/boot: Use '-std=gnu11' to fix build with GCC 15
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Nathan Chancellor <nathan@kernel.org>
+
+commit ee2ab467bddfb2d7f68d996dbab94d7b88f8eaf7 upstream.
+
+GCC 15 changed the default C standard version to C23, which should not
+have impacted the kernel because it requests the gnu11 standard via
+'-std=' in the main Makefile. However, the x86 compressed boot Makefile
+uses its own set of KBUILD_CFLAGS without a '-std=' value (i.e., using
+the default), resulting in errors from the kernel's definitions of bool,
+true, and false in stddef.h, which are reserved keywords under C23.
+
+ ./include/linux/stddef.h:11:9: error: expected identifier before ‘false’
+ 11 | false = 0,
+ ./include/linux/types.h:35:33: error: two or more data types in declaration specifiers
+ 35 | typedef _Bool bool;
+
+Set '-std=gnu11' in the x86 compressed boot Makefile to resolve the
+error and consistently use the same C standard version for the entire
+kernel.
+
+Closes: https://lore.kernel.org/4OAhbllK7x4QJGpZjkYjtBYNLd_2whHx9oFiuZcGwtVR4hIzvduultkgfAIRZI3vQpZylu7Gl929HaYFRGeMEalWCpeMzCIIhLxxRhq4U-Y=@protonmail.com/
+Closes: https://lore.kernel.org/Z4467umXR2PZ0M1H@tucnak/
+Reported-by: Kostadin Shishmanov <kostadinshishmanov@protonmail.com>
+Reported-by: Jakub Jelinek <jakub@redhat.com>
+Signed-off-by: Nathan Chancellor <nathan@kernel.org>
+Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
+Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
+Cc:stable@vger.kernel.org
+Link: https://lore.kernel.org/all/20250121-x86-use-std-consistently-gcc-15-v1-1-8ab0acf645cb%40kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/boot/compressed/Makefile | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/x86/boot/compressed/Makefile
++++ b/arch/x86/boot/compressed/Makefile
+@@ -25,6 +25,7 @@ targets := vmlinux vmlinux.bin vmlinux.b
+ # avoid errors with '-march=i386', and future flags may depend on the target to
+ # be valid.
+ KBUILD_CFLAGS := -m$(BITS) -O2 $(CLANG_FLAGS)
++KBUILD_CFLAGS += -std=gnu11
+ KBUILD_CFLAGS += -fno-strict-aliasing -fPIE
+ KBUILD_CFLAGS += -Wundef
+ KBUILD_CFLAGS += -DDISABLE_BRANCH_PROFILING
--- /dev/null
+From 6273a058383e05465083b535ed9469f2c8a48321 Mon Sep 17 00:00:00 2001
+From: Alice Ryhl <aliceryhl@google.com>
+Date: Mon, 3 Feb 2025 08:40:57 +0000
+Subject: x86: rust: set rustc-abi=x86-softfloat on rustc>=1.86.0
+
+From: Alice Ryhl <aliceryhl@google.com>
+
+commit 6273a058383e05465083b535ed9469f2c8a48321 upstream.
+
+When using Rust on the x86 architecture, we are currently using the
+unstable target.json feature to specify the compilation target. Rustc is
+going to change how softfloat is specified in the target.json file on
+x86, thus update generate_rust_target.rs to specify softfloat using the
+new option.
+
+Note that if you enable this parameter with a compiler that does not
+recognize it, then that triggers a warning but it does not break the
+build.
+
+[ For future reference, this solves the following error:
+
+ RUSTC L rust/core.o
+ error: Error loading target specification: target feature
+ `soft-float` is incompatible with the ABI but gets enabled in
+ target spec. Run `rustc --print target-list` for a list of
+ built-in targets
+
+ - Miguel ]
+
+Cc: <stable@vger.kernel.org> # Needed in 6.12.y and 6.13.y only (Rust is pinned in older LTSs).
+Link: https://github.com/rust-lang/rust/pull/136146
+Signed-off-by: Alice Ryhl <aliceryhl@google.com>
+Acked-by: Dave Hansen <dave.hansen@linux.intel.com> # for x86
+Link: https://lore.kernel.org/r/20250203-rustc-1-86-x86-softfloat-v1-1-220a72a5003e@google.com
+[ Added 6.13.y too to Cc: stable tag and added reasoning to avoid
+ over-backporting. - Miguel ]
+Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ scripts/generate_rust_target.rs | 18 ++++++++++++++++++
+ 1 file changed, 18 insertions(+)
+
+diff --git a/scripts/generate_rust_target.rs b/scripts/generate_rust_target.rs
+index 0d00ac3723b5..4fd6b6ab3e32 100644
+--- a/scripts/generate_rust_target.rs
++++ b/scripts/generate_rust_target.rs
+@@ -165,6 +165,18 @@ fn has(&self, option: &str) -> bool {
+ let option = "CONFIG_".to_owned() + option;
+ self.0.contains_key(&option)
+ }
++
++ /// Is the rustc version at least `major.minor.patch`?
++ fn rustc_version_atleast(&self, major: u32, minor: u32, patch: u32) -> bool {
++ let check_version = 100000 * major + 100 * minor + patch;
++ let actual_version = self
++ .0
++ .get("CONFIG_RUSTC_VERSION")
++ .unwrap()
++ .parse::<u32>()
++ .unwrap();
++ check_version <= actual_version
++ }
+ }
+
+ fn main() {
+@@ -182,6 +194,9 @@ fn main() {
+ }
+ } else if cfg.has("X86_64") {
+ ts.push("arch", "x86_64");
++ if cfg.rustc_version_atleast(1, 86, 0) {
++ ts.push("rustc-abi", "x86-softfloat");
++ }
+ ts.push(
+ "data-layout",
+ "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128",
+@@ -215,6 +230,9 @@ fn main() {
+ panic!("32-bit x86 only works under UML");
+ }
+ ts.push("arch", "x86");
++ if cfg.rustc_version_atleast(1, 86, 0) {
++ ts.push("rustc-abi", "x86-softfloat");
++ }
+ ts.push(
+ "data-layout",
+ "e-m:e-p:32:32-p270:32:32-p271:32:32-p272:64:64-i128:128-f64:32:64-f80:32-n8:16:32-S128",
+--
+2.48.1
+
--- /dev/null
+From 26b63bee2f6e711c5a169997fd126fddcfb90848 Mon Sep 17 00:00:00 2001
+From: Wentao Liang <vulab@iscas.ac.cn>
+Date: Fri, 24 Jan 2025 11:45:09 +0800
+Subject: xfs: Add error handling for xfs_reflink_cancel_cow_range
+
+From: Wentao Liang <vulab@iscas.ac.cn>
+
+commit 26b63bee2f6e711c5a169997fd126fddcfb90848 upstream.
+
+In xfs_inactive(), xfs_reflink_cancel_cow_range() is called
+without error handling, risking unnoticed failures and
+inconsistent behavior compared to other parts of the code.
+
+Fix this issue by adding an error handling for the
+xfs_reflink_cancel_cow_range(), improving code robustness.
+
+Fixes: 6231848c3aa5 ("xfs: check for cow blocks before trying to clear them")
+Cc: stable@vger.kernel.org # v4.17
+Reviewed-by: Darrick J. Wong <djwong@kernel.org>
+Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
+Signed-off-by: Carlos Maiolino <cem@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/xfs/xfs_inode.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/fs/xfs/xfs_inode.c
++++ b/fs/xfs/xfs_inode.c
+@@ -1392,8 +1392,11 @@ xfs_inactive(
+ goto out;
+
+ /* Try to clean out the cow blocks if there are any. */
+- if (xfs_inode_has_cow_data(ip))
+- xfs_reflink_cancel_cow_range(ip, 0, NULLFILEOFF, true);
++ if (xfs_inode_has_cow_data(ip)) {
++ error = xfs_reflink_cancel_cow_range(ip, 0, NULLFILEOFF, true);
++ if (error)
++ goto out;
++ }
+
+ if (VFS_I(ip)->i_nlink != 0) {
+ /*
--- /dev/null
+From f5f0ed89f13e3e5246404a322ee85169a226bfb5 Mon Sep 17 00:00:00 2001
+From: Christoph Hellwig <hch@lst.de>
+Date: Wed, 22 Jan 2025 06:43:21 +0100
+Subject: xfs: don't call remap_verify_area with sb write protection held
+
+From: Christoph Hellwig <hch@lst.de>
+
+commit f5f0ed89f13e3e5246404a322ee85169a226bfb5 upstream.
+
+The XFS_IOC_EXCHANGE_RANGE ioctl with the XFS_EXCHANGE_RANGE_TO_EOF flag
+operates on a range bounded by the end of the file. This means the
+actual amount of blocks exchanged is derived from the inode size, which
+is only stable with the IOLOCK (i_rwsem) held. Do that, it currently
+calls remap_verify_area from inside the sb write protection which nests
+outside the IOLOCK. But this makes fsnotify_file_area_perm which is
+called from remap_verify_area unhappy when the kernel is built with
+lockdep and the recently added CONFIG_FANOTIFY_ACCESS_PERMISSIONS
+option.
+
+Fix this by always calling remap_verify_area before taking the write
+protection, and passing a 0 size to remap_verify_area similar to
+the FICLONE/FICLONERANGE ioctls when they are asked to clone until
+the file end.
+
+(Note: the size argument gets passed to fsnotify_file_area_perm, but
+then isn't actually used there).
+
+Fixes: 9a64d9b3109d ("xfs: introduce new file range exchange ioctl")
+Cc: <stable@vger.kernel.org> # v6.10
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Reviewed-by: Darrick J. Wong <djwong@kernel.org>
+Signed-off-by: Carlos Maiolino <cem@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/xfs/xfs_exchrange.c | 71 ++++++++++++++++++-------------------------------
+ 1 file changed, 27 insertions(+), 44 deletions(-)
+
+--- a/fs/xfs/xfs_exchrange.c
++++ b/fs/xfs/xfs_exchrange.c
+@@ -326,22 +326,6 @@ out_trans_cancel:
+ * successfully but before locks are dropped.
+ */
+
+-/* Verify that we have security clearance to perform this operation. */
+-static int
+-xfs_exchange_range_verify_area(
+- struct xfs_exchrange *fxr)
+-{
+- int ret;
+-
+- ret = remap_verify_area(fxr->file1, fxr->file1_offset, fxr->length,
+- true);
+- if (ret)
+- return ret;
+-
+- return remap_verify_area(fxr->file2, fxr->file2_offset, fxr->length,
+- true);
+-}
+-
+ /*
+ * Performs necessary checks before doing a range exchange, having stabilized
+ * mutable inode attributes via i_rwsem.
+@@ -352,11 +336,13 @@ xfs_exchange_range_checks(
+ unsigned int alloc_unit)
+ {
+ struct inode *inode1 = file_inode(fxr->file1);
++ loff_t size1 = i_size_read(inode1);
+ struct inode *inode2 = file_inode(fxr->file2);
++ loff_t size2 = i_size_read(inode2);
+ uint64_t allocmask = alloc_unit - 1;
+ int64_t test_len;
+ uint64_t blen;
+- loff_t size1, size2, tmp;
++ loff_t tmp;
+ int error;
+
+ /* Don't touch certain kinds of inodes */
+@@ -365,24 +351,25 @@ xfs_exchange_range_checks(
+ if (IS_SWAPFILE(inode1) || IS_SWAPFILE(inode2))
+ return -ETXTBSY;
+
+- size1 = i_size_read(inode1);
+- size2 = i_size_read(inode2);
+-
+ /* Ranges cannot start after EOF. */
+ if (fxr->file1_offset > size1 || fxr->file2_offset > size2)
+ return -EINVAL;
+
+- /*
+- * If the caller said to exchange to EOF, we set the length of the
+- * request large enough to cover everything to the end of both files.
+- */
+ if (fxr->flags & XFS_EXCHANGE_RANGE_TO_EOF) {
++ /*
++ * If the caller said to exchange to EOF, we set the length of
++ * the request large enough to cover everything to the end of
++ * both files.
++ */
+ fxr->length = max_t(int64_t, size1 - fxr->file1_offset,
+ size2 - fxr->file2_offset);
+-
+- error = xfs_exchange_range_verify_area(fxr);
+- if (error)
+- return error;
++ } else {
++ /*
++ * Otherwise we require both ranges to end within EOF.
++ */
++ if (fxr->file1_offset + fxr->length > size1 ||
++ fxr->file2_offset + fxr->length > size2)
++ return -EINVAL;
+ }
+
+ /*
+@@ -399,15 +386,6 @@ xfs_exchange_range_checks(
+ return -EINVAL;
+
+ /*
+- * We require both ranges to end within EOF, unless we're exchanging
+- * to EOF.
+- */
+- if (!(fxr->flags & XFS_EXCHANGE_RANGE_TO_EOF) &&
+- (fxr->file1_offset + fxr->length > size1 ||
+- fxr->file2_offset + fxr->length > size2))
+- return -EINVAL;
+-
+- /*
+ * Make sure we don't hit any file size limits. If we hit any size
+ * limits such that test_length was adjusted, we abort the whole
+ * operation.
+@@ -744,6 +722,7 @@ xfs_exchange_range(
+ {
+ struct inode *inode1 = file_inode(fxr->file1);
+ struct inode *inode2 = file_inode(fxr->file2);
++ loff_t check_len = fxr->length;
+ int ret;
+
+ BUILD_BUG_ON(XFS_EXCHANGE_RANGE_ALL_FLAGS &
+@@ -776,14 +755,18 @@ xfs_exchange_range(
+ return -EBADF;
+
+ /*
+- * If we're not exchanging to EOF, we can check the areas before
+- * stabilizing both files' i_size.
++ * If we're exchanging to EOF we can't calculate the length until taking
++ * the iolock. Pass a 0 length to remap_verify_area similar to the
++ * FICLONE and FICLONERANGE ioctls that support cloning to EOF as well.
+ */
+- if (!(fxr->flags & XFS_EXCHANGE_RANGE_TO_EOF)) {
+- ret = xfs_exchange_range_verify_area(fxr);
+- if (ret)
+- return ret;
+- }
++ if (fxr->flags & XFS_EXCHANGE_RANGE_TO_EOF)
++ check_len = 0;
++ ret = remap_verify_area(fxr->file1, fxr->file1_offset, check_len, true);
++ if (ret)
++ return ret;
++ ret = remap_verify_area(fxr->file2, fxr->file2_offset, check_len, true);
++ if (ret)
++ return ret;
+
+ /* Update cmtime if the fd/inode don't forbid it. */
+ if (!(fxr->file1->f_mode & FMODE_NOCMTIME) && !IS_NOCMTIME(inode1))
--- /dev/null
+From fb95897b8c60653805aa09daec575ca30983f768 Mon Sep 17 00:00:00 2001
+From: Wentao Liang <vulab@iscas.ac.cn>
+Date: Fri, 24 Jan 2025 11:22:28 +0800
+Subject: xfs: Propagate errors from xfs_reflink_cancel_cow_range in xfs_dax_write_iomap_end
+
+From: Wentao Liang <vulab@iscas.ac.cn>
+
+commit fb95897b8c60653805aa09daec575ca30983f768 upstream.
+
+In xfs_dax_write_iomap_end(), directly return the result of
+xfs_reflink_cancel_cow_range() when !written, ensuring proper
+error propagation and improving code robustness.
+
+Fixes: ea6c49b784f0 ("xfs: support CoW in fsdax mode")
+Cc: stable@vger.kernel.org # v6.0
+Reviewed-by: Darrick J. Wong <djwong@kernel.org>
+Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
+Signed-off-by: Carlos Maiolino <cem@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/xfs/xfs_iomap.c | 6 ++----
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+--- a/fs/xfs/xfs_iomap.c
++++ b/fs/xfs/xfs_iomap.c
+@@ -942,10 +942,8 @@ xfs_dax_write_iomap_end(
+ if (!xfs_is_cow_inode(ip))
+ return 0;
+
+- if (!written) {
+- xfs_reflink_cancel_cow_range(ip, pos, length, true);
+- return 0;
+- }
++ if (!written)
++ return xfs_reflink_cancel_cow_range(ip, pos, length, true);
+
+ return xfs_reflink_end_cow(ip, pos, written);
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
