--- /dev/null
+From 3179a5f7f86bcc3acd5d6fb2a29f891ef5615852 Mon Sep 17 00:00:00 2001
+From: Li Chen <chenl311@chinatelecom.cn>
+Date: Mon, 17 Nov 2025 13:34:07 +0800
+Subject: block: rate-limit capacity change info log
+
+From: Li Chen <chenl311@chinatelecom.cn>
+
+commit 3179a5f7f86bcc3acd5d6fb2a29f891ef5615852 upstream.
+
+loop devices under heavy stress-ng loop streessor can trigger many
+capacity change events in a short time. Each event prints an info
+message from set_capacity_and_notify(), flooding the console and
+contributing to soft lockups on slow consoles.
+
+Switch the printk in set_capacity_and_notify() to
+pr_info_ratelimited() so frequent capacity changes do not spam
+the log while still reporting occasional changes.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Li Chen <chenl311@chinatelecom.cn>
+Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
+Reviewed-by: Bart Van Assche <bvanassche@acm.org>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ block/genhd.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/block/genhd.c
++++ b/block/genhd.c
+@@ -83,7 +83,7 @@ bool set_capacity_and_notify(struct gend
+ (disk->flags & GENHD_FL_HIDDEN))
+ return false;
+
+- pr_info("%s: detected capacity change from %lld to %lld\n",
++ pr_info_ratelimited("%s: detected capacity change from %lld to %lld\n",
+ disk->disk_name, capacity, size);
+
+ /*
--- /dev/null
+From 82d20481024cbae2ea87fe8b86d12961bfda7169 Mon Sep 17 00:00:00 2001
+From: Rene Rebe <rene@exactco.de>
+Date: Fri, 14 Nov 2025 14:41:27 +0100
+Subject: floppy: fix for PAGE_SIZE != 4KB
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Rene Rebe <rene@exactco.de>
+
+commit 82d20481024cbae2ea87fe8b86d12961bfda7169 upstream.
+
+For years I wondered why the floppy driver does not just work on
+sparc64, e.g:
+
+root@SUNW_375_0066:# disktype /dev/fd0
+disktype: Can't open /dev/fd0: No such device or address
+
+[ 525.341906] disktype: attempt to access beyond end of device
+fd0: rw=0, sector=0, nr_sectors = 16 limit=8
+[ 525.341991] floppy: error 10 while reading block 0
+
+Turns out floppy.c __floppy_read_block_0 tries to read one page for
+the first test read to determine the disk size and thus fails if that
+is greater than 4k. Adjust minimum MAX_DISK_SIZE to PAGE_SIZE to fix
+floppy on sparc64 and likely all other PAGE_SIZE != 4KB configs.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: René Rebe <rene@exactco.de>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/block/floppy.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/block/floppy.c
++++ b/drivers/block/floppy.c
+@@ -331,7 +331,7 @@ static bool initialized;
+ * This default is used whenever the current disk size is unknown.
+ * [Now it is rather a minimum]
+ */
+-#define MAX_DISK_SIZE 4 /* 3984 */
++#define MAX_DISK_SIZE (PAGE_SIZE / 1024)
+
+ /*
+ * globals used by 'result()'
--- /dev/null
+From 801f614ba263cb37624982b27b4c82f3c3c597a9 Mon Sep 17 00:00:00 2001
+From: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
+Date: Thu, 18 Sep 2025 13:35:24 +0300
+Subject: fs/ntfs3: fix mount failure for sparse runs in run_unpack()
+
+From: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
+
+commit 801f614ba263cb37624982b27b4c82f3c3c597a9 upstream.
+
+Some NTFS volumes failed to mount because sparse data runs were not
+handled correctly during runlist unpacking. The code performed arithmetic
+on the special SPARSE_LCN64 marker, leading to invalid LCN values and
+mount errors.
+
+Add an explicit check for the case described above, marking the run as
+sparse without applying arithmetic.
+
+Fixes: 736fc7bf5f68 ("fs: ntfs3: Fix integer overflow in run_unpack()")
+Cc: stable@vger.kernel.org
+Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ntfs3/run.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/fs/ntfs3/run.c
++++ b/fs/ntfs3/run.c
+@@ -984,8 +984,12 @@ int run_unpack(struct runs_tree *run, st
+ if (!dlcn)
+ return -EINVAL;
+
+- if (check_add_overflow(prev_lcn, dlcn, &lcn))
++ /* Check special combination: 0 + SPARSE_LCN64. */
++ if (!prev_lcn && dlcn == SPARSE_LCN64) {
++ lcn = SPARSE_LCN64;
++ } else if (check_add_overflow(prev_lcn, dlcn, &lcn)) {
+ return -EINVAL;
++ }
+ prev_lcn = lcn;
+ } else
+ return -EINVAL;
--- /dev/null
+From b14fad555302a2104948feaff70503b64c80ac01 Mon Sep 17 00:00:00 2001
+From: Prithvi Tambewagh <activprithvi@gmail.com>
+Date: Thu, 25 Dec 2025 12:58:29 +0530
+Subject: io_uring: fix filename leak in __io_openat_prep()
+
+From: Prithvi Tambewagh <activprithvi@gmail.com>
+
+commit b14fad555302a2104948feaff70503b64c80ac01 upstream.
+
+ __io_openat_prep() allocates a struct filename using getname(). However,
+for the condition of the file being installed in the fixed file table as
+well as having O_CLOEXEC flag set, the function returns early. At that
+point, the request doesn't have REQ_F_NEED_CLEANUP flag set. Due to this,
+the memory for the newly allocated struct filename is not cleaned up,
+causing a memory leak.
+
+Fix this by setting the REQ_F_NEED_CLEANUP for the request just after the
+successful getname() call, so that when the request is torn down, the
+filename will be cleaned up, along with other resources needing cleanup.
+
+Reported-by: syzbot+00e61c43eb5e4740438f@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=00e61c43eb5e4740438f
+Tested-by: syzbot+00e61c43eb5e4740438f@syzkaller.appspotmail.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Prithvi Tambewagh <activprithvi@gmail.com>
+Fixes: b9445598d8c6 ("io_uring: openat directly into fixed fd table")
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ io_uring/openclose.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/io_uring/openclose.c
++++ b/io_uring/openclose.c
+@@ -65,13 +65,13 @@ static int __io_openat_prep(struct io_ki
+ open->filename = NULL;
+ return ret;
+ }
++ req->flags |= REQ_F_NEED_CLEANUP;
+
+ open->file_slot = READ_ONCE(sqe->file_index);
+ if (open->file_slot && (open->how.flags & O_CLOEXEC))
+ return -EINVAL;
+
+ open->nofile = rlimit(RLIMIT_NOFILE);
+- req->flags |= REQ_F_NEED_CLEANUP;
+ if (io_openat_force_async(open))
+ req->flags |= REQ_F_FORCE_ASYNC;
+ return 0;
--- /dev/null
+From f3f9f42232dee596d15491ca3f611d02174db49c Mon Sep 17 00:00:00 2001
+From: Zheng Yejian <zhengyejian@huaweicloud.com>
+Date: Fri, 11 Oct 2024 22:38:53 +0800
+Subject: kallsyms: Fix wrong "big" kernel symbol type read from procfs
+
+From: Zheng Yejian <zhengyejian@huaweicloud.com>
+
+commit f3f9f42232dee596d15491ca3f611d02174db49c upstream.
+
+Currently when the length of a symbol is longer than 0x7f characters,
+its type shown in /proc/kallsyms can be incorrect.
+
+I found this issue when reading the code, but it can be reproduced by
+following steps:
+
+ 1. Define a function which symbol length is 130 characters:
+
+ #define X13(x) x##x##x##x##x##x##x##x##x##x##x##x##x
+ static noinline void X13(x123456789)(void)
+ {
+ printk("hello world\n");
+ }
+
+ 2. The type in vmlinux is 't':
+
+ $ nm vmlinux | grep x123456
+ ffffffff816290f0 t x123456789x123456789x123456789x12[...]
+
+ 3. Then boot the kernel, the type shown in /proc/kallsyms becomes 'g'
+ instead of the expected 't':
+
+ # cat /proc/kallsyms | grep x123456
+ ffffffff816290f0 g x123456789x123456789x123456789x12[...]
+
+The root cause is that, after commit 73bbb94466fd ("kallsyms: support
+"big" kernel symbols"), ULEB128 was used to encode symbol name length.
+That is, for "big" kernel symbols of which name length is longer than
+0x7f characters, the length info is encoded into 2 bytes.
+
+kallsyms_get_symbol_type() expects to read the first char of the
+symbol name which indicates the symbol type. However, due to the
+"big" symbol case not being handled, the symbol type read from
+/proc/kallsyms may be wrong, so handle it properly.
+
+Cc: stable@vger.kernel.org
+Fixes: 73bbb94466fd ("kallsyms: support "big" kernel symbols")
+Signed-off-by: Zheng Yejian <zhengyejian@huaweicloud.com>
+Acked-by: Gary Guo <gary@garyguo.net>
+Link: https://patch.msgid.link/20241011143853.3022643-1-zhengyejian@huaweicloud.com
+Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/kallsyms.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/kernel/kallsyms.c
++++ b/kernel/kallsyms.c
+@@ -103,8 +103,11 @@ static char kallsyms_get_symbol_type(uns
+ {
+ /*
+ * Get just the first code, look it up in the token table,
+- * and return the first char from this token.
++ * and return the first char from this token. If MSB of length
++ * is 1, it is a "big" symbol, so needs an additional byte.
+ */
++ if (kallsyms_names[off] & 0x80)
++ off++;
+ return kallsyms_token_table[kallsyms_token_index[kallsyms_names[off + 1]]];
+ }
+
--- /dev/null
+From 62cd5d480b9762ce70d720a81fa5b373052ae05f Mon Sep 17 00:00:00 2001
+From: Jarkko Sakkinen <jarkko@kernel.org>
+Date: Sat, 18 Oct 2025 13:30:36 +0300
+Subject: KEYS: trusted: Fix a memory leak in tpm2_load_cmd
+
+From: Jarkko Sakkinen <jarkko@kernel.org>
+
+commit 62cd5d480b9762ce70d720a81fa5b373052ae05f upstream.
+
+'tpm2_load_cmd' allocates a tempoary blob indirectly via 'tpm2_key_decode'
+but it is not freed in the failure paths. Address this by wrapping the blob
+into with a cleanup helper.
+
+Cc: stable@vger.kernel.org # v5.13+
+Fixes: f2219745250f ("security: keys: trusted: use ASN.1 TPM2 key format for the blobs")
+Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ security/keys/trusted-keys/trusted_tpm2.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/security/keys/trusted-keys/trusted_tpm2.c
++++ b/security/keys/trusted-keys/trusted_tpm2.c
+@@ -375,6 +375,7 @@ static int tpm2_load_cmd(struct tpm_chip
+ struct trusted_key_options *options,
+ u32 *blob_handle)
+ {
++ u8 *blob_ref __free(kfree) = NULL;
+ struct tpm_buf buf;
+ unsigned int private_len;
+ unsigned int public_len;
+@@ -388,6 +389,9 @@ static int tpm2_load_cmd(struct tpm_chip
+ /* old form */
+ blob = payload->blob;
+ payload->old_format = 1;
++ } else {
++ /* Bind for cleanup: */
++ blob_ref = blob;
+ }
+
+ /* new format carries keyhandle but old format doesn't */
+@@ -446,8 +450,6 @@ static int tpm2_load_cmd(struct tpm_chip
+ (__be32 *) &buf.data[TPM_HEADER_SIZE]);
+
+ out:
+- if (blob != payload->blob)
+- kfree(blob);
+ tpm_buf_destroy(&buf);
+
+ if (rc > 0)
--- /dev/null
+From d3042cbe84a060b4df764eb6c5300bbe20d125ca Mon Sep 17 00:00:00 2001
+From: Steven Rostedt <rostedt@goodmis.org>
+Date: Wed, 3 Dec 2025 18:09:24 -0500
+Subject: ktest.pl: Fix uninitialized var in config-bisect.pl
+
+From: Steven Rostedt <rostedt@goodmis.org>
+
+commit d3042cbe84a060b4df764eb6c5300bbe20d125ca upstream.
+
+The error path of copying the old config used the wrong variable in the
+error message:
+
+ $ mkdir /tmp/build
+ $ ./tools/testing/ktest/config-bisect.pl -b /tmp/build config-good /tmp/config-bad
+ $ chmod 0 /tmp/build
+ $ ./tools/testing/ktest/config-bisect.pl -b /tmp/build config-good /tmp/config-bad good
+ cp /tmp/build//.config config-good.tmp ... [0 seconds] FAILED!
+ Use of uninitialized value $config in concatenation (.) or string at ./tools/testing/ktest/config-bisect.pl line 744.
+ failed to copy to config-good.tmp
+
+When it should have shown:
+
+ failed to copy /tmp/build//.config to config-good.tmp
+
+Cc: stable@vger.kernel.org
+Cc: John 'Warthog9' Hawley <warthog9@kernel.org>
+Fixes: 0f0db065999cf ("ktest: Add standalone config-bisect.pl program")
+Link: https://patch.msgid.link/20251203180924.6862bd26@gandalf.local.home
+Reported-by: "John W. Krahn" <jwkrahn@shaw.ca>
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/testing/ktest/config-bisect.pl | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/tools/testing/ktest/config-bisect.pl
++++ b/tools/testing/ktest/config-bisect.pl
+@@ -741,9 +741,9 @@ if ($start) {
+ die "Can not find file $bad\n";
+ }
+ if ($val eq "good") {
+- run_command "cp $output_config $good" or die "failed to copy $config to $good\n";
++ run_command "cp $output_config $good" or die "failed to copy $output_config to $good\n";
+ } elsif ($val eq "bad") {
+- run_command "cp $output_config $bad" or die "failed to copy $config to $bad\n";
++ run_command "cp $output_config $bad" or die "failed to copy $output_config to $bad\n";
+ }
+ }
+
--- /dev/null
+From 2f22115709fc7ebcfa40af3367a508fbbd2f71e9 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@kernel.org>
+Date: Sun, 2 Nov 2025 15:42:04 -0800
+Subject: lib/crypto: x86/blake2s: Fix 32-bit arg treated as 64-bit
+
+From: Eric Biggers <ebiggers@kernel.org>
+
+commit 2f22115709fc7ebcfa40af3367a508fbbd2f71e9 upstream.
+
+In the C code, the 'inc' argument to the assembly functions
+blake2s_compress_ssse3() and blake2s_compress_avx512() is declared with
+type u32, matching blake2s_compress(). The assembly code then reads it
+from the 64-bit %rcx. However, the ABI doesn't guarantee zero-extension
+to 64 bits, nor do gcc or clang guarantee it. Therefore, fix these
+functions to read this argument from the 32-bit %ecx.
+
+In theory, this bug could have caused the wrong 'inc' value to be used,
+causing incorrect BLAKE2s hashes. In practice, probably not: I've fixed
+essentially this same bug in many other assembly files too, but there's
+never been a real report of it having caused a problem. In x86_64, all
+writes to 32-bit registers are zero-extended to 64 bits. That results
+in zero-extension in nearly all situations. I've only been able to
+demonstrate a lack of zero-extension with a somewhat contrived example
+involving truncation, e.g. when the C code has a u64 variable holding
+0x1234567800000040 and passes it as a u32 expecting it to be truncated
+to 0x40 (64). But that's not what the real code does, of course.
+
+Fixes: ed0356eda153 ("crypto: blake2s - x86_64 SIMD implementation")
+Cc: stable@vger.kernel.org
+Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
+Link: https://lore.kernel.org/r/20251102234209.62133-2-ebiggers@kernel.org
+Signed-off-by: Eric Biggers <ebiggers@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/crypto/blake2s-core.S | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/crypto/blake2s-core.S
++++ b/arch/x86/crypto/blake2s-core.S
+@@ -54,7 +54,7 @@ SYM_FUNC_START(blake2s_compress_ssse3)
+ movdqa ROT16(%rip),%xmm12
+ movdqa ROR328(%rip),%xmm13
+ movdqu 0x20(%rdi),%xmm14
+- movq %rcx,%xmm15
++ movd %ecx,%xmm15
+ leaq SIGMA+0xa0(%rip),%r8
+ jmp .Lbeginofloop
+ .align 32
+@@ -179,7 +179,7 @@ SYM_FUNC_START(blake2s_compress_avx512)
+ vmovdqu (%rdi),%xmm0
+ vmovdqu 0x10(%rdi),%xmm1
+ vmovdqu 0x20(%rdi),%xmm4
+- vmovq %rcx,%xmm5
++ vmovd %ecx,%xmm5
+ vmovdqa IV(%rip),%xmm14
+ vmovdqa IV+16(%rip),%xmm15
+ jmp .Lblake2s_compress_avx512_mainloop
--- /dev/null
+From b1f856b1727c2eaa4be2c6d7cd7a8ed052bbeb87 Mon Sep 17 00:00:00 2001
+From: Sarthak Garg <sarthak.garg@oss.qualcomm.com>
+Date: Fri, 14 Nov 2025 13:58:24 +0530
+Subject: mmc: sdhci-msm: Avoid early clock doubling during HS400 transition
+
+From: Sarthak Garg <sarthak.garg@oss.qualcomm.com>
+
+commit b1f856b1727c2eaa4be2c6d7cd7a8ed052bbeb87 upstream.
+
+According to the hardware programming guide, the clock frequency must
+remain below 52MHz during the transition to HS400 mode.
+
+However,in the current implementation, the timing is set to HS400 (a
+DDR mode) before adjusting the clock. This causes the clock to double
+prematurely to 104MHz during the transition phase, violating the
+specification and potentially resulting in CRC errors or CMD timeouts.
+
+This change ensures that clock doubling is avoided during intermediate
+transitions and is applied only when the card requires a 200MHz clock
+for HS400 operation.
+
+Signed-off-by: Sarthak Garg <sarthak.garg@oss.qualcomm.com>
+Reviewed-by: Bjorn Andersson <andersson@kernel.org>
+Acked-by: Adrian Hunter <adrian.hunter@intel.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/sdhci-msm.c | 27 +++++++++++++++------------
+ 1 file changed, 15 insertions(+), 12 deletions(-)
+
+--- a/drivers/mmc/host/sdhci-msm.c
++++ b/drivers/mmc/host/sdhci-msm.c
+@@ -344,41 +344,43 @@ static void sdhci_msm_v5_variant_writel_
+ writel_relaxed(val, host->ioaddr + offset);
+ }
+
+-static unsigned int msm_get_clock_mult_for_bus_mode(struct sdhci_host *host)
++static unsigned int msm_get_clock_mult_for_bus_mode(struct sdhci_host *host,
++ unsigned int clock,
++ unsigned int timing)
+ {
+- struct mmc_ios ios = host->mmc->ios;
+ /*
+ * The SDHC requires internal clock frequency to be double the
+ * actual clock that will be set for DDR mode. The controller
+ * uses the faster clock(100/400MHz) for some of its parts and
+ * send the actual required clock (50/200MHz) to the card.
+ */
+- if (ios.timing == MMC_TIMING_UHS_DDR50 ||
+- ios.timing == MMC_TIMING_MMC_DDR52 ||
+- ios.timing == MMC_TIMING_MMC_HS400 ||
++ if (timing == MMC_TIMING_UHS_DDR50 ||
++ timing == MMC_TIMING_MMC_DDR52 ||
++ (timing == MMC_TIMING_MMC_HS400 &&
++ clock == MMC_HS200_MAX_DTR) ||
+ host->flags & SDHCI_HS400_TUNING)
+ return 2;
+ return 1;
+ }
+
+ static void msm_set_clock_rate_for_bus_mode(struct sdhci_host *host,
+- unsigned int clock)
++ unsigned int clock,
++ unsigned int timing)
+ {
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
+- struct mmc_ios curr_ios = host->mmc->ios;
+ struct clk *core_clk = msm_host->bulk_clks[0].clk;
+ unsigned long achieved_rate;
+ unsigned int desired_rate;
+ unsigned int mult;
+ int rc;
+
+- mult = msm_get_clock_mult_for_bus_mode(host);
++ mult = msm_get_clock_mult_for_bus_mode(host, clock, timing);
+ desired_rate = clock * mult;
+ rc = dev_pm_opp_set_rate(mmc_dev(host->mmc), desired_rate);
+ if (rc) {
+ pr_err("%s: Failed to set clock at rate %u at timing %d\n",
+- mmc_hostname(host->mmc), desired_rate, curr_ios.timing);
++ mmc_hostname(host->mmc), desired_rate, timing);
+ return;
+ }
+
+@@ -397,7 +399,7 @@ static void msm_set_clock_rate_for_bus_m
+ msm_host->clk_rate = desired_rate;
+
+ pr_debug("%s: Setting clock at rate %lu at timing %d\n",
+- mmc_hostname(host->mmc), achieved_rate, curr_ios.timing);
++ mmc_hostname(host->mmc), achieved_rate, timing);
+ }
+
+ /* Platform specific tuning */
+@@ -1239,7 +1241,7 @@ static int sdhci_msm_execute_tuning(stru
+ */
+ if (host->flags & SDHCI_HS400_TUNING) {
+ sdhci_msm_hc_select_mode(host);
+- msm_set_clock_rate_for_bus_mode(host, ios.clock);
++ msm_set_clock_rate_for_bus_mode(host, ios.clock, ios.timing);
+ host->flags &= ~SDHCI_HS400_TUNING;
+ }
+
+@@ -1864,6 +1866,7 @@ static void sdhci_msm_set_clock(struct s
+ {
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
++ struct mmc_ios ios = host->mmc->ios;
+
+ if (!clock) {
+ host->mmc->actual_clock = msm_host->clk_rate = 0;
+@@ -1872,7 +1875,7 @@ static void sdhci_msm_set_clock(struct s
+
+ sdhci_msm_hc_select_mode(host);
+
+- msm_set_clock_rate_for_bus_mode(host, clock);
++ msm_set_clock_rate_for_bus_mode(host, ios.clock, ios.timing);
+ out:
+ __sdhci_msm_set_clock(host, clock);
+ }
--- /dev/null
+From c943bfc6afb8d0e781b9b7406f36caa8bbf95cb9 Mon Sep 17 00:00:00 2001
+From: Stefan Haberland <sth@linux.ibm.com>
+Date: Wed, 26 Nov 2025 17:06:31 +0100
+Subject: s390/dasd: Fix gendisk parent after copy pair swap
+
+From: Stefan Haberland <sth@linux.ibm.com>
+
+commit c943bfc6afb8d0e781b9b7406f36caa8bbf95cb9 upstream.
+
+After a copy pair swap the block device's "device" symlink points to
+the secondary CCW device, but the gendisk's parent remained the
+primary, leaving /sys/block/<dasdx> under the wrong parent.
+
+Move the gendisk to the secondary's device with device_move(), keeping
+the sysfs topology consistent after the swap.
+
+Fixes: 413862caad6f ("s390/dasd: add copy pair swap capability")
+Cc: stable@vger.kernel.org #6.1
+Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
+Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/s390/block/dasd_eckd.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/s390/block/dasd_eckd.c
++++ b/drivers/s390/block/dasd_eckd.c
+@@ -6189,6 +6189,7 @@ static int dasd_eckd_copy_pair_swap(stru
+ struct dasd_copy_relation *copy;
+ struct dasd_block *block;
+ struct gendisk *gdp;
++ int rc;
+
+ copy = device->copy;
+ if (!copy)
+@@ -6223,6 +6224,13 @@ static int dasd_eckd_copy_pair_swap(stru
+ /* swap blocklayer device link */
+ gdp = block->gdp;
+ dasd_add_link_to_gendisk(gdp, secondary);
++ rc = device_move(disk_to_dev(gdp), &secondary->cdev->dev, DPM_ORDER_NONE);
++ if (rc) {
++ dev_err(&primary->cdev->dev,
++ "copy_pair_swap: moving blockdevice parent %s->%s failed (%d)\n",
++ dev_name(&primary->cdev->dev),
++ dev_name(&secondary->cdev->dev), rc);
++ }
+
+ /* re-enable device */
+ dasd_device_remove_stop_bits(primary, DASD_STOPPED_PPRC);
block-rnbd-clt-fix-signedness-bug-in-init_dev.patch
vhost-vsock-improve-rcu-read-sections-around-vhost_v.patch
cifs-fix-memory-and-information-leak-in-smb3_reconfi.patch
+keys-trusted-fix-a-memory-leak-in-tpm2_load_cmd.patch
+io_uring-fix-filename-leak-in-__io_openat_prep.patch
+mmc-sdhci-msm-avoid-early-clock-doubling-during-hs400-transition.patch
+lib-crypto-x86-blake2s-fix-32-bit-arg-treated-as-64-bit.patch
+s390-dasd-fix-gendisk-parent-after-copy-pair-swap.patch
+block-rate-limit-capacity-change-info-log.patch
+floppy-fix-for-page_size-4kb.patch
+kallsyms-fix-wrong-big-kernel-symbol-type-read-from-procfs.patch
+fs-ntfs3-fix-mount-failure-for-sparse-runs-in-run_unpack.patch
+ktest.pl-fix-uninitialized-var-in-config-bisect.pl.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
