From: Greg Kroah-Hartman Date: Mon, 10 Feb 2025 15:38:34 +0000 (+0100) Subject: 6.12-stable patches X-Git-Tag: v6.6.77~4 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=ba339d2097d05f91d0d52f38587ca52b7eb1a60f;p=thirdparty%2Fkernel%2Fstable-queue.git 6.12-stable patches added patches: accel-ivpu-clear-runtime_error-after-pm_runtime_resume_and_get-fails.patch acpi-prm-remove-unnecessary-strict-handler-address-checks.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-sm6115-fix-adsp-memory-base-and-length.patch arm64-dts-qcom-sm6115-fix-cdsp-memory-length.patch arm64-dts-qcom-sm6115-fix-mpss-memory-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-correct-mdss-interconnects.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-correct-mdss-interconnects.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-x1e80100-fix-adsp-memory-base-and-length.patch arm64-dts-qcom-x1e80100-fix-cdsp-memory-length.patch arm64-tegra-disable-tegra234-sce-fabric-node.patch arm64-tegra-fix-typo-in-tegra234-dce-fabric-compatible.patch crypto-qce-fix-priority-to-be-less-than-armv8-ce.patch hrtimers-force-migrate-away-hrtimers-queued-after-cpuhp_ap_hrtimers_dying.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 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 media-ccs-fix-ccs-static-data-parsing-for-large-block-sizes.patch media-ccs-fix-cleanup-order-in-ccs_probe.patch media-i2c-ds90ub960-fix-logging-sp-eq-status-only-for-ub9702.patch media-i2c-ds90ub960-fix-ub9702-vc-map.patch media-i2c-ds90ub960-fix-use-of-non-existing-registers-on-ub9702.patch media-i2c-ds90ub9x3-fix-extra-fwnode_handle_put.patch media-imx296-add-standby-delay-during-probe.patch media-intel-ipu6-remove-cpu-latency-qos-request-on-error.patch media-mc-fix-endpoint-iteration.patch media-mmp-bring-back-registration-of-the-device.patch media-nuvoton-fix-an-error-check-in-npcm_video_ece_init.patch media-ov5640-fix-get_light_freq-on-auto.patch media-stm32-dcmipp-correct-dma_set_mask_and_coherent-mask-value.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-only-save-async-fh-if-success.patch media-uvcvideo-remove-dangling-pointers.patch media-uvcvideo-remove-redundant-null-assignment.patch media-uvcvideo-support-partial-control-reads.patch mm-compaction-fix-ubsan-shift-out-of-bounds-warning.patch mm-gup-fix-infinite-loop-within-__get_longterm_locked.patch mm-hugetlb-fix-avoid_reserve-to-allow-taking-folio-from-subpool.patch mm-hugetlb-fix-hugepage-allocation-for-interleaved-memory-nodes.patch mm-kmemleak-fix-upper-boundary-check-for-physical-address-objects.patch mm-vmscan-accumulate-nr_demoted-for-accurate-demotion-statistics.patch parisc-temporarily-disable-jump-label-support.patch pwm-microchip-core-fix-incorrect-comparison-with-max-period.patch rust-init-use-explicit-abi-to-clean-warning-in-future-compilers.patch rv-reset-per-task-monitors-also-for-idle-tasks.patch soc-mediatek-mtk-devapc-fix-leaking-io-map-on-driver-remove.patch soc-mediatek-mtk-devapc-fix-leaking-io-map-on-error-paths.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 soc-samsung-exynos-pmu-fix-uninitialized-ret-in-tensor_set_bits_atomic.patch tpm-change-to-kvalloc-in-eventlog-acpi.c.patch ubi-add-a-check-for-ubi_num.patch x86-acpi-fix-lapic-x2apic-parsing-order.patch x86-boot-use-std-gnu11-to-fix-build-with-gcc-15.patch x86-rust-set-rustc-abi-x86-softfloat-on-rustc-1.86.0.patch xfs-add-error-handling-for-xfs_reflink_cancel_cow_range.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 --- diff --git a/queue-6.12/accel-ivpu-clear-runtime_error-after-pm_runtime_resume_and_get-fails.patch b/queue-6.12/accel-ivpu-clear-runtime_error-after-pm_runtime_resume_and_get-fails.patch new file mode 100644 index 0000000000..1a6d7e2812 --- /dev/null +++ b/queue-6.12/accel-ivpu-clear-runtime_error-after-pm_runtime_resume_and_get-fails.patch @@ -0,0 +1,40 @@ +From f2bc2afe34c107a02ce829a4039e85514feafe55 Mon Sep 17 00:00:00 2001 +From: Jacek Lawrynowicz +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 + +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 +Reviewed-by: Jeffrey Hugo +Signed-off-by: Jacek Lawrynowicz +Link: https://patchwork.freedesktop.org/patch/msgid/20250129124009.1039982-3-jacek.lawrynowicz@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-6.12/acpi-prm-remove-unnecessary-strict-handler-address-checks.patch b/queue-6.12/acpi-prm-remove-unnecessary-strict-handler-address-checks.patch new file mode 100644 index 0000000000..b7d1ba1538 --- /dev/null +++ b/queue-6.12/acpi-prm-remove-unnecessary-strict-handler-address-checks.patch @@ -0,0 +1,65 @@ +From 7f5704b6a143b8eca640cba820968e798d065e91 Mon Sep 17 00:00:00 2001 +From: Aubrey Li +Date: Sun, 26 Jan 2025 10:22:50 +0800 +Subject: ACPI: PRM: Remove unnecessary strict handler address checks + +From: Aubrey Li + +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 +Cc: All applicable +Signed-off-by: Aubrey Li +Link: https://uefi.org/sites/default/files/resources/Platform%20Runtime%20Mechanism%20-%20with%20legal%20notice.pdf # [1] +Reviewed-by: Koba Ko +Acked-by: Ard Biesheuvel +Link: https://patch.msgid.link/20250126022250.3014210-1-aubrey.li@linux.intel.com +[ rjw: Minor changelog edits ] +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-6.12/arm-dts-dra7-add-bus_dma_limit-for-l4-cfg-bus.patch b/queue-6.12/arm-dts-dra7-add-bus_dma_limit-for-l4-cfg-bus.patch new file mode 100644 index 0000000000..e7bf0051df --- /dev/null +++ b/queue-6.12/arm-dts-dra7-add-bus_dma_limit-for-l4-cfg-bus.patch @@ -0,0 +1,54 @@ +From c1472ec1dc4419d0bae663c1a1e6cb98dc7881ad Mon Sep 17 00:00:00 2001 +From: Romain Naour +Date: Fri, 15 Nov 2024 11:25:37 +0100 +Subject: ARM: dts: dra7: Add bus_dma_limit for l4 cfg bus + +From: Romain Naour + +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 +Link: https://lore.kernel.org/r/20241115102537.1330300-1-romain.naour@smile.fr +Signed-off-by: Kevin Hilman +Signed-off-by: Greg Kroah-Hartman +--- + 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"; diff --git a/queue-6.12/arm-dts-ti-omap-gta04-fix-pm-issues-caused-by-spi-module.patch b/queue-6.12/arm-dts-ti-omap-gta04-fix-pm-issues-caused-by-spi-module.patch new file mode 100644 index 0000000000..27e571adaf --- /dev/null +++ b/queue-6.12/arm-dts-ti-omap-gta04-fix-pm-issues-caused-by-spi-module.patch @@ -0,0 +1,62 @@ +From 0cfbd7805fe13406500e6a6f2aa08f198d5db4bd Mon Sep 17 00:00:00 2001 +From: Andreas Kemnade +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 + +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 +Reviewed-by: Roger Quadros +Link: https://lore.kernel.org/r/20241204174152.2360431-1-andreas@kemnade.info +Signed-off-by: Kevin Hilman +Signed-off-by: Greg Kroah-Hartman +--- + 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 */ diff --git a/queue-6.12/arm64-dts-mediatek-mt8183-disable-dpi-display-output-by-default.patch b/queue-6.12/arm64-dts-mediatek-mt8183-disable-dpi-display-output-by-default.patch new file mode 100644 index 0000000000..f0d004d857 --- /dev/null +++ b/queue-6.12/arm64-dts-mediatek-mt8183-disable-dpi-display-output-by-default.patch @@ -0,0 +1,57 @@ +From 93a680af46436780fd64f4e856a4cfa8b393be6e Mon Sep 17 00:00:00 2001 +From: Chen-Yu Tsai +Date: Fri, 25 Oct 2024 15:56:27 +0800 +Subject: arm64: dts: mediatek: mt8183: Disable DPI display output by default + +From: Chen-Yu Tsai + +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 +Reviewed-by: Fei Shao +Link: https://lore.kernel.org/r/20241025075630.3917458-1-wenst@chromium.org +Signed-off-by: AngeloGioacchino Del Regno +Signed-off-by: Greg Kroah-Hartman +--- + 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 { }; diff --git a/queue-6.12/arm64-dts-qcom-sdx75-fix-mpss-memory-length.patch b/queue-6.12/arm64-dts-qcom-sdx75-fix-mpss-memory-length.patch new file mode 100644 index 0000000000..1efa6e81ea --- /dev/null +++ b/queue-6.12/arm64-dts-qcom-sdx75-fix-mpss-memory-length.patch @@ -0,0 +1,44 @@ +From 9a27f0e1869e992e4107e2af8ec348e1a3b9d4d5 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Fri, 13 Dec 2024 15:54:09 +0100 +Subject: arm64: dts: qcom: sdx75: Fix MPSS memory length + +From: Krzysztof Kozlowski + +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 +Reviewed-by: Konrad Dybcio +Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-20-2e0036fccd8d@linaro.org +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + 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 + diff --git a/queue-6.12/arm64-dts-qcom-sm6115-fix-adsp-memory-base-and-length.patch b/queue-6.12/arm64-dts-qcom-sm6115-fix-adsp-memory-base-and-length.patch new file mode 100644 index 0000000000..721cdbca35 --- /dev/null +++ b/queue-6.12/arm64-dts-qcom-sm6115-fix-adsp-memory-base-and-length.patch @@ -0,0 +1,45 @@ +From 47d178caac3ec13f5f472afda25fcfdfaa00d0da Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Fri, 13 Dec 2024 15:54:12 +0100 +Subject: arm64: dts: qcom: sm6115: Fix ADSP memory base and length + +From: Krzysztof Kozlowski + +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 +Reviewed-by: Konrad Dybcio +Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-23-2e0036fccd8d@linaro.org +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + 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>, diff --git a/queue-6.12/arm64-dts-qcom-sm6115-fix-cdsp-memory-length.patch b/queue-6.12/arm64-dts-qcom-sm6115-fix-cdsp-memory-length.patch new file mode 100644 index 0000000000..37b8255719 --- /dev/null +++ b/queue-6.12/arm64-dts-qcom-sm6115-fix-cdsp-memory-length.patch @@ -0,0 +1,39 @@ +From 846f49c3f01680f4af3043bf5b7abc9cf71bb42d Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Fri, 13 Dec 2024 15:54:11 +0100 +Subject: arm64: dts: qcom: sm6115: Fix CDSP memory length + +From: Krzysztof Kozlowski + +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 +Reviewed-by: Konrad Dybcio +Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-22-2e0036fccd8d@linaro.org +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + 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>, diff --git a/queue-6.12/arm64-dts-qcom-sm6115-fix-mpss-memory-length.patch b/queue-6.12/arm64-dts-qcom-sm6115-fix-mpss-memory-length.patch new file mode 100644 index 0000000000..7b4492dc2f --- /dev/null +++ b/queue-6.12/arm64-dts-qcom-sm6115-fix-mpss-memory-length.patch @@ -0,0 +1,39 @@ +From 472d65e7cb591c8379dd6f40561f96be73a46f0f Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Fri, 13 Dec 2024 15:54:10 +0100 +Subject: arm64: dts: qcom: sm6115: Fix MPSS memory length + +From: Krzysztof Kozlowski + +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 +Reviewed-by: Konrad Dybcio +Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-21-2e0036fccd8d@linaro.org +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + 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>, diff --git a/queue-6.12/arm64-dts-qcom-sm6350-fix-adsp-memory-length.patch b/queue-6.12/arm64-dts-qcom-sm6350-fix-adsp-memory-length.patch new file mode 100644 index 0000000000..f4bb4bba60 --- /dev/null +++ b/queue-6.12/arm64-dts-qcom-sm6350-fix-adsp-memory-length.patch @@ -0,0 +1,39 @@ +From b0805a864459a29831577d2a47165afebe338faf Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Fri, 13 Dec 2024 15:54:04 +0100 +Subject: arm64: dts: qcom: sm6350: Fix ADSP memory length + +From: Krzysztof Kozlowski + +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 +Reviewed-by: Konrad Dybcio +Signed-off-by: Krzysztof Kozlowski +Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-15-2e0036fccd8d@linaro.org +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + 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>, diff --git a/queue-6.12/arm64-dts-qcom-sm6350-fix-mpss-memory-length.patch b/queue-6.12/arm64-dts-qcom-sm6350-fix-mpss-memory-length.patch new file mode 100644 index 0000000000..6ed58a8ffa --- /dev/null +++ b/queue-6.12/arm64-dts-qcom-sm6350-fix-mpss-memory-length.patch @@ -0,0 +1,40 @@ +From cd8d83de9cc9ecfb1f9a12bc838041c4eb4d10bd Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Fri, 13 Dec 2024 15:54:05 +0100 +Subject: arm64: dts: qcom: sm6350: Fix MPSS memory length + +From: Krzysztof Kozlowski + +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 +Reviewed-by: Konrad Dybcio +Signed-off-by: Krzysztof Kozlowski +Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-16-2e0036fccd8d@linaro.org +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + 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>, diff --git a/queue-6.12/arm64-dts-qcom-sm6350-fix-uart1-interconnect-path.patch b/queue-6.12/arm64-dts-qcom-sm6350-fix-uart1-interconnect-path.patch new file mode 100644 index 0000000000..97803e7617 --- /dev/null +++ b/queue-6.12/arm64-dts-qcom-sm6350-fix-uart1-interconnect-path.patch @@ -0,0 +1,35 @@ +From be2f81eaa2c8e81d3de5b73dca5e133f63384cb3 Mon Sep 17 00:00:00 2001 +From: Luca Weiss +Date: Fri, 20 Dec 2024 09:59:50 +0100 +Subject: arm64: dts: qcom: sm6350: Fix uart1 interconnect path + +From: Luca Weiss + +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 +Reviewed-by: Konrad Dybcio +Link: https://lore.kernel.org/r/20241220-sm6350-uart1-icc-v1-1-f4f10fd91adf@fairphone.com +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + 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"; + }; diff --git a/queue-6.12/arm64-dts-qcom-sm6375-fix-adsp-memory-length.patch b/queue-6.12/arm64-dts-qcom-sm6375-fix-adsp-memory-length.patch new file mode 100644 index 0000000000..9c9af01ae6 --- /dev/null +++ b/queue-6.12/arm64-dts-qcom-sm6375-fix-adsp-memory-length.patch @@ -0,0 +1,38 @@ +From bf4dda83da27b7efc49326ebb82cbd8b3e637c38 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Fri, 13 Dec 2024 15:54:06 +0100 +Subject: arm64: dts: qcom: sm6375: Fix ADSP memory length + +From: Krzysztof Kozlowski + +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 +Reviewed-by: Konrad Dybcio +Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-17-2e0036fccd8d@linaro.org +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + 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>, diff --git a/queue-6.12/arm64-dts-qcom-sm6375-fix-cdsp-memory-base-and-length.patch b/queue-6.12/arm64-dts-qcom-sm6375-fix-cdsp-memory-base-and-length.patch new file mode 100644 index 0000000000..789cb0f7b7 --- /dev/null +++ b/queue-6.12/arm64-dts-qcom-sm6375-fix-cdsp-memory-base-and-length.patch @@ -0,0 +1,44 @@ +From c9f7f341e896836c99709421a23bae5f53039aab Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Fri, 13 Dec 2024 15:54:07 +0100 +Subject: arm64: dts: qcom: sm6375: Fix CDSP memory base and length + +From: Krzysztof Kozlowski + +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 +Reviewed-by: Konrad Dybcio +Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-18-2e0036fccd8d@linaro.org +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + 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>, diff --git a/queue-6.12/arm64-dts-qcom-sm6375-fix-mpss-memory-base-and-length.patch b/queue-6.12/arm64-dts-qcom-sm6375-fix-mpss-memory-base-and-length.patch new file mode 100644 index 0000000000..165673161e --- /dev/null +++ b/queue-6.12/arm64-dts-qcom-sm6375-fix-mpss-memory-base-and-length.patch @@ -0,0 +1,44 @@ +From 918e71ba0c08c3d609ad69067854b0f675c4a253 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Fri, 13 Dec 2024 15:54:08 +0100 +Subject: arm64: dts: qcom: sm6375: Fix MPSS memory base and length + +From: Krzysztof Kozlowski + +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 +Reviewed-by: Konrad Dybcio +Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-19-2e0036fccd8d@linaro.org +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + 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>, diff --git a/queue-6.12/arm64-dts-qcom-sm8350-fix-adsp-memory-base-and-length.patch b/queue-6.12/arm64-dts-qcom-sm8350-fix-adsp-memory-base-and-length.patch new file mode 100644 index 0000000000..76e026cde7 --- /dev/null +++ b/queue-6.12/arm64-dts-qcom-sm8350-fix-adsp-memory-base-and-length.patch @@ -0,0 +1,324 @@ +From f9ba85566ddd5a3db8fa291aaecd70c4e55a3732 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Fri, 13 Dec 2024 15:53:50 +0100 +Subject: arm64: dts: qcom: sm8350: Fix ADSP memory base and length + +From: Krzysztof Kozlowski + +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 +Signed-off-by: Krzysztof Kozlowski +Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-1-2e0036fccd8d@linaro.org +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + 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 = ; ++ #address-cells = <1>; ++ #size-cells = <0>; ++ ++ service@3 { ++ reg = ; ++ compatible = "qcom,q6core"; ++ qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd"; ++ }; ++ ++ q6afe: service@4 { ++ compatible = "qcom,q6afe"; ++ reg = ; ++ 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 = ; ++ 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 = ; ++ 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 @@ + ; + }; + +- 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 = ; +- #address-cells = <1>; +- #size-cells = <0>; +- +- service@3 { +- reg = ; +- compatible = "qcom,q6core"; +- qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd"; +- }; +- +- q6afe: service@4 { +- compatible = "qcom,q6afe"; +- reg = ; +- 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 = ; +- 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 = ; +- 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>; diff --git a/queue-6.12/arm64-dts-qcom-sm8350-fix-cdsp-memory-base-and-length.patch b/queue-6.12/arm64-dts-qcom-sm8350-fix-cdsp-memory-base-and-length.patch new file mode 100644 index 0000000000..1e1d98ea66 --- /dev/null +++ b/queue-6.12/arm64-dts-qcom-sm8350-fix-cdsp-memory-base-and-length.patch @@ -0,0 +1,272 @@ +From f4afd8ba453b6e82245b9068868c72c831aec84e Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Fri, 13 Dec 2024 15:53:51 +0100 +Subject: arm64: dts: qcom: sm8350: Fix CDSP memory base and length + +From: Krzysztof Kozlowski + +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 +Signed-off-by: Krzysztof Kozlowski +Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-2-2e0036fccd8d@linaro.org +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + 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 { diff --git a/queue-6.12/arm64-dts-qcom-sm8350-fix-mpss-memory-length.patch b/queue-6.12/arm64-dts-qcom-sm8350-fix-mpss-memory-length.patch new file mode 100644 index 0000000000..82c8f10e09 --- /dev/null +++ b/queue-6.12/arm64-dts-qcom-sm8350-fix-mpss-memory-length.patch @@ -0,0 +1,39 @@ +From da1937dec9cd986e685b6a429b528a4cbc7b1603 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Fri, 13 Dec 2024 15:53:52 +0100 +Subject: arm64: dts: qcom: sm8350: Fix MPSS memory length + +From: Krzysztof Kozlowski + +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 +Signed-off-by: Krzysztof Kozlowski +Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-3-2e0036fccd8d@linaro.org +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + 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>, diff --git a/queue-6.12/arm64-dts-qcom-sm8450-fix-adsp-memory-base-and-length.patch b/queue-6.12/arm64-dts-qcom-sm8450-fix-adsp-memory-base-and-length.patch new file mode 100644 index 0000000000..1f9e73b473 --- /dev/null +++ b/queue-6.12/arm64-dts-qcom-sm8450-fix-adsp-memory-base-and-length.patch @@ -0,0 +1,260 @@ +From 13c96bee5d5e5b61a9d8d000c9bb37bb9a2a0551 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Fri, 13 Dec 2024 15:53:53 +0100 +Subject: arm64: dts: qcom: sm8450: Fix ADSP memory base and length + +From: Krzysztof Kozlowski + +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 +Signed-off-by: Krzysztof Kozlowski +Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-4-2e0036fccd8d@linaro.org +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + 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 = ; ++ qcom,intents = <512 20>; ++ #address-cells = <1>; ++ #size-cells = <0>; ++ ++ q6apm: service@1 { ++ compatible = "qcom,q6apm"; ++ reg = ; ++ #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 = ; ++ 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 = ; +- qcom,intents = <512 20>; +- #address-cells = <1>; +- #size-cells = <0>; +- +- q6apm: service@1 { +- compatible = "qcom,q6apm"; +- reg = ; +- #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 = ; +- 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>; diff --git a/queue-6.12/arm64-dts-qcom-sm8450-fix-cdsp-memory-length.patch b/queue-6.12/arm64-dts-qcom-sm8450-fix-cdsp-memory-length.patch new file mode 100644 index 0000000000..9a060a6583 --- /dev/null +++ b/queue-6.12/arm64-dts-qcom-sm8450-fix-cdsp-memory-length.patch @@ -0,0 +1,39 @@ +From 3751fe2cba2a9fba2204ef62102bc4bb027cec7b Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Fri, 13 Dec 2024 15:53:54 +0100 +Subject: arm64: dts: qcom: sm8450: Fix CDSP memory length + +From: Krzysztof Kozlowski + +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 +Signed-off-by: Krzysztof Kozlowski +Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-5-2e0036fccd8d@linaro.org +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + 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>, diff --git a/queue-6.12/arm64-dts-qcom-sm8450-fix-mpss-memory-length.patch b/queue-6.12/arm64-dts-qcom-sm8450-fix-mpss-memory-length.patch new file mode 100644 index 0000000000..81a917b966 --- /dev/null +++ b/queue-6.12/arm64-dts-qcom-sm8450-fix-mpss-memory-length.patch @@ -0,0 +1,39 @@ +From fa6442e87ab7c4a58c0b5fc64aab1aacc8034712 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Fri, 13 Dec 2024 15:53:55 +0100 +Subject: arm64: dts: qcom: sm8450: Fix MPSS memory length + +From: Krzysztof Kozlowski + +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 +Signed-off-by: Krzysztof Kozlowski +Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-6-2e0036fccd8d@linaro.org +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + 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>, diff --git a/queue-6.12/arm64-dts-qcom-sm8550-correct-mdss-interconnects.patch b/queue-6.12/arm64-dts-qcom-sm8550-correct-mdss-interconnects.patch new file mode 100644 index 0000000000..696c95bd2e --- /dev/null +++ b/queue-6.12/arm64-dts-qcom-sm8550-correct-mdss-interconnects.patch @@ -0,0 +1,46 @@ +From b8591df49cde459e3b84cdc0517d7bf92053d244 Mon Sep 17 00:00:00 2001 +From: Dmitry Baryshkov +Date: Sat, 26 Oct 2024 20:59:40 +0300 +Subject: arm64: dts: qcom: sm8550: correct MDSS interconnects + +From: Dmitry Baryshkov + +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 +Reviewed-by: Konrad Dybcio +Link: https://lore.kernel.org/r/20241026-fix-sm8x50-mdp-icc-v2-1-fd8ddf755acc@linaro.org +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + 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>; + diff --git a/queue-6.12/arm64-dts-qcom-sm8550-fix-adsp-memory-base-and-length.patch b/queue-6.12/arm64-dts-qcom-sm8550-fix-adsp-memory-base-and-length.patch new file mode 100644 index 0000000000..1a3445276a --- /dev/null +++ b/queue-6.12/arm64-dts-qcom-sm8550-fix-adsp-memory-base-and-length.patch @@ -0,0 +1,313 @@ +From a6a8f54bc2af555738322783ba1e990c2ae7f443 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Fri, 13 Dec 2024 15:53:56 +0100 +Subject: arm64: dts: qcom: sm8550: Fix ADSP memory base and length + +From: Krzysztof Kozlowski + +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 +Reviewed-by: Konrad Dybcio +Signed-off-by: Krzysztof Kozlowski +Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-7-2e0036fccd8d@linaro.org +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + 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 = ; ++ qcom,intents = <512 20>; ++ #address-cells = <1>; ++ #size-cells = <0>; ++ ++ q6apm: service@1 { ++ compatible = "qcom,q6apm"; ++ reg = ; ++ #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 = ; ++ 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 = ; + }; + +- 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 = ; +- qcom,intents = <512 20>; +- #address-cells = <1>; +- #size-cells = <0>; +- +- q6apm: service@1 { +- compatible = "qcom,q6apm"; +- reg = ; +- #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 = ; +- 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>; diff --git a/queue-6.12/arm64-dts-qcom-sm8550-fix-cdsp-memory-length.patch b/queue-6.12/arm64-dts-qcom-sm8550-fix-cdsp-memory-length.patch new file mode 100644 index 0000000000..8fd43bb095 --- /dev/null +++ b/queue-6.12/arm64-dts-qcom-sm8550-fix-cdsp-memory-length.patch @@ -0,0 +1,40 @@ +From 6b2570e1e43e4acd0fcb98c6489736fe1c67b222 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Fri, 13 Dec 2024 15:53:57 +0100 +Subject: arm64: dts: qcom: sm8550: Fix CDSP memory length + +From: Krzysztof Kozlowski + +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 +Reviewed-by: Konrad Dybcio +Signed-off-by: Krzysztof Kozlowski +Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-8-2e0036fccd8d@linaro.org +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + 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>, diff --git a/queue-6.12/arm64-dts-qcom-sm8550-fix-mpss-memory-length.patch b/queue-6.12/arm64-dts-qcom-sm8550-fix-mpss-memory-length.patch new file mode 100644 index 0000000000..c37e5db879 --- /dev/null +++ b/queue-6.12/arm64-dts-qcom-sm8550-fix-mpss-memory-length.patch @@ -0,0 +1,40 @@ +From 8ef227e93a513d431f9345f23cd4d2d65607b985 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Fri, 13 Dec 2024 15:53:58 +0100 +Subject: arm64: dts: qcom: sm8550: Fix MPSS memory length + +From: Krzysztof Kozlowski + +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 +Reviewed-by: Konrad Dybcio +Signed-off-by: Krzysztof Kozlowski +Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-9-2e0036fccd8d@linaro.org +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + 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>, diff --git a/queue-6.12/arm64-dts-qcom-sm8650-correct-mdss-interconnects.patch b/queue-6.12/arm64-dts-qcom-sm8650-correct-mdss-interconnects.patch new file mode 100644 index 0000000000..0a77b087db --- /dev/null +++ b/queue-6.12/arm64-dts-qcom-sm8650-correct-mdss-interconnects.patch @@ -0,0 +1,46 @@ +From 9fa33cbca3d2842f1f47ed4e5f6574e611dae32b Mon Sep 17 00:00:00 2001 +From: Dmitry Baryshkov +Date: Sat, 26 Oct 2024 20:59:41 +0300 +Subject: arm64: dts: qcom: sm8650: correct MDSS interconnects + +From: Dmitry Baryshkov + +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 +Link: https://lore.kernel.org/r/20241026-fix-sm8x50-mdp-icc-v2-2-fd8ddf755acc@linaro.org +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + 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>; + diff --git a/queue-6.12/arm64-dts-qcom-sm8650-fix-adsp-memory-base-and-length.patch b/queue-6.12/arm64-dts-qcom-sm8650-fix-adsp-memory-base-and-length.patch new file mode 100644 index 0000000000..54c8a99ab3 --- /dev/null +++ b/queue-6.12/arm64-dts-qcom-sm8650-fix-adsp-memory-base-and-length.patch @@ -0,0 +1,347 @@ +From b6ddc5c37323f7875c2533cc4949be58d15e430a Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Fri, 13 Dec 2024 15:53:59 +0100 +Subject: arm64: dts: qcom: sm8650: Fix ADSP memory base and length + +From: Krzysztof Kozlowski + +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 +Reviewed-by: Konrad Dybcio +Signed-off-by: Krzysztof Kozlowski +Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-10-2e0036fccd8d@linaro.org +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + 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 = ; ++ qcom,intents = <512 20>; ++ #address-cells = <1>; ++ #size-cells = <0>; ++ ++ q6apm: service@1 { ++ compatible = "qcom,q6apm"; ++ reg = ; ++ #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 = ; ++ 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 = ; + }; + +- 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 = ; +- qcom,intents = <512 20>; +- #address-cells = <1>; +- #size-cells = <0>; +- +- q6apm: service@1 { +- compatible = "qcom,q6apm"; +- reg = ; +- #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 = ; +- 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>; diff --git a/queue-6.12/arm64-dts-qcom-sm8650-fix-cdsp-memory-length.patch b/queue-6.12/arm64-dts-qcom-sm8650-fix-cdsp-memory-length.patch new file mode 100644 index 0000000000..3ea7c2cce2 --- /dev/null +++ b/queue-6.12/arm64-dts-qcom-sm8650-fix-cdsp-memory-length.patch @@ -0,0 +1,40 @@ +From aca0053f051625a224c2e802a0e88755770819e4 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Fri, 13 Dec 2024 15:54:00 +0100 +Subject: arm64: dts: qcom: sm8650: Fix CDSP memory length + +From: Krzysztof Kozlowski + +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 +Reviewed-by: Konrad Dybcio +Signed-off-by: Krzysztof Kozlowski +Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-11-2e0036fccd8d@linaro.org +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + 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>, diff --git a/queue-6.12/arm64-dts-qcom-sm8650-fix-mpss-memory-length.patch b/queue-6.12/arm64-dts-qcom-sm8650-fix-mpss-memory-length.patch new file mode 100644 index 0000000000..3b187f30f1 --- /dev/null +++ b/queue-6.12/arm64-dts-qcom-sm8650-fix-mpss-memory-length.patch @@ -0,0 +1,40 @@ +From d4fa87daf3dd39d6bd4b69613e22bfb43c737831 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Fri, 13 Dec 2024 15:54:01 +0100 +Subject: arm64: dts: qcom: sm8650: Fix MPSS memory length + +From: Krzysztof Kozlowski + +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 +Reviewed-by: Konrad Dybcio +Signed-off-by: Krzysztof Kozlowski +Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-12-2e0036fccd8d@linaro.org +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + 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>, diff --git a/queue-6.12/arm64-dts-qcom-x1e80100-fix-adsp-memory-base-and-length.patch b/queue-6.12/arm64-dts-qcom-x1e80100-fix-adsp-memory-base-and-length.patch new file mode 100644 index 0000000000..ace8377dab --- /dev/null +++ b/queue-6.12/arm64-dts-qcom-x1e80100-fix-adsp-memory-base-and-length.patch @@ -0,0 +1,324 @@ +From 7a003077366946a5ed1adab6d177efb2ab59e815 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Fri, 13 Dec 2024 15:54:02 +0100 +Subject: arm64: dts: qcom: x1e80100: Fix ADSP memory base and length + +From: Krzysztof Kozlowski + +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 +Signed-off-by: Krzysztof Kozlowski +Reviewed-by: Johan Hovold +Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-13-2e0036fccd8d@linaro.org +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + 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 = ; ++ qcom,intents = <512 20>; ++ #address-cells = <1>; ++ #size-cells = <0>; ++ ++ q6apm: service@1 { ++ compatible = "qcom,q6apm"; ++ reg = ; ++ #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 = ; ++ 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 = ; + }; + +- 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 = ; +- qcom,intents = <512 20>; +- #address-cells = <1>; +- #size-cells = <0>; +- +- q6apm: service@1 { +- compatible = "qcom,q6apm"; +- reg = ; +- #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 = ; +- 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>; diff --git a/queue-6.12/arm64-dts-qcom-x1e80100-fix-cdsp-memory-length.patch b/queue-6.12/arm64-dts-qcom-x1e80100-fix-cdsp-memory-length.patch new file mode 100644 index 0000000000..c6cc4043a2 --- /dev/null +++ b/queue-6.12/arm64-dts-qcom-x1e80100-fix-cdsp-memory-length.patch @@ -0,0 +1,40 @@ +From 3de1bf12c6bfb9a92f0803941ecae39b08470446 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Fri, 13 Dec 2024 15:54:03 +0100 +Subject: arm64: dts: qcom: x1e80100: Fix CDSP memory length + +From: Krzysztof Kozlowski + +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 +Signed-off-by: Krzysztof Kozlowski +Reviewed-by: Johan Hovold +Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-14-2e0036fccd8d@linaro.org +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + 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>, diff --git a/queue-6.12/arm64-tegra-disable-tegra234-sce-fabric-node.patch b/queue-6.12/arm64-tegra-disable-tegra234-sce-fabric-node.patch new file mode 100644 index 0000000000..11e6c4651b --- /dev/null +++ b/queue-6.12/arm64-tegra-disable-tegra234-sce-fabric-node.patch @@ -0,0 +1,44 @@ +From a5e6fc0a10fe280989f1367a3b4f8047c7d00ea6 Mon Sep 17 00:00:00 2001 +From: Sumit Gupta +Date: Wed, 18 Dec 2024 00:07:37 +0000 +Subject: arm64: tegra: Disable Tegra234 sce-fabric node + +From: Sumit Gupta + +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 +Signed-off-by: Ivy Huang +Reviewed-by: Brad Griffis +Reviewed-by: Jon Hunter +Link: https://lore.kernel.org/r/20241218000737.1789569-3-yijuh@nvidia.com +Signed-off-by: Thierry Reding +Signed-off-by: Greg Kroah-Hartman +--- + 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 = ; +- status = "okay"; ++ status = "disabled"; + }; + + rce-fabric@be00000 { diff --git a/queue-6.12/arm64-tegra-fix-typo-in-tegra234-dce-fabric-compatible.patch b/queue-6.12/arm64-tegra-fix-typo-in-tegra234-dce-fabric-compatible.patch new file mode 100644 index 0000000000..1921fcfdb4 --- /dev/null +++ b/queue-6.12/arm64-tegra-fix-typo-in-tegra234-dce-fabric-compatible.patch @@ -0,0 +1,41 @@ +From 604120fd9e9df50ee0e803d3c6e77a1f45d2c58e Mon Sep 17 00:00:00 2001 +From: Sumit Gupta +Date: Wed, 18 Dec 2024 00:07:36 +0000 +Subject: arm64: tegra: Fix typo in Tegra234 dce-fabric compatible + +From: Sumit Gupta + +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 +Signed-off-by: Ivy Huang +Reviewed-by: Brad Griffis +Reviewed-by: Jon Hunter +Link: https://lore.kernel.org/r/20241218000737.1789569-2-yijuh@nvidia.com +Signed-off-by: Thierry Reding +Signed-off-by: Greg Kroah-Hartman +--- + 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 = ; + status = "okay"; diff --git a/queue-6.12/crypto-qce-fix-priority-to-be-less-than-armv8-ce.patch b/queue-6.12/crypto-qce-fix-priority-to-be-less-than-armv8-ce.patch new file mode 100644 index 0000000000..7306d4e211 --- /dev/null +++ b/queue-6.12/crypto-qce-fix-priority-to-be-less-than-armv8-ce.patch @@ -0,0 +1,64 @@ +From 49b9258b05b97c6464e1964b6a2fddb3ddb65d17 Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Tue, 3 Dec 2024 10:05:53 -0800 +Subject: crypto: qce - fix priority to be less than ARMv8 CE + +From: Eric Biggers + +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 +Cc: Neil Armstrong +Cc: Thara Gopinath +Signed-off-by: Eric Biggers +Reviewed-by: Bartosz Golaszewski +Reviewed-by: Ard Biesheuvel +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.12/hrtimers-force-migrate-away-hrtimers-queued-after-cpuhp_ap_hrtimers_dying.patch b/queue-6.12/hrtimers-force-migrate-away-hrtimers-queued-after-cpuhp_ap_hrtimers_dying.patch new file mode 100644 index 0000000000..a7d7b2c1c4 --- /dev/null +++ b/queue-6.12/hrtimers-force-migrate-away-hrtimers-queued-after-cpuhp_ap_hrtimers_dying.patch @@ -0,0 +1,269 @@ +From 53dac345395c0d2493cbc2f4c85fe38aef5b63f5 Mon Sep 17 00:00:00 2001 +From: Frederic Weisbecker +Date: Sat, 18 Jan 2025 00:24:33 +0100 +Subject: hrtimers: Force migrate away hrtimers queued after CPUHP_AP_HRTIMERS_DYING + +From: Frederic Weisbecker + +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: + + 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 +Reported-by: Usama Arif +Signed-off-by: Frederic Weisbecker +Signed-off-by: Paul E. McKenney +Signed-off-by: Thomas Gleixner +Cc: stable@vger.kernel.org +Tested-by: Paul E. McKenney +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 +--- + 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 diff --git a/queue-6.12/iio-light-as73211-fix-channel-handling-in-only-color-triggered-buffer.patch b/queue-6.12/iio-light-as73211-fix-channel-handling-in-only-color-triggered-buffer.patch new file mode 100644 index 0000000000..8922d5785a --- /dev/null +++ b/queue-6.12/iio-light-as73211-fix-channel-handling-in-only-color-triggered-buffer.patch @@ -0,0 +1,86 @@ +From ab09c6cfe01b317f515bcd944668697241a54b9d Mon Sep 17 00:00:00 2001 +From: Javier Carrasco +Date: Sat, 14 Dec 2024 23:55:50 +0100 +Subject: iio: light: as73211: fix channel handling in only-color triggered buffer + +From: Javier Carrasco + +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 +Signed-off-by: Javier Carrasco +Link: https://patch.msgid.link/20241214-iio_memset_scan_holes-v4-1-260b395b8ed5@gmail.com +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-6.12/iommu-tegra241-cmdqv-read-smmu-idr1.cmdqs-instead-of-hardcoding.patch b/queue-6.12/iommu-tegra241-cmdqv-read-smmu-idr1.cmdqs-instead-of-hardcoding.patch new file mode 100644 index 0000000000..e22abf8485 --- /dev/null +++ b/queue-6.12/iommu-tegra241-cmdqv-read-smmu-idr1.cmdqs-instead-of-hardcoding.patch @@ -0,0 +1,69 @@ +From e94dc6ddda8dd3770879a132d577accd2cce25f9 Mon Sep 17 00:00:00 2001 +From: Nicolin Chen +Date: Wed, 18 Dec 2024 21:14:21 -0800 +Subject: iommu/tegra241-cmdqv: Read SMMU IDR1.CMDQS instead of hardcoding + +From: Nicolin Chen + +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 +Cc: stable@vger.kernel.org +Signed-off-by: Nicolin Chen +Link: https://lore.kernel.org/r/20241219051421.1850267-1-nicolinc@nvidia.com +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + 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 + diff --git a/queue-6.12/iommufd-fault-destroy-response-and-mutex-in-iommufd_fault_destroy.patch b/queue-6.12/iommufd-fault-destroy-response-and-mutex-in-iommufd_fault_destroy.patch new file mode 100644 index 0000000000..8ae0722445 --- /dev/null +++ b/queue-6.12/iommufd-fault-destroy-response-and-mutex-in-iommufd_fault_destroy.patch @@ -0,0 +1,48 @@ +From 3f4818ec139030f425476bf8a10b616bab53a7b5 Mon Sep 17 00:00:00 2001 +From: Nicolin Chen +Date: Tue, 14 Jan 2025 22:55:59 -0800 +Subject: iommufd/fault: Destroy response and mutex in iommufd_fault_destroy() + +From: Nicolin Chen + +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 +Reviewed-by: Kevin Tian +Reviewed-by: Lu Baolu +Signed-off-by: Nicolin Chen +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-6.12/iommufd-fault-use-a-separate-spinlock-to-protect-fault-deliver-list.patch b/queue-6.12/iommufd-fault-use-a-separate-spinlock-to-protect-fault-deliver-list.patch new file mode 100644 index 0000000000..f5504f54bd --- /dev/null +++ b/queue-6.12/iommufd-fault-use-a-separate-spinlock-to-protect-fault-deliver-list.patch @@ -0,0 +1,193 @@ +From 3d49020a327cd7d069059317c11df24e407ccfa3 Mon Sep 17 00:00:00 2001 +From: Nicolin Chen +Date: Fri, 17 Jan 2025 11:29:01 -0800 +Subject: iommufd/fault: Use a separate spinlock to protect fault->deliver list + +From: Nicolin Chen + +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 +Reviewed-by: Kevin Tian +Reviewed-by: Lu Baolu +Reviewed-by: Jason Gunthorpe +Signed-off-by: Nicolin Chen +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.12/iommufd-fix-struct-iommu_hwpt_pgfault-init-and-padding.patch b/queue-6.12/iommufd-fix-struct-iommu_hwpt_pgfault-init-and-padding.patch new file mode 100644 index 0000000000..100c942799 --- /dev/null +++ b/queue-6.12/iommufd-fix-struct-iommu_hwpt_pgfault-init-and-padding.patch @@ -0,0 +1,96 @@ +From e721f619e3ec9bae08bf419c3944cf1e6966c821 Mon Sep 17 00:00:00 2001 +From: Nicolin Chen +Date: Mon, 20 Jan 2025 11:50:51 -0800 +Subject: iommufd: Fix struct iommu_hwpt_pgfault init and padding + +From: Nicolin Chen + +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 +Signed-off-by: Nicolin Chen +Reviewed-by: Kevin Tian +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman +--- + 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; + }; diff --git a/queue-6.12/kfence-skip-__gfp_thisnode-allocations-on-numa-systems.patch b/queue-6.12/kfence-skip-__gfp_thisnode-allocations-on-numa-systems.patch new file mode 100644 index 0000000000..af9cf6c1ba --- /dev/null +++ b/queue-6.12/kfence-skip-__gfp_thisnode-allocations-on-numa-systems.patch @@ -0,0 +1,50 @@ +From e64f81946adf68cd75e2207dd9a51668348a4af8 Mon Sep 17 00:00:00 2001 +From: Marco Elver +Date: Fri, 24 Jan 2025 13:01:38 +0100 +Subject: kfence: skip __GFP_THISNODE allocations on NUMA systems + +From: Marco Elver + +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 +Reported-by: Vlastimil Babka +Acked-by: Vlastimil Babka +Cc: Christoph Lameter +Cc: Alexander Potapenko +Cc: Chistoph Lameter +Cc: Dmitriy Vyukov +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + 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 + #include + #include ++#include + #include + #include + #include +@@ -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; diff --git a/queue-6.12/media-ccs-clean-up-parsed-ccs-static-data-on-parse-failure.patch b/queue-6.12/media-ccs-clean-up-parsed-ccs-static-data-on-parse-failure.patch new file mode 100644 index 0000000000..c1f6eb7e5d --- /dev/null +++ b/queue-6.12/media-ccs-clean-up-parsed-ccs-static-data-on-parse-failure.patch @@ -0,0 +1,72 @@ +From da73efa8e675a2b58f1c7ae61201acfe57714bf7 Mon Sep 17 00:00:00 2001 +From: Sakari Ailus +Date: Tue, 3 Dec 2024 12:23:01 +0200 +Subject: media: ccs: Clean up parsed CCS static data on parse failure + +From: Sakari Ailus + +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 +Reviewed-by: Mehdi Djait +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + 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 + #include + #include ++#include + + #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; + } diff --git a/queue-6.12/media-ccs-fix-ccs-static-data-parsing-for-large-block-sizes.patch b/queue-6.12/media-ccs-fix-ccs-static-data-parsing-for-large-block-sizes.patch new file mode 100644 index 0000000000..21c10db3da --- /dev/null +++ b/queue-6.12/media-ccs-fix-ccs-static-data-parsing-for-large-block-sizes.patch @@ -0,0 +1,37 @@ +From 82b696750f0b60e7513082a10ad42786854f59f8 Mon Sep 17 00:00:00 2001 +From: Sakari Ailus +Date: Tue, 3 Dec 2024 10:10:23 +0200 +Subject: media: ccs: Fix CCS static data parsing for large block sizes + +From: Sakari Ailus + +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 +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + 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: diff --git a/queue-6.12/media-ccs-fix-cleanup-order-in-ccs_probe.patch b/queue-6.12/media-ccs-fix-cleanup-order-in-ccs_probe.patch new file mode 100644 index 0000000000..46dff04bb9 --- /dev/null +++ b/queue-6.12/media-ccs-fix-cleanup-order-in-ccs_probe.patch @@ -0,0 +1,44 @@ +From 6fdbff0f54786e94f0f630ff200ec1d666b1633e Mon Sep 17 00:00:00 2001 +From: Mehdi Djait +Date: Wed, 11 Dec 2024 14:30:45 +0100 +Subject: media: ccs: Fix cleanup order in ccs_probe() + +From: Mehdi Djait + +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 +Signed-off-by: Sakari Ailus +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-6.12/media-i2c-ds90ub960-fix-logging-sp-eq-status-only-for-ub9702.patch b/queue-6.12/media-i2c-ds90ub960-fix-logging-sp-eq-status-only-for-ub9702.patch new file mode 100644 index 0000000000..8fdd8880f8 --- /dev/null +++ b/queue-6.12/media-i2c-ds90ub960-fix-logging-sp-eq-status-only-for-ub9702.patch @@ -0,0 +1,138 @@ +From 42d0ec194aa12e9b97f09a94fe565ba2e5f631a2 Mon Sep 17 00:00:00 2001 +From: Tomi Valkeinen +Date: Fri, 6 Dec 2024 10:26:40 +0200 +Subject: media: i2c: ds90ub960: Fix logging SP & EQ status only for UB9702 + +From: Tomi Valkeinen + +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 +Signed-off-by: Tomi Valkeinen +Signed-off-by: Sakari Ailus +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + 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++) { diff --git a/queue-6.12/media-i2c-ds90ub960-fix-ub9702-vc-map.patch b/queue-6.12/media-i2c-ds90ub960-fix-ub9702-vc-map.patch new file mode 100644 index 0000000000..575e8c6da7 --- /dev/null +++ b/queue-6.12/media-i2c-ds90ub960-fix-ub9702-vc-map.patch @@ -0,0 +1,43 @@ +From 5dbbd0609b83f6eb72c005e2e5979d0cd25243c8 Mon Sep 17 00:00:00 2001 +From: Tomi Valkeinen +Date: Fri, 6 Dec 2024 10:26:41 +0200 +Subject: media: i2c: ds90ub960: Fix UB9702 VC map + +From: Tomi Valkeinen + +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 +Signed-off-by: Tomi Valkeinen +Signed-off-by: Sakari Ailus +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.12/media-i2c-ds90ub960-fix-use-of-non-existing-registers-on-ub9702.patch b/queue-6.12/media-i2c-ds90ub960-fix-use-of-non-existing-registers-on-ub9702.patch new file mode 100644 index 0000000000..cfe5b0e5f1 --- /dev/null +++ b/queue-6.12/media-i2c-ds90ub960-fix-use-of-non-existing-registers-on-ub9702.patch @@ -0,0 +1,60 @@ +From 698cf6df87ffa83f259703e7443c15a4c5ceae86 Mon Sep 17 00:00:00 2001 +From: Tomi Valkeinen +Date: Fri, 6 Dec 2024 10:26:39 +0200 +Subject: media: i2c: ds90ub960: Fix use of non-existing registers on UB9702 + +From: Tomi Valkeinen + +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 +Signed-off-by: Tomi Valkeinen +Signed-off-by: Sakari Ailus +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.12/media-i2c-ds90ub9x3-fix-extra-fwnode_handle_put.patch b/queue-6.12/media-i2c-ds90ub9x3-fix-extra-fwnode_handle_put.patch new file mode 100644 index 0000000000..a9460c0ce1 --- /dev/null +++ b/queue-6.12/media-i2c-ds90ub9x3-fix-extra-fwnode_handle_put.patch @@ -0,0 +1,51 @@ +From 60b45ece41c5632a3a3274115a401cb244180646 Mon Sep 17 00:00:00 2001 +From: Tomi Valkeinen +Date: Fri, 6 Dec 2024 10:26:37 +0200 +Subject: media: i2c: ds90ub9x3: Fix extra fwnode_handle_put() + +From: Tomi Valkeinen + +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 +Signed-off-by: Tomi Valkeinen +Signed-off-by: Sakari Ailus +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + 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); + } + diff --git a/queue-6.12/media-imx296-add-standby-delay-during-probe.patch b/queue-6.12/media-imx296-add-standby-delay-during-probe.patch new file mode 100644 index 0000000000..0ad121cb69 --- /dev/null +++ b/queue-6.12/media-imx296-add-standby-delay-during-probe.patch @@ -0,0 +1,40 @@ +From 57d10bcac67707caaa542e09dee86e13ea85defc Mon Sep 17 00:00:00 2001 +From: Naushir Patuck +Date: Fri, 15 Nov 2024 20:07:17 +0200 +Subject: media: imx296: Add standby delay during probe + +From: Naushir Patuck + +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 +Signed-off-by: Naushir Patuck +Reviewed-by: Kieran Bingham +Reviewed-by: Laurent Pinchart +Signed-off-by: Sakari Ailus +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + 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", diff --git a/queue-6.12/media-intel-ipu6-remove-cpu-latency-qos-request-on-error.patch b/queue-6.12/media-intel-ipu6-remove-cpu-latency-qos-request-on-error.patch new file mode 100644 index 0000000000..a6388e7132 --- /dev/null +++ b/queue-6.12/media-intel-ipu6-remove-cpu-latency-qos-request-on-error.patch @@ -0,0 +1,54 @@ +From facb541ff0805314e0b56e508f7d3cbd07af513c Mon Sep 17 00:00:00 2001 +From: Stanislaw Gruszka +Date: Wed, 11 Dec 2024 12:49:05 +0100 +Subject: media: intel/ipu6: remove cpu latency qos request on error + +From: Stanislaw Gruszka + +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 + +[ 30.634640] l7 kernel: Call Trace: +[ 30.634650] l7 kernel: +[ 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 +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 +Reviewed-by: Hans de Goede +Signed-off-by: Sakari Ailus +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + 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: diff --git a/queue-6.12/media-mc-fix-endpoint-iteration.patch b/queue-6.12/media-mc-fix-endpoint-iteration.patch new file mode 100644 index 0000000000..472179ccb8 --- /dev/null +++ b/queue-6.12/media-mc-fix-endpoint-iteration.patch @@ -0,0 +1,42 @@ +From fb2bd86270cd0ad004f4c614ba4f8c63a5720e25 Mon Sep 17 00:00:00 2001 +From: Cosmin Tanislav +Date: Fri, 22 Nov 2024 16:55:24 +0200 +Subject: media: mc: fix endpoint iteration + +From: Cosmin Tanislav + +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 +Fixes: 0d3c81e82da9 ("media: v4l2-mc: add v4l2_create_fwnode_links helpers") +Cc: stable@vger.kernel.org +Reviewed-by: Laurent Pinchart +Signed-off-by: Sakari Ailus +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.12/media-mmp-bring-back-registration-of-the-device.patch b/queue-6.12/media-mmp-bring-back-registration-of-the-device.patch new file mode 100644 index 0000000000..60199000fe --- /dev/null +++ b/queue-6.12/media-mmp-bring-back-registration-of-the-device.patch @@ -0,0 +1,89 @@ +From fbb5298bf1a7b71723cd2bb193642429ceb0fb84 Mon Sep 17 00:00:00 2001 +From: Lubomir Rintel +Date: Tue, 31 Dec 2024 20:04:34 +0100 +Subject: media: mmp: Bring back registration of the device + +From: Lubomir Rintel + +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 +Cc: stable@vger.kernel.org # v6.6+ +Signed-off-by: Hans Verkuil +Signed-off-by: Greg Kroah-Hartman +--- + 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); + } + diff --git a/queue-6.12/media-nuvoton-fix-an-error-check-in-npcm_video_ece_init.patch b/queue-6.12/media-nuvoton-fix-an-error-check-in-npcm_video_ece_init.patch new file mode 100644 index 0000000000..2981b42296 --- /dev/null +++ b/queue-6.12/media-nuvoton-fix-an-error-check-in-npcm_video_ece_init.patch @@ -0,0 +1,38 @@ +From c4b7779abc6633677e6edb79e2809f4f61fde157 Mon Sep 17 00:00:00 2001 +From: Zhen Lei +Date: Tue, 15 Oct 2024 09:40:53 +0800 +Subject: media: nuvoton: Fix an error check in npcm_video_ece_init() + +From: Zhen Lei + +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 +Link: https://lore.kernel.org/r/20241015014053.669-1-thunder.leizhen@huawei.com +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + 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); + diff --git a/queue-6.12/media-ov5640-fix-get_light_freq-on-auto.patch b/queue-6.12/media-ov5640-fix-get_light_freq-on-auto.patch new file mode 100644 index 0000000000..bc32085b2d --- /dev/null +++ b/queue-6.12/media-ov5640-fix-get_light_freq-on-auto.patch @@ -0,0 +1,33 @@ +From 001d3753538d26ddcbef011f5643cfff58a7f672 Mon Sep 17 00:00:00 2001 +From: Sam Bobrowicz +Date: Fri, 22 Nov 2024 09:28:01 +0100 +Subject: media: ov5640: fix get_light_freq on auto + +From: Sam Bobrowicz + +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 +Signed-off-by: Michal Simek +Signed-off-by: Sakari Ailus +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } + } + diff --git a/queue-6.12/media-stm32-dcmipp-correct-dma_set_mask_and_coherent-mask-value.patch b/queue-6.12/media-stm32-dcmipp-correct-dma_set_mask_and_coherent-mask-value.patch new file mode 100644 index 0000000000..44c994cb76 --- /dev/null +++ b/queue-6.12/media-stm32-dcmipp-correct-dma_set_mask_and_coherent-mask-value.patch @@ -0,0 +1,32 @@ +From b36077ba289b827b4e76e25e8d8e0cc90fa09186 Mon Sep 17 00:00:00 2001 +From: Alain Volmat +Date: Thu, 12 Dec 2024 10:17:25 +0100 +Subject: media: stm32: dcmipp: correct dma_set_mask_and_coherent mask value + +From: Alain Volmat + +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 +Signed-off-by: Hans Verkuil +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.12/media-uvcvideo-fix-crash-during-unbind-if-gpio-unit-is-in-use.patch b/queue-6.12/media-uvcvideo-fix-crash-during-unbind-if-gpio-unit-is-in-use.patch new file mode 100644 index 0000000000..1e1fcf75cf --- /dev/null +++ b/queue-6.12/media-uvcvideo-fix-crash-during-unbind-if-gpio-unit-is-in-use.patch @@ -0,0 +1,111 @@ +From a9ea1a3d88b7947ce8cadb2afceee7a54872bbc5 Mon Sep 17 00:00:00 2001 +From: Ricardo Ribalda +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 + +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 +Signed-off-by: Ricardo Ribalda +Reviewed-by: Laurent Pinchart +Link: https://lore.kernel.org/r/20241106-uvc-crashrmmod-v6-1-fbf9781c6e83@chromium.org +Signed-off-by: Laurent Pinchart +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + 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; + }; + diff --git a/queue-6.12/media-uvcvideo-fix-event-flags-in-uvc_ctrl_send_events.patch b/queue-6.12/media-uvcvideo-fix-event-flags-in-uvc_ctrl_send_events.patch new file mode 100644 index 0000000000..2bb2d12cc8 --- /dev/null +++ b/queue-6.12/media-uvcvideo-fix-event-flags-in-uvc_ctrl_send_events.patch @@ -0,0 +1,46 @@ +From c31cffd5ae2c3d7ef21d9008977a9d117ce7a64e Mon Sep 17 00:00:00 2001 +From: Ricardo Ribalda +Date: Thu, 14 Nov 2024 19:10:30 +0000 +Subject: media: uvcvideo: Fix event flags in uvc_ctrl_send_events + +From: Ricardo Ribalda + +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 +Reviewed-by: Laurent Pinchart +Link: https://lore.kernel.org/r/20241114-uvc-roi-v15-1-64cfeb56b6f8@chromium.org +Signed-off-by: Laurent Pinchart +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.12/media-uvcvideo-only-save-async-fh-if-success.patch b/queue-6.12/media-uvcvideo-only-save-async-fh-if-success.patch new file mode 100644 index 0000000000..24baada716 --- /dev/null +++ b/queue-6.12/media-uvcvideo-only-save-async-fh-if-success.patch @@ -0,0 +1,85 @@ +From d9fecd096f67a4469536e040a8a10bbfb665918b Mon Sep 17 00:00:00 2001 +From: Ricardo Ribalda +Date: Tue, 3 Dec 2024 21:20:08 +0000 +Subject: media: uvcvideo: Only save async fh if success + +From: Ricardo Ribalda + +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 +Reviewed-by: Hans de Goede +Reviewed-by: Laurent Pinchart +Signed-off-by: Ricardo Ribalda +Link: https://lore.kernel.org/r/20241203-uvc-fix-async-v6-1-26c867231118@chromium.org +Signed-off-by: Laurent Pinchart +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-6.12/media-uvcvideo-remove-dangling-pointers.patch b/queue-6.12/media-uvcvideo-remove-dangling-pointers.patch new file mode 100644 index 0000000000..ac92077a7e --- /dev/null +++ b/queue-6.12/media-uvcvideo-remove-dangling-pointers.patch @@ -0,0 +1,170 @@ +From 221cd51efe4565501a3dbf04cc011b537dcce7fb Mon Sep 17 00:00:00 2001 +From: Ricardo Ribalda +Date: Tue, 3 Dec 2024 21:20:10 +0000 +Subject: media: uvcvideo: Remove dangling pointers + +From: Ricardo Ribalda + +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 +Signed-off-by: Ricardo Ribalda +Reviewed-by: Laurent Pinchart +Link: https://lore.kernel.org/r/20241203-uvc-fix-async-v6-3-26c867231118@chromium.org +Signed-off-by: Laurent Pinchart +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-6.12/media-uvcvideo-remove-redundant-null-assignment.patch b/queue-6.12/media-uvcvideo-remove-redundant-null-assignment.patch new file mode 100644 index 0000000000..2d7eb70a4b --- /dev/null +++ b/queue-6.12/media-uvcvideo-remove-redundant-null-assignment.patch @@ -0,0 +1,40 @@ +From 04d3398f66d2d31c4b8caea88f051a4257b7a161 Mon Sep 17 00:00:00 2001 +From: Ricardo Ribalda +Date: Tue, 3 Dec 2024 21:20:09 +0000 +Subject: media: uvcvideo: Remove redundant NULL assignment + +From: Ricardo Ribalda + +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 +Reviewed-by: Hans de Goede +Signed-off-by: Ricardo Ribalda +Link: https://lore.kernel.org/r/20241203-uvc-fix-async-v6-2-26c867231118@chromium.org +Signed-off-by: Laurent Pinchart +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.12/media-uvcvideo-support-partial-control-reads.patch b/queue-6.12/media-uvcvideo-support-partial-control-reads.patch new file mode 100644 index 0000000000..b114e718b0 --- /dev/null +++ b/queue-6.12/media-uvcvideo-support-partial-control-reads.patch @@ -0,0 +1,60 @@ +From f00ee2ca8da25ebccb8e19956d853c9055e2c8d0 Mon Sep 17 00:00:00 2001 +From: Ricardo Ribalda +Date: Thu, 28 Nov 2024 20:53:41 +0000 +Subject: media: uvcvideo: Support partial control reads + +From: Ricardo Ribalda + +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 +Signed-off-by: Ricardo Ribalda +Link: https://lore.kernel.org/r/20241128-uvc-readless-v5-1-cf16ed282af8@chromium.org +Signed-off-by: Hans de Goede +Reviewed-by: Laurent Pinchart +Signed-off-by: Laurent Pinchart +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + 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", diff --git a/queue-6.12/mm-compaction-fix-ubsan-shift-out-of-bounds-warning.patch b/queue-6.12/mm-compaction-fix-ubsan-shift-out-of-bounds-warning.patch new file mode 100644 index 0000000000..10dc8f6cdf --- /dev/null +++ b/queue-6.12/mm-compaction-fix-ubsan-shift-out-of-bounds-warning.patch @@ -0,0 +1,45 @@ +From d1366e74342e75555af2648a2964deb2d5c92200 Mon Sep 17 00:00:00 2001 +From: Liu Shixin +Date: Thu, 23 Jan 2025 10:10:29 +0800 +Subject: mm/compaction: fix UBSAN shift-out-of-bounds warning + +From: Liu Shixin + +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 +Reviewed-by: Kemeng Shi +Acked-by: David Hildenbrand +Reviewed-by: Oscar Salvador +Cc: Baolin Wang +Cc: David Hildenbrand +Cc: Kemeng Shi +Cc: Matthew Wilcox +Cc: Mel Gorman +Cc: Nanyong Sun +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.12/mm-gup-fix-infinite-loop-within-__get_longterm_locked.patch b/queue-6.12/mm-gup-fix-infinite-loop-within-__get_longterm_locked.patch new file mode 100644 index 0000000000..7a9e8aabfc --- /dev/null +++ b/queue-6.12/mm-gup-fix-infinite-loop-within-__get_longterm_locked.patch @@ -0,0 +1,87 @@ +From 1aaf8c122918aa8897605a9aa1e8ed6600d6f930 Mon Sep 17 00:00:00 2001 +From: Zhaoyang Huang +Date: Tue, 21 Jan 2025 10:01:59 +0800 +Subject: mm: gup: fix infinite loop within __get_longterm_locked + +From: Zhaoyang Huang + +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 +Reviewed-by: John Hubbard +Reviewed-by: David Hildenbrand +Suggested-by: David Hildenbrand +Acked-by: David Hildenbrand +Cc: Aijun Sun +Cc: Alistair Popple +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-6.12/mm-hugetlb-fix-avoid_reserve-to-allow-taking-folio-from-subpool.patch b/queue-6.12/mm-hugetlb-fix-avoid_reserve-to-allow-taking-folio-from-subpool.patch new file mode 100644 index 0000000000..79d2726022 --- /dev/null +++ b/queue-6.12/mm-hugetlb-fix-avoid_reserve-to-allow-taking-folio-from-subpool.patch @@ -0,0 +1,230 @@ +From 58db7c5fbe7daa42098d4965133a864f98ba90ba Mon Sep 17 00:00:00 2001 +From: Peter Xu +Date: Tue, 7 Jan 2025 15:39:56 -0500 +Subject: mm/hugetlb: fix avoid_reserve to allow taking folio from subpool + +From: Peter Xu + +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 + #include + #include + #include + #include + #include + + #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 \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 +Reviewed-by: Ackerley Tng +Tested-by: Ackerley Tng +Reviewed-by: Oscar Salvador +Cc: Breno Leitao +Cc: Muchun Song +Cc: Naoya Horiguchi +Cc: Rik van Riel +Cc: Roman Gushchin +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-6.12/mm-hugetlb-fix-hugepage-allocation-for-interleaved-memory-nodes.patch b/queue-6.12/mm-hugetlb-fix-hugepage-allocation-for-interleaved-memory-nodes.patch new file mode 100644 index 0000000000..2c111edba1 --- /dev/null +++ b/queue-6.12/mm-hugetlb-fix-hugepage-allocation-for-interleaved-memory-nodes.patch @@ -0,0 +1,79 @@ +From 76e961157e078bc5d3cd2df08317e00b00a829eb Mon Sep 17 00:00:00 2001 +From: "Ritesh Harjani (IBM)" +Date: Sat, 11 Jan 2025 16:36:55 +0530 +Subject: mm/hugetlb: fix hugepage allocation for interleaved memory nodes + +From: Ritesh Harjani (IBM) + +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) +Reported-by: Pavithra Prakash +Suggested-by: Muchun Song +Tested-by: Sourabh Jain +Reviewed-by: Luiz Capitulino +Acked-by: David Rientjes +Cc: Donet Tom +Cc: Gang Li +Cc: Daniel Jordan +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + 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), diff --git a/queue-6.12/mm-kmemleak-fix-upper-boundary-check-for-physical-address-objects.patch b/queue-6.12/mm-kmemleak-fix-upper-boundary-check-for-physical-address-objects.patch new file mode 100644 index 0000000000..920f8cc194 --- /dev/null +++ b/queue-6.12/mm-kmemleak-fix-upper-boundary-check-for-physical-address-objects.patch @@ -0,0 +1,51 @@ +From 488b5b9eca68497b533ced059be5eff19578bbca Mon Sep 17 00:00:00 2001 +From: Catalin Marinas +Date: Mon, 27 Jan 2025 18:42:33 +0000 +Subject: mm: kmemleak: fix upper boundary check for physical address objects + +From: Catalin Marinas + +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 +Reported-by: Jakub Kicinski +Tested-by: Matthieu Baerts (NGI0) +Cc: Patrick Wang +Cc: [6.0.x] +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + 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); + } + diff --git a/queue-6.12/mm-vmscan-accumulate-nr_demoted-for-accurate-demotion-statistics.patch b/queue-6.12/mm-vmscan-accumulate-nr_demoted-for-accurate-demotion-statistics.patch new file mode 100644 index 0000000000..9cb69ee8cf --- /dev/null +++ b/queue-6.12/mm-vmscan-accumulate-nr_demoted-for-accurate-demotion-statistics.patch @@ -0,0 +1,55 @@ +From a479b078fddb0ad7f9e3c6da22d9cf8f2b5c7799 Mon Sep 17 00:00:00 2001 +From: Li Zhijian +Date: Fri, 10 Jan 2025 20:21:32 +0800 +Subject: mm/vmscan: accumulate nr_demoted for accurate demotion statistics + +From: Li Zhijian + +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 +Acked-by: Kaiyang Zhao +Tested-by: Donet Tom +Reviewed-by: Donet Tom +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + 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 */ diff --git a/queue-6.12/parisc-temporarily-disable-jump-label-support.patch b/queue-6.12/parisc-temporarily-disable-jump-label-support.patch new file mode 100644 index 0000000000..e8fb988aca --- /dev/null +++ b/queue-6.12/parisc-temporarily-disable-jump-label-support.patch @@ -0,0 +1,93 @@ +From 3599bae489d86fbabe039f9a2ab5472ffb04f7f1 Mon Sep 17 00:00:00 2001 +From: Helge Deller +Date: Thu, 16 Jan 2025 21:17:47 +0100 +Subject: parisc: Temporarily disable jump label support + +From: Helge Deller + +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 + 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 +Cc: Guenter Roeck +Reviewed-by: Guenter Roeck +Cc: # v6.12+ +Signed-off-by: Greg Kroah-Hartman +--- + 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 + diff --git a/queue-6.12/pwm-microchip-core-fix-incorrect-comparison-with-max-period.patch b/queue-6.12/pwm-microchip-core-fix-incorrect-comparison-with-max-period.patch new file mode 100644 index 0000000000..f1ee4fc769 --- /dev/null +++ b/queue-6.12/pwm-microchip-core-fix-incorrect-comparison-with-max-period.patch @@ -0,0 +1,46 @@ +From 752b6e3af374460a2de18f0c10bfa06bf844dbe8 Mon Sep 17 00:00:00 2001 +From: Conor Dooley +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 + +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 +Link: https://lore.kernel.org/r/20250122-pastor-fancied-0b993da2d2d2@spud +Signed-off-by: Uwe Kleine-König +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.12/rust-init-use-explicit-abi-to-clean-warning-in-future-compilers.patch b/queue-6.12/rust-init-use-explicit-abi-to-clean-warning-in-future-compilers.patch new file mode 100644 index 0000000000..af5ccf206b --- /dev/null +++ b/queue-6.12/rust-init-use-explicit-abi-to-clean-warning-in-future-compilers.patch @@ -0,0 +1,48 @@ +From c21bdb3d8a850afdfa4afe77eea39ae9533629b0 Mon Sep 17 00:00:00 2001 +From: Miguel Ojeda +Date: Tue, 21 Jan 2025 21:09:34 +0100 +Subject: rust: init: use explicit ABI to clean warning in future compilers + +From: Miguel Ojeda + +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: # 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`") +Link: https://github.com/rust-lang/rust/pull/132397 [1] +Reviewed-by: Gary Guo +Reviewed-by: Alice Ryhl +Reviewed-by: Fiona Behrens +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 +Signed-off-by: Greg Kroah-Hartman +--- + 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 +Date: Wed, 15 Jan 2025 16:15:48 +0100 +Subject: rv: Reset per-task monitors also for idle tasks + +From: Gabriele Monaco + +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 +Cc: Thomas Gleixner +Cc: Peter Zijlstra +Cc: John Kacur +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 +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + 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 + #include + #include ++#include + + #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); \ + } \ + \ diff --git a/queue-6.12/series b/queue-6.12/series index b8dd9fc6b7..34e47d0efd 100644 --- a/queue-6.12/series +++ b/queue-6.12/series @@ -258,3 +258,87 @@ scsi-ufs-core-fix-use-after-free-in-init-error-and-remove-paths.patch 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 diff --git a/queue-6.12/soc-mediatek-mtk-devapc-fix-leaking-io-map-on-driver-remove.patch b/queue-6.12/soc-mediatek-mtk-devapc-fix-leaking-io-map-on-driver-remove.patch new file mode 100644 index 0000000000..9c711d7261 --- /dev/null +++ b/queue-6.12/soc-mediatek-mtk-devapc-fix-leaking-io-map-on-driver-remove.patch @@ -0,0 +1,31 @@ +From c9c0036c1990da8d2dd33563e327e05a775fcf10 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Sat, 4 Jan 2025 15:20:12 +0100 +Subject: soc: mediatek: mtk-devapc: Fix leaking IO map on driver remove + +From: Krzysztof Kozlowski + +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 +Link: https://lore.kernel.org/r/20250104142012.115974-2-krzysztof.kozlowski@linaro.org +Signed-off-by: AngeloGioacchino Del Regno +Signed-off-by: Greg Kroah-Hartman +--- + 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 = { diff --git a/queue-6.12/soc-mediatek-mtk-devapc-fix-leaking-io-map-on-error-paths.patch b/queue-6.12/soc-mediatek-mtk-devapc-fix-leaking-io-map-on-error-paths.patch new file mode 100644 index 0000000000..d16102de27 --- /dev/null +++ b/queue-6.12/soc-mediatek-mtk-devapc-fix-leaking-io-map-on-error-paths.patch @@ -0,0 +1,63 @@ +From c0eb059a4575ed57f265d9883a5203799c19982c Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Sat, 4 Jan 2025 15:20:11 +0100 +Subject: soc: mediatek: mtk-devapc: Fix leaking IO map on error paths + +From: Krzysztof Kozlowski + +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 +Link: https://lore.kernel.org/r/20250104142012.115974-1-krzysztof.kozlowski@linaro.org +Signed-off-by: AngeloGioacchino Del Regno +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-6.12/soc-qcom-llcc-enable-llcc_wrcache-at-boot-on-x1.patch b/queue-6.12/soc-qcom-llcc-enable-llcc_wrcache-at-boot-on-x1.patch new file mode 100644 index 0000000000..9ba8eba403 --- /dev/null +++ b/queue-6.12/soc-qcom-llcc-enable-llcc_wrcache-at-boot-on-x1.patch @@ -0,0 +1,43 @@ +From 35d8bc131de0f0f280f0db42499512d79f05f456 Mon Sep 17 00:00:00 2001 +From: Konrad Dybcio +Date: Thu, 19 Dec 2024 19:53:29 +0100 +Subject: soc: qcom: llcc: Enable LLCC_WRCACHE at boot on X1 + +From: Konrad Dybcio + +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 +Signed-off-by: Konrad Dybcio +Reviewed-by: Johan Hovold +Tested-by: Johan Hovold +Link: https://lore.kernel.org/r/20241219-topic-llcc_x1e_wrcache-v3-1-b9848d9c3d63@oss.qualcomm.com +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-6.12/soc-qcom-smem_state-fix-missing-of_node_put-in-error-path.patch b/queue-6.12/soc-qcom-smem_state-fix-missing-of_node_put-in-error-path.patch new file mode 100644 index 0000000000..51767bbe99 --- /dev/null +++ b/queue-6.12/soc-qcom-smem_state-fix-missing-of_node_put-in-error-path.patch @@ -0,0 +1,35 @@ +From 70096b4990848229d0784c5e51dc3c7c072f1111 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +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 + +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 +Reviewed-by: Dmitry Baryshkov +Link: https://lore.kernel.org/r/20240822164853.231087-2-krzysztof.kozlowski@linaro.org +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-6.12/soc-samsung-exynos-pmu-fix-uninitialized-ret-in-tensor_set_bits_atomic.patch b/queue-6.12/soc-samsung-exynos-pmu-fix-uninitialized-ret-in-tensor_set_bits_atomic.patch new file mode 100644 index 0000000000..6dd6401442 --- /dev/null +++ b/queue-6.12/soc-samsung-exynos-pmu-fix-uninitialized-ret-in-tensor_set_bits_atomic.patch @@ -0,0 +1,37 @@ +From eca836dfd8386b32f1aae60f8e323218ac6a0b75 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +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 + +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 +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-6.12/tpm-change-to-kvalloc-in-eventlog-acpi.c.patch b/queue-6.12/tpm-change-to-kvalloc-in-eventlog-acpi.c.patch new file mode 100644 index 0000000000..5da6797fb7 --- /dev/null +++ b/queue-6.12/tpm-change-to-kvalloc-in-eventlog-acpi.c.patch @@ -0,0 +1,84 @@ +From a3a860bc0fd6c07332e4911cf9a238d20de90173 Mon Sep 17 00:00:00 2001 +From: Jarkko Sakkinen +Date: Fri, 27 Dec 2024 17:39:09 +0200 +Subject: tpm: Change to kvalloc() in eventlog/acpi.c + +From: Jarkko Sakkinen + +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 +Cc: stable@vger.kernel.org # v2.6.16+ +Fixes: 55a82ab3181b ("[PATCH] tpm: add bios measurement log") +Reported-by: Andy Liang +Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219495 +Reviewed-by: Ard Biesheuvel +Reviewed-by: Stefan Berger +Reviewed-by: Takashi Iwai +Tested-by: Andy Liang +Signed-off-by: Jarkko Sakkinen +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-6.12/ubi-add-a-check-for-ubi_num.patch b/queue-6.12/ubi-add-a-check-for-ubi_num.patch new file mode 100644 index 0000000000..e1c81a6adb --- /dev/null +++ b/queue-6.12/ubi-add-a-check-for-ubi_num.patch @@ -0,0 +1,43 @@ +From 97bbf9e312c3fbaf0baa56120238825d2eb23b8a Mon Sep 17 00:00:00 2001 +From: Denis Arefev +Date: Mon, 2 Dec 2024 12:36:52 +0300 +Subject: ubi: Add a check for ubi_num + +From: Denis Arefev + +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 +Reviewed-by: Zhihao Cheng +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.12/x86-acpi-fix-lapic-x2apic-parsing-order.patch b/queue-6.12/x86-acpi-fix-lapic-x2apic-parsing-order.patch new file mode 100644 index 0000000000..d7c2cea299 --- /dev/null +++ b/queue-6.12/x86-acpi-fix-lapic-x2apic-parsing-order.patch @@ -0,0 +1,131 @@ +From 0141978ae75bd48bac13fca6de131a5071c32011 Mon Sep 17 00:00:00 2001 +From: Zhang Rui +Date: Fri, 17 Jan 2025 16:14:20 +0800 +Subject: x86/acpi: Fix LAPIC/x2APIC parsing order + +From: Zhang Rui + +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 +Reported-by: Jim Mattson +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 +Reviewed-by: Jim Mattson +Tested-by: Jim Mattson +Reviewed-by: Thomas Gleixner +Link: https://patch.msgid.link/20250117081420.4046737-1-rui.zhang@intel.com +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + 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"); diff --git a/queue-6.12/x86-boot-use-std-gnu11-to-fix-build-with-gcc-15.patch b/queue-6.12/x86-boot-use-std-gnu11-to-fix-build-with-gcc-15.patch new file mode 100644 index 0000000000..9262bc5975 --- /dev/null +++ b/queue-6.12/x86-boot-use-std-gnu11-to-fix-build-with-gcc-15.patch @@ -0,0 +1,52 @@ +From ee2ab467bddfb2d7f68d996dbab94d7b88f8eaf7 Mon Sep 17 00:00:00 2001 +From: Nathan Chancellor +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 + +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 +Reported-by: Jakub Jelinek +Signed-off-by: Nathan Chancellor +Signed-off-by: Dave Hansen +Reviewed-by: Ard Biesheuvel +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 +--- + 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 diff --git a/queue-6.12/x86-rust-set-rustc-abi-x86-softfloat-on-rustc-1.86.0.patch b/queue-6.12/x86-rust-set-rustc-abi-x86-softfloat-on-rustc-1.86.0.patch new file mode 100644 index 0000000000..f26d1653eb --- /dev/null +++ b/queue-6.12/x86-rust-set-rustc-abi-x86-softfloat-on-rustc-1.86.0.patch @@ -0,0 +1,88 @@ +From 6273a058383e05465083b535ed9469f2c8a48321 Mon Sep 17 00:00:00 2001 +From: Alice Ryhl +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 + +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: # 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 +Acked-by: Dave Hansen # 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 +Signed-off-by: Greg Kroah-Hartman +--- + 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::() ++ .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 + diff --git a/queue-6.12/xfs-add-error-handling-for-xfs_reflink_cancel_cow_range.patch b/queue-6.12/xfs-add-error-handling-for-xfs_reflink_cancel_cow_range.patch new file mode 100644 index 0000000000..49b687ed64 --- /dev/null +++ b/queue-6.12/xfs-add-error-handling-for-xfs_reflink_cancel_cow_range.patch @@ -0,0 +1,42 @@ +From 26b63bee2f6e711c5a169997fd126fddcfb90848 Mon Sep 17 00:00:00 2001 +From: Wentao Liang +Date: Fri, 24 Jan 2025 11:45:09 +0800 +Subject: xfs: Add error handling for xfs_reflink_cancel_cow_range + +From: Wentao Liang + +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 +Signed-off-by: Wentao Liang +Signed-off-by: Carlos Maiolino +Signed-off-by: Greg Kroah-Hartman +--- + 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) { + /* diff --git a/queue-6.12/xfs-don-t-call-remap_verify_area-with-sb-write-protection-held.patch b/queue-6.12/xfs-don-t-call-remap_verify_area-with-sb-write-protection-held.patch new file mode 100644 index 0000000000..aca6d2d2e1 --- /dev/null +++ b/queue-6.12/xfs-don-t-call-remap_verify_area-with-sb-write-protection-held.patch @@ -0,0 +1,164 @@ +From f5f0ed89f13e3e5246404a322ee85169a226bfb5 Mon Sep 17 00:00:00 2001 +From: Christoph Hellwig +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 + +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: # v6.10 +Signed-off-by: Christoph Hellwig +Reviewed-by: Darrick J. Wong +Signed-off-by: Carlos Maiolino +Signed-off-by: Greg Kroah-Hartman +--- + 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)) diff --git a/queue-6.12/xfs-propagate-errors-from-xfs_reflink_cancel_cow_range-in-xfs_dax_write_iomap_end.patch b/queue-6.12/xfs-propagate-errors-from-xfs_reflink_cancel_cow_range-in-xfs_dax_write_iomap_end.patch new file mode 100644 index 0000000000..8f503eb8b9 --- /dev/null +++ b/queue-6.12/xfs-propagate-errors-from-xfs_reflink_cancel_cow_range-in-xfs_dax_write_iomap_end.patch @@ -0,0 +1,38 @@ +From fb95897b8c60653805aa09daec575ca30983f768 Mon Sep 17 00:00:00 2001 +From: Wentao Liang +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 + +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 +Signed-off-by: Wentao Liang +Signed-off-by: Carlos Maiolino +Signed-off-by: Greg Kroah-Hartman +--- + 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); + }