--- /dev/null
+From 04ff48239f46e8b493571e260bd0e6c3a6400371 Mon Sep 17 00:00:00 2001
+From: Simon Schuster <schuster.simon@siemens-energy.com>
+Date: Mon, 1 Sep 2025 15:09:50 +0200
+Subject: copy_sighand: Handle architectures where sizeof(unsigned long) < sizeof(u64)
+
+From: Simon Schuster <schuster.simon@siemens-energy.com>
+
+commit 04ff48239f46e8b493571e260bd0e6c3a6400371 upstream.
+
+With the introduction of clone3 in commit 7f192e3cd316 ("fork: add
+clone3") the effective bit width of clone_flags on all architectures was
+increased from 32-bit to 64-bit. However, the signature of the copy_*
+helper functions (e.g., copy_sighand) used by copy_process was not
+adapted.
+
+As such, they truncate the flags on any 32-bit architectures that
+supports clone3 (arc, arm, csky, m68k, microblaze, mips32, openrisc,
+parisc32, powerpc32, riscv32, x86-32 and xtensa).
+
+For copy_sighand with CLONE_CLEAR_SIGHAND being an actual u64
+constant, this triggers an observable bug in kernel selftest
+clone3_clear_sighand:
+
+ if (clone_flags & CLONE_CLEAR_SIGHAND)
+
+in function copy_sighand within fork.c will always fail given:
+
+ unsigned long /* == uint32_t */ clone_flags
+ #define CLONE_CLEAR_SIGHAND 0x100000000ULL
+
+This commit fixes the bug by always passing clone_flags to copy_sighand
+via their declared u64 type, invariant of architecture-dependent integer
+sizes.
+
+Fixes: b612e5df4587 ("clone3: add CLONE_CLEAR_SIGHAND")
+Cc: stable@vger.kernel.org # linux-5.5+
+Signed-off-by: Simon Schuster <schuster.simon@siemens-energy.com>
+Link: https://lore.kernel.org/20250901-nios2-implement-clone3-v2-1-53fcf5577d57@siemens-energy.com
+Acked-by: David Hildenbrand <david@redhat.com>
+Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
+Reviewed-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Christian Brauner <brauner@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/fork.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/fork.c
++++ b/kernel/fork.c
+@@ -1799,7 +1799,7 @@ static int copy_files(unsigned long clon
+ return 0;
+ }
+
+-static int copy_sighand(unsigned long clone_flags, struct task_struct *tsk)
++static int copy_sighand(u64 clone_flags, struct task_struct *tsk)
+ {
+ struct sighand_struct *sig;
+
--- /dev/null
+From f965d111e68f4a993cc44d487d416e3d954eea11 Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+Date: Fri, 26 Sep 2025 12:19:41 +0200
+Subject: cpufreq: CPPC: Avoid using CPUFREQ_ETERNAL as transition delay
+
+From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+commit f965d111e68f4a993cc44d487d416e3d954eea11 upstream.
+
+If cppc_get_transition_latency() returns CPUFREQ_ETERNAL to indicate a
+failure to retrieve the transition latency value from the platform
+firmware, the CPPC cpufreq driver will use that value (converted to
+microseconds) as the policy transition delay, but it is way too large
+for any practical use.
+
+Address this by making the driver use the cpufreq's default
+transition latency value (in microseconds) as the transition delay
+if CPUFREQ_ETERNAL is returned by cppc_get_transition_latency().
+
+Fixes: d4f3388afd48 ("cpufreq / CPPC: Set platform specific transition_delay_us")
+Cc: 5.19+ <stable@vger.kernel.org> # 5.19
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
+Reviewed-by: Jie Zhan <zhanjie9@hisilicon.com>
+Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
+Reviewed-by: Qais Yousef <qyousef@layalina.io>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/cpufreq/cppc_cpufreq.c | 14 ++++++++++++--
+ 1 file changed, 12 insertions(+), 2 deletions(-)
+
+--- a/drivers/cpufreq/cppc_cpufreq.c
++++ b/drivers/cpufreq/cppc_cpufreq.c
+@@ -344,6 +344,16 @@ static int cppc_verify_policy(struct cpu
+ return 0;
+ }
+
++static unsigned int __cppc_cpufreq_get_transition_delay_us(unsigned int cpu)
++{
++ unsigned int transition_latency_ns = cppc_get_transition_latency(cpu);
++
++ if (transition_latency_ns == CPUFREQ_ETERNAL)
++ return CPUFREQ_DEFAULT_TRANSITION_LATENCY_NS / NSEC_PER_USEC;
++
++ return transition_latency_ns / NSEC_PER_USEC;
++}
++
+ /*
+ * The PCC subspace describes the rate at which platform can accept commands
+ * on the shared PCC channel (including READs which do not count towards freq
+@@ -366,12 +376,12 @@ static unsigned int cppc_cpufreq_get_tra
+ return 10000;
+ }
+ }
+- return cppc_get_transition_latency(cpu) / NSEC_PER_USEC;
++ return __cppc_cpufreq_get_transition_delay_us(cpu);
+ }
+ #else
+ static unsigned int cppc_cpufreq_get_transition_delay_us(unsigned int cpu)
+ {
+- return cppc_get_transition_latency(cpu) / NSEC_PER_USEC;
++ return __cppc_cpufreq_get_transition_delay_us(cpu);
+ }
+ #endif
+
--- /dev/null
+From 69e5d50fcf4093fb3f9f41c4f931f12c2ca8c467 Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+Date: Fri, 5 Sep 2025 15:52:03 +0200
+Subject: cpufreq: intel_pstate: Fix object lifecycle issue in update_qos_request()
+
+From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+commit 69e5d50fcf4093fb3f9f41c4f931f12c2ca8c467 upstream.
+
+The cpufreq_cpu_put() call in update_qos_request() takes place too early
+because the latter subsequently calls freq_qos_update_request() that
+indirectly accesses the policy object in question through the QoS request
+object passed to it.
+
+Fortunately, update_qos_request() is called under intel_pstate_driver_lock,
+so this issue does not matter for changing the intel_pstate operation
+mode, but it theoretically can cause a crash to occur on CPU device hot
+removal (which currently can only happen in virt, but it is formally
+supported nevertheless).
+
+Address this issue by modifying update_qos_request() to drop the
+reference to the policy later.
+
+Fixes: da5c504c7aae ("cpufreq: intel_pstate: Implement QoS supported freq constraints")
+Cc: 5.4+ <stable@vger.kernel.org> # 5.4+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Reviewed-by: Zihuan Zhang <zhangzihuan@kylinos.cn>
+Link: https://patch.msgid.link/2255671.irdbgypaU6@rafael.j.wysocki
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/cpufreq/intel_pstate.c | 8 +++++---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+--- a/drivers/cpufreq/intel_pstate.c
++++ b/drivers/cpufreq/intel_pstate.c
+@@ -1341,10 +1341,10 @@ static void update_qos_request(enum freq
+ continue;
+
+ req = policy->driver_data;
+- cpufreq_cpu_put(policy);
+-
+- if (!req)
++ if (!req) {
++ cpufreq_cpu_put(policy);
+ continue;
++ }
+
+ if (hwp_active)
+ intel_pstate_get_hwp_cap(cpu);
+@@ -1360,6 +1360,8 @@ static void update_qos_request(enum freq
+
+ if (freq_qos_update_request(req, freq) < 0)
+ pr_warn("Failed to update freq constraint: CPU%d\n", i);
++
++ cpufreq_cpu_put(policy);
+ }
+ }
+
--- /dev/null
+From 838d2d51513e6d2504a678e906823cfd2ecaaa22 Mon Sep 17 00:00:00 2001
+From: Thomas Fourier <fourier.thomas@gmail.com>
+Date: Wed, 10 Sep 2025 10:22:31 +0200
+Subject: crypto: aspeed - Fix dma_unmap_sg() direction
+
+From: Thomas Fourier <fourier.thomas@gmail.com>
+
+commit 838d2d51513e6d2504a678e906823cfd2ecaaa22 upstream.
+
+It seems like everywhere in this file, when the request is not
+bidirectionala, req->src is mapped with DMA_TO_DEVICE and req->dst is
+mapped with DMA_FROM_DEVICE.
+
+Fixes: 62f58b1637b7 ("crypto: aspeed - add HACE crypto driver")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/crypto/aspeed/aspeed-hace-crypto.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/crypto/aspeed/aspeed-hace-crypto.c
++++ b/drivers/crypto/aspeed/aspeed-hace-crypto.c
+@@ -346,7 +346,7 @@ free_req:
+
+ } else {
+ dma_unmap_sg(hace_dev->dev, req->dst, rctx->dst_nents,
+- DMA_TO_DEVICE);
++ DMA_FROM_DEVICE);
+ dma_unmap_sg(hace_dev->dev, req->src, rctx->src_nents,
+ DMA_TO_DEVICE);
+ }
--- /dev/null
+From f5d643156ef62216955c119216d2f3815bd51cb1 Mon Sep 17 00:00:00 2001
+From: Thomas Fourier <fourier.thomas@gmail.com>
+Date: Wed, 3 Sep 2025 10:34:46 +0200
+Subject: crypto: atmel - Fix dma_unmap_sg() direction
+
+From: Thomas Fourier <fourier.thomas@gmail.com>
+
+commit f5d643156ef62216955c119216d2f3815bd51cb1 upstream.
+
+It seems like everywhere in this file, dd->in_sg is mapped with
+DMA_TO_DEVICE and dd->out_sg is mapped with DMA_FROM_DEVICE.
+
+Fixes: 13802005d8f2 ("crypto: atmel - add Atmel DES/TDES driver")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/crypto/atmel-tdes.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/crypto/atmel-tdes.c
++++ b/drivers/crypto/atmel-tdes.c
+@@ -548,7 +548,7 @@ static int atmel_tdes_crypt_start(struct
+
+ if (err && (dd->flags & TDES_FLAGS_FAST)) {
+ dma_unmap_sg(dd->dev, dd->in_sg, 1, DMA_TO_DEVICE);
+- dma_unmap_sg(dd->dev, dd->out_sg, 1, DMA_TO_DEVICE);
++ dma_unmap_sg(dd->dev, dd->out_sg, 1, DMA_FROM_DEVICE);
+ }
+
+ return err;
--- /dev/null
+From 21140e5caf019e4a24e1ceabcaaa16bd693b393f Mon Sep 17 00:00:00 2001
+From: Thomas Fourier <fourier.thomas@gmail.com>
+Date: Wed, 3 Sep 2025 10:06:46 +0200
+Subject: crypto: rockchip - Fix dma_unmap_sg() nents value
+
+From: Thomas Fourier <fourier.thomas@gmail.com>
+
+commit 21140e5caf019e4a24e1ceabcaaa16bd693b393f upstream.
+
+The dma_unmap_sg() functions should be called with the same nents as the
+dma_map_sg(), not the value the map function returned.
+
+Fixes: 57d67c6e8219 ("crypto: rockchip - rework by using crypto_engine")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/crypto/rockchip/rk3288_crypto_ahash.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/crypto/rockchip/rk3288_crypto_ahash.c
++++ b/drivers/crypto/rockchip/rk3288_crypto_ahash.c
+@@ -252,7 +252,7 @@ static void rk_hash_unprepare(struct cry
+ struct rk_ahash_rctx *rctx = ahash_request_ctx(areq);
+ struct rk_crypto_info *rkc = rctx->dev;
+
+- dma_unmap_sg(rkc->dev, areq->src, rctx->nrsg, DMA_TO_DEVICE);
++ dma_unmap_sg(rkc->dev, areq->src, sg_nents(areq->src), DMA_TO_DEVICE);
+ }
+
+ static int rk_hash_run(struct crypto_engine *engine, void *breq)
--- /dev/null
+From 15df28699b28d6b49dc305040c4e26a9553df07a Mon Sep 17 00:00:00 2001
+From: Finn Thain <fthain@linux-m68k.org>
+Date: Thu, 9 Oct 2025 09:56:25 +1100
+Subject: fbdev: Fix logic error in "offb" name match
+
+From: Finn Thain <fthain@linux-m68k.org>
+
+commit 15df28699b28d6b49dc305040c4e26a9553df07a upstream.
+
+A regression was reported to me recently whereby /dev/fb0 had disappeared
+from a PowerBook G3 Series "Wallstreet". The problem shows up when the
+"video=ofonly" parameter is passed to the kernel, which is what the
+bootloader does when "no video driver" is selected. The cause of the
+problem is the "offb" string comparison, which got mangled when it got
+refactored. Fix it.
+
+Cc: stable@vger.kernel.org
+Fixes: 93604a5ade3a ("fbdev: Handle video= parameter in video/cmdline.c")
+Reported-and-tested-by: Stan Johnson <userm57@yahoo.com>
+Signed-off-by: Finn Thain <fthain@linux-m68k.org>
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/video/fbdev/core/fb_cmdline.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/video/fbdev/core/fb_cmdline.c b/drivers/video/fbdev/core/fb_cmdline.c
+index 4d1634c492ec..594b60424d1c 100644
+--- a/drivers/video/fbdev/core/fb_cmdline.c
++++ b/drivers/video/fbdev/core/fb_cmdline.c
+@@ -40,7 +40,7 @@ int fb_get_options(const char *name, char **option)
+ bool enabled;
+
+ if (name)
+- is_of = strncmp(name, "offb", 4);
++ is_of = !strncmp(name, "offb", 4);
+
+ enabled = __video_get_options(name, &options, is_of);
+
+--
+2.51.0
+
--- /dev/null
+From d68318471aa2e16222ebf492883e05a2d72b9b17 Mon Sep 17 00:00:00 2001
+From: Haoxiang Li <haoxiang_li2024@163.com>
+Date: Tue, 15 Jul 2025 17:51:20 +0800
+Subject: fs/ntfs3: Fix a resource leak bug in wnd_extend()
+
+From: Haoxiang Li <haoxiang_li2024@163.com>
+
+commit d68318471aa2e16222ebf492883e05a2d72b9b17 upstream.
+
+Add put_bh() to decrease the refcount of 'bh' after the job
+is finished, preventing a resource leak.
+
+Fixes: 3f3b442b5ad2 ("fs/ntfs3: Add bitmap")
+Cc: stable@vger.kernel.org
+Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
+Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ntfs3/bitmap.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/ntfs3/bitmap.c
++++ b/fs/ntfs3/bitmap.c
+@@ -1399,6 +1399,7 @@ int wnd_extend(struct wnd_bitmap *wnd, s
+ mark_buffer_dirty(bh);
+ unlock_buffer(bh);
+ /* err = sync_dirty_buffer(bh); */
++ put_bh(bh);
+
+ b0 = 0;
+ bits -= op;
--- /dev/null
+From f9381ece76de999a2065d5b4fdd87fa17883978c Mon Sep 17 00:00:00 2001
+From: Qianfeng Rong <rongqianfeng@vivo.com>
+Date: Mon, 1 Sep 2025 21:57:25 +0800
+Subject: iio: dac: ad5360: use int type to store negative error codes
+
+From: Qianfeng Rong <rongqianfeng@vivo.com>
+
+commit f9381ece76de999a2065d5b4fdd87fa17883978c upstream.
+
+Change the 'ret' variable in ad5360_update_ctrl() from unsigned int to
+int, as it needs to store either negative error codes or zero returned
+by ad5360_write_unlocked().
+
+Fixes: a3e2940c24d3 ("staging:iio:dac: Add AD5360 driver")
+Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
+Link: https://patch.msgid.link/20250901135726.17601-2-rongqianfeng@vivo.com
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/dac/ad5360.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/iio/dac/ad5360.c
++++ b/drivers/iio/dac/ad5360.c
+@@ -262,7 +262,7 @@ static int ad5360_update_ctrl(struct iio
+ unsigned int clr)
+ {
+ struct ad5360_state *st = iio_priv(indio_dev);
+- unsigned int ret;
++ int ret;
+
+ mutex_lock(&st->lock);
+
--- /dev/null
+From 3379c900320954d768ed9903691fb2520926bbe3 Mon Sep 17 00:00:00 2001
+From: Qianfeng Rong <rongqianfeng@vivo.com>
+Date: Mon, 1 Sep 2025 21:57:26 +0800
+Subject: iio: dac: ad5421: use int type to store negative error codes
+
+From: Qianfeng Rong <rongqianfeng@vivo.com>
+
+commit 3379c900320954d768ed9903691fb2520926bbe3 upstream.
+
+Change the 'ret' variable in ad5421_update_ctrl() from unsigned int to
+int, as it needs to store either negative error codes or zero returned
+by ad5421_write_unlocked().
+
+Fixes: 5691b23489db ("staging:iio:dac: Add AD5421 driver")
+Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
+Link: https://patch.msgid.link/20250901135726.17601-3-rongqianfeng@vivo.com
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/dac/ad5421.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/iio/dac/ad5421.c
++++ b/drivers/iio/dac/ad5421.c
+@@ -186,7 +186,7 @@ static int ad5421_update_ctrl(struct iio
+ unsigned int clr)
+ {
+ struct ad5421_state *st = iio_priv(indio_dev);
+- unsigned int ret;
++ int ret;
+
+ mutex_lock(&st->lock);
+
--- /dev/null
+From 33d7ecbf69aa7dd4145e3b77962bcb8759eede3d Mon Sep 17 00:00:00 2001
+From: Michael Hennerich <michael.hennerich@analog.com>
+Date: Fri, 29 Aug 2025 12:25:42 +0100
+Subject: iio: frequency: adf4350: Fix prescaler usage.
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Michael Hennerich <michael.hennerich@analog.com>
+
+commit 33d7ecbf69aa7dd4145e3b77962bcb8759eede3d upstream.
+
+The ADF4350/1 features a programmable dual-modulus prescaler of 4/5 or 8/9.
+When set to 4/5, the maximum RF frequency allowed is 3 GHz.
+Therefore, when operating the ADF4351 above 3 GHz, this must be set to 8/9.
+In this context not the RF output frequency is meant
+- it's the VCO frequency.
+
+Therefore move the prescaler selection after we derived the VCO frequency
+from the desired RF output frequency.
+
+This BUG may have caused PLL lock instabilities when operating the VCO at
+the very high range close to 4.4 GHz.
+
+Fixes: e31166f0fd48 ("iio: frequency: New driver for Analog Devices ADF4350/ADF4351 Wideband Synthesizers")
+Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
+Signed-off-by: Nuno Sá <nuno.sa@analog.com>
+Reviewed-by: Andy Shevchenko <andy@kernel.org>
+Link: https://patch.msgid.link/20250829-adf4350-fix-v2-1-0bf543ba797d@analog.com
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/frequency/adf4350.c | 20 +++++++++++++-------
+ 1 file changed, 13 insertions(+), 7 deletions(-)
+
+--- a/drivers/iio/frequency/adf4350.c
++++ b/drivers/iio/frequency/adf4350.c
+@@ -143,6 +143,19 @@ static int adf4350_set_freq(struct adf43
+ if (freq > ADF4350_MAX_OUT_FREQ || freq < st->min_out_freq)
+ return -EINVAL;
+
++ st->r4_rf_div_sel = 0;
++
++ /*
++ * !\TODO: The below computation is making sure we get a power of 2
++ * shift (st->r4_rf_div_sel) so that freq becomes higher or equal to
++ * ADF4350_MIN_VCO_FREQ. This might be simplified with fls()/fls_long()
++ * and friends.
++ */
++ while (freq < ADF4350_MIN_VCO_FREQ) {
++ freq <<= 1;
++ st->r4_rf_div_sel++;
++ }
++
+ if (freq > ADF4350_MAX_FREQ_45_PRESC) {
+ prescaler = ADF4350_REG1_PRESCALER;
+ mdiv = 75;
+@@ -151,13 +164,6 @@ static int adf4350_set_freq(struct adf43
+ mdiv = 23;
+ }
+
+- st->r4_rf_div_sel = 0;
+-
+- while (freq < ADF4350_MIN_VCO_FREQ) {
+- freq <<= 1;
+- st->r4_rf_div_sel++;
+- }
+-
+ /*
+ * Allow a predefined reference division factor
+ * if not set, compute our own
--- /dev/null
+From a95a0b4e471a6d8860f40c6ac8f1cad9dde3189a Mon Sep 17 00:00:00 2001
+From: Sean Nyekjaer <sean@geanix.com>
+Date: Mon, 1 Sep 2025 09:49:14 +0200
+Subject: iio: imu: inv_icm42600: Drop redundant pm_runtime reinitialization in resume
+
+From: Sean Nyekjaer <sean@geanix.com>
+
+commit a95a0b4e471a6d8860f40c6ac8f1cad9dde3189a upstream.
+
+Remove unnecessary calls to pm_runtime_disable(), pm_runtime_set_active(),
+and pm_runtime_enable() from the resume path. These operations are not
+required here and can interfere with proper pm_runtime state handling,
+especially when resuming from a pm_runtime suspended state.
+
+Fixes: 31c24c1e93c3 ("iio: imu: inv_icm42600: add core of new inv_icm42600 driver")
+Signed-off-by: Sean Nyekjaer <sean@geanix.com>
+Link: https://patch.msgid.link/20250901-icm42pmreg-v3-2-ef1336246960@geanix.com
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/imu/inv_icm42600/inv_icm42600_core.c | 4 ----
+ 1 file changed, 4 deletions(-)
+
+--- a/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c
++++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c
+@@ -747,10 +747,6 @@ static int inv_icm42600_resume(struct de
+ if (ret)
+ goto out_unlock;
+
+- pm_runtime_disable(dev);
+- pm_runtime_set_active(dev);
+- pm_runtime_enable(dev);
+-
+ /* restore sensors state */
+ ret = inv_icm42600_set_pwr_mgmt0(st, st->suspended.gyro,
+ st->suspended.accel,
--- /dev/null
+From 1315cc2dbd5034f566e20ddce4d675cb9e6d4ddd Mon Sep 17 00:00:00 2001
+From: Sean Anderson <sean.anderson@linux.dev>
+Date: Mon, 14 Jul 2025 20:30:58 -0400
+Subject: iio: xilinx-ams: Fix AMS_ALARM_THR_DIRECT_MASK
+
+From: Sean Anderson <sean.anderson@linux.dev>
+
+commit 1315cc2dbd5034f566e20ddce4d675cb9e6d4ddd upstream.
+
+AMS_ALARM_THR_DIRECT_MASK should be bit 0, not bit 1. This would cause
+hysteresis to be enabled with a lower threshold of -28C. The temperature
+alarm would never deassert even if the temperature dropped below the
+upper threshold.
+
+Fixes: d5c70627a794 ("iio: adc: Add Xilinx AMS driver")
+Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
+Reviewed-by: O'Griofa, Conall <conall.ogriofa@amd.com>
+Tested-by: Erim, Salih <Salih.Erim@amd.com>
+Acked-by: Erim, Salih <Salih.Erim@amd.com>
+Link: https://patch.msgid.link/20250715003058.2035656-1-sean.anderson@linux.dev
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/adc/xilinx-ams.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/iio/adc/xilinx-ams.c
++++ b/drivers/iio/adc/xilinx-ams.c
+@@ -118,7 +118,7 @@
+ #define AMS_ALARM_THRESHOLD_OFF_10 0x10
+ #define AMS_ALARM_THRESHOLD_OFF_20 0x20
+
+-#define AMS_ALARM_THR_DIRECT_MASK BIT(1)
++#define AMS_ALARM_THR_DIRECT_MASK BIT(0)
+ #define AMS_ALARM_THR_MIN 0x0000
+ #define AMS_ALARM_THR_MAX (BIT(16) - 1)
+
--- /dev/null
+From feb500c7ae7a198db4d2757901bce562feeefa5e Mon Sep 17 00:00:00 2001
+From: Sean Anderson <sean.anderson@linux.dev>
+Date: Mon, 14 Jul 2025 20:28:47 -0400
+Subject: iio: xilinx-ams: Unmask interrupts after updating alarms
+
+From: Sean Anderson <sean.anderson@linux.dev>
+
+commit feb500c7ae7a198db4d2757901bce562feeefa5e upstream.
+
+To convert level-triggered alarms into edge-triggered IIO events, alarms
+are masked when they are triggered. To ensure we catch subsequent
+alarms, we then periodically poll to see if the alarm is still active.
+If it isn't, we unmask it. Active but masked alarms are stored in
+current_masked_alarm.
+
+If an active alarm is disabled, it will remain set in
+current_masked_alarm until ams_unmask_worker clears it. If the alarm is
+re-enabled before ams_unmask_worker runs, then it will never be cleared
+from current_masked_alarm. This will prevent the alarm event from being
+pushed even if the alarm is still active.
+
+Fix this by recalculating current_masked_alarm immediately when enabling
+or disabling alarms.
+
+Fixes: d5c70627a794 ("iio: adc: Add Xilinx AMS driver")
+Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
+Reviewed-by: O'Griofa, Conall <conall.ogriofa@amd.com>
+Tested-by: Erim, Salih <Salih.Erim@amd.com>
+Acked-by: Erim, Salih <Salih.Erim@amd.com>
+Link: https://patch.msgid.link/20250715002847.2035228-1-sean.anderson@linux.dev
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/adc/xilinx-ams.c | 45 +++++++++++++++++++++++--------------------
+ 1 file changed, 25 insertions(+), 20 deletions(-)
+
+--- a/drivers/iio/adc/xilinx-ams.c
++++ b/drivers/iio/adc/xilinx-ams.c
+@@ -385,6 +385,29 @@ static void ams_update_pl_alarm(struct a
+ ams_pl_update_reg(ams, AMS_REG_CONFIG3, AMS_REGCFG3_ALARM_MASK, cfg);
+ }
+
++static void ams_unmask(struct ams *ams)
++{
++ unsigned int status, unmask;
++
++ status = readl(ams->base + AMS_ISR_0);
++
++ /* Clear those bits which are not active anymore */
++ unmask = (ams->current_masked_alarm ^ status) & ams->current_masked_alarm;
++
++ /* Clear status of disabled alarm */
++ unmask |= ams->intr_mask;
++
++ ams->current_masked_alarm &= status;
++
++ /* Also clear those which are masked out anyway */
++ ams->current_masked_alarm &= ~ams->intr_mask;
++
++ /* Clear the interrupts before we unmask them */
++ writel(unmask, ams->base + AMS_ISR_0);
++
++ ams_update_intrmask(ams, ~AMS_ALARM_MASK, ~AMS_ALARM_MASK);
++}
++
+ static void ams_update_alarm(struct ams *ams, unsigned long alarm_mask)
+ {
+ unsigned long flags;
+@@ -397,6 +420,7 @@ static void ams_update_alarm(struct ams
+
+ spin_lock_irqsave(&ams->intr_lock, flags);
+ ams_update_intrmask(ams, AMS_ISR0_ALARM_MASK, ~alarm_mask);
++ ams_unmask(ams);
+ spin_unlock_irqrestore(&ams->intr_lock, flags);
+ }
+
+@@ -1025,28 +1049,9 @@ static void ams_handle_events(struct iio
+ static void ams_unmask_worker(struct work_struct *work)
+ {
+ struct ams *ams = container_of(work, struct ams, ams_unmask_work.work);
+- unsigned int status, unmask;
+
+ spin_lock_irq(&ams->intr_lock);
+-
+- status = readl(ams->base + AMS_ISR_0);
+-
+- /* Clear those bits which are not active anymore */
+- unmask = (ams->current_masked_alarm ^ status) & ams->current_masked_alarm;
+-
+- /* Clear status of disabled alarm */
+- unmask |= ams->intr_mask;
+-
+- ams->current_masked_alarm &= status;
+-
+- /* Also clear those which are masked out anyway */
+- ams->current_masked_alarm &= ~ams->intr_mask;
+-
+- /* Clear the interrupts before we unmask them */
+- writel(unmask, ams->base + AMS_ISR_0);
+-
+- ams_update_intrmask(ams, ~AMS_ALARM_MASK, ~AMS_ALARM_MASK);
+-
++ ams_unmask(ams);
+ spin_unlock_irq(&ams->intr_lock);
+
+ /* If still pending some alarm re-trigger the timer */
--- /dev/null
+From e416f0ed3c500c05c55fb62ee62662717b1c7f71 Mon Sep 17 00:00:00 2001
+From: Huacai Chen <chenhuacai@loongson.cn>
+Date: Mon, 21 Jul 2025 18:13:43 +0800
+Subject: init: handle bootloader identifier in kernel parameters
+
+From: Huacai Chen <chenhuacai@loongson.cn>
+
+commit e416f0ed3c500c05c55fb62ee62662717b1c7f71 upstream.
+
+BootLoaders (Grub, LILO, etc) may pass an identifier such as "BOOT_IMAGE=
+/boot/vmlinuz-x.y.z" to kernel parameters. But these identifiers are not
+recognized by the kernel itself so will be passed to userspace. However
+user space init program also don't recognize it.
+
+KEXEC/KDUMP (kexec-tools) may also pass an identifier such as "kexec" on
+some architectures.
+
+We cannot change BootLoader's behavior, because this behavior exists for
+many years, and there are already user space programs search BOOT_IMAGE=
+in /proc/cmdline to obtain the kernel image locations:
+
+https://github.com/linuxdeepin/deepin-ab-recovery/blob/master/util.go
+(search getBootOptions)
+https://github.com/linuxdeepin/deepin-ab-recovery/blob/master/main.go
+(search getKernelReleaseWithBootOption) So the the best way is handle
+(ignore) it by the kernel itself, which can avoid such boot warnings (if
+we use something like init=/bin/bash, bootloader identifier can even cause
+a crash):
+
+Kernel command line: BOOT_IMAGE=(hd0,1)/vmlinuz-6.x root=/dev/sda3 ro console=tty
+Unknown kernel command line parameters "BOOT_IMAGE=(hd0,1)/vmlinuz-6.x", will be passed to user space.
+
+[chenhuacai@loongson.cn: use strstarts()]
+ Link: https://lkml.kernel.org/r/20250815090120.1569947-1-chenhuacai@loongson.cn
+Link: https://lkml.kernel.org/r/20250721101343.3283480-1-chenhuacai@loongson.cn
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Cc: Al Viro <viro@zeniv.linux.org.uk>
+Cc: Christian Brauner <brauner@kernel.org>
+Cc: Jan Kara <jack@suse.cz>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ init/main.c | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+--- a/init/main.c
++++ b/init/main.c
+@@ -530,6 +530,12 @@ static int __init unknown_bootoption(cha
+ const char *unused, void *arg)
+ {
+ size_t len = strlen(param);
++ /*
++ * Well-known bootloader identifiers:
++ * 1. LILO/Grub pass "BOOT_IMAGE=...";
++ * 2. kexec/kdump (kexec-tools) pass "kexec".
++ */
++ const char *bootloader[] = { "BOOT_IMAGE=", "kexec", NULL };
+
+ /* Handle params aliased to sysctls */
+ if (sysctl_is_alias(param))
+@@ -537,6 +543,12 @@ static int __init unknown_bootoption(cha
+
+ repair_env_string(param, val);
+
++ /* Handle bootloader identifier */
++ for (int i = 0; bootloader[i]; i++) {
++ if (strstarts(param, bootloader[i]))
++ return 0;
++ }
++
+ /* Handle obsolete-style parameters */
+ if (obsolete_checksetup(param))
+ return 0;
--- /dev/null
+From 5ef7e24c742038a5d8c626fdc0e3a21834358341 Mon Sep 17 00:00:00 2001
+From: Lu Baolu <baolu.lu@linux.intel.com>
+Date: Thu, 18 Sep 2025 13:02:02 +0800
+Subject: iommu/vt-d: PRS isn't usable if PDS isn't supported
+
+From: Lu Baolu <baolu.lu@linux.intel.com>
+
+commit 5ef7e24c742038a5d8c626fdc0e3a21834358341 upstream.
+
+The specification, Section 7.10, "Software Steps to Drain Page Requests &
+Responses," requires software to submit an Invalidation Wait Descriptor
+(inv_wait_dsc) with the Page-request Drain (PD=1) flag set, along with
+the Invalidation Wait Completion Status Write flag (SW=1). It then waits
+for the Invalidation Wait Descriptor's completion.
+
+However, the PD field in the Invalidation Wait Descriptor is optional, as
+stated in Section 6.5.2.9, "Invalidation Wait Descriptor":
+
+"Page-request Drain (PD): Remapping hardware implementations reporting
+ Page-request draining as not supported (PDS = 0 in ECAP_REG) treat this
+ field as reserved."
+
+This implies that if the IOMMU doesn't support the PDS capability, software
+can't drain page requests and group responses as expected.
+
+Do not enable PCI/PRI if the IOMMU doesn't support PDS.
+
+Reported-by: Joel Granados <joel.granados@kernel.org>
+Closes: https://lore.kernel.org/r/20250909-jag-pds-v1-1-ad8cba0e494e@kernel.org
+Fixes: 66ac4db36f4c ("iommu/vt-d: Add page request draining support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
+Link: https://lore.kernel.org/r/20250915062946.120196-1-baolu.lu@linux.intel.com
+Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iommu/intel/iommu.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/iommu/intel/iommu.c
++++ b/drivers/iommu/intel/iommu.c
+@@ -4415,7 +4415,7 @@ static struct iommu_device *intel_iommu_
+ }
+
+ if (info->ats_supported && ecap_prs(iommu->ecap) &&
+- pci_pri_supported(pdev))
++ ecap_pds(iommu->ecap) && pci_pri_supported(pdev))
+ info->pri_supported = 1;
+ }
+ }
--- /dev/null
+From a15f37a40145c986cdf289a4b88390f35efdecc4 Mon Sep 17 00:00:00 2001
+From: Oleg Nesterov <oleg@redhat.com>
+Date: Mon, 15 Sep 2025 14:09:17 +0200
+Subject: kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in sys_prlimit64() paths
+
+From: Oleg Nesterov <oleg@redhat.com>
+
+commit a15f37a40145c986cdf289a4b88390f35efdecc4 upstream.
+
+The usage of task_lock(tsk->group_leader) in sys_prlimit64()->do_prlimit()
+path is very broken.
+
+sys_prlimit64() does get_task_struct(tsk) but this only protects task_struct
+itself. If tsk != current and tsk is not a leader, this process can exit/exec
+and task_lock(tsk->group_leader) may use the already freed task_struct.
+
+Another problem is that sys_prlimit64() can race with mt-exec which changes
+->group_leader. In this case do_prlimit() may take the wrong lock, or (worse)
+->group_leader may change between task_lock() and task_unlock().
+
+Change sys_prlimit64() to take tasklist_lock when necessary. This is not
+nice, but I don't see a better fix for -stable.
+
+Link: https://lkml.kernel.org/r/20250915120917.GA27702@redhat.com
+Fixes: 18c91bb2d872 ("prlimit: do not grab the tasklist_lock")
+Signed-off-by: Oleg Nesterov <oleg@redhat.com>
+Cc: Christian Brauner <brauner@kernel.org>
+Cc: Jiri Slaby <jirislaby@kernel.org>
+Cc: Mateusz Guzik <mjguzik@gmail.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/sys.c | 22 ++++++++++++++++++++--
+ 1 file changed, 20 insertions(+), 2 deletions(-)
+
+--- a/kernel/sys.c
++++ b/kernel/sys.c
+@@ -1689,6 +1689,7 @@ SYSCALL_DEFINE4(prlimit64, pid_t, pid, u
+ struct rlimit old, new;
+ struct task_struct *tsk;
+ unsigned int checkflags = 0;
++ bool need_tasklist;
+ int ret;
+
+ if (old_rlim)
+@@ -1715,8 +1716,25 @@ SYSCALL_DEFINE4(prlimit64, pid_t, pid, u
+ get_task_struct(tsk);
+ rcu_read_unlock();
+
+- ret = do_prlimit(tsk, resource, new_rlim ? &new : NULL,
+- old_rlim ? &old : NULL);
++ need_tasklist = !same_thread_group(tsk, current);
++ if (need_tasklist) {
++ /*
++ * Ensure we can't race with group exit or de_thread(),
++ * so tsk->group_leader can't be freed or changed until
++ * read_unlock(tasklist_lock) below.
++ */
++ read_lock(&tasklist_lock);
++ if (!pid_alive(tsk))
++ ret = -ESRCH;
++ }
++
++ if (!ret) {
++ ret = do_prlimit(tsk, resource, new_rlim ? &new : NULL,
++ old_rlim ? &old : NULL);
++ }
++
++ if (need_tasklist)
++ read_unlock(&tasklist_lock);
+
+ if (!ret && old_rlim) {
+ rlim_to_rlim64(&old, &old64);
btrfs-avoid-potential-out-of-bounds-in-btrfs_encode_fh.patch
bus-mhi-ep-fix-chained-transfer-handling-in-read-path.patch
bus-mhi-host-do-not-use-uninitialized-dev-pointer-in-mhi_init_irq_setup.patch
+copy_sighand-handle-architectures-where-sizeof-unsigned-long-sizeof-u64.patch
+cpufreq-cppc-avoid-using-cpufreq_eternal-as-transition-delay.patch
+cpufreq-intel_pstate-fix-object-lifecycle-issue-in-update_qos_request.patch
+crypto-aspeed-fix-dma_unmap_sg-direction.patch
+crypto-atmel-fix-dma_unmap_sg-direction.patch
+crypto-rockchip-fix-dma_unmap_sg-nents-value.patch
+fbdev-fix-logic-error-in-offb-name-match.patch
+fs-ntfs3-fix-a-resource-leak-bug-in-wnd_extend.patch
+iio-dac-ad5360-use-int-type-to-store-negative-error-codes.patch
+iio-dac-ad5421-use-int-type-to-store-negative-error-codes.patch
+iio-frequency-adf4350-fix-prescaler-usage.patch
+iio-xilinx-ams-fix-ams_alarm_thr_direct_mask.patch
+iio-xilinx-ams-unmask-interrupts-after-updating-alarms.patch
+init-handle-bootloader-identifier-in-kernel-parameters.patch
+iio-imu-inv_icm42600-drop-redundant-pm_runtime-reinitialization-in-resume.patch
+iommu-vt-d-prs-isn-t-usable-if-pds-isn-t-supported.patch
+kernel-sys.c-fix-the-racy-usage-of-task_lock-tsk-group_leader-in-sys_prlimit64-paths.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
