--- /dev/null
+From 7f5704b6a143b8eca640cba820968e798d065e91 Mon Sep 17 00:00:00 2001
+From: Aubrey Li <aubrey.li@linux.intel.com>
+Date: Sun, 26 Jan 2025 10:22:50 +0800
+Subject: ACPI: PRM: Remove unnecessary strict handler address checks
+
+From: Aubrey Li <aubrey.li@linux.intel.com>
+
+commit 7f5704b6a143b8eca640cba820968e798d065e91 upstream.
+
+Commit 088984c8d54c ("ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM
+handler and context") added unnecessary strict handler address checks,
+causing the PRM module to fail in translating memory error addresses.
+
+Both static data buffer address and ACPI parameter buffer address may
+be NULL if they are not needed, as described in section 4.1.2 PRM Handler
+Information Structure of Platform Runtime Mechanism specification [1].
+
+Here are two examples from real hardware:
+
+----PRMT.dsl----
+
+- staic data address is not used
+[10Ch 0268 2] Revision : 0000
+[10Eh 0270 2] Length : 002C
+[110h 0272 16] Handler GUID : F6A58D47-E04F-4F5A-86B8-2A50D4AA109B
+[120h 0288 8] Handler address : 0000000065CE51F4
+[128h 0296 8] Satic Data Address : 0000000000000000
+[130h 0304 8] ACPI Parameter Address : 000000006522A718
+
+- ACPI parameter address is not used
+[1B0h 0432 2] Revision : 0000
+[1B2h 0434 2] Length : 002C
+[1B4h 0436 16] Handler GUID : 657E8AE6-A8FC-4877-BB28-42E7DE1899A5
+[1C4h 0452 8] Handler address : 0000000065C567C8
+[1CCh 0460 8] Satic Data Address : 000000006113FB98
+[1D4h 0468 8] ACPI Parameter Address : 0000000000000000
+
+Fixes: 088984c8d54c ("ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context")
+Reported-and-tested-by: Shi Liu <aurelianliu@tencent.com>
+Cc: All applicable <stable@vger.kernel.org>
+Signed-off-by: Aubrey Li <aubrey.li@linux.intel.com>
+Link: https://uefi.org/sites/default/files/resources/Platform%20Runtime%20Mechanism%20-%20with%20legal%20notice.pdf # [1]
+Reviewed-by: Koba Ko <kobak@nvidia.com>
+Acked-by: Ard Biesheuvel <ardb@kernel.org>
+Link: https://patch.msgid.link/20250126022250.3014210-1-aubrey.li@linux.intel.com
+[ rjw: Minor changelog edits ]
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/prmt.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/drivers/acpi/prmt.c
++++ b/drivers/acpi/prmt.c
+@@ -263,9 +263,7 @@ static acpi_status acpi_platformrt_space
+ if (!handler || !module)
+ goto invalid_guid;
+
+- if (!handler->handler_addr ||
+- !handler->static_data_buffer_addr ||
+- !handler->acpi_param_buffer_addr) {
++ if (!handler->handler_addr) {
+ buffer->prm_status = PRM_HANDLER_ERROR;
+ return AE_OK;
+ }
--- /dev/null
+From b0805a864459a29831577d2a47165afebe338faf Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Fri, 13 Dec 2024 15:54:04 +0100
+Subject: arm64: dts: qcom: sm6350: Fix ADSP memory length
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit b0805a864459a29831577d2a47165afebe338faf upstream.
+
+The address space in ADSP (Peripheral Authentication Service) remoteproc
+node should point to the QDSP PUB address space (QDSP6...SS_PUB) which
+has a length of 0x10000.
+
+This should have no functional impact on Linux users, because PAS loader
+does not use this address space at all.
+
+Fixes: efc33c969f23 ("arm64: dts: qcom: sm6350: Add ADSP nodes")
+Cc: stable@vger.kernel.org
+Tested-by: Luca Weiss <luca.weiss@fairphone.com>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-15-2e0036fccd8d@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sm6350.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/qcom/sm6350.dtsi
++++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi
+@@ -855,7 +855,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_LEVEL_HIGH>,
+ <&smp2p_adsp_in 0 IRQ_TYPE_EDGE_RISING>,
--- /dev/null
+From cd8d83de9cc9ecfb1f9a12bc838041c4eb4d10bd Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Fri, 13 Dec 2024 15:54:05 +0100
+Subject: arm64: dts: qcom: sm6350: Fix MPSS memory length
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit cd8d83de9cc9ecfb1f9a12bc838041c4eb4d10bd upstream.
+
+The address space in MPSS/Modem PAS (Peripheral Authentication Service)
+remoteproc node should point to the QDSP PUB address space
+(QDSP6...SS_PUB) which has a length of 0x10000. Value of 0x4040 was
+copied from older DTS, but it grew since then.
+
+This should have no functional impact on Linux users, because PAS loader
+does not use this address space at all.
+
+Fixes: 489be59b635b ("arm64: dts: qcom: sm6350: Add MPSS nodes")
+Cc: stable@vger.kernel.org
+Tested-by: Luca Weiss <luca.weiss@fairphone.com>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-16-2e0036fccd8d@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sm6350.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/qcom/sm6350.dtsi
++++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi
+@@ -923,7 +923,7 @@
+
+ mpss: remoteproc@4080000 {
+ compatible = "qcom,sm6350-mpss-pas";
+- reg = <0x0 0x04080000 0x0 0x4040>;
++ reg = <0x0 0x04080000 0x0 0x10000>;
+
+ interrupts-extended = <&intc GIC_SPI 136 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
--- /dev/null
+From da1937dec9cd986e685b6a429b528a4cbc7b1603 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Fri, 13 Dec 2024 15:53:52 +0100
+Subject: arm64: dts: qcom: sm8350: Fix MPSS memory length
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit da1937dec9cd986e685b6a429b528a4cbc7b1603 upstream.
+
+The address space in MPSS/Modem PAS (Peripheral Authentication Service)
+remoteproc node should point to the QDSP PUB address space
+(QDSP6...SS_PUB) which has a length of 0x10000. Value of 0x4040 was
+copied from older DTS, but it grew since then.
+
+This should have no functional impact on Linux users, because PAS loader
+does not use this address space at all.
+
+Fixes: 177fcf0aeda2 ("arm64: dts: qcom: sm8350: Add remoteprocs")
+Cc: stable@vger.kernel.org
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-3-2e0036fccd8d@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sm8350.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
++++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
+@@ -1641,7 +1641,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_LEVEL_HIGH>,
+ <&smp2p_modem_in 0 IRQ_TYPE_EDGE_RISING>,
--- /dev/null
+From fa6442e87ab7c4a58c0b5fc64aab1aacc8034712 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Fri, 13 Dec 2024 15:53:55 +0100
+Subject: arm64: dts: qcom: sm8450: Fix MPSS memory length
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit fa6442e87ab7c4a58c0b5fc64aab1aacc8034712 upstream.
+
+The address space in MPSS/Modem PAS (Peripheral Authentication Service)
+remoteproc node should point to the QDSP PUB address space
+(QDSP6...SS_PUB) which has a length of 0x10000. Value of 0x4040 was
+copied from older DTS, but it grew since then.
+
+This should have no functional impact on Linux users, because PAS loader
+does not use this address space at all.
+
+Fixes: 1172729576fb ("arm64: dts: qcom: sm8450: Add remoteproc enablers and instances")
+Cc: stable@vger.kernel.org
+Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Link: https://lore.kernel.org/r/20241213-dts-qcom-cdsp-mpss-base-address-v3-6-2e0036fccd8d@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sm8450.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
++++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
+@@ -2265,7 +2265,7 @@
+
+ remoteproc_mpss: remoteproc@4080000 {
+ compatible = "qcom,sm8450-mpss-pas";
+- reg = <0x0 0x04080000 0x0 0x4040>;
++ reg = <0x0 0x04080000 0x0 0x10000>;
+
+ interrupts-extended = <&intc GIC_SPI 264 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_modem_in 0 IRQ_TYPE_EDGE_RISING>,
--- /dev/null
+From a5e6fc0a10fe280989f1367a3b4f8047c7d00ea6 Mon Sep 17 00:00:00 2001
+From: Sumit Gupta <sumitg@nvidia.com>
+Date: Wed, 18 Dec 2024 00:07:37 +0000
+Subject: arm64: tegra: Disable Tegra234 sce-fabric node
+
+From: Sumit Gupta <sumitg@nvidia.com>
+
+commit a5e6fc0a10fe280989f1367a3b4f8047c7d00ea6 upstream.
+
+Access to safety cluster engine (SCE) fabric registers was blocked
+by firewall after the introduction of Functional Safety Island in
+Tegra234. After that, any access by software to SCE registers is
+correctly resulting in the internal bus error. However, when CPUs
+try accessing the SCE-fabric registers to print error info,
+another firewall error occurs as the fabric registers are also
+firewall protected. This results in a second error to be printed.
+Disable the SCE fabric node to avoid printing the misleading error.
+The first error info will be printed by the interrupt from the
+fabric causing the actual access.
+
+Cc: stable@vger.kernel.org
+Fixes: 302e154000ec ("arm64: tegra: Add node for CBB 2.0 on Tegra234")
+Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
+Signed-off-by: Ivy Huang <yijuh@nvidia.com>
+Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
+Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
+Link: https://lore.kernel.org/r/20241218000737.1789569-3-yijuh@nvidia.com
+Signed-off-by: Thierry Reding <treding@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/nvidia/tegra234.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/nvidia/tegra234.dtsi
++++ b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
+@@ -1249,7 +1249,7 @@
+ compatible = "nvidia,tegra234-sce-fabric";
+ reg = <0xb600000 0x40000>;
+ interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
+- status = "okay";
++ status = "disabled";
+ };
+
+ rce-fabric@be00000 {
--- /dev/null
+From 49b9258b05b97c6464e1964b6a2fddb3ddb65d17 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Tue, 3 Dec 2024 10:05:53 -0800
+Subject: crypto: qce - fix priority to be less than ARMv8 CE
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit 49b9258b05b97c6464e1964b6a2fddb3ddb65d17 upstream.
+
+As QCE is an order of magnitude slower than the ARMv8 Crypto Extensions
+on the CPU, and is also less well tested, give it a lower priority.
+Previously the QCE SHA algorithms had higher priority than the ARMv8 CE
+equivalents, and the ciphers such as AES-XTS had the same priority which
+meant the QCE versions were chosen if they happened to be loaded later.
+
+Fixes: ec8f5d8f6f76 ("crypto: qce - Qualcomm crypto engine driver")
+Cc: stable@vger.kernel.org
+Cc: Bartosz Golaszewski <brgl@bgdev.pl>
+Cc: Neil Armstrong <neil.armstrong@linaro.org>
+Cc: Thara Gopinath <thara.gopinath@gmail.com>
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/crypto/qce/aead.c | 2 +-
+ drivers/crypto/qce/sha.c | 2 +-
+ drivers/crypto/qce/skcipher.c | 2 +-
+ 3 files changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/crypto/qce/aead.c
++++ b/drivers/crypto/qce/aead.c
+@@ -786,7 +786,7 @@ static int qce_aead_register_one(const s
+ alg->init = qce_aead_init;
+ alg->exit = qce_aead_exit;
+
+- alg->base.cra_priority = 300;
++ alg->base.cra_priority = 275;
+ alg->base.cra_flags = CRYPTO_ALG_ASYNC |
+ CRYPTO_ALG_ALLOCATES_MEMORY |
+ CRYPTO_ALG_KERN_DRIVER_ONLY |
+--- a/drivers/crypto/qce/sha.c
++++ b/drivers/crypto/qce/sha.c
+@@ -482,7 +482,7 @@ static int qce_ahash_register_one(const
+
+ base = &alg->halg.base;
+ base->cra_blocksize = def->blocksize;
+- base->cra_priority = 300;
++ base->cra_priority = 175;
+ base->cra_flags = CRYPTO_ALG_ASYNC | CRYPTO_ALG_KERN_DRIVER_ONLY;
+ base->cra_ctxsize = sizeof(struct qce_sha_ctx);
+ base->cra_alignmask = 0;
+--- a/drivers/crypto/qce/skcipher.c
++++ b/drivers/crypto/qce/skcipher.c
+@@ -461,7 +461,7 @@ static int qce_skcipher_register_one(con
+ alg->encrypt = qce_skcipher_encrypt;
+ alg->decrypt = qce_skcipher_decrypt;
+
+- alg->base.cra_priority = 300;
++ alg->base.cra_priority = 275;
+ alg->base.cra_flags = CRYPTO_ALG_ASYNC |
+ CRYPTO_ALG_ALLOCATES_MEMORY |
+ CRYPTO_ALG_KERN_DRIVER_ONLY;
--- /dev/null
+From ab09c6cfe01b317f515bcd944668697241a54b9d Mon Sep 17 00:00:00 2001
+From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+Date: Sat, 14 Dec 2024 23:55:50 +0100
+Subject: iio: light: as73211: fix channel handling in only-color triggered buffer
+
+From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+commit ab09c6cfe01b317f515bcd944668697241a54b9d upstream.
+
+The channel index is off by one unit if AS73211_SCAN_MASK_ALL is not
+set (optimized path for color channel readings), and it must be shifted
+instead of leaving an empty channel for the temperature when it is off.
+
+Once the channel index is fixed, the uninitialized channel must be set
+to zero to avoid pushing uninitialized data.
+
+Add available_scan_masks for all channels and only-color channels to let
+the IIO core demux and repack the enabled channels.
+
+Cc: stable@vger.kernel.org
+Fixes: 403e5586b52e ("iio: light: as73211: New driver")
+Tested-by: Christian Eggers <ceggers@arri.de>
+Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+Link: https://patch.msgid.link/20241214-iio_memset_scan_holes-v4-1-260b395b8ed5@gmail.com
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/light/as73211.c | 24 ++++++++++++++++++++----
+ 1 file changed, 20 insertions(+), 4 deletions(-)
+
+--- a/drivers/iio/light/as73211.c
++++ b/drivers/iio/light/as73211.c
+@@ -154,6 +154,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,
+@@ -602,9 +608,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) {
+@@ -612,9 +621,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));
+@@ -684,6 +699,7 @@ static int as73211_probe(struct i2c_clie
+ indio_dev->channels = as73211_channels;
+ indio_dev->num_channels = ARRAY_SIZE(as73211_channels);
+ indio_dev->modes = INDIO_DIRECT_MODE;
++ indio_dev->available_scan_masks = as73211_scan_masks;
+
+ ret = i2c_smbus_read_byte_data(data->client, AS73211_REG_OSR);
+ if (ret < 0)
--- /dev/null
+From e64f81946adf68cd75e2207dd9a51668348a4af8 Mon Sep 17 00:00:00 2001
+From: Marco Elver <elver@google.com>
+Date: Fri, 24 Jan 2025 13:01:38 +0100
+Subject: kfence: skip __GFP_THISNODE allocations on NUMA systems
+
+From: Marco Elver <elver@google.com>
+
+commit e64f81946adf68cd75e2207dd9a51668348a4af8 upstream.
+
+On NUMA systems, __GFP_THISNODE indicates that an allocation _must_ be on
+a particular node, and failure to allocate on the desired node will result
+in a failed allocation.
+
+Skip __GFP_THISNODE allocations if we are running on a NUMA system, since
+KFENCE can't guarantee which node its pool pages are allocated on.
+
+Link: https://lkml.kernel.org/r/20250124120145.410066-1-elver@google.com
+Fixes: 236e9f153852 ("kfence: skip all GFP_ZONEMASK allocations")
+Signed-off-by: Marco Elver <elver@google.com>
+Reported-by: Vlastimil Babka <vbabka@suse.cz>
+Acked-by: Vlastimil Babka <vbabka@suse.cz>
+Cc: Christoph Lameter <cl@linux.com>
+Cc: Alexander Potapenko <glider@google.com>
+Cc: Chistoph Lameter <cl@linux.com>
+Cc: Dmitriy Vyukov <dvyukov@google.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/kfence/core.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/mm/kfence/core.c
++++ b/mm/kfence/core.c
+@@ -21,6 +21,7 @@
+ #include <linux/log2.h>
+ #include <linux/memblock.h>
+ #include <linux/moduleparam.h>
++#include <linux/nodemask.h>
+ #include <linux/notifier.h>
+ #include <linux/panic_notifier.h>
+ #include <linux/random.h>
+@@ -997,6 +998,7 @@ void *__kfence_alloc(struct kmem_cache *
+ * properties (e.g. reside in DMAable memory).
+ */
+ if ((flags & GFP_ZONEMASK) ||
++ ((flags & __GFP_THISNODE) && num_online_nodes() > 1) ||
+ (s->flags & (SLAB_CACHE_DMA | SLAB_CACHE_DMA32))) {
+ atomic_long_inc(&counters[KFENCE_COUNTER_SKIP_INCOMPAT]);
+ return NULL;
--- /dev/null
+From da73efa8e675a2b58f1c7ae61201acfe57714bf7 Mon Sep 17 00:00:00 2001
+From: Sakari Ailus <sakari.ailus@linux.intel.com>
+Date: Tue, 3 Dec 2024 12:23:01 +0200
+Subject: media: ccs: Clean up parsed CCS static data on parse failure
+
+From: Sakari Ailus <sakari.ailus@linux.intel.com>
+
+commit da73efa8e675a2b58f1c7ae61201acfe57714bf7 upstream.
+
+ccs_data_parse() releases the allocated in-memory data structure when the
+parser fails, but it does not clean up parsed metadata that is there to
+help access the actual data. Do that, in order to return the data
+structure in a sane state.
+
+Fixes: a6b396f410b1 ("media: ccs: Add CCS static data parser library")
+Cc: stable@vger.kernel.org
+Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/i2c/ccs/ccs-data.c | 12 +++++++-----
+ 1 file changed, 7 insertions(+), 5 deletions(-)
+
+--- a/drivers/media/i2c/ccs/ccs-data.c
++++ b/drivers/media/i2c/ccs/ccs-data.c
+@@ -10,6 +10,7 @@
+ #include <linux/limits.h>
+ #include <linux/mm.h>
+ #include <linux/slab.h>
++#include <linux/string.h>
+
+ #include "ccs-data-defs.h"
+
+@@ -948,15 +949,15 @@ int ccs_data_parse(struct ccs_data_conta
+
+ rval = __ccs_data_parse(&bin, ccsdata, data, len, dev, verbose);
+ if (rval)
+- return rval;
++ goto out_cleanup;
+
+ rval = bin_backing_alloc(&bin);
+ if (rval)
+- return rval;
++ goto out_cleanup;
+
+ rval = __ccs_data_parse(&bin, ccsdata, data, len, dev, false);
+ if (rval)
+- goto out_free;
++ goto out_cleanup;
+
+ if (verbose && ccsdata->version)
+ print_ccs_data_version(dev, ccsdata->version);
+@@ -965,15 +966,16 @@ int ccs_data_parse(struct ccs_data_conta
+ rval = -EPROTO;
+ dev_dbg(dev, "parsing mismatch; base %p; now %p; end %p\n",
+ bin.base, bin.now, bin.end);
+- goto out_free;
++ goto out_cleanup;
+ }
+
+ ccsdata->backing = bin.base;
+
+ return 0;
+
+-out_free:
++out_cleanup:
+ kvfree(bin.base);
++ memset(ccsdata, 0, sizeof(*ccsdata));
+
+ return rval;
+ }
--- /dev/null
+From 82b696750f0b60e7513082a10ad42786854f59f8 Mon Sep 17 00:00:00 2001
+From: Sakari Ailus <sakari.ailus@linux.intel.com>
+Date: Tue, 3 Dec 2024 10:10:23 +0200
+Subject: media: ccs: Fix CCS static data parsing for large block sizes
+
+From: Sakari Ailus <sakari.ailus@linux.intel.com>
+
+commit 82b696750f0b60e7513082a10ad42786854f59f8 upstream.
+
+The length field of the CCS static data blocks was mishandled, leading to
+wrong interpretation of the length header for blocks that are 16 kiB in
+size. Such large blocks are very, very rare and so this wasn't found
+earlier.
+
+As the length is used as part of input validation, the issue has no
+security implications.
+
+Fixes: a6b396f410b1 ("media: ccs: Add CCS static data parser library")
+Cc: stable@vger.kernel.org
+Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/i2c/ccs/ccs-data.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/media/i2c/ccs/ccs-data.c
++++ b/drivers/media/i2c/ccs/ccs-data.c
+@@ -98,7 +98,7 @@ ccs_data_parse_length_specifier(const st
+ plen = ((size_t)
+ (__len3->length[0] &
+ ((1 << CCS_DATA_LENGTH_SPECIFIER_SIZE_SHIFT) - 1))
+- << 16) + (__len3->length[0] << 8) + __len3->length[1];
++ << 16) + (__len3->length[1] << 8) + __len3->length[2];
+ break;
+ }
+ default:
--- /dev/null
+From 6fdbff0f54786e94f0f630ff200ec1d666b1633e Mon Sep 17 00:00:00 2001
+From: Mehdi Djait <mehdi.djait@linux.intel.com>
+Date: Wed, 11 Dec 2024 14:30:45 +0100
+Subject: media: ccs: Fix cleanup order in ccs_probe()
+
+From: Mehdi Djait <mehdi.djait@linux.intel.com>
+
+commit 6fdbff0f54786e94f0f630ff200ec1d666b1633e upstream.
+
+ccs_limits is allocated in ccs_read_all_limits() after the allocation of
+mdata.backing. Ensure that resources are freed in the reverse order of
+their allocation by moving out_free_ccs_limits up.
+
+Fixes: a11d3d6891f0 ("media: ccs: Read CCS static data from firmware binaries")
+Cc: stable@vger.kernel.org
+Signed-off-by: Mehdi Djait <mehdi.djait@linux.intel.com>
+Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/i2c/ccs/ccs-core.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/media/i2c/ccs/ccs-core.c
++++ b/drivers/media/i2c/ccs/ccs-core.c
+@@ -3649,15 +3649,15 @@ out_media_entity_cleanup:
+ out_cleanup:
+ ccs_cleanup(sensor);
+
++out_free_ccs_limits:
++ kfree(sensor->ccs_limits);
++
+ out_release_mdata:
+ kvfree(sensor->mdata.backing);
+
+ out_release_sdata:
+ kvfree(sensor->sdata.backing);
+
+-out_free_ccs_limits:
+- kfree(sensor->ccs_limits);
+-
+ out_power_off:
+ ccs_power_off(&client->dev);
+ mutex_destroy(&sensor->mutex);
--- /dev/null
+From fb2bd86270cd0ad004f4c614ba4f8c63a5720e25 Mon Sep 17 00:00:00 2001
+From: Cosmin Tanislav <demonsingur@gmail.com>
+Date: Fri, 22 Nov 2024 16:55:24 +0200
+Subject: media: mc: fix endpoint iteration
+
+From: Cosmin Tanislav <demonsingur@gmail.com>
+
+commit fb2bd86270cd0ad004f4c614ba4f8c63a5720e25 upstream.
+
+When creating links from a subdev to a sink, the current logic tries to
+iterate over the endpoints of dev's fwnode.
+
+This might not be correct when the subdev uses a different fwnode
+compared to the dev's fwnode.
+
+If, when registering, the subdev's fwnode is not set, the code inside
+v4l2_async_register_subdev will set it to the dev's fwnode.
+
+To fix this, just use the subdev's fwnode.
+
+Signed-off-by: Cosmin Tanislav <demonsingur@gmail.com>
+Fixes: 0d3c81e82da9 ("media: v4l2-mc: add v4l2_create_fwnode_links helpers")
+Cc: stable@vger.kernel.org
+Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
+Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/v4l2-core/v4l2-mc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/media/v4l2-core/v4l2-mc.c
++++ b/drivers/media/v4l2-core/v4l2-mc.c
+@@ -321,7 +321,7 @@ int v4l2_create_fwnode_links_to_pad(stru
+
+ sink_sd = media_entity_to_v4l2_subdev(sink->entity);
+
+- fwnode_graph_for_each_endpoint(dev_fwnode(src_sd->dev), endpoint) {
++ fwnode_graph_for_each_endpoint(src_sd->fwnode, endpoint) {
+ struct fwnode_handle *remote_ep;
+ int src_idx, sink_idx, ret;
+ struct media_pad *src;
--- /dev/null
+From 001d3753538d26ddcbef011f5643cfff58a7f672 Mon Sep 17 00:00:00 2001
+From: Sam Bobrowicz <sam@elite-embedded.com>
+Date: Fri, 22 Nov 2024 09:28:01 +0100
+Subject: media: ov5640: fix get_light_freq on auto
+
+From: Sam Bobrowicz <sam@elite-embedded.com>
+
+commit 001d3753538d26ddcbef011f5643cfff58a7f672 upstream.
+
+Light frequency was not properly returned when in auto
+mode and the detected frequency was 60Hz.
+
+Fixes: 19a81c1426c1 ("[media] add Omnivision OV5640 sensor driver")
+Cc: stable@vger.kernel.org
+Signed-off-by: Sam Bobrowicz <sam@elite-embedded.com>
+Signed-off-by: Michal Simek <michal.simek@amd.com>
+Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/i2c/ov5640.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/media/i2c/ov5640.c
++++ b/drivers/media/i2c/ov5640.c
+@@ -1971,6 +1971,7 @@ static int ov5640_get_light_freq(struct
+ light_freq = 50;
+ } else {
+ /* 60Hz */
++ light_freq = 60;
+ }
+ }
+
--- /dev/null
+From c31cffd5ae2c3d7ef21d9008977a9d117ce7a64e Mon Sep 17 00:00:00 2001
+From: Ricardo Ribalda <ribalda@chromium.org>
+Date: Thu, 14 Nov 2024 19:10:30 +0000
+Subject: media: uvcvideo: Fix event flags in uvc_ctrl_send_events
+
+From: Ricardo Ribalda <ribalda@chromium.org>
+
+commit c31cffd5ae2c3d7ef21d9008977a9d117ce7a64e upstream.
+
+If there is an event that needs the V4L2_EVENT_CTRL_CH_FLAGS flag, all
+the following events will have that flag, regardless if they need it or
+not.
+
+This is because we keep using the same variable all the time and we do
+not reset its original value.
+
+Cc: stable@vger.kernel.org
+Fixes: 805e9b4a06bf ("[media] uvcvideo: Send control change events for slave ctrls when the master changes")
+Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
+Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Link: https://lore.kernel.org/r/20241114-uvc-roi-v15-1-64cfeb56b6f8@chromium.org
+Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/uvc/uvc_ctrl.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/media/usb/uvc/uvc_ctrl.c
++++ b/drivers/media/usb/uvc/uvc_ctrl.c
+@@ -1564,13 +1564,13 @@ static void uvc_ctrl_send_events(struct
+ {
+ struct uvc_control_mapping *mapping;
+ struct uvc_control *ctrl;
+- u32 changes = V4L2_EVENT_CTRL_CH_VALUE;
+ unsigned int i;
+ unsigned int j;
+
+ for (i = 0; i < xctrls_count; ++i) {
+- ctrl = uvc_find_control(handle->chain, xctrls[i].id, &mapping);
++ u32 changes = V4L2_EVENT_CTRL_CH_VALUE;
+
++ ctrl = uvc_find_control(handle->chain, xctrls[i].id, &mapping);
+ if (ctrl->info.flags & UVC_CTRL_FLAG_ASYNCHRONOUS)
+ /* Notification will be sent from an Interrupt event. */
+ continue;
--- /dev/null
+From 04d3398f66d2d31c4b8caea88f051a4257b7a161 Mon Sep 17 00:00:00 2001
+From: Ricardo Ribalda <ribalda@chromium.org>
+Date: Tue, 3 Dec 2024 21:20:09 +0000
+Subject: media: uvcvideo: Remove redundant NULL assignment
+
+From: Ricardo Ribalda <ribalda@chromium.org>
+
+commit 04d3398f66d2d31c4b8caea88f051a4257b7a161 upstream.
+
+ctrl->handle will only be different than NULL for controls that have
+mappings. This is because that assignment is only done inside
+uvc_ctrl_set() for mapped controls.
+
+Cc: stable@vger.kernel.org
+Fixes: e5225c820c05 ("media: uvcvideo: Send a control event when a Control Change interrupt arrives")
+Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Reviewed-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
+Link: https://lore.kernel.org/r/20241203-uvc-fix-async-v6-2-26c867231118@chromium.org
+Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/uvc/uvc_ctrl.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/drivers/media/usb/uvc/uvc_ctrl.c
++++ b/drivers/media/usb/uvc/uvc_ctrl.c
+@@ -1531,10 +1531,8 @@ bool uvc_ctrl_status_event_async(struct
+ struct uvc_device *dev = chain->dev;
+ struct uvc_ctrl_work *w = &dev->async_ctrl;
+
+- if (list_empty(&ctrl->info.mappings)) {
+- ctrl->handle = NULL;
++ if (list_empty(&ctrl->info.mappings))
+ return false;
+- }
+
+ w->data = data;
+ w->urb = urb;
--- /dev/null
+From 488b5b9eca68497b533ced059be5eff19578bbca Mon Sep 17 00:00:00 2001
+From: Catalin Marinas <catalin.marinas@arm.com>
+Date: Mon, 27 Jan 2025 18:42:33 +0000
+Subject: mm: kmemleak: fix upper boundary check for physical address objects
+
+From: Catalin Marinas <catalin.marinas@arm.com>
+
+commit 488b5b9eca68497b533ced059be5eff19578bbca upstream.
+
+Memblock allocations are registered by kmemleak separately, based on their
+physical address. During the scanning stage, it checks whether an object
+is within the min_low_pfn and max_low_pfn boundaries and ignores it
+otherwise.
+
+With the recent addition of __percpu pointer leak detection (commit
+6c99d4eb7c5e ("kmemleak: enable tracking for percpu pointers")), kmemleak
+started reporting leaks in setup_zone_pageset() and
+setup_per_cpu_pageset(). These were caused by the node_data[0] object
+(initialised in alloc_node_data()) ending on the PFN_PHYS(max_low_pfn)
+boundary. The non-strict upper boundary check introduced by commit
+84c326299191 ("mm: kmemleak: check physical address when scan") causes the
+pg_data_t object to be ignored (not scanned) and the __percpu pointers it
+contains to be reported as leaks.
+
+Make the max_low_pfn upper boundary check strict when deciding whether to
+ignore a physical address object and not scan it.
+
+Link: https://lkml.kernel.org/r/20250127184233.2974311-1-catalin.marinas@arm.com
+Fixes: 84c326299191 ("mm: kmemleak: check physical address when scan")
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Reported-by: Jakub Kicinski <kuba@kernel.org>
+Tested-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Cc: Patrick Wang <patrick.wang.shcn@gmail.com>
+Cc: <stable@vger.kernel.org> [6.0.x]
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/kmemleak.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/mm/kmemleak.c
++++ b/mm/kmemleak.c
+@@ -1520,7 +1520,7 @@ static void kmemleak_scan(void)
+ unsigned long phys = object->pointer;
+
+ if (PHYS_PFN(phys) < min_low_pfn ||
+- PHYS_PFN(phys + object->size) >= max_low_pfn)
++ PHYS_PFN(phys + object->size) > max_low_pfn)
+ __paint_it(object, KMEMLEAK_BLACK);
+ }
+
--- /dev/null
+From 8259cb14a70680553d5e82d65d1302fe589e9b39 Mon Sep 17 00:00:00 2001
+From: Gabriele Monaco <gmonaco@redhat.com>
+Date: Wed, 15 Jan 2025 16:15:48 +0100
+Subject: rv: Reset per-task monitors also for idle tasks
+
+From: Gabriele Monaco <gmonaco@redhat.com>
+
+commit 8259cb14a70680553d5e82d65d1302fe589e9b39 upstream.
+
+RV per-task monitors are implemented through a monitor structure
+available for each task_struct. This structure is reset every time the
+monitor is (re-)started, to avoid inconsistencies if the monitor was
+activated previously.
+To do so, we reset the monitor on all threads using the macro
+for_each_process_thread. However, this macro excludes the idle tasks on
+each CPU. Idle tasks could be considered tasks on their own right and it
+should be up to the model whether to ignore them or not.
+
+Reset monitors also on the idle tasks for each present CPU whenever we
+reset all per-task monitors.
+
+Cc: stable@vger.kernel.org
+Cc: Juri Lelli <juri.lelli@redhat.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: John Kacur <jkacur@redhat.com>
+Link: https://lore.kernel.org/20250115151547.605750-2-gmonaco@redhat.com
+Fixes: 792575348ff7 ("rv/include: Add deterministic automata monitor definition via C macros")
+Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/rv/da_monitor.h | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/include/rv/da_monitor.h b/include/rv/da_monitor.h
+index 9705b2a98e49..510c88bfabd4 100644
+--- a/include/rv/da_monitor.h
++++ b/include/rv/da_monitor.h
+@@ -14,6 +14,7 @@
+ #include <rv/automata.h>
+ #include <linux/rv.h>
+ #include <linux/bug.h>
++#include <linux/sched.h>
+
+ #ifdef CONFIG_RV_REACTORS
+
+@@ -324,10 +325,13 @@ static inline struct da_monitor *da_get_monitor_##name(struct task_struct *tsk)
+ 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); \
+ } \
+ \
+--
+2.48.1
+
scsi-qla2xxx-move-fce-trace-buffer-allocation-to-user-control.patch
scsi-storvsc-set-correct-data-length-for-sending-scsi-command-without-payload.patch
kbuild-move-wenum-enum-conversion-to-w-2.patch
+x86-boot-use-std-gnu11-to-fix-build-with-gcc-15.patch
+arm64-dts-qcom-sm6350-fix-adsp-memory-length.patch
+arm64-dts-qcom-sm6350-fix-mpss-memory-length.patch
+arm64-dts-qcom-sm8350-fix-mpss-memory-length.patch
+arm64-dts-qcom-sm8450-fix-mpss-memory-length.patch
+crypto-qce-fix-priority-to-be-less-than-armv8-ce.patch
+arm64-tegra-disable-tegra234-sce-fabric-node.patch
+xfs-add-error-handling-for-xfs_reflink_cancel_cow_range.patch
+acpi-prm-remove-unnecessary-strict-handler-address-checks.patch
+rv-reset-per-task-monitors-also-for-idle-tasks.patch
+kfence-skip-__gfp_thisnode-allocations-on-numa-systems.patch
+media-ccs-clean-up-parsed-ccs-static-data-on-parse-failure.patch
+iio-light-as73211-fix-channel-handling-in-only-color-triggered-buffer.patch
+soc-qcom-smem_state-fix-missing-of_node_put-in-error-path.patch
+media-mc-fix-endpoint-iteration.patch
+media-ov5640-fix-get_light_freq-on-auto.patch
+media-ccs-fix-ccs-static-data-parsing-for-large-block-sizes.patch
+media-ccs-fix-cleanup-order-in-ccs_probe.patch
+media-uvcvideo-fix-event-flags-in-uvc_ctrl_send_events.patch
+media-uvcvideo-remove-redundant-null-assignment.patch
+mm-kmemleak-fix-upper-boundary-check-for-physical-address-objects.patch
--- /dev/null
+From 70096b4990848229d0784c5e51dc3c7c072f1111 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Thu, 22 Aug 2024 18:48:51 +0200
+Subject: soc: qcom: smem_state: fix missing of_node_put in error path
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit 70096b4990848229d0784c5e51dc3c7c072f1111 upstream.
+
+If of_parse_phandle_with_args() succeeds, the OF node reference should
+be dropped, regardless of number of phandle arguments.
+
+Cc: stable@vger.kernel.org
+Fixes: 9460ae2ff308 ("soc: qcom: Introduce common SMEM state machine code")
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+Link: https://lore.kernel.org/r/20240822164853.231087-2-krzysztof.kozlowski@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/soc/qcom/smem_state.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/soc/qcom/smem_state.c
++++ b/drivers/soc/qcom/smem_state.c
+@@ -116,7 +116,8 @@ struct qcom_smem_state *qcom_smem_state_
+
+ if (args.args_count != 1) {
+ dev_err(dev, "invalid #qcom,smem-state-cells\n");
+- return ERR_PTR(-EINVAL);
++ state = ERR_PTR(-EINVAL);
++ goto put;
+ }
+
+ state = of_node_to_state(args.np);
--- /dev/null
+From ee2ab467bddfb2d7f68d996dbab94d7b88f8eaf7 Mon Sep 17 00:00:00 2001
+From: Nathan Chancellor <nathan@kernel.org>
+Date: Tue, 21 Jan 2025 18:11:33 -0700
+Subject: x86/boot: Use '-std=gnu11' to fix build with GCC 15
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Nathan Chancellor <nathan@kernel.org>
+
+commit ee2ab467bddfb2d7f68d996dbab94d7b88f8eaf7 upstream.
+
+GCC 15 changed the default C standard version to C23, which should not
+have impacted the kernel because it requests the gnu11 standard via
+'-std=' in the main Makefile. However, the x86 compressed boot Makefile
+uses its own set of KBUILD_CFLAGS without a '-std=' value (i.e., using
+the default), resulting in errors from the kernel's definitions of bool,
+true, and false in stddef.h, which are reserved keywords under C23.
+
+ ./include/linux/stddef.h:11:9: error: expected identifier before ‘false’
+ 11 | false = 0,
+ ./include/linux/types.h:35:33: error: two or more data types in declaration specifiers
+ 35 | typedef _Bool bool;
+
+Set '-std=gnu11' in the x86 compressed boot Makefile to resolve the
+error and consistently use the same C standard version for the entire
+kernel.
+
+Closes: https://lore.kernel.org/4OAhbllK7x4QJGpZjkYjtBYNLd_2whHx9oFiuZcGwtVR4hIzvduultkgfAIRZI3vQpZylu7Gl929HaYFRGeMEalWCpeMzCIIhLxxRhq4U-Y=@protonmail.com/
+Closes: https://lore.kernel.org/Z4467umXR2PZ0M1H@tucnak/
+Reported-by: Kostadin Shishmanov <kostadinshishmanov@protonmail.com>
+Reported-by: Jakub Jelinek <jakub@redhat.com>
+Signed-off-by: Nathan Chancellor <nathan@kernel.org>
+Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
+Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
+Cc:stable@vger.kernel.org
+Link: https://lore.kernel.org/all/20250121-x86-use-std-consistently-gcc-15-v1-1-8ab0acf645cb%40kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/boot/compressed/Makefile | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/x86/boot/compressed/Makefile
++++ b/arch/x86/boot/compressed/Makefile
+@@ -34,6 +34,7 @@ targets := vmlinux vmlinux.bin vmlinux.b
+ # avoid errors with '-march=i386', and future flags may depend on the target to
+ # be valid.
+ KBUILD_CFLAGS := -m$(BITS) -O2 $(CLANG_FLAGS)
++KBUILD_CFLAGS += -std=gnu11
+ KBUILD_CFLAGS += -fno-strict-aliasing -fPIE
+ KBUILD_CFLAGS += -Wundef
+ KBUILD_CFLAGS += -DDISABLE_BRANCH_PROFILING
--- /dev/null
+From 26b63bee2f6e711c5a169997fd126fddcfb90848 Mon Sep 17 00:00:00 2001
+From: Wentao Liang <vulab@iscas.ac.cn>
+Date: Fri, 24 Jan 2025 11:45:09 +0800
+Subject: xfs: Add error handling for xfs_reflink_cancel_cow_range
+
+From: Wentao Liang <vulab@iscas.ac.cn>
+
+commit 26b63bee2f6e711c5a169997fd126fddcfb90848 upstream.
+
+In xfs_inactive(), xfs_reflink_cancel_cow_range() is called
+without error handling, risking unnoticed failures and
+inconsistent behavior compared to other parts of the code.
+
+Fix this issue by adding an error handling for the
+xfs_reflink_cancel_cow_range(), improving code robustness.
+
+Fixes: 6231848c3aa5 ("xfs: check for cow blocks before trying to clear them")
+Cc: stable@vger.kernel.org # v4.17
+Reviewed-by: Darrick J. Wong <djwong@kernel.org>
+Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
+Signed-off-by: Carlos Maiolino <cem@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/xfs/xfs_inode.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/fs/xfs/xfs_inode.c
++++ b/fs/xfs/xfs_inode.c
+@@ -1726,8 +1726,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) {
+ /*
projects / thirdparty / kernel / stable-queue.git / commitdiff
