--- /dev/null
+From 12c5dd1870da2e811451a4ca292f4ae843f919ae Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 22 Feb 2026 23:52:40 -0300
+Subject: ACPI: OSI: Add DMI quirk for Acer Aspire One D255
+
+From: Sofia Schneider <sofia@schn.dev>
+
+[ Upstream commit 5ede90206273ff156a778254f0f972a55e973c89 ]
+
+The screen backlight turns off during boot (specifically during udev device
+initialization) when returning true for _OSI("Windows 2009").
+
+Analyzing the device's DSDT reveals that the firmware takes a different
+code path when Windows 7 is reported, which leads to the backlight shutoff.
+Add a DMI quirk to invoke dmi_disable_osi_win7 for this model.
+
+Signed-off-by: Sofia Schneider <sofia@schn.dev>
+Link: https://patch.msgid.link/20260223025240.518509-1-sofia@schn.dev
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/acpi/osi.c | 13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+diff --git a/drivers/acpi/osi.c b/drivers/acpi/osi.c
+index d93409f2b2a07..6913264490225 100644
+--- a/drivers/acpi/osi.c
++++ b/drivers/acpi/osi.c
+@@ -413,6 +413,19 @@ static const struct dmi_system_id acpi_osi_dmi_table[] __initconst = {
+ },
+ },
+
++ /*
++ * The screen backlight turns off during udev device creation
++ * when returning true for _OSI("Windows 2009")
++ */
++ {
++ .callback = dmi_disable_osi_win7,
++ .ident = "Acer Aspire One D255",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "AOD255"),
++ },
++ },
++
+ /*
+ * The wireless hotkey does not work on those machines when
+ * returning true for _OSI("Windows 2012")
+--
+2.51.0
+
--- /dev/null
+From 6e0831cae2b5f399801212293745233bc48c515c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 5 Feb 2026 23:05:02 +0100
+Subject: ACPI: PM: Save NVS memory on Lenovo G70-35
+
+From: Piotr Mazek <pmazek@outlook.com>
+
+[ Upstream commit 023cd6d90f8aa2ef7b72d84be84a18e61ecebd64 ]
+
+[821d6f0359b0614792ab8e2fb93b503e25a65079] prevented machines
+produced later than 2012 from saving NVS region to accelerate S3.
+
+Despite being made after 2012, Lenovo G70-35 still needs NVS memory
+saving during S3. A quirk is introduced for this platform.
+
+Signed-off-by: Piotr Mazek <pmazek@outlook.com>
+[ rjw: Subject adjustment ]
+Link: https://patch.msgid.link/GV2PPF3CD5B63CC2442EE3F76F8443EAD90D499A@GV2PPF3CD5B63CC.EURP251.PROD.OUTLOOK.COM
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/acpi/sleep.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
+index e79c004ca0b24..df03b6ed16fbb 100644
+--- a/drivers/acpi/sleep.c
++++ b/drivers/acpi/sleep.c
+@@ -372,6 +372,14 @@ static const struct dmi_system_id acpisleep_dmi_table[] __initconst = {
+ DMI_MATCH(DMI_PRODUCT_NAME, "80E1"),
+ },
+ },
++ {
++ .callback = init_nvs_save_s3,
++ .ident = "Lenovo G70-35",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "80Q5"),
++ },
++ },
+ /*
+ * ThinkPad X1 Tablet(2016) cannot do suspend-to-idle using
+ * the Low Power S0 Idle firmware interface (see
+--
+2.51.0
+
--- /dev/null
+From 3912e0576ab48b50000b41c12363a466c832442c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 3 Mar 2026 16:31:42 +0100
+Subject: powerpc: 83xx: km83xx: Fix keymile vendor prefix
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: J. Neuschäfer <j.ne@posteo.net>
+
+[ Upstream commit 691417ffe7821721e0a28bd25ad8c0dc0d4ae4ad ]
+
+When kmeter.c was refactored into km83xx.c in 2011, the "keymile" vendor
+prefix was changed to upper-case "Keymile". The devicetree at
+arch/powerpc/boot/dts/kmeter1.dts never underwent the same change,
+suggesting that this was simply a mistake.
+
+Fixes: 93e2b95c81042d ("powerpc/83xx: rename and update kmeter1")
+Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
+Reviewed-by: Heiko Schocher <hs@nabladev.com>
+Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
+Link: https://patch.msgid.link/20260303-keymile-v1-1-463a11e71702@posteo.net
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/platforms/83xx/km83xx.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/arch/powerpc/platforms/83xx/km83xx.c b/arch/powerpc/platforms/83xx/km83xx.c
+index bcdc2c203ec93..e108d316a744e 100644
+--- a/arch/powerpc/platforms/83xx/km83xx.c
++++ b/arch/powerpc/platforms/83xx/km83xx.c
+@@ -156,8 +156,8 @@ machine_device_initcall(mpc83xx_km, mpc83xx_declare_of_platform_devices);
+
+ /* list of the supported boards */
+ static char *board[] __initdata = {
+- "Keymile,KMETER1",
+- "Keymile,kmpbec8321",
++ "keymile,KMETER1",
++ "keymile,kmpbec8321",
+ NULL
+ };
+
+--
+2.51.0
+
--- /dev/null
+From 935685f1513b9c4b6a7884f8f49f28785aa18caa Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 3 Feb 2026 08:30:41 +0100
+Subject: powerpc/uaccess: Fix inline assembly for clang build on PPC32
+
+From: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
+
+[ Upstream commit 0ee95a1d458630272d0415d0ffa9424fcb606c90 ]
+
+Test robot reports the following error with clang-16.0.6:
+
+ In file included from kernel/rseq.c:75:
+ include/linux/rseq_entry.h:141:3: error: invalid operand for instruction
+ unsafe_get_user(offset, &ucs->post_commit_offset, efault);
+ ^
+ include/linux/uaccess.h:608:2: note: expanded from macro 'unsafe_get_user'
+ arch_unsafe_get_user(x, ptr, local_label); \
+ ^
+ arch/powerpc/include/asm/uaccess.h:518:2: note: expanded from macro 'arch_unsafe_get_user'
+ __get_user_size_goto(__gu_val, __gu_addr, sizeof(*(p)), e); \
+ ^
+ arch/powerpc/include/asm/uaccess.h:284:2: note: expanded from macro '__get_user_size_goto'
+ __get_user_size_allowed(x, ptr, size, __gus_retval); \
+ ^
+ arch/powerpc/include/asm/uaccess.h:275:10: note: expanded from macro '__get_user_size_allowed'
+ case 8: __get_user_asm2(x, (u64 __user *)ptr, retval); break; \
+ ^
+ arch/powerpc/include/asm/uaccess.h:258:4: note: expanded from macro '__get_user_asm2'
+ " li %1+1,0\n" \
+ ^
+ <inline asm>:7:5: note: instantiated into assembly here
+ li 31+1,0
+ ^
+ 1 error generated.
+
+On PPC32, for 64 bits vars a pair of registers is used. Usually the
+lower register in the pair is the high part and the higher register is
+the low part. GCC uses r3/r4 ... r11/r12 ... r14/r15 ... r30/r31
+
+In older kernel code inline assembly was using %1 and %1+1 to represent
+64 bits values. However here it looks like clang uses r31 as high part,
+allthough r32 doesn't exist hence the error.
+
+Allthoug %1+1 should work, most places now use %L1 instead of %1+1, so
+let's do the same here.
+
+With that change, the build doesn't fail anymore and a disassembly shows
+clang uses r17/r18 and r31/r14 pair when GCC would have used r16/r17 and
+r30/r31:
+
+ Disassembly of section .fixup:
+
+ 00000000 <.fixup>:
+ 0: 38 a0 ff f2 li r5,-14
+ 4: 3a 20 00 00 li r17,0
+ 8: 3a 40 00 00 li r18,0
+ c: 48 00 00 00 b c <.fixup+0xc>
+ c: R_PPC_REL24 .text+0xbc
+ 10: 38 a0 ff f2 li r5,-14
+ 14: 3b e0 00 00 li r31,0
+ 18: 39 c0 00 00 li r14,0
+ 1c: 48 00 00 00 b 1c <.fixup+0x1c>
+ 1c: R_PPC_REL24 .text+0x144
+
+Reported-by: kernel test robot <lkp@intel.com>
+Closes: https://lore.kernel.org/oe-kbuild-all/202602021825.otcItxGi-lkp@intel.com/
+Fixes: c20beffeec3c ("powerpc/uaccess: Use flexible addressing with __put_user()/__get_user()")
+Signed-off-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
+Acked-by: Nathan Chancellor <nathan@kernel.org>
+Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
+Link: https://patch.msgid.link/8ca3a657a650e497a96bfe7acde2f637dadab344.1770103646.git.chleroy@kernel.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/include/asm/uaccess.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h
+index 6df110c1254e2..ab9efc429615f 100644
+--- a/arch/powerpc/include/asm/uaccess.h
++++ b/arch/powerpc/include/asm/uaccess.h
+@@ -279,7 +279,7 @@ extern long __get_user_bad(void);
+ ".section .fixup,\"ax\"\n" \
+ "4: li %0,%3\n" \
+ " li %1,0\n" \
+- " li %1+1,0\n" \
++ " li %L1,0\n" \
+ " b 3b\n" \
+ ".previous\n" \
+ EX_TABLE(1b, 4b) \
+--
+2.51.0
+
--- /dev/null
+From 5cdb71f64da698268437654cfa172cb77f5d1e2a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 20 Feb 2026 15:11:48 -0600
+Subject: remoteproc: sysmon: Correct subsys_name_len type in QMI request
+
+From: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
+
+[ Upstream commit da994db94e60f9a9411108ddf4d1836147ad4c9c ]
+
+The QMI message encoder has up until recently read a single byte (as
+elem_size == 1), but with the introduction of big endian support it's
+become apparent that this field is expected to be a full u32 -
+regardless of the size of the length in the encoded message (which is
+what elem_size specifies).
+
+The result is that the encoder now reads past the length byte and
+rejects the unreasonably large length formed when including the
+following 3 bytes from the subsys_name array.
+
+Fix this by changing to the expected type.
+
+Fixes: 1fb82ee806d1 ("remoteproc: qcom: Introduce sysmon")
+Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
+Reviewed-by: Chris Lew <christopher.lew@oss.qualcomm.com>
+Link: https://lore.kernel.org/r/20260220-qmi-encode-invalid-length-v2-1-5674be35ab29@oss.qualcomm.com
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/remoteproc/qcom_sysmon.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/remoteproc/qcom_sysmon.c b/drivers/remoteproc/qcom_sysmon.c
+index c348ea35e47c3..be3a2fa12394b 100644
+--- a/drivers/remoteproc/qcom_sysmon.c
++++ b/drivers/remoteproc/qcom_sysmon.c
+@@ -196,7 +196,7 @@ static struct qmi_elem_info ssctl_shutdown_resp_ei[] = {
+ };
+
+ struct ssctl_subsys_event_req {
+- u8 subsys_name_len;
++ u32 subsys_name_len;
+ char subsys_name[SSCTL_SUBSYS_NAME_LENGTH];
+ u32 event;
+ u8 evt_driven_valid;
+--
+2.51.0
+
--- /dev/null
+From a38c05d62053917207794d7233f1e48d017d45d0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 10 Feb 2026 20:18:50 +0100
+Subject: scsi: ses: Fix devices attaching to different hosts
+
+From: Tomas Henzl <thenzl@redhat.com>
+
+[ Upstream commit 70ca8caa96ce473647054f5c7b9dab5423902402 ]
+
+On a multipath SAS system some devices don't end up with correct symlinks
+from the SCSI device to its enclosure. Some devices even have enclosure
+links pointing to enclosures attached to different SCSI hosts.
+
+ses_match_to_enclosure() calls enclosure_for_each_device() which iterates
+over all enclosures on the system, not just enclosures attached to the
+current SCSI host.
+
+Replace the iteration with a direct call to ses_enclosure_find_by_addr().
+
+Reviewed-by: David Jeffery <djeffery@redhat.com>
+Signed-off-by: Tomas Henzl <thenzl@redhat.com>
+Link: https://patch.msgid.link/20260210191850.36784-1-thenzl@redhat.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/ses.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/scsi/ses.c b/drivers/scsi/ses.c
+index 6a1428d453f3e..92b3fd10058dd 100644
+--- a/drivers/scsi/ses.c
++++ b/drivers/scsi/ses.c
+@@ -497,9 +497,8 @@ struct efd {
+ };
+
+ static int ses_enclosure_find_by_addr(struct enclosure_device *edev,
+- void *data)
++ struct efd *efd)
+ {
+- struct efd *efd = data;
+ int i;
+ struct ses_component *scomp;
+
+@@ -652,7 +651,7 @@ static void ses_match_to_enclosure(struct enclosure_device *edev,
+ if (efd.addr) {
+ efd.dev = &sdev->sdev_gendev;
+
+- enclosure_for_each_device(ses_enclosure_find_by_addr, &efd);
++ ses_enclosure_find_by_addr(edev, &efd);
+ }
+ }
+
+--
+2.51.0
+
--- /dev/null
+From 396f8c99c1083e78db2abdd27b5dee2c855906d2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 29 Jan 2026 15:30:39 +0100
+Subject: scsi: storvsc: Fix scheduling while atomic on PREEMPT_RT
+
+From: Jan Kiszka <jan.kiszka@siemens.com>
+
+[ Upstream commit 57297736c08233987e5d29ce6584c6ca2a831b12 ]
+
+This resolves the follow splat and lock-up when running with PREEMPT_RT
+enabled on Hyper-V:
+
+[ 415.140818] BUG: scheduling while atomic: stress-ng-iomix/1048/0x00000002
+[ 415.140822] INFO: lockdep is turned off.
+[ 415.140823] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec ghash_clmulni_intel aesni_intel rapl binfmt_misc nls_ascii nls_cp437 vfat fat snd_pcm hyperv_drm snd_timer drm_client_lib drm_shmem_helper snd sg soundcore drm_kms_helper pcspkr hv_balloon hv_utils evdev joydev drm configfs efi_pstore nfnetlink vsock_loopback vmw_vsock_virtio_transport_common hv_sock vmw_vsock_vmci_transport vsock vmw_vmci efivarfs autofs4 ext4 crc16 mbcache jbd2 sr_mod sd_mod cdrom hv_storvsc serio_raw hid_generic scsi_transport_fc hid_hyperv scsi_mod hid hv_netvsc hyperv_keyboard scsi_common
+[ 415.140846] Preemption disabled at:
+[ 415.140847] [<ffffffffc0656171>] storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc]
+[ 415.140854] CPU: 8 UID: 0 PID: 1048 Comm: stress-ng-iomix Not tainted 6.19.0-rc7 #30 PREEMPT_{RT,(full)}
+[ 415.140856] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/04/2024
+[ 415.140857] Call Trace:
+[ 415.140861] <TASK>
+[ 415.140861] ? storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc]
+[ 415.140863] dump_stack_lvl+0x91/0xb0
+[ 415.140870] __schedule_bug+0x9c/0xc0
+[ 415.140875] __schedule+0xdf6/0x1300
+[ 415.140877] ? rtlock_slowlock_locked+0x56c/0x1980
+[ 415.140879] ? rcu_is_watching+0x12/0x60
+[ 415.140883] schedule_rtlock+0x21/0x40
+[ 415.140885] rtlock_slowlock_locked+0x502/0x1980
+[ 415.140891] rt_spin_lock+0x89/0x1e0
+[ 415.140893] hv_ringbuffer_write+0x87/0x2a0
+[ 415.140899] vmbus_sendpacket_mpb_desc+0xb6/0xe0
+[ 415.140900] ? rcu_is_watching+0x12/0x60
+[ 415.140902] storvsc_queuecommand+0x669/0xbe0 [hv_storvsc]
+[ 415.140904] ? HARDIRQ_verbose+0x10/0x10
+[ 415.140908] ? __rq_qos_issue+0x28/0x40
+[ 415.140911] scsi_queue_rq+0x760/0xd80 [scsi_mod]
+[ 415.140926] __blk_mq_issue_directly+0x4a/0xc0
+[ 415.140928] blk_mq_issue_direct+0x87/0x2b0
+[ 415.140931] blk_mq_dispatch_queue_requests+0x120/0x440
+[ 415.140933] blk_mq_flush_plug_list+0x7a/0x1a0
+[ 415.140935] __blk_flush_plug+0xf4/0x150
+[ 415.140940] __submit_bio+0x2b2/0x5c0
+[ 415.140944] ? submit_bio_noacct_nocheck+0x272/0x360
+[ 415.140946] submit_bio_noacct_nocheck+0x272/0x360
+[ 415.140951] ext4_read_bh_lock+0x3e/0x60 [ext4]
+[ 415.140995] ext4_block_write_begin+0x396/0x650 [ext4]
+[ 415.141018] ? __pfx_ext4_da_get_block_prep+0x10/0x10 [ext4]
+[ 415.141038] ext4_da_write_begin+0x1c4/0x350 [ext4]
+[ 415.141060] generic_perform_write+0x14e/0x2c0
+[ 415.141065] ext4_buffered_write_iter+0x6b/0x120 [ext4]
+[ 415.141083] vfs_write+0x2ca/0x570
+[ 415.141087] ksys_write+0x76/0xf0
+[ 415.141089] do_syscall_64+0x99/0x1490
+[ 415.141093] ? rcu_is_watching+0x12/0x60
+[ 415.141095] ? finish_task_switch.isra.0+0xdf/0x3d0
+[ 415.141097] ? rcu_is_watching+0x12/0x60
+[ 415.141098] ? lock_release+0x1f0/0x2a0
+[ 415.141100] ? rcu_is_watching+0x12/0x60
+[ 415.141101] ? finish_task_switch.isra.0+0xe4/0x3d0
+[ 415.141103] ? rcu_is_watching+0x12/0x60
+[ 415.141104] ? __schedule+0xb34/0x1300
+[ 415.141106] ? hrtimer_try_to_cancel+0x1d/0x170
+[ 415.141109] ? do_nanosleep+0x8b/0x160
+[ 415.141111] ? hrtimer_nanosleep+0x89/0x100
+[ 415.141114] ? __pfx_hrtimer_wakeup+0x10/0x10
+[ 415.141116] ? xfd_validate_state+0x26/0x90
+[ 415.141118] ? rcu_is_watching+0x12/0x60
+[ 415.141120] ? do_syscall_64+0x1e0/0x1490
+[ 415.141121] ? do_syscall_64+0x1e0/0x1490
+[ 415.141123] ? rcu_is_watching+0x12/0x60
+[ 415.141124] ? do_syscall_64+0x1e0/0x1490
+[ 415.141125] ? do_syscall_64+0x1e0/0x1490
+[ 415.141127] ? irqentry_exit+0x140/0x7e0
+[ 415.141129] entry_SYSCALL_64_after_hwframe+0x76/0x7e
+
+get_cpu() disables preemption while the spinlock hv_ringbuffer_write is
+using is converted to an rt-mutex under PREEMPT_RT.
+
+Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
+Tested-by: Florian Bezdeka <florian.bezdeka@siemens.com>
+Reviewed-by: Michael Kelley <mhklinux@outlook.com>
+Tested-by: Michael Kelley <mhklinux@outlook.com>
+Link: https://patch.msgid.link/0c7fb5cd-fb21-4760-8593-e04bade84744@siemens.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/storvsc_drv.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
+index 917ba169d418b..d91e022a0154c 100644
+--- a/drivers/scsi/storvsc_drv.c
++++ b/drivers/scsi/storvsc_drv.c
+@@ -1832,8 +1832,9 @@ static int storvsc_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *scmnd)
+ cmd_request->payload_sz = payload_sz;
+
+ /* Invokes the vsc to start an IO */
+- ret = storvsc_do_io(dev, cmd_request, get_cpu());
+- put_cpu();
++ migrate_disable();
++ ret = storvsc_do_io(dev, cmd_request, smp_processor_id());
++ migrate_enable();
+
+ if (ret == -EAGAIN) {
+ if (payload_sz > sizeof(cmd_request->mpb))
+--
+2.51.0
+
net-bridge-fix-nd_tbl-null-dereference-when-ipv6-is-.patch
net-vxlan-fix-nd_tbl-null-dereference-when-ipv6-is-d.patch
net-ipv6-fix-panic-when-ipv4-route-references-loopba.patch
+scsi-storvsc-fix-scheduling-while-atomic-on-preempt_.patch
+acpi-pm-save-nvs-memory-on-lenovo-g70-35.patch
+unshare-fix-unshare_fs-handling.patch
+acpi-osi-add-dmi-quirk-for-acer-aspire-one-d255.patch
+scsi-ses-fix-devices-attaching-to-different-hosts.patch
+powerpc-uaccess-fix-inline-assembly-for-clang-build-.patch
+remoteproc-sysmon-correct-subsys_name_len-type-in-qm.patch
+powerpc-83xx-km83xx-fix-keymile-vendor-prefix.patch
--- /dev/null
+From 9a9b68e50546bbaf61a3e5735b6593b67fdfdec5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 7 Feb 2026 08:25:24 +0000
+Subject: unshare: fix unshare_fs() handling
+
+From: Al Viro <viro@zeniv.linux.org.uk>
+
+[ Upstream commit 6c4b2243cb6c0755159bd567130d5e12e7b10d9f ]
+
+There's an unpleasant corner case in unshare(2), when we have a
+CLONE_NEWNS in flags and current->fs hadn't been shared at all; in that
+case copy_mnt_ns() gets passed current->fs instead of a private copy,
+which causes interesting warts in proof of correctness]
+
+> I guess if private means fs->users == 1, the condition could still be true.
+
+Unfortunately, it's worse than just a convoluted proof of correctness.
+Consider the case when we have CLONE_NEWCGROUP in addition to CLONE_NEWNS
+(and current->fs->users == 1).
+
+We pass current->fs to copy_mnt_ns(), all right. Suppose it succeeds and
+flips current->fs->{pwd,root} to corresponding locations in the new namespace.
+Now we proceed to copy_cgroup_ns(), which fails (e.g. with -ENOMEM).
+We call put_mnt_ns() on the namespace created by copy_mnt_ns(), it's
+destroyed and its mount tree is dissolved, but... current->fs->root and
+current->fs->pwd are both left pointing to now detached mounts.
+
+They are pinning those, so it's not a UAF, but it leaves the calling
+process with unshare(2) failing with -ENOMEM _and_ leaving it with
+pwd and root on detached isolated mounts. The last part is clearly a bug.
+
+There is other fun related to that mess (races with pivot_root(), including
+the one between pivot_root() and fork(), of all things), but this one
+is easy to isolate and fix - treat CLONE_NEWNS as "allocate a new
+fs_struct even if it hadn't been shared in the first place". Sure, we could
+go for something like "if both CLONE_NEWNS *and* one of the things that might
+end up failing after copy_mnt_ns() call in create_new_namespaces() are set,
+force allocation of new fs_struct", but let's keep it simple - the cost
+of copy_fs_struct() is trivial.
+
+Another benefit is that copy_mnt_ns() with CLONE_NEWNS *always* gets
+a freshly allocated fs_struct, yet to be attached to anything. That
+seriously simplifies the analysis...
+
+FWIW, that bug had been there since the introduction of unshare(2) ;-/
+
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Link: https://patch.msgid.link/20260207082524.GE3183987@ZenIV
+Tested-by: Waiman Long <longman@redhat.com>
+Signed-off-by: Christian Brauner <brauner@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/fork.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/kernel/fork.c b/kernel/fork.c
+index 072fe9d6c47b6..531de2d1b3bfe 100644
+--- a/kernel/fork.c
++++ b/kernel/fork.c
+@@ -2989,7 +2989,7 @@ static int unshare_fs(unsigned long unshare_flags, struct fs_struct **new_fsp)
+ return 0;
+
+ /* don't need lock here; in the worst case we'll do useless copy */
+- if (fs->users == 1)
++ if (!(unshare_flags & CLONE_NEWNS) && fs->users == 1)
+ return 0;
+
+ *new_fsp = copy_fs_struct(fs);
+--
+2.51.0
+
--- /dev/null
+From 4bea82b32c807273b8389566d5c9bc2538c31774 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 22 Feb 2026 23:52:40 -0300
+Subject: ACPI: OSI: Add DMI quirk for Acer Aspire One D255
+
+From: Sofia Schneider <sofia@schn.dev>
+
+[ Upstream commit 5ede90206273ff156a778254f0f972a55e973c89 ]
+
+The screen backlight turns off during boot (specifically during udev device
+initialization) when returning true for _OSI("Windows 2009").
+
+Analyzing the device's DSDT reveals that the firmware takes a different
+code path when Windows 7 is reported, which leads to the backlight shutoff.
+Add a DMI quirk to invoke dmi_disable_osi_win7 for this model.
+
+Signed-off-by: Sofia Schneider <sofia@schn.dev>
+Link: https://patch.msgid.link/20260223025240.518509-1-sofia@schn.dev
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/acpi/osi.c | 13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+diff --git a/drivers/acpi/osi.c b/drivers/acpi/osi.c
+index d93409f2b2a07..6913264490225 100644
+--- a/drivers/acpi/osi.c
++++ b/drivers/acpi/osi.c
+@@ -413,6 +413,19 @@ static const struct dmi_system_id acpi_osi_dmi_table[] __initconst = {
+ },
+ },
+
++ /*
++ * The screen backlight turns off during udev device creation
++ * when returning true for _OSI("Windows 2009")
++ */
++ {
++ .callback = dmi_disable_osi_win7,
++ .ident = "Acer Aspire One D255",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "AOD255"),
++ },
++ },
++
+ /*
+ * The wireless hotkey does not work on those machines when
+ * returning true for _OSI("Windows 2012")
+--
+2.51.0
+
--- /dev/null
+From eed5e396630f601911b78df8ef996a765bc7daf0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 5 Feb 2026 23:05:02 +0100
+Subject: ACPI: PM: Save NVS memory on Lenovo G70-35
+
+From: Piotr Mazek <pmazek@outlook.com>
+
+[ Upstream commit 023cd6d90f8aa2ef7b72d84be84a18e61ecebd64 ]
+
+[821d6f0359b0614792ab8e2fb93b503e25a65079] prevented machines
+produced later than 2012 from saving NVS region to accelerate S3.
+
+Despite being made after 2012, Lenovo G70-35 still needs NVS memory
+saving during S3. A quirk is introduced for this platform.
+
+Signed-off-by: Piotr Mazek <pmazek@outlook.com>
+[ rjw: Subject adjustment ]
+Link: https://patch.msgid.link/GV2PPF3CD5B63CC2442EE3F76F8443EAD90D499A@GV2PPF3CD5B63CC.EURP251.PROD.OUTLOOK.COM
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/acpi/sleep.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
+index 95deb55fb9a8c..11e21be2ff31d 100644
+--- a/drivers/acpi/sleep.c
++++ b/drivers/acpi/sleep.c
+@@ -369,6 +369,14 @@ static const struct dmi_system_id acpisleep_dmi_table[] __initconst = {
+ DMI_MATCH(DMI_PRODUCT_NAME, "80E1"),
+ },
+ },
++ {
++ .callback = init_nvs_save_s3,
++ .ident = "Lenovo G70-35",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "80Q5"),
++ },
++ },
+ /*
+ * ThinkPad X1 Tablet(2016) cannot do suspend-to-idle using
+ * the Low Power S0 Idle firmware interface (see
+--
+2.51.0
+
--- /dev/null
+From c289628d4b9a5d7710250eb234c7b5e234dd0287 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 25 Feb 2026 09:52:30 +0100
+Subject: ALSA: usb-audio: Avoid implicit feedback mode on DIYINHK USB Audio
+ 2.0
+
+From: Takashi Iwai <tiwai@suse.de>
+
+[ Upstream commit c5bf24c8aba1ff711226ee0f039ff01a5754692b ]
+
+Although DIYINHK USB Audio 2.0 (ID 20b1:2009) shows the implicit
+feedback source for the capture stream, this would cause several
+problems for the playback. Namely, the device can get wMaxPackSize
+1024 for 24/32 bit format with 6 channels, and when a high sample rate
+like 352.8kHz or 384kHz is played, the packet size overflows the max
+limit. Also, the device has another two playback altsets, and those
+aren't properly handled with the implicit feedback.
+
+Since the device has been working well even before introducing the
+implicit feedback, we can assume that it works fine in the async mode.
+This patch adds the explicit skip of the implicit fb detection to make
+the playback running in the async mode.
+
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=221076
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Link: https://patch.msgid.link/20260225085233.316306-4-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/usb/quirks.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
+index 55fd74f198184..ceca05f91c89c 100644
+--- a/sound/usb/quirks.c
++++ b/sound/usb/quirks.c
+@@ -1929,6 +1929,8 @@ static const struct usb_audio_quirk_flags_table quirk_flags_table[] = {
+ QUIRK_FLAG_SHARE_MEDIA_DEVICE | QUIRK_FLAG_ALIGN_TRANSFER),
+ DEVICE_FLG(0x2040, 0x7281, /* Hauppauge HVR-950Q-MXL */
+ QUIRK_FLAG_SHARE_MEDIA_DEVICE | QUIRK_FLAG_ALIGN_TRANSFER),
++ DEVICE_FLG(0x20b1, 0x2009, /* XMOS Ltd DIYINHK USB Audio 2.0 */
++ QUIRK_FLAG_SKIP_IMPLICIT_FB | QUIRK_FLAG_DSD_RAW),
+ DEVICE_FLG(0x2040, 0x8200, /* Hauppauge Woodbury */
+ QUIRK_FLAG_SHARE_MEDIA_DEVICE | QUIRK_FLAG_ALIGN_TRANSFER),
+ DEVICE_FLG(0x21b4, 0x0081, /* AudioQuest DragonFly */
+--
+2.51.0
+
--- /dev/null
+From c1435d3d125bfadacf169783beb6d366800970e5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 25 Feb 2026 09:52:29 +0100
+Subject: ALSA: usb-audio: Check max frame size for implicit feedback mode, too
+
+From: Takashi Iwai <tiwai@suse.de>
+
+[ Upstream commit 7cb2a5422f5bbdf1cf32eae0eda41000485b9346 ]
+
+When the packet sizes are taken from the capture stream in the
+implicit feedback mode, the sizes might be larger than the upper
+boundary defined by the descriptor. As already done for other
+transfer modes, we have to cap the sizes accordingly at sending,
+otherwise this would lead to an error in USB core at submission of
+URBs.
+
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=221076
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Link: https://patch.msgid.link/20260225085233.316306-3-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/usb/endpoint.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
+index 6ba99ff2cefcf..22eb5de94c2be 100644
+--- a/sound/usb/endpoint.c
++++ b/sound/usb/endpoint.c
+@@ -223,6 +223,7 @@ int snd_usb_endpoint_next_packet_size(struct snd_usb_endpoint *ep,
+
+ packet = ctx->packet_size[idx];
+ if (packet) {
++ packet = min(packet, ep->maxframesize);
+ if (avail && packet >= avail)
+ return -EAGAIN;
+ return packet;
+--
+2.51.0
+
--- /dev/null
+From 8f6956c6747628389594c366a241e156fa842e35 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 3 Mar 2026 16:31:42 +0100
+Subject: powerpc: 83xx: km83xx: Fix keymile vendor prefix
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: J. Neuschäfer <j.ne@posteo.net>
+
+[ Upstream commit 691417ffe7821721e0a28bd25ad8c0dc0d4ae4ad ]
+
+When kmeter.c was refactored into km83xx.c in 2011, the "keymile" vendor
+prefix was changed to upper-case "Keymile". The devicetree at
+arch/powerpc/boot/dts/kmeter1.dts never underwent the same change,
+suggesting that this was simply a mistake.
+
+Fixes: 93e2b95c81042d ("powerpc/83xx: rename and update kmeter1")
+Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
+Reviewed-by: Heiko Schocher <hs@nabladev.com>
+Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
+Link: https://patch.msgid.link/20260303-keymile-v1-1-463a11e71702@posteo.net
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/platforms/83xx/km83xx.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/arch/powerpc/platforms/83xx/km83xx.c b/arch/powerpc/platforms/83xx/km83xx.c
+index 108e1e4d2683e..fa6a022892e63 100644
+--- a/arch/powerpc/platforms/83xx/km83xx.c
++++ b/arch/powerpc/platforms/83xx/km83xx.c
+@@ -156,8 +156,8 @@ machine_device_initcall(mpc83xx_km, mpc83xx_declare_of_platform_devices);
+
+ /* list of the supported boards */
+ static char *board[] __initdata = {
+- "Keymile,KMETER1",
+- "Keymile,kmpbec8321",
++ "keymile,KMETER1",
++ "keymile,kmpbec8321",
+ NULL
+ };
+
+--
+2.51.0
+
--- /dev/null
+From d91bbc897fb9766022c1b3ab0936d3ca2cc64289 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 3 Feb 2026 08:30:41 +0100
+Subject: powerpc/uaccess: Fix inline assembly for clang build on PPC32
+
+From: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
+
+[ Upstream commit 0ee95a1d458630272d0415d0ffa9424fcb606c90 ]
+
+Test robot reports the following error with clang-16.0.6:
+
+ In file included from kernel/rseq.c:75:
+ include/linux/rseq_entry.h:141:3: error: invalid operand for instruction
+ unsafe_get_user(offset, &ucs->post_commit_offset, efault);
+ ^
+ include/linux/uaccess.h:608:2: note: expanded from macro 'unsafe_get_user'
+ arch_unsafe_get_user(x, ptr, local_label); \
+ ^
+ arch/powerpc/include/asm/uaccess.h:518:2: note: expanded from macro 'arch_unsafe_get_user'
+ __get_user_size_goto(__gu_val, __gu_addr, sizeof(*(p)), e); \
+ ^
+ arch/powerpc/include/asm/uaccess.h:284:2: note: expanded from macro '__get_user_size_goto'
+ __get_user_size_allowed(x, ptr, size, __gus_retval); \
+ ^
+ arch/powerpc/include/asm/uaccess.h:275:10: note: expanded from macro '__get_user_size_allowed'
+ case 8: __get_user_asm2(x, (u64 __user *)ptr, retval); break; \
+ ^
+ arch/powerpc/include/asm/uaccess.h:258:4: note: expanded from macro '__get_user_asm2'
+ " li %1+1,0\n" \
+ ^
+ <inline asm>:7:5: note: instantiated into assembly here
+ li 31+1,0
+ ^
+ 1 error generated.
+
+On PPC32, for 64 bits vars a pair of registers is used. Usually the
+lower register in the pair is the high part and the higher register is
+the low part. GCC uses r3/r4 ... r11/r12 ... r14/r15 ... r30/r31
+
+In older kernel code inline assembly was using %1 and %1+1 to represent
+64 bits values. However here it looks like clang uses r31 as high part,
+allthough r32 doesn't exist hence the error.
+
+Allthoug %1+1 should work, most places now use %L1 instead of %1+1, so
+let's do the same here.
+
+With that change, the build doesn't fail anymore and a disassembly shows
+clang uses r17/r18 and r31/r14 pair when GCC would have used r16/r17 and
+r30/r31:
+
+ Disassembly of section .fixup:
+
+ 00000000 <.fixup>:
+ 0: 38 a0 ff f2 li r5,-14
+ 4: 3a 20 00 00 li r17,0
+ 8: 3a 40 00 00 li r18,0
+ c: 48 00 00 00 b c <.fixup+0xc>
+ c: R_PPC_REL24 .text+0xbc
+ 10: 38 a0 ff f2 li r5,-14
+ 14: 3b e0 00 00 li r31,0
+ 18: 39 c0 00 00 li r14,0
+ 1c: 48 00 00 00 b 1c <.fixup+0x1c>
+ 1c: R_PPC_REL24 .text+0x144
+
+Reported-by: kernel test robot <lkp@intel.com>
+Closes: https://lore.kernel.org/oe-kbuild-all/202602021825.otcItxGi-lkp@intel.com/
+Fixes: c20beffeec3c ("powerpc/uaccess: Use flexible addressing with __put_user()/__get_user()")
+Signed-off-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
+Acked-by: Nathan Chancellor <nathan@kernel.org>
+Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
+Link: https://patch.msgid.link/8ca3a657a650e497a96bfe7acde2f637dadab344.1770103646.git.chleroy@kernel.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/include/asm/uaccess.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h
+index 7781f6dd51390..62c07deb995c1 100644
+--- a/arch/powerpc/include/asm/uaccess.h
++++ b/arch/powerpc/include/asm/uaccess.h
+@@ -228,7 +228,7 @@ __gus_failed: \
+ ".section .fixup,\"ax\"\n" \
+ "4: li %0,%3\n" \
+ " li %1,0\n" \
+- " li %1+1,0\n" \
++ " li %L1,0\n" \
+ " b 3b\n" \
+ ".previous\n" \
+ EX_TABLE(1b, 4b) \
+--
+2.51.0
+
--- /dev/null
+From 291eb4dbc6635cd70927e3ab7f3330aba93c6e6d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 6 Feb 2026 03:30:33 +0000
+Subject: remoteproc: mediatek: Unprepare SCP clock during system suspend
+
+From: Tzung-Bi Shih <tzungbi@kernel.org>
+
+[ Upstream commit 35c3f72a2d55dbf52f28f4ecae51c76be1acf545 ]
+
+Prior to commit d935187cfb27 ("remoteproc: mediatek: Break lock
+dependency to prepare_lock"), `scp->clk` was prepared and enabled only
+when it needs to communicate with the SCP. The commit d935187cfb27
+moved the prepare operation to remoteproc's prepare(), keeping the clock
+prepared as long as the SCP is running.
+
+The power consumption due to the prolonged clock preparation can be
+negligible when the system is running, as SCP is designed to be a very
+power efficient processor.
+
+However, the clock remains prepared even when the system enters system
+suspend. This prevents the underlying clock controller (and potentially
+the parent PLLs) from shutting down, which increases power consumption
+and may block the system from entering deep sleep states.
+
+Add suspend and resume callbacks. Unprepare the clock in suspend() if
+it was active and re-prepare it in resume() to ensure the clock is
+properly disabled during system suspend, while maintaining the "always
+prepared" semantics while the system is active. The driver doesn't
+implement .attach() callback, hence it only checks for RPROC_RUNNING.
+
+Fixes: d935187cfb27 ("remoteproc: mediatek: Break lock dependency to prepare_lock")
+Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
+Link: https://lore.kernel.org/r/20260206033034.3031781-1-tzungbi@kernel.org
+Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/remoteproc/mtk_scp.c | 39 ++++++++++++++++++++++++++++++++++++
+ 1 file changed, 39 insertions(+)
+
+diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
+index bf9228bd5090f..a92b2d47e4fb4 100644
+--- a/drivers/remoteproc/mtk_scp.c
++++ b/drivers/remoteproc/mtk_scp.c
+@@ -906,12 +906,51 @@ static const struct of_device_id mtk_scp_of_match[] = {
+ };
+ MODULE_DEVICE_TABLE(of, mtk_scp_of_match);
+
++static int __maybe_unused scp_suspend(struct device *dev)
++{
++ struct mtk_scp *scp = dev_get_drvdata(dev);
++ struct rproc *rproc = scp->rproc;
++
++ /*
++ * Only unprepare if the SCP is running and holding the clock.
++ *
++ * Note: `scp_ops` doesn't implement .attach() callback, hence
++ * `rproc->state` can never be RPROC_ATTACHED. Otherwise, it
++ * should also be checked here.
++ */
++ if (rproc->state == RPROC_RUNNING)
++ clk_unprepare(scp->clk);
++ return 0;
++}
++
++static int __maybe_unused scp_resume(struct device *dev)
++{
++ struct mtk_scp *scp = dev_get_drvdata(dev);
++ struct rproc *rproc = scp->rproc;
++
++ /*
++ * Only prepare if the SCP was running and holding the clock.
++ *
++ * Note: `scp_ops` doesn't implement .attach() callback, hence
++ * `rproc->state` can never be RPROC_ATTACHED. Otherwise, it
++ * should also be checked here.
++ */
++ if (rproc->state == RPROC_RUNNING)
++ return clk_prepare(scp->clk);
++ return 0;
++}
++
++static const struct dev_pm_ops scp_pm_ops = {
++ SET_SYSTEM_SLEEP_PM_OPS(scp_suspend, scp_resume)
++};
++
+ static struct platform_driver mtk_scp_driver = {
+ .probe = scp_probe,
+ .remove = scp_remove,
+ .driver = {
+ .name = "mtk-scp",
+ .of_match_table = mtk_scp_of_match,
++ .pm = &scp_pm_ops,
+ },
+ };
+
+--
+2.51.0
+
--- /dev/null
+From 5b5165990390ca644b8c5bde467a08969245c98c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 20 Feb 2026 15:11:48 -0600
+Subject: remoteproc: sysmon: Correct subsys_name_len type in QMI request
+
+From: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
+
+[ Upstream commit da994db94e60f9a9411108ddf4d1836147ad4c9c ]
+
+The QMI message encoder has up until recently read a single byte (as
+elem_size == 1), but with the introduction of big endian support it's
+become apparent that this field is expected to be a full u32 -
+regardless of the size of the length in the encoded message (which is
+what elem_size specifies).
+
+The result is that the encoder now reads past the length byte and
+rejects the unreasonably large length formed when including the
+following 3 bytes from the subsys_name array.
+
+Fix this by changing to the expected type.
+
+Fixes: 1fb82ee806d1 ("remoteproc: qcom: Introduce sysmon")
+Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
+Reviewed-by: Chris Lew <christopher.lew@oss.qualcomm.com>
+Link: https://lore.kernel.org/r/20260220-qmi-encode-invalid-length-v2-1-5674be35ab29@oss.qualcomm.com
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/remoteproc/qcom_sysmon.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/remoteproc/qcom_sysmon.c b/drivers/remoteproc/qcom_sysmon.c
+index fbfaf2637a91a..28bf1b04be820 100644
+--- a/drivers/remoteproc/qcom_sysmon.c
++++ b/drivers/remoteproc/qcom_sysmon.c
+@@ -204,7 +204,7 @@ static struct qmi_elem_info ssctl_shutdown_resp_ei[] = {
+ };
+
+ struct ssctl_subsys_event_req {
+- u8 subsys_name_len;
++ u32 subsys_name_len;
+ char subsys_name[SSCTL_SUBSYS_NAME_LENGTH];
+ u32 event;
+ u8 evt_driven_valid;
+--
+2.51.0
+
--- /dev/null
+From 015b93a323707cceea458ef5ec3570e5ed541f5b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 12 Feb 2026 12:30:26 +0530
+Subject: scsi: mpi3mr: Add NULL checks when resetting request and reply queues
+
+From: Ranjan Kumar <ranjan.kumar@broadcom.com>
+
+[ Upstream commit fa96392ebebc8fade2b878acb14cce0f71016503 ]
+
+The driver encountered a crash during resource cleanup when the reply and
+request queues were NULL due to freed memory. This issue occurred when the
+creation of reply or request queues failed, and the driver freed the memory
+first, but attempted to mem set the content of the freed memory, leading to
+a system crash.
+
+Add NULL pointer checks for reply and request queues before accessing the
+reply/request memory during cleanup
+
+Signed-off-by: Ranjan Kumar <ranjan.kumar@broadcom.com>
+Link: https://patch.msgid.link/20260212070026.30263-1-ranjan.kumar@broadcom.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/mpi3mr/mpi3mr_fw.c | 34 ++++++++++++++++++---------------
+ 1 file changed, 19 insertions(+), 15 deletions(-)
+
+diff --git a/drivers/scsi/mpi3mr/mpi3mr_fw.c b/drivers/scsi/mpi3mr/mpi3mr_fw.c
+index 939c3509b316a..9e5e44bc0c88a 100644
+--- a/drivers/scsi/mpi3mr/mpi3mr_fw.c
++++ b/drivers/scsi/mpi3mr/mpi3mr_fw.c
+@@ -3534,21 +3534,25 @@ void mpi3mr_memset_buffers(struct mpi3mr_ioc *mrioc)
+ memset(mrioc->devrem_bitmap, 0, mrioc->devrem_bitmap_sz);
+
+ for (i = 0; i < mrioc->num_queues; i++) {
+- mrioc->op_reply_qinfo[i].qid = 0;
+- mrioc->op_reply_qinfo[i].ci = 0;
+- mrioc->op_reply_qinfo[i].num_replies = 0;
+- mrioc->op_reply_qinfo[i].ephase = 0;
+- atomic_set(&mrioc->op_reply_qinfo[i].pend_ios, 0);
+- atomic_set(&mrioc->op_reply_qinfo[i].in_use, 0);
+- mpi3mr_memset_op_reply_q_buffers(mrioc, i);
+-
+- mrioc->req_qinfo[i].ci = 0;
+- mrioc->req_qinfo[i].pi = 0;
+- mrioc->req_qinfo[i].num_requests = 0;
+- mrioc->req_qinfo[i].qid = 0;
+- mrioc->req_qinfo[i].reply_qid = 0;
+- spin_lock_init(&mrioc->req_qinfo[i].q_lock);
+- mpi3mr_memset_op_req_q_buffers(mrioc, i);
++ if (mrioc->op_reply_qinfo) {
++ mrioc->op_reply_qinfo[i].qid = 0;
++ mrioc->op_reply_qinfo[i].ci = 0;
++ mrioc->op_reply_qinfo[i].num_replies = 0;
++ mrioc->op_reply_qinfo[i].ephase = 0;
++ atomic_set(&mrioc->op_reply_qinfo[i].pend_ios, 0);
++ atomic_set(&mrioc->op_reply_qinfo[i].in_use, 0);
++ mpi3mr_memset_op_reply_q_buffers(mrioc, i);
++ }
++
++ if (mrioc->req_qinfo) {
++ mrioc->req_qinfo[i].ci = 0;
++ mrioc->req_qinfo[i].pi = 0;
++ mrioc->req_qinfo[i].num_requests = 0;
++ mrioc->req_qinfo[i].qid = 0;
++ mrioc->req_qinfo[i].reply_qid = 0;
++ spin_lock_init(&mrioc->req_qinfo[i].q_lock);
++ mpi3mr_memset_op_req_q_buffers(mrioc, i);
++ }
+ }
+ }
+
+--
+2.51.0
+
--- /dev/null
+From 61a839f2be0f5b986582321cb2eca227bb66ed0f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 10 Feb 2026 20:18:50 +0100
+Subject: scsi: ses: Fix devices attaching to different hosts
+
+From: Tomas Henzl <thenzl@redhat.com>
+
+[ Upstream commit 70ca8caa96ce473647054f5c7b9dab5423902402 ]
+
+On a multipath SAS system some devices don't end up with correct symlinks
+from the SCSI device to its enclosure. Some devices even have enclosure
+links pointing to enclosures attached to different SCSI hosts.
+
+ses_match_to_enclosure() calls enclosure_for_each_device() which iterates
+over all enclosures on the system, not just enclosures attached to the
+current SCSI host.
+
+Replace the iteration with a direct call to ses_enclosure_find_by_addr().
+
+Reviewed-by: David Jeffery <djeffery@redhat.com>
+Signed-off-by: Tomas Henzl <thenzl@redhat.com>
+Link: https://patch.msgid.link/20260210191850.36784-1-thenzl@redhat.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/ses.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/scsi/ses.c b/drivers/scsi/ses.c
+index 6a1428d453f3e..92b3fd10058dd 100644
+--- a/drivers/scsi/ses.c
++++ b/drivers/scsi/ses.c
+@@ -497,9 +497,8 @@ struct efd {
+ };
+
+ static int ses_enclosure_find_by_addr(struct enclosure_device *edev,
+- void *data)
++ struct efd *efd)
+ {
+- struct efd *efd = data;
+ int i;
+ struct ses_component *scomp;
+
+@@ -652,7 +651,7 @@ static void ses_match_to_enclosure(struct enclosure_device *edev,
+ if (efd.addr) {
+ efd.dev = &sdev->sdev_gendev;
+
+- enclosure_for_each_device(ses_enclosure_find_by_addr, &efd);
++ ses_enclosure_find_by_addr(edev, &efd);
+ }
+ }
+
+--
+2.51.0
+
--- /dev/null
+From 8eb970e8a6b881a45c58262884c9984252e96f3c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 29 Jan 2026 15:30:39 +0100
+Subject: scsi: storvsc: Fix scheduling while atomic on PREEMPT_RT
+
+From: Jan Kiszka <jan.kiszka@siemens.com>
+
+[ Upstream commit 57297736c08233987e5d29ce6584c6ca2a831b12 ]
+
+This resolves the follow splat and lock-up when running with PREEMPT_RT
+enabled on Hyper-V:
+
+[ 415.140818] BUG: scheduling while atomic: stress-ng-iomix/1048/0x00000002
+[ 415.140822] INFO: lockdep is turned off.
+[ 415.140823] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec ghash_clmulni_intel aesni_intel rapl binfmt_misc nls_ascii nls_cp437 vfat fat snd_pcm hyperv_drm snd_timer drm_client_lib drm_shmem_helper snd sg soundcore drm_kms_helper pcspkr hv_balloon hv_utils evdev joydev drm configfs efi_pstore nfnetlink vsock_loopback vmw_vsock_virtio_transport_common hv_sock vmw_vsock_vmci_transport vsock vmw_vmci efivarfs autofs4 ext4 crc16 mbcache jbd2 sr_mod sd_mod cdrom hv_storvsc serio_raw hid_generic scsi_transport_fc hid_hyperv scsi_mod hid hv_netvsc hyperv_keyboard scsi_common
+[ 415.140846] Preemption disabled at:
+[ 415.140847] [<ffffffffc0656171>] storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc]
+[ 415.140854] CPU: 8 UID: 0 PID: 1048 Comm: stress-ng-iomix Not tainted 6.19.0-rc7 #30 PREEMPT_{RT,(full)}
+[ 415.140856] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/04/2024
+[ 415.140857] Call Trace:
+[ 415.140861] <TASK>
+[ 415.140861] ? storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc]
+[ 415.140863] dump_stack_lvl+0x91/0xb0
+[ 415.140870] __schedule_bug+0x9c/0xc0
+[ 415.140875] __schedule+0xdf6/0x1300
+[ 415.140877] ? rtlock_slowlock_locked+0x56c/0x1980
+[ 415.140879] ? rcu_is_watching+0x12/0x60
+[ 415.140883] schedule_rtlock+0x21/0x40
+[ 415.140885] rtlock_slowlock_locked+0x502/0x1980
+[ 415.140891] rt_spin_lock+0x89/0x1e0
+[ 415.140893] hv_ringbuffer_write+0x87/0x2a0
+[ 415.140899] vmbus_sendpacket_mpb_desc+0xb6/0xe0
+[ 415.140900] ? rcu_is_watching+0x12/0x60
+[ 415.140902] storvsc_queuecommand+0x669/0xbe0 [hv_storvsc]
+[ 415.140904] ? HARDIRQ_verbose+0x10/0x10
+[ 415.140908] ? __rq_qos_issue+0x28/0x40
+[ 415.140911] scsi_queue_rq+0x760/0xd80 [scsi_mod]
+[ 415.140926] __blk_mq_issue_directly+0x4a/0xc0
+[ 415.140928] blk_mq_issue_direct+0x87/0x2b0
+[ 415.140931] blk_mq_dispatch_queue_requests+0x120/0x440
+[ 415.140933] blk_mq_flush_plug_list+0x7a/0x1a0
+[ 415.140935] __blk_flush_plug+0xf4/0x150
+[ 415.140940] __submit_bio+0x2b2/0x5c0
+[ 415.140944] ? submit_bio_noacct_nocheck+0x272/0x360
+[ 415.140946] submit_bio_noacct_nocheck+0x272/0x360
+[ 415.140951] ext4_read_bh_lock+0x3e/0x60 [ext4]
+[ 415.140995] ext4_block_write_begin+0x396/0x650 [ext4]
+[ 415.141018] ? __pfx_ext4_da_get_block_prep+0x10/0x10 [ext4]
+[ 415.141038] ext4_da_write_begin+0x1c4/0x350 [ext4]
+[ 415.141060] generic_perform_write+0x14e/0x2c0
+[ 415.141065] ext4_buffered_write_iter+0x6b/0x120 [ext4]
+[ 415.141083] vfs_write+0x2ca/0x570
+[ 415.141087] ksys_write+0x76/0xf0
+[ 415.141089] do_syscall_64+0x99/0x1490
+[ 415.141093] ? rcu_is_watching+0x12/0x60
+[ 415.141095] ? finish_task_switch.isra.0+0xdf/0x3d0
+[ 415.141097] ? rcu_is_watching+0x12/0x60
+[ 415.141098] ? lock_release+0x1f0/0x2a0
+[ 415.141100] ? rcu_is_watching+0x12/0x60
+[ 415.141101] ? finish_task_switch.isra.0+0xe4/0x3d0
+[ 415.141103] ? rcu_is_watching+0x12/0x60
+[ 415.141104] ? __schedule+0xb34/0x1300
+[ 415.141106] ? hrtimer_try_to_cancel+0x1d/0x170
+[ 415.141109] ? do_nanosleep+0x8b/0x160
+[ 415.141111] ? hrtimer_nanosleep+0x89/0x100
+[ 415.141114] ? __pfx_hrtimer_wakeup+0x10/0x10
+[ 415.141116] ? xfd_validate_state+0x26/0x90
+[ 415.141118] ? rcu_is_watching+0x12/0x60
+[ 415.141120] ? do_syscall_64+0x1e0/0x1490
+[ 415.141121] ? do_syscall_64+0x1e0/0x1490
+[ 415.141123] ? rcu_is_watching+0x12/0x60
+[ 415.141124] ? do_syscall_64+0x1e0/0x1490
+[ 415.141125] ? do_syscall_64+0x1e0/0x1490
+[ 415.141127] ? irqentry_exit+0x140/0x7e0
+[ 415.141129] entry_SYSCALL_64_after_hwframe+0x76/0x7e
+
+get_cpu() disables preemption while the spinlock hv_ringbuffer_write is
+using is converted to an rt-mutex under PREEMPT_RT.
+
+Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
+Tested-by: Florian Bezdeka <florian.bezdeka@siemens.com>
+Reviewed-by: Michael Kelley <mhklinux@outlook.com>
+Tested-by: Michael Kelley <mhklinux@outlook.com>
+Link: https://patch.msgid.link/0c7fb5cd-fb21-4760-8593-e04bade84744@siemens.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/storvsc_drv.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
+index a5e1b6a73fa8a..775afea4b2e89 100644
+--- a/drivers/scsi/storvsc_drv.c
++++ b/drivers/scsi/storvsc_drv.c
+@@ -1910,8 +1910,9 @@ static int storvsc_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *scmnd)
+ cmd_request->payload_sz = payload_sz;
+
+ /* Invokes the vsc to start an IO */
+- ret = storvsc_do_io(dev, cmd_request, get_cpu());
+- put_cpu();
++ migrate_disable();
++ ret = storvsc_do_io(dev, cmd_request, smp_processor_id());
++ migrate_enable();
+
+ if (ret == -EAGAIN) {
+ if (payload_sz > sizeof(cmd_request->mpb))
+--
+2.51.0
+
net-vxlan-fix-nd_tbl-null-dereference-when-ipv6-is-d.patch
net-ipv6-fix-panic-when-ipv4-route-references-loopba.patch
net-sched-only-allow-act_ct-to-bind-to-clsact-ingress-qdiscs-and-shared-blocks.patch
+scsi-storvsc-fix-scheduling-while-atomic-on-preempt_.patch
+acpi-pm-save-nvs-memory-on-lenovo-g70-35.patch
+scsi-mpi3mr-add-null-checks-when-resetting-request-a.patch
+unshare-fix-unshare_fs-handling.patch
+acpi-osi-add-dmi-quirk-for-acer-aspire-one-d255.patch
+scsi-ses-fix-devices-attaching-to-different-hosts.patch
+alsa-usb-audio-avoid-implicit-feedback-mode-on-diyin.patch
+alsa-usb-audio-check-max-frame-size-for-implicit-fee.patch
+powerpc-uaccess-fix-inline-assembly-for-clang-build-.patch
+remoteproc-sysmon-correct-subsys_name_len-type-in-qm.patch
+remoteproc-mediatek-unprepare-scp-clock-during-syste.patch
+powerpc-83xx-km83xx-fix-keymile-vendor-prefix.patch
--- /dev/null
+From ecb9b2d48429d79530715346be6879cbdbcbda68 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 7 Feb 2026 08:25:24 +0000
+Subject: unshare: fix unshare_fs() handling
+
+From: Al Viro <viro@zeniv.linux.org.uk>
+
+[ Upstream commit 6c4b2243cb6c0755159bd567130d5e12e7b10d9f ]
+
+There's an unpleasant corner case in unshare(2), when we have a
+CLONE_NEWNS in flags and current->fs hadn't been shared at all; in that
+case copy_mnt_ns() gets passed current->fs instead of a private copy,
+which causes interesting warts in proof of correctness]
+
+> I guess if private means fs->users == 1, the condition could still be true.
+
+Unfortunately, it's worse than just a convoluted proof of correctness.
+Consider the case when we have CLONE_NEWCGROUP in addition to CLONE_NEWNS
+(and current->fs->users == 1).
+
+We pass current->fs to copy_mnt_ns(), all right. Suppose it succeeds and
+flips current->fs->{pwd,root} to corresponding locations in the new namespace.
+Now we proceed to copy_cgroup_ns(), which fails (e.g. with -ENOMEM).
+We call put_mnt_ns() on the namespace created by copy_mnt_ns(), it's
+destroyed and its mount tree is dissolved, but... current->fs->root and
+current->fs->pwd are both left pointing to now detached mounts.
+
+They are pinning those, so it's not a UAF, but it leaves the calling
+process with unshare(2) failing with -ENOMEM _and_ leaving it with
+pwd and root on detached isolated mounts. The last part is clearly a bug.
+
+There is other fun related to that mess (races with pivot_root(), including
+the one between pivot_root() and fork(), of all things), but this one
+is easy to isolate and fix - treat CLONE_NEWNS as "allocate a new
+fs_struct even if it hadn't been shared in the first place". Sure, we could
+go for something like "if both CLONE_NEWNS *and* one of the things that might
+end up failing after copy_mnt_ns() call in create_new_namespaces() are set,
+force allocation of new fs_struct", but let's keep it simple - the cost
+of copy_fs_struct() is trivial.
+
+Another benefit is that copy_mnt_ns() with CLONE_NEWNS *always* gets
+a freshly allocated fs_struct, yet to be attached to anything. That
+seriously simplifies the analysis...
+
+FWIW, that bug had been there since the introduction of unshare(2) ;-/
+
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Link: https://patch.msgid.link/20260207082524.GE3183987@ZenIV
+Tested-by: Waiman Long <longman@redhat.com>
+Signed-off-by: Christian Brauner <brauner@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/fork.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/kernel/fork.c b/kernel/fork.c
+index 2c99d39e2bc08..e1b291e5e1038 100644
+--- a/kernel/fork.c
++++ b/kernel/fork.c
+@@ -3086,7 +3086,7 @@ static int unshare_fs(unsigned long unshare_flags, struct fs_struct **new_fsp)
+ return 0;
+
+ /* don't need lock here; in the worst case we'll do useless copy */
+- if (fs->users == 1)
++ if (!(unshare_flags & CLONE_NEWNS) && fs->users == 1)
+ return 0;
+
+ *new_fsp = copy_fs_struct(fs);
+--
+2.51.0
+
--- /dev/null
+From 4a8dcce11d9dcb0bbf7220912e8b29b25e6416f8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 22 Feb 2026 23:52:40 -0300
+Subject: ACPI: OSI: Add DMI quirk for Acer Aspire One D255
+
+From: Sofia Schneider <sofia@schn.dev>
+
+[ Upstream commit 5ede90206273ff156a778254f0f972a55e973c89 ]
+
+The screen backlight turns off during boot (specifically during udev device
+initialization) when returning true for _OSI("Windows 2009").
+
+Analyzing the device's DSDT reveals that the firmware takes a different
+code path when Windows 7 is reported, which leads to the backlight shutoff.
+Add a DMI quirk to invoke dmi_disable_osi_win7 for this model.
+
+Signed-off-by: Sofia Schneider <sofia@schn.dev>
+Link: https://patch.msgid.link/20260223025240.518509-1-sofia@schn.dev
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/acpi/osi.c | 13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+diff --git a/drivers/acpi/osi.c b/drivers/acpi/osi.c
+index ae9620757865b..600af8814038a 100644
+--- a/drivers/acpi/osi.c
++++ b/drivers/acpi/osi.c
+@@ -389,6 +389,19 @@ static const struct dmi_system_id acpi_osi_dmi_table[] __initconst = {
+ },
+ },
+
++ /*
++ * The screen backlight turns off during udev device creation
++ * when returning true for _OSI("Windows 2009")
++ */
++ {
++ .callback = dmi_disable_osi_win7,
++ .ident = "Acer Aspire One D255",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "AOD255"),
++ },
++ },
++
+ /*
+ * The wireless hotkey does not work on those machines when
+ * returning true for _OSI("Windows 2012")
+--
+2.51.0
+
--- /dev/null
+From f13fee547e5c490f37b0c75c43c77071fc143da3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 5 Feb 2026 23:05:02 +0100
+Subject: ACPI: PM: Save NVS memory on Lenovo G70-35
+
+From: Piotr Mazek <pmazek@outlook.com>
+
+[ Upstream commit 023cd6d90f8aa2ef7b72d84be84a18e61ecebd64 ]
+
+[821d6f0359b0614792ab8e2fb93b503e25a65079] prevented machines
+produced later than 2012 from saving NVS region to accelerate S3.
+
+Despite being made after 2012, Lenovo G70-35 still needs NVS memory
+saving during S3. A quirk is introduced for this platform.
+
+Signed-off-by: Piotr Mazek <pmazek@outlook.com>
+[ rjw: Subject adjustment ]
+Link: https://patch.msgid.link/GV2PPF3CD5B63CC2442EE3F76F8443EAD90D499A@GV2PPF3CD5B63CC.EURP251.PROD.OUTLOOK.COM
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/acpi/sleep.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
+index 6026e20f022a2..cc490fbcfe273 100644
+--- a/drivers/acpi/sleep.c
++++ b/drivers/acpi/sleep.c
+@@ -372,6 +372,14 @@ static const struct dmi_system_id acpisleep_dmi_table[] __initconst = {
+ DMI_MATCH(DMI_PRODUCT_NAME, "80E1"),
+ },
+ },
++ {
++ .callback = init_nvs_save_s3,
++ .ident = "Lenovo G70-35",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "80Q5"),
++ },
++ },
+ /*
+ * ThinkPad X1 Tablet(2016) cannot do suspend-to-idle using
+ * the Low Power S0 Idle firmware interface (see
+--
+2.51.0
+
--- /dev/null
+From 6236c3d598ab9adc3b6a615278e91f4f1b3aa200 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 25 Feb 2026 09:52:30 +0100
+Subject: ALSA: usb-audio: Avoid implicit feedback mode on DIYINHK USB Audio
+ 2.0
+
+From: Takashi Iwai <tiwai@suse.de>
+
+[ Upstream commit c5bf24c8aba1ff711226ee0f039ff01a5754692b ]
+
+Although DIYINHK USB Audio 2.0 (ID 20b1:2009) shows the implicit
+feedback source for the capture stream, this would cause several
+problems for the playback. Namely, the device can get wMaxPackSize
+1024 for 24/32 bit format with 6 channels, and when a high sample rate
+like 352.8kHz or 384kHz is played, the packet size overflows the max
+limit. Also, the device has another two playback altsets, and those
+aren't properly handled with the implicit feedback.
+
+Since the device has been working well even before introducing the
+implicit feedback, we can assume that it works fine in the async mode.
+This patch adds the explicit skip of the implicit fb detection to make
+the playback running in the async mode.
+
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=221076
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Link: https://patch.msgid.link/20260225085233.316306-4-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/usb/quirks.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
+index f9e998fad773c..74828de545e22 100644
+--- a/sound/usb/quirks.c
++++ b/sound/usb/quirks.c
+@@ -2243,6 +2243,8 @@ static const struct usb_audio_quirk_flags_table quirk_flags_table[] = {
+ QUIRK_FLAG_SHARE_MEDIA_DEVICE | QUIRK_FLAG_ALIGN_TRANSFER),
+ DEVICE_FLG(0x2040, 0x7281, /* Hauppauge HVR-950Q-MXL */
+ QUIRK_FLAG_SHARE_MEDIA_DEVICE | QUIRK_FLAG_ALIGN_TRANSFER),
++ DEVICE_FLG(0x20b1, 0x2009, /* XMOS Ltd DIYINHK USB Audio 2.0 */
++ QUIRK_FLAG_SKIP_IMPLICIT_FB | QUIRK_FLAG_DSD_RAW),
+ DEVICE_FLG(0x2040, 0x8200, /* Hauppauge Woodbury */
+ QUIRK_FLAG_SHARE_MEDIA_DEVICE | QUIRK_FLAG_ALIGN_TRANSFER),
+ DEVICE_FLG(0x21b4, 0x0081, /* AudioQuest DragonFly */
+--
+2.51.0
+
--- /dev/null
+From 0c43b795ba07ac0dad6957d8a5fbca3ed7dcc66c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 25 Feb 2026 09:52:29 +0100
+Subject: ALSA: usb-audio: Check max frame size for implicit feedback mode, too
+
+From: Takashi Iwai <tiwai@suse.de>
+
+[ Upstream commit 7cb2a5422f5bbdf1cf32eae0eda41000485b9346 ]
+
+When the packet sizes are taken from the capture stream in the
+implicit feedback mode, the sizes might be larger than the upper
+boundary defined by the descriptor. As already done for other
+transfer modes, we have to cap the sizes accordingly at sending,
+otherwise this would lead to an error in USB core at submission of
+URBs.
+
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=221076
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Link: https://patch.msgid.link/20260225085233.316306-3-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/usb/endpoint.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
+index b5af8dc1e48de..0f86319f62598 100644
+--- a/sound/usb/endpoint.c
++++ b/sound/usb/endpoint.c
+@@ -224,6 +224,7 @@ int snd_usb_endpoint_next_packet_size(struct snd_usb_endpoint *ep,
+
+ packet = ctx->packet_size[idx];
+ if (packet) {
++ packet = min(packet, ep->maxframesize);
+ if (avail && packet >= avail)
+ return -EAGAIN;
+ return packet;
+--
+2.51.0
+
--- /dev/null
+From 2070d8592f9e6836fca0a3e2ea513c1f3eb88038 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 21 Feb 2026 12:48:13 +0100
+Subject: ASoC: amd: yc: Add ASUS EXPERTBOOK BM1503CDA to quirk table
+
+From: Azamat Almazbek uulu <almazbek1608@gmail.com>
+
+[ Upstream commit 32fc4168fa56f6301d858c778a3d712774e9657e ]
+
+The ASUS ExpertBook BM1503CDA (Ryzen 5 7535U, Barcelo-R) has an
+internal DMIC connected through the AMD ACP (Audio CoProcessor)
+but is missing from the DMI quirk table, so the acp6x machine
+driver probe returns -ENODEV and no DMIC capture device is created.
+
+Add the DMI entry so the internal microphone works out of the box.
+
+Signed-off-by: Azamat Almazbek uulu <almazbek1608@gmail.com>
+Reviewed-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
+Link: https://patch.msgid.link/20260221114813.5610-1-almazbek1608@gmail.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/soc/amd/yc/acp6x-mach.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c
+index 31e4661f78671..715f1f76dab54 100644
+--- a/sound/soc/amd/yc/acp6x-mach.c
++++ b/sound/soc/amd/yc/acp6x-mach.c
+@@ -549,6 +549,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = {
+ DMI_MATCH(DMI_PRODUCT_NAME, "Vivobook_ASUSLaptop M6501RR_M6501RR"),
+ }
+ },
++ {
++ .driver_data = &acp6x_card,
++ .matches = {
++ DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK COMPUTER INC."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "ASUS EXPERTBOOK BM1503CDA"),
++ }
++ },
+ {}
+ };
+
+--
+2.51.0
+
--- /dev/null
+From 92a7726e1b7431fba1c3416a529805ddbea80bc4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 3 Mar 2026 16:31:42 +0100
+Subject: powerpc: 83xx: km83xx: Fix keymile vendor prefix
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: J. Neuschäfer <j.ne@posteo.net>
+
+[ Upstream commit 691417ffe7821721e0a28bd25ad8c0dc0d4ae4ad ]
+
+When kmeter.c was refactored into km83xx.c in 2011, the "keymile" vendor
+prefix was changed to upper-case "Keymile". The devicetree at
+arch/powerpc/boot/dts/kmeter1.dts never underwent the same change,
+suggesting that this was simply a mistake.
+
+Fixes: 93e2b95c81042d ("powerpc/83xx: rename and update kmeter1")
+Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
+Reviewed-by: Heiko Schocher <hs@nabladev.com>
+Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
+Link: https://patch.msgid.link/20260303-keymile-v1-1-463a11e71702@posteo.net
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/platforms/83xx/km83xx.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/arch/powerpc/platforms/83xx/km83xx.c b/arch/powerpc/platforms/83xx/km83xx.c
+index 907acdecc94af..25135a1518fc8 100644
+--- a/arch/powerpc/platforms/83xx/km83xx.c
++++ b/arch/powerpc/platforms/83xx/km83xx.c
+@@ -155,8 +155,8 @@ machine_device_initcall(mpc83xx_km, mpc83xx_declare_of_platform_devices);
+
+ /* list of the supported boards */
+ static char *board[] __initdata = {
+- "Keymile,KMETER1",
+- "Keymile,kmpbec8321",
++ "keymile,KMETER1",
++ "keymile,kmpbec8321",
+ NULL
+ };
+
+--
+2.51.0
+
--- /dev/null
+From 2a4ea7f163be5d8f31331be688aa8b63e474712e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 3 Feb 2026 08:30:41 +0100
+Subject: powerpc/uaccess: Fix inline assembly for clang build on PPC32
+
+From: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
+
+[ Upstream commit 0ee95a1d458630272d0415d0ffa9424fcb606c90 ]
+
+Test robot reports the following error with clang-16.0.6:
+
+ In file included from kernel/rseq.c:75:
+ include/linux/rseq_entry.h:141:3: error: invalid operand for instruction
+ unsafe_get_user(offset, &ucs->post_commit_offset, efault);
+ ^
+ include/linux/uaccess.h:608:2: note: expanded from macro 'unsafe_get_user'
+ arch_unsafe_get_user(x, ptr, local_label); \
+ ^
+ arch/powerpc/include/asm/uaccess.h:518:2: note: expanded from macro 'arch_unsafe_get_user'
+ __get_user_size_goto(__gu_val, __gu_addr, sizeof(*(p)), e); \
+ ^
+ arch/powerpc/include/asm/uaccess.h:284:2: note: expanded from macro '__get_user_size_goto'
+ __get_user_size_allowed(x, ptr, size, __gus_retval); \
+ ^
+ arch/powerpc/include/asm/uaccess.h:275:10: note: expanded from macro '__get_user_size_allowed'
+ case 8: __get_user_asm2(x, (u64 __user *)ptr, retval); break; \
+ ^
+ arch/powerpc/include/asm/uaccess.h:258:4: note: expanded from macro '__get_user_asm2'
+ " li %1+1,0\n" \
+ ^
+ <inline asm>:7:5: note: instantiated into assembly here
+ li 31+1,0
+ ^
+ 1 error generated.
+
+On PPC32, for 64 bits vars a pair of registers is used. Usually the
+lower register in the pair is the high part and the higher register is
+the low part. GCC uses r3/r4 ... r11/r12 ... r14/r15 ... r30/r31
+
+In older kernel code inline assembly was using %1 and %1+1 to represent
+64 bits values. However here it looks like clang uses r31 as high part,
+allthough r32 doesn't exist hence the error.
+
+Allthoug %1+1 should work, most places now use %L1 instead of %1+1, so
+let's do the same here.
+
+With that change, the build doesn't fail anymore and a disassembly shows
+clang uses r17/r18 and r31/r14 pair when GCC would have used r16/r17 and
+r30/r31:
+
+ Disassembly of section .fixup:
+
+ 00000000 <.fixup>:
+ 0: 38 a0 ff f2 li r5,-14
+ 4: 3a 20 00 00 li r17,0
+ 8: 3a 40 00 00 li r18,0
+ c: 48 00 00 00 b c <.fixup+0xc>
+ c: R_PPC_REL24 .text+0xbc
+ 10: 38 a0 ff f2 li r5,-14
+ 14: 3b e0 00 00 li r31,0
+ 18: 39 c0 00 00 li r14,0
+ 1c: 48 00 00 00 b 1c <.fixup+0x1c>
+ 1c: R_PPC_REL24 .text+0x144
+
+Reported-by: kernel test robot <lkp@intel.com>
+Closes: https://lore.kernel.org/oe-kbuild-all/202602021825.otcItxGi-lkp@intel.com/
+Fixes: c20beffeec3c ("powerpc/uaccess: Use flexible addressing with __put_user()/__get_user()")
+Signed-off-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
+Acked-by: Nathan Chancellor <nathan@kernel.org>
+Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
+Link: https://patch.msgid.link/8ca3a657a650e497a96bfe7acde2f637dadab344.1770103646.git.chleroy@kernel.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/include/asm/uaccess.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h
+index 0d874e343b9f6..bd95fa2c4092b 100644
+--- a/arch/powerpc/include/asm/uaccess.h
++++ b/arch/powerpc/include/asm/uaccess.h
+@@ -237,7 +237,7 @@ __gus_failed: \
+ ".section .fixup,\"ax\"\n" \
+ "4: li %0,%3\n" \
+ " li %1,0\n" \
+- " li %1+1,0\n" \
++ " li %L1,0\n" \
+ " b 3b\n" \
+ ".previous\n" \
+ EX_TABLE(1b, 4b) \
+--
+2.51.0
+
--- /dev/null
+From b547b082418a3c2912f025344c96b7bcf480179b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 6 Feb 2026 03:30:33 +0000
+Subject: remoteproc: mediatek: Unprepare SCP clock during system suspend
+
+From: Tzung-Bi Shih <tzungbi@kernel.org>
+
+[ Upstream commit 35c3f72a2d55dbf52f28f4ecae51c76be1acf545 ]
+
+Prior to commit d935187cfb27 ("remoteproc: mediatek: Break lock
+dependency to prepare_lock"), `scp->clk` was prepared and enabled only
+when it needs to communicate with the SCP. The commit d935187cfb27
+moved the prepare operation to remoteproc's prepare(), keeping the clock
+prepared as long as the SCP is running.
+
+The power consumption due to the prolonged clock preparation can be
+negligible when the system is running, as SCP is designed to be a very
+power efficient processor.
+
+However, the clock remains prepared even when the system enters system
+suspend. This prevents the underlying clock controller (and potentially
+the parent PLLs) from shutting down, which increases power consumption
+and may block the system from entering deep sleep states.
+
+Add suspend and resume callbacks. Unprepare the clock in suspend() if
+it was active and re-prepare it in resume() to ensure the clock is
+properly disabled during system suspend, while maintaining the "always
+prepared" semantics while the system is active. The driver doesn't
+implement .attach() callback, hence it only checks for RPROC_RUNNING.
+
+Fixes: d935187cfb27 ("remoteproc: mediatek: Break lock dependency to prepare_lock")
+Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
+Link: https://lore.kernel.org/r/20260206033034.3031781-1-tzungbi@kernel.org
+Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/remoteproc/mtk_scp.c | 39 ++++++++++++++++++++++++++++++++++++
+ 1 file changed, 39 insertions(+)
+
+diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
+index 8f513e66ef6bb..476066c9590cb 100644
+--- a/drivers/remoteproc/mtk_scp.c
++++ b/drivers/remoteproc/mtk_scp.c
+@@ -1025,12 +1025,51 @@ static const struct of_device_id mtk_scp_of_match[] = {
+ };
+ MODULE_DEVICE_TABLE(of, mtk_scp_of_match);
+
++static int __maybe_unused scp_suspend(struct device *dev)
++{
++ struct mtk_scp *scp = dev_get_drvdata(dev);
++ struct rproc *rproc = scp->rproc;
++
++ /*
++ * Only unprepare if the SCP is running and holding the clock.
++ *
++ * Note: `scp_ops` doesn't implement .attach() callback, hence
++ * `rproc->state` can never be RPROC_ATTACHED. Otherwise, it
++ * should also be checked here.
++ */
++ if (rproc->state == RPROC_RUNNING)
++ clk_unprepare(scp->clk);
++ return 0;
++}
++
++static int __maybe_unused scp_resume(struct device *dev)
++{
++ struct mtk_scp *scp = dev_get_drvdata(dev);
++ struct rproc *rproc = scp->rproc;
++
++ /*
++ * Only prepare if the SCP was running and holding the clock.
++ *
++ * Note: `scp_ops` doesn't implement .attach() callback, hence
++ * `rproc->state` can never be RPROC_ATTACHED. Otherwise, it
++ * should also be checked here.
++ */
++ if (rproc->state == RPROC_RUNNING)
++ return clk_prepare(scp->clk);
++ return 0;
++}
++
++static const struct dev_pm_ops scp_pm_ops = {
++ SET_SYSTEM_SLEEP_PM_OPS(scp_suspend, scp_resume)
++};
++
+ static struct platform_driver mtk_scp_driver = {
+ .probe = scp_probe,
+ .remove = scp_remove,
+ .driver = {
+ .name = "mtk-scp",
+ .of_match_table = mtk_scp_of_match,
++ .pm = &scp_pm_ops,
+ },
+ };
+
+--
+2.51.0
+
--- /dev/null
+From a771aed545262b4e3de4fbaef6034860e02471c4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 20 Feb 2026 15:11:48 -0600
+Subject: remoteproc: sysmon: Correct subsys_name_len type in QMI request
+
+From: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
+
+[ Upstream commit da994db94e60f9a9411108ddf4d1836147ad4c9c ]
+
+The QMI message encoder has up until recently read a single byte (as
+elem_size == 1), but with the introduction of big endian support it's
+become apparent that this field is expected to be a full u32 -
+regardless of the size of the length in the encoded message (which is
+what elem_size specifies).
+
+The result is that the encoder now reads past the length byte and
+rejects the unreasonably large length formed when including the
+following 3 bytes from the subsys_name array.
+
+Fix this by changing to the expected type.
+
+Fixes: 1fb82ee806d1 ("remoteproc: qcom: Introduce sysmon")
+Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
+Reviewed-by: Chris Lew <christopher.lew@oss.qualcomm.com>
+Link: https://lore.kernel.org/r/20260220-qmi-encode-invalid-length-v2-1-5674be35ab29@oss.qualcomm.com
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/remoteproc/qcom_sysmon.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/remoteproc/qcom_sysmon.c b/drivers/remoteproc/qcom_sysmon.c
+index 15af52f8499eb..78786e08f4f56 100644
+--- a/drivers/remoteproc/qcom_sysmon.c
++++ b/drivers/remoteproc/qcom_sysmon.c
+@@ -204,7 +204,7 @@ static struct qmi_elem_info ssctl_shutdown_resp_ei[] = {
+ };
+
+ struct ssctl_subsys_event_req {
+- u8 subsys_name_len;
++ u32 subsys_name_len;
+ char subsys_name[SSCTL_SUBSYS_NAME_LENGTH];
+ u32 event;
+ u8 evt_driven_valid;
+--
+2.51.0
+
--- /dev/null
+From 269472cc368fb9d1710db0e4af41637a1f026e58 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 12 Feb 2026 12:30:26 +0530
+Subject: scsi: mpi3mr: Add NULL checks when resetting request and reply queues
+
+From: Ranjan Kumar <ranjan.kumar@broadcom.com>
+
+[ Upstream commit fa96392ebebc8fade2b878acb14cce0f71016503 ]
+
+The driver encountered a crash during resource cleanup when the reply and
+request queues were NULL due to freed memory. This issue occurred when the
+creation of reply or request queues failed, and the driver freed the memory
+first, but attempted to mem set the content of the freed memory, leading to
+a system crash.
+
+Add NULL pointer checks for reply and request queues before accessing the
+reply/request memory during cleanup
+
+Signed-off-by: Ranjan Kumar <ranjan.kumar@broadcom.com>
+Link: https://patch.msgid.link/20260212070026.30263-1-ranjan.kumar@broadcom.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/mpi3mr/mpi3mr_fw.c | 34 ++++++++++++++++++---------------
+ 1 file changed, 19 insertions(+), 15 deletions(-)
+
+diff --git a/drivers/scsi/mpi3mr/mpi3mr_fw.c b/drivers/scsi/mpi3mr/mpi3mr_fw.c
+index 9d8f5a4794666..d4747ff4d800a 100644
+--- a/drivers/scsi/mpi3mr/mpi3mr_fw.c
++++ b/drivers/scsi/mpi3mr/mpi3mr_fw.c
+@@ -4246,21 +4246,25 @@ void mpi3mr_memset_buffers(struct mpi3mr_ioc *mrioc)
+ }
+
+ for (i = 0; i < mrioc->num_queues; i++) {
+- mrioc->op_reply_qinfo[i].qid = 0;
+- mrioc->op_reply_qinfo[i].ci = 0;
+- mrioc->op_reply_qinfo[i].num_replies = 0;
+- mrioc->op_reply_qinfo[i].ephase = 0;
+- atomic_set(&mrioc->op_reply_qinfo[i].pend_ios, 0);
+- atomic_set(&mrioc->op_reply_qinfo[i].in_use, 0);
+- mpi3mr_memset_op_reply_q_buffers(mrioc, i);
+-
+- mrioc->req_qinfo[i].ci = 0;
+- mrioc->req_qinfo[i].pi = 0;
+- mrioc->req_qinfo[i].num_requests = 0;
+- mrioc->req_qinfo[i].qid = 0;
+- mrioc->req_qinfo[i].reply_qid = 0;
+- spin_lock_init(&mrioc->req_qinfo[i].q_lock);
+- mpi3mr_memset_op_req_q_buffers(mrioc, i);
++ if (mrioc->op_reply_qinfo) {
++ mrioc->op_reply_qinfo[i].qid = 0;
++ mrioc->op_reply_qinfo[i].ci = 0;
++ mrioc->op_reply_qinfo[i].num_replies = 0;
++ mrioc->op_reply_qinfo[i].ephase = 0;
++ atomic_set(&mrioc->op_reply_qinfo[i].pend_ios, 0);
++ atomic_set(&mrioc->op_reply_qinfo[i].in_use, 0);
++ mpi3mr_memset_op_reply_q_buffers(mrioc, i);
++ }
++
++ if (mrioc->req_qinfo) {
++ mrioc->req_qinfo[i].ci = 0;
++ mrioc->req_qinfo[i].pi = 0;
++ mrioc->req_qinfo[i].num_requests = 0;
++ mrioc->req_qinfo[i].qid = 0;
++ mrioc->req_qinfo[i].reply_qid = 0;
++ spin_lock_init(&mrioc->req_qinfo[i].q_lock);
++ mpi3mr_memset_op_req_q_buffers(mrioc, i);
++ }
+ }
+
+ atomic_set(&mrioc->pend_large_data_sz, 0);
+--
+2.51.0
+
--- /dev/null
+From e2f19d68e272b52196a8acab96cd43b8c2343338 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 10 Feb 2026 20:18:50 +0100
+Subject: scsi: ses: Fix devices attaching to different hosts
+
+From: Tomas Henzl <thenzl@redhat.com>
+
+[ Upstream commit 70ca8caa96ce473647054f5c7b9dab5423902402 ]
+
+On a multipath SAS system some devices don't end up with correct symlinks
+from the SCSI device to its enclosure. Some devices even have enclosure
+links pointing to enclosures attached to different SCSI hosts.
+
+ses_match_to_enclosure() calls enclosure_for_each_device() which iterates
+over all enclosures on the system, not just enclosures attached to the
+current SCSI host.
+
+Replace the iteration with a direct call to ses_enclosure_find_by_addr().
+
+Reviewed-by: David Jeffery <djeffery@redhat.com>
+Signed-off-by: Tomas Henzl <thenzl@redhat.com>
+Link: https://patch.msgid.link/20260210191850.36784-1-thenzl@redhat.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/ses.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/scsi/ses.c b/drivers/scsi/ses.c
+index 6a1428d453f3e..92b3fd10058dd 100644
+--- a/drivers/scsi/ses.c
++++ b/drivers/scsi/ses.c
+@@ -497,9 +497,8 @@ struct efd {
+ };
+
+ static int ses_enclosure_find_by_addr(struct enclosure_device *edev,
+- void *data)
++ struct efd *efd)
+ {
+- struct efd *efd = data;
+ int i;
+ struct ses_component *scomp;
+
+@@ -652,7 +651,7 @@ static void ses_match_to_enclosure(struct enclosure_device *edev,
+ if (efd.addr) {
+ efd.dev = &sdev->sdev_gendev;
+
+- enclosure_for_each_device(ses_enclosure_find_by_addr, &efd);
++ ses_enclosure_find_by_addr(edev, &efd);
+ }
+ }
+
+--
+2.51.0
+
--- /dev/null
+From f873c163b77dfa28e9734cfe0b31d27597f520db Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 29 Jan 2026 15:30:39 +0100
+Subject: scsi: storvsc: Fix scheduling while atomic on PREEMPT_RT
+
+From: Jan Kiszka <jan.kiszka@siemens.com>
+
+[ Upstream commit 57297736c08233987e5d29ce6584c6ca2a831b12 ]
+
+This resolves the follow splat and lock-up when running with PREEMPT_RT
+enabled on Hyper-V:
+
+[ 415.140818] BUG: scheduling while atomic: stress-ng-iomix/1048/0x00000002
+[ 415.140822] INFO: lockdep is turned off.
+[ 415.140823] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec ghash_clmulni_intel aesni_intel rapl binfmt_misc nls_ascii nls_cp437 vfat fat snd_pcm hyperv_drm snd_timer drm_client_lib drm_shmem_helper snd sg soundcore drm_kms_helper pcspkr hv_balloon hv_utils evdev joydev drm configfs efi_pstore nfnetlink vsock_loopback vmw_vsock_virtio_transport_common hv_sock vmw_vsock_vmci_transport vsock vmw_vmci efivarfs autofs4 ext4 crc16 mbcache jbd2 sr_mod sd_mod cdrom hv_storvsc serio_raw hid_generic scsi_transport_fc hid_hyperv scsi_mod hid hv_netvsc hyperv_keyboard scsi_common
+[ 415.140846] Preemption disabled at:
+[ 415.140847] [<ffffffffc0656171>] storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc]
+[ 415.140854] CPU: 8 UID: 0 PID: 1048 Comm: stress-ng-iomix Not tainted 6.19.0-rc7 #30 PREEMPT_{RT,(full)}
+[ 415.140856] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/04/2024
+[ 415.140857] Call Trace:
+[ 415.140861] <TASK>
+[ 415.140861] ? storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc]
+[ 415.140863] dump_stack_lvl+0x91/0xb0
+[ 415.140870] __schedule_bug+0x9c/0xc0
+[ 415.140875] __schedule+0xdf6/0x1300
+[ 415.140877] ? rtlock_slowlock_locked+0x56c/0x1980
+[ 415.140879] ? rcu_is_watching+0x12/0x60
+[ 415.140883] schedule_rtlock+0x21/0x40
+[ 415.140885] rtlock_slowlock_locked+0x502/0x1980
+[ 415.140891] rt_spin_lock+0x89/0x1e0
+[ 415.140893] hv_ringbuffer_write+0x87/0x2a0
+[ 415.140899] vmbus_sendpacket_mpb_desc+0xb6/0xe0
+[ 415.140900] ? rcu_is_watching+0x12/0x60
+[ 415.140902] storvsc_queuecommand+0x669/0xbe0 [hv_storvsc]
+[ 415.140904] ? HARDIRQ_verbose+0x10/0x10
+[ 415.140908] ? __rq_qos_issue+0x28/0x40
+[ 415.140911] scsi_queue_rq+0x760/0xd80 [scsi_mod]
+[ 415.140926] __blk_mq_issue_directly+0x4a/0xc0
+[ 415.140928] blk_mq_issue_direct+0x87/0x2b0
+[ 415.140931] blk_mq_dispatch_queue_requests+0x120/0x440
+[ 415.140933] blk_mq_flush_plug_list+0x7a/0x1a0
+[ 415.140935] __blk_flush_plug+0xf4/0x150
+[ 415.140940] __submit_bio+0x2b2/0x5c0
+[ 415.140944] ? submit_bio_noacct_nocheck+0x272/0x360
+[ 415.140946] submit_bio_noacct_nocheck+0x272/0x360
+[ 415.140951] ext4_read_bh_lock+0x3e/0x60 [ext4]
+[ 415.140995] ext4_block_write_begin+0x396/0x650 [ext4]
+[ 415.141018] ? __pfx_ext4_da_get_block_prep+0x10/0x10 [ext4]
+[ 415.141038] ext4_da_write_begin+0x1c4/0x350 [ext4]
+[ 415.141060] generic_perform_write+0x14e/0x2c0
+[ 415.141065] ext4_buffered_write_iter+0x6b/0x120 [ext4]
+[ 415.141083] vfs_write+0x2ca/0x570
+[ 415.141087] ksys_write+0x76/0xf0
+[ 415.141089] do_syscall_64+0x99/0x1490
+[ 415.141093] ? rcu_is_watching+0x12/0x60
+[ 415.141095] ? finish_task_switch.isra.0+0xdf/0x3d0
+[ 415.141097] ? rcu_is_watching+0x12/0x60
+[ 415.141098] ? lock_release+0x1f0/0x2a0
+[ 415.141100] ? rcu_is_watching+0x12/0x60
+[ 415.141101] ? finish_task_switch.isra.0+0xe4/0x3d0
+[ 415.141103] ? rcu_is_watching+0x12/0x60
+[ 415.141104] ? __schedule+0xb34/0x1300
+[ 415.141106] ? hrtimer_try_to_cancel+0x1d/0x170
+[ 415.141109] ? do_nanosleep+0x8b/0x160
+[ 415.141111] ? hrtimer_nanosleep+0x89/0x100
+[ 415.141114] ? __pfx_hrtimer_wakeup+0x10/0x10
+[ 415.141116] ? xfd_validate_state+0x26/0x90
+[ 415.141118] ? rcu_is_watching+0x12/0x60
+[ 415.141120] ? do_syscall_64+0x1e0/0x1490
+[ 415.141121] ? do_syscall_64+0x1e0/0x1490
+[ 415.141123] ? rcu_is_watching+0x12/0x60
+[ 415.141124] ? do_syscall_64+0x1e0/0x1490
+[ 415.141125] ? do_syscall_64+0x1e0/0x1490
+[ 415.141127] ? irqentry_exit+0x140/0x7e0
+[ 415.141129] entry_SYSCALL_64_after_hwframe+0x76/0x7e
+
+get_cpu() disables preemption while the spinlock hv_ringbuffer_write is
+using is converted to an rt-mutex under PREEMPT_RT.
+
+Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
+Tested-by: Florian Bezdeka <florian.bezdeka@siemens.com>
+Reviewed-by: Michael Kelley <mhklinux@outlook.com>
+Tested-by: Michael Kelley <mhklinux@outlook.com>
+Link: https://patch.msgid.link/0c7fb5cd-fb21-4760-8593-e04bade84744@siemens.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/storvsc_drv.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
+index ae9258347106d..d5165655fc053 100644
+--- a/drivers/scsi/storvsc_drv.c
++++ b/drivers/scsi/storvsc_drv.c
+@@ -1852,8 +1852,9 @@ static int storvsc_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *scmnd)
+ cmd_request->payload_sz = payload_sz;
+
+ /* Invokes the vsc to start an IO */
+- ret = storvsc_do_io(dev, cmd_request, get_cpu());
+- put_cpu();
++ migrate_disable();
++ ret = storvsc_do_io(dev, cmd_request, smp_processor_id());
++ migrate_enable();
+
+ if (ret)
+ scsi_dma_unmap(scmnd);
+--
+2.51.0
+
tracing-add-null-pointer-check-to-trigger_data_free.patch
net-sched-only-allow-act_ct-to-bind-to-clsact-ingress-qdiscs-and-shared-blocks.patch
net-tcp-accept-old-ack-during-closing.patch
+scsi-storvsc-fix-scheduling-while-atomic-on-preempt_.patch
+acpi-pm-save-nvs-memory-on-lenovo-g70-35.patch
+scsi-mpi3mr-add-null-checks-when-resetting-request-a.patch
+unshare-fix-unshare_fs-handling.patch
+wifi-mac80211-set-default-wmm-parameters-on-all-link.patch
+acpi-osi-add-dmi-quirk-for-acer-aspire-one-d255.patch
+scsi-ses-fix-devices-attaching-to-different-hosts.patch
+asoc-amd-yc-add-asus-expertbook-bm1503cda-to-quirk-t.patch
+alsa-usb-audio-avoid-implicit-feedback-mode-on-diyin.patch
+alsa-usb-audio-check-max-frame-size-for-implicit-fee.patch
+powerpc-uaccess-fix-inline-assembly-for-clang-build-.patch
+remoteproc-sysmon-correct-subsys_name_len-type-in-qm.patch
+remoteproc-mediatek-unprepare-scp-clock-during-syste.patch
+powerpc-83xx-km83xx-fix-keymile-vendor-prefix.patch
--- /dev/null
+From d62db5bb6c84291cdec965d760fa50c120a000b0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 7 Feb 2026 08:25:24 +0000
+Subject: unshare: fix unshare_fs() handling
+
+From: Al Viro <viro@zeniv.linux.org.uk>
+
+[ Upstream commit 6c4b2243cb6c0755159bd567130d5e12e7b10d9f ]
+
+There's an unpleasant corner case in unshare(2), when we have a
+CLONE_NEWNS in flags and current->fs hadn't been shared at all; in that
+case copy_mnt_ns() gets passed current->fs instead of a private copy,
+which causes interesting warts in proof of correctness]
+
+> I guess if private means fs->users == 1, the condition could still be true.
+
+Unfortunately, it's worse than just a convoluted proof of correctness.
+Consider the case when we have CLONE_NEWCGROUP in addition to CLONE_NEWNS
+(and current->fs->users == 1).
+
+We pass current->fs to copy_mnt_ns(), all right. Suppose it succeeds and
+flips current->fs->{pwd,root} to corresponding locations in the new namespace.
+Now we proceed to copy_cgroup_ns(), which fails (e.g. with -ENOMEM).
+We call put_mnt_ns() on the namespace created by copy_mnt_ns(), it's
+destroyed and its mount tree is dissolved, but... current->fs->root and
+current->fs->pwd are both left pointing to now detached mounts.
+
+They are pinning those, so it's not a UAF, but it leaves the calling
+process with unshare(2) failing with -ENOMEM _and_ leaving it with
+pwd and root on detached isolated mounts. The last part is clearly a bug.
+
+There is other fun related to that mess (races with pivot_root(), including
+the one between pivot_root() and fork(), of all things), but this one
+is easy to isolate and fix - treat CLONE_NEWNS as "allocate a new
+fs_struct even if it hadn't been shared in the first place". Sure, we could
+go for something like "if both CLONE_NEWNS *and* one of the things that might
+end up failing after copy_mnt_ns() call in create_new_namespaces() are set,
+force allocation of new fs_struct", but let's keep it simple - the cost
+of copy_fs_struct() is trivial.
+
+Another benefit is that copy_mnt_ns() with CLONE_NEWNS *always* gets
+a freshly allocated fs_struct, yet to be attached to anything. That
+seriously simplifies the analysis...
+
+FWIW, that bug had been there since the introduction of unshare(2) ;-/
+
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Link: https://patch.msgid.link/20260207082524.GE3183987@ZenIV
+Tested-by: Waiman Long <longman@redhat.com>
+Signed-off-by: Christian Brauner <brauner@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/fork.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/kernel/fork.c b/kernel/fork.c
+index c548538d3ade8..b8cf8891ffc7b 100644
+--- a/kernel/fork.c
++++ b/kernel/fork.c
+@@ -3193,7 +3193,7 @@ static int unshare_fs(unsigned long unshare_flags, struct fs_struct **new_fsp)
+ return 0;
+
+ /* don't need lock here; in the worst case we'll do useless copy */
+- if (fs->users == 1)
++ if (!(unshare_flags & CLONE_NEWNS) && fs->users == 1)
+ return 0;
+
+ *new_fsp = copy_fs_struct(fs);
+--
+2.51.0
+
--- /dev/null
+From fd2e824a97701172a5108b4bfbf75840c4e41853 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 5 Feb 2026 15:12:16 +0530
+Subject: wifi: mac80211: set default WMM parameters on all links
+
+From: Ramanathan Choodamani <quic_rchoodam@quicinc.com>
+
+[ Upstream commit 2259d14499d16b115ef8d5d2ddc867e2be7cb5b5 ]
+
+Currently, mac80211 only initializes default WMM parameters
+on the deflink during do_open(). For MLO cases, this
+leaves the additional links without proper WMM defaults
+if hostapd does not supply per-link WMM parameters, leading
+to inconsistent QoS behavior across links.
+
+Set default WMM parameters for each link during
+ieee80211_vif_update_links(), because this ensures all
+individual links in an MLD have valid WMM settings during
+bring-up and behave consistently across different BSS.
+
+Signed-off-by: Ramanathan Choodamani <quic_rchoodam@quicinc.com>
+Signed-off-by: Aishwarya R <aishwarya.r@oss.qualcomm.com>
+Link: https://patch.msgid.link/20260205094216.3093542-1-aishwarya.r@oss.qualcomm.com
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/mac80211/link.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/net/mac80211/link.c b/net/mac80211/link.c
+index a85b44c1bc995..cd84e7f3b742e 100644
+--- a/net/mac80211/link.c
++++ b/net/mac80211/link.c
+@@ -176,6 +176,7 @@ static int ieee80211_vif_update_links(struct ieee80211_sub_if_data *sdata,
+ struct ieee80211_bss_conf *old[IEEE80211_MLD_MAX_NUM_LINKS];
+ struct ieee80211_link_data *old_data[IEEE80211_MLD_MAX_NUM_LINKS];
+ bool use_deflink = old_links == 0; /* set for error case */
++ bool non_sta = sdata->vif.type != NL80211_IFTYPE_STATION;
+
+ sdata_assert_lock(sdata);
+
+@@ -229,6 +230,7 @@ static int ieee80211_vif_update_links(struct ieee80211_sub_if_data *sdata,
+ link = links[link_id];
+ ieee80211_link_init(sdata, link_id, &link->data, &link->conf);
+ ieee80211_link_setup(&link->data);
++ ieee80211_set_wmm_default(&link->data, true, non_sta);
+ }
+
+ if (new_links == 0)
+--
+2.51.0
+
--- /dev/null
+From 03635fc8087821efe64b2368506e04c538c01264 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 22 Feb 2026 23:52:40 -0300
+Subject: ACPI: OSI: Add DMI quirk for Acer Aspire One D255
+
+From: Sofia Schneider <sofia@schn.dev>
+
+[ Upstream commit 5ede90206273ff156a778254f0f972a55e973c89 ]
+
+The screen backlight turns off during boot (specifically during udev device
+initialization) when returning true for _OSI("Windows 2009").
+
+Analyzing the device's DSDT reveals that the firmware takes a different
+code path when Windows 7 is reported, which leads to the backlight shutoff.
+Add a DMI quirk to invoke dmi_disable_osi_win7 for this model.
+
+Signed-off-by: Sofia Schneider <sofia@schn.dev>
+Link: https://patch.msgid.link/20260223025240.518509-1-sofia@schn.dev
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/acpi/osi.c | 13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+diff --git a/drivers/acpi/osi.c b/drivers/acpi/osi.c
+index f2c943b934be0..9470f1830ff50 100644
+--- a/drivers/acpi/osi.c
++++ b/drivers/acpi/osi.c
+@@ -389,6 +389,19 @@ static const struct dmi_system_id acpi_osi_dmi_table[] __initconst = {
+ },
+ },
+
++ /*
++ * The screen backlight turns off during udev device creation
++ * when returning true for _OSI("Windows 2009")
++ */
++ {
++ .callback = dmi_disable_osi_win7,
++ .ident = "Acer Aspire One D255",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "AOD255"),
++ },
++ },
++
+ /*
+ * The wireless hotkey does not work on those machines when
+ * returning true for _OSI("Windows 2012")
+--
+2.51.0
+
--- /dev/null
+From 98cd6d3101cbf415eecc515f77f473d0e7a66d09 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 5 Feb 2026 23:05:02 +0100
+Subject: ACPI: PM: Save NVS memory on Lenovo G70-35
+
+From: Piotr Mazek <pmazek@outlook.com>
+
+[ Upstream commit 023cd6d90f8aa2ef7b72d84be84a18e61ecebd64 ]
+
+[821d6f0359b0614792ab8e2fb93b503e25a65079] prevented machines
+produced later than 2012 from saving NVS region to accelerate S3.
+
+Despite being made after 2012, Lenovo G70-35 still needs NVS memory
+saving during S3. A quirk is introduced for this platform.
+
+Signed-off-by: Piotr Mazek <pmazek@outlook.com>
+[ rjw: Subject adjustment ]
+Link: https://patch.msgid.link/GV2PPF3CD5B63CC2442EE3F76F8443EAD90D499A@GV2PPF3CD5B63CC.EURP251.PROD.OUTLOOK.COM
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/acpi/sleep.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
+index c8ee8e42b0f64..0b7fa4a8c379c 100644
+--- a/drivers/acpi/sleep.c
++++ b/drivers/acpi/sleep.c
+@@ -386,6 +386,14 @@ static const struct dmi_system_id acpisleep_dmi_table[] __initconst = {
+ DMI_MATCH(DMI_PRODUCT_NAME, "80E1"),
+ },
+ },
++ {
++ .callback = init_nvs_save_s3,
++ .ident = "Lenovo G70-35",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "80Q5"),
++ },
++ },
+ /*
+ * ThinkPad X1 Tablet(2016) cannot do suspend-to-idle using
+ * the Low Power S0 Idle firmware interface (see
+--
+2.51.0
+
--- /dev/null
+From 68950c9fa6386e2e1a21af07f0158aa7e06bcb11 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 19 Feb 2026 20:14:26 +0000
+Subject: ALSA: hda/realtek: Fix speaker pop on Star Labs StarFighter
+
+From: Sean Rhodes <sean@starlabs.systems>
+
+[ Upstream commit 1cb3c20688fc8380c9b365d03aea7e84faf6a9fd ]
+
+On Star Labs StarFighter (Realtek ALC233/235), the internal speakers can
+emit an audible pop when entering or leaving runtime suspend.
+
+Mute the speaker output paths via snd_hda_gen_shutup_speakers() in the
+Realtek shutup callback before the codec is powered down.
+
+This is enough to avoid the pop without special EAPD handling.
+
+Test results:
+- runtime PM pop fixed
+- still reaches D3 (PCI 0000:00:1f.3 power_state=D3hot)
+- does not address pops on cold boot (G3 exit) or around display manager
+ start/shutdown
+
+journalctl -k (boot):
+- snd_hda_codec_alc269 hdaudioC0D0: ALC233: picked fixup for PCI SSID
+ 7017:2014
+- snd_hda_codec_alc269 hdaudioC0D0: autoconfig for ALC233: line_outs=1
+ (0x1b/0x0/0x0/0x0/0x0) type:speaker
+
+Suggested-by: Takashi Iwai <tiwai@suse.com>
+Tested-by: Sean Rhodes <sean@starlabs.systems>
+Signed-off-by: Sean Rhodes <sean@starlabs.systems>
+Link: https://patch.msgid.link/4d5fb71b132bb283fd41c622b8413770b2065242.1771532060.git.sean@starlabs.systems
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/pci/hda/patch_realtek.c | 25 +++++++++++++++++++++++++
+ 1 file changed, 25 insertions(+)
+
+diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
+index c13def0f1e1a4..cb6ff3c36c5f0 100644
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -4164,6 +4164,24 @@ static int alc269_resume(struct hda_codec *codec)
+ return 0;
+ }
+
++#define STARLABS_STARFIGHTER_SHUTUP_DELAY_MS 30
++
++static void starlabs_starfighter_shutup(struct hda_codec *codec)
++{
++ if (snd_hda_gen_shutup_speakers(codec))
++ msleep(STARLABS_STARFIGHTER_SHUTUP_DELAY_MS);
++}
++
++static void alc233_fixup_starlabs_starfighter(struct hda_codec *codec,
++ const struct hda_fixup *fix,
++ int action)
++{
++ struct alc_spec *spec = codec->spec;
++
++ if (action == HDA_FIXUP_ACT_PRE_PROBE)
++ spec->shutup = starlabs_starfighter_shutup;
++}
++
+ static void alc269_fixup_pincfg_no_hp_to_lineout(struct hda_codec *codec,
+ const struct hda_fixup *fix, int action)
+ {
+@@ -8203,6 +8221,7 @@ enum {
+ ALC245_FIXUP_CLEVO_NOISY_MIC,
+ ALC269_FIXUP_VAIO_VJFH52_MIC_NO_PRESENCE,
+ ALC233_FIXUP_MEDION_MTL_SPK,
++ ALC233_FIXUP_STARLABS_STARFIGHTER,
+ ALC294_FIXUP_BASS_SPEAKER_15,
+ ALC283_FIXUP_DELL_HP_RESUME,
+ ALC294_FIXUP_ASUS_CS35L41_SPI_2,
+@@ -10591,6 +10610,10 @@ static const struct hda_fixup alc269_fixups[] = {
+ { }
+ },
+ },
++ [ALC233_FIXUP_STARLABS_STARFIGHTER] = {
++ .type = HDA_FIXUP_FUNC,
++ .v.func = alc233_fixup_starlabs_starfighter,
++ },
+ [ALC294_FIXUP_BASS_SPEAKER_15] = {
+ .type = HDA_FIXUP_FUNC,
+ .v.func = alc294_fixup_bass_speaker_15,
+@@ -11606,6 +11629,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
+ SND_PCI_QUIRK(0x2782, 0x1705, "MEDION E15433", ALC269VC_FIXUP_INFINIX_Y4_MAX),
+ SND_PCI_QUIRK(0x2782, 0x1707, "Vaio VJFE-ADL", ALC298_FIXUP_SPK_VOLUME),
+ SND_PCI_QUIRK(0x2782, 0x4900, "MEDION E15443", ALC233_FIXUP_MEDION_MTL_SPK),
++ SND_PCI_QUIRK(0x7017, 0x2014, "Star Labs StarFighter", ALC233_FIXUP_STARLABS_STARFIGHTER),
+ SND_PCI_QUIRK(0x8086, 0x2074, "Intel NUC 8", ALC233_FIXUP_INTEL_NUC8_DMIC),
+ SND_PCI_QUIRK(0x8086, 0x2080, "Intel NUC 8 Rugged", ALC256_FIXUP_INTEL_NUC8_RUGGED),
+ SND_PCI_QUIRK(0x8086, 0x2081, "Intel NUC 10", ALC256_FIXUP_INTEL_NUC10),
+@@ -11702,6 +11726,7 @@ static const struct hda_model_fixup alc269_fixup_models[] = {
+ {.id = ALC298_FIXUP_TPT470_DOCK_FIX, .name = "tpt470-dock-fix"},
+ {.id = ALC298_FIXUP_TPT470_DOCK, .name = "tpt470-dock"},
+ {.id = ALC233_FIXUP_LENOVO_MULTI_CODECS, .name = "dual-codecs"},
++ {.id = ALC233_FIXUP_STARLABS_STARFIGHTER, .name = "starlabs-starfighter"},
+ {.id = ALC700_FIXUP_INTEL_REFERENCE, .name = "alc700-ref"},
+ {.id = ALC269_FIXUP_SONY_VAIO, .name = "vaio"},
+ {.id = ALC269_FIXUP_DELL_M101Z, .name = "dell-m101z"},
+--
+2.51.0
+
--- /dev/null
+From ef2922f8de64e9adb561afad732e07901ae08704 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 25 Feb 2026 09:52:30 +0100
+Subject: ALSA: usb-audio: Avoid implicit feedback mode on DIYINHK USB Audio
+ 2.0
+
+From: Takashi Iwai <tiwai@suse.de>
+
+[ Upstream commit c5bf24c8aba1ff711226ee0f039ff01a5754692b ]
+
+Although DIYINHK USB Audio 2.0 (ID 20b1:2009) shows the implicit
+feedback source for the capture stream, this would cause several
+problems for the playback. Namely, the device can get wMaxPackSize
+1024 for 24/32 bit format with 6 channels, and when a high sample rate
+like 352.8kHz or 384kHz is played, the packet size overflows the max
+limit. Also, the device has another two playback altsets, and those
+aren't properly handled with the implicit feedback.
+
+Since the device has been working well even before introducing the
+implicit feedback, we can assume that it works fine in the async mode.
+This patch adds the explicit skip of the implicit fb detection to make
+the playback running in the async mode.
+
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=221076
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Link: https://patch.msgid.link/20260225085233.316306-4-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/usb/quirks.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
+index 41752b8197463..5c3a97ea46e04 100644
+--- a/sound/usb/quirks.c
++++ b/sound/usb/quirks.c
+@@ -2351,6 +2351,8 @@ static const struct usb_audio_quirk_flags_table quirk_flags_table[] = {
+ QUIRK_FLAG_SHARE_MEDIA_DEVICE | QUIRK_FLAG_ALIGN_TRANSFER),
+ DEVICE_FLG(0x2040, 0x7281, /* Hauppauge HVR-950Q-MXL */
+ QUIRK_FLAG_SHARE_MEDIA_DEVICE | QUIRK_FLAG_ALIGN_TRANSFER),
++ DEVICE_FLG(0x20b1, 0x2009, /* XMOS Ltd DIYINHK USB Audio 2.0 */
++ QUIRK_FLAG_SKIP_IMPLICIT_FB | QUIRK_FLAG_DSD_RAW),
+ DEVICE_FLG(0x2040, 0x8200, /* Hauppauge Woodbury */
+ QUIRK_FLAG_SHARE_MEDIA_DEVICE | QUIRK_FLAG_ALIGN_TRANSFER),
+ DEVICE_FLG(0x21b4, 0x0081, /* AudioQuest DragonFly */
+--
+2.51.0
+
--- /dev/null
+From 615ad027bde0b3f29e62478a88a1b8b1ace75b46 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 25 Feb 2026 09:52:29 +0100
+Subject: ALSA: usb-audio: Check max frame size for implicit feedback mode, too
+
+From: Takashi Iwai <tiwai@suse.de>
+
+[ Upstream commit 7cb2a5422f5bbdf1cf32eae0eda41000485b9346 ]
+
+When the packet sizes are taken from the capture stream in the
+implicit feedback mode, the sizes might be larger than the upper
+boundary defined by the descriptor. As already done for other
+transfer modes, we have to cap the sizes accordingly at sending,
+otherwise this would lead to an error in USB core at submission of
+URBs.
+
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=221076
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Link: https://patch.msgid.link/20260225085233.316306-3-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/usb/endpoint.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
+index 9d22613f71e24..2616a7efcc212 100644
+--- a/sound/usb/endpoint.c
++++ b/sound/usb/endpoint.c
+@@ -224,6 +224,7 @@ int snd_usb_endpoint_next_packet_size(struct snd_usb_endpoint *ep,
+
+ packet = ctx->packet_size[idx];
+ if (packet) {
++ packet = min(packet, ep->maxframesize);
+ if (avail && packet >= avail)
+ return -EAGAIN;
+ return packet;
+--
+2.51.0
+
--- /dev/null
+From 2e1a1aaf86f32e58e7a5d658b10f818d2a6a213d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 21 Feb 2026 12:48:13 +0100
+Subject: ASoC: amd: yc: Add ASUS EXPERTBOOK BM1503CDA to quirk table
+
+From: Azamat Almazbek uulu <almazbek1608@gmail.com>
+
+[ Upstream commit 32fc4168fa56f6301d858c778a3d712774e9657e ]
+
+The ASUS ExpertBook BM1503CDA (Ryzen 5 7535U, Barcelo-R) has an
+internal DMIC connected through the AMD ACP (Audio CoProcessor)
+but is missing from the DMI quirk table, so the acp6x machine
+driver probe returns -ENODEV and no DMIC capture device is created.
+
+Add the DMI entry so the internal microphone works out of the box.
+
+Signed-off-by: Azamat Almazbek uulu <almazbek1608@gmail.com>
+Reviewed-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
+Link: https://patch.msgid.link/20260221114813.5610-1-almazbek1608@gmail.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/soc/amd/yc/acp6x-mach.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c
+index f33946fb895da..b4f38d2245ec7 100644
+--- a/sound/soc/amd/yc/acp6x-mach.c
++++ b/sound/soc/amd/yc/acp6x-mach.c
+@@ -696,6 +696,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = {
+ DMI_MATCH(DMI_PRODUCT_NAME, "Vivobook_ASUSLaptop M6501RR_M6501RR"),
+ }
+ },
++ {
++ .driver_data = &acp6x_card,
++ .matches = {
++ DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK COMPUTER INC."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "ASUS EXPERTBOOK BM1503CDA"),
++ }
++ },
+ {}
+ };
+
+--
+2.51.0
+
--- /dev/null
+From 9d477bb9fc4346b811a42445223172c1a52932c2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 23 Feb 2026 09:36:16 +0000
+Subject: ASoC: cs42l43: Report insert for exotic peripherals
+
+From: Charles Keepax <ckeepax@opensource.cirrus.com>
+
+[ Upstream commit 6510e1324bcdc8caf21f6d17efe27604c48f0d64 ]
+
+For some exotic peripherals the type detect can return a reserved value
+of 0x4. This will currently return an error and not report anything to
+user-space, update this to report the insert normally.
+
+Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
+Link: https://patch.msgid.link/20260223093616.3800350-1-ckeepax@opensource.cirrus.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/soc/codecs/cs42l43-jack.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/sound/soc/codecs/cs42l43-jack.c b/sound/soc/codecs/cs42l43-jack.c
+index aa0062f3aa918..3a61f222d85fe 100644
+--- a/sound/soc/codecs/cs42l43-jack.c
++++ b/sound/soc/codecs/cs42l43-jack.c
+@@ -711,6 +711,7 @@ static int cs42l43_run_type_detect(struct cs42l43_codec *priv)
+ switch (type & CS42L43_HSDET_TYPE_STS_MASK) {
+ case 0x0: // CTIA
+ case 0x1: // OMTP
++ case 0x4:
+ return cs42l43_run_load_detect(priv, true);
+ case 0x2: // 3-pole
+ return cs42l43_run_load_detect(priv, false);
+--
+2.51.0
+
--- /dev/null
+From b788d72da5335b71e1f50d8b8f083877cb21c872 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 21 Feb 2026 10:03:32 +0530
+Subject: drm/amdgpu/vcn5: Add SMU dpm interface type
+
+From: sguttula <suresh.guttula@amd.com>
+
+[ Upstream commit a5fe1a54513196e4bc8f9170006057dc31e7155e ]
+
+This will set AMDGPU_VCN_SMU_DPM_INTERFACE_* smu_type
+based on soc type and fixing ring timeout issue seen
+for DPM enabled case.
+
+Signed-off-by: sguttula <suresh.guttula@amd.com>
+Reviewed-by: Pratik Vishwakarma <Pratik.Vishwakarma@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+(cherry picked from commit f0f23c315b38c55e8ce9484cf59b65811f350630)
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c b/drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c
+index a359d612182dd..3aa715830fbe8 100644
+--- a/drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c
++++ b/drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c
+@@ -166,6 +166,10 @@ static int vcn_v5_0_0_sw_init(void *handle)
+ fw_shared->present_flag_0 = cpu_to_le32(AMDGPU_FW_SHARED_FLAG_0_UNIFIED_QUEUE);
+ fw_shared->sq.is_enabled = 1;
+
++ fw_shared->present_flag_0 |= cpu_to_le32(AMDGPU_VCN_SMU_DPM_INTERFACE_FLAG);
++ fw_shared->smu_dpm_interface.smu_interface_type = (adev->flags & AMD_IS_APU) ?
++ AMDGPU_VCN_SMU_DPM_INTERFACE_APU : AMDGPU_VCN_SMU_DPM_INTERFACE_DGPU;
++
+ if (amdgpu_vcnfw_log)
+ amdgpu_vcn_fwlog_init(&adev->vcn.inst[i]);
+ }
+--
+2.51.0
+
--- /dev/null
+From 3726d56ea396652b9c249f2162b9d39f706ac065 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 4 Dec 2024 14:20:02 +0000
+Subject: kexec: Consolidate machine_kexec_mask_interrupts() implementation
+
+From: Eliav Farber <farbere@amazon.com>
+
+[ Upstream commit bad6722e478f5b17a5ceb039dfb4c680cf2c0b48 ]
+
+Consolidate the machine_kexec_mask_interrupts implementation into a common
+function located in a new file: kernel/irq/kexec.c. This removes duplicate
+implementations from architecture-specific files in arch/arm, arch/arm64,
+arch/powerpc, and arch/riscv, reducing code duplication and improving
+maintainability.
+
+The new implementation retains architecture-specific behavior for
+CONFIG_GENERIC_IRQ_KEXEC_CLEAR_VM_FORWARD, which was previously implemented
+for ARM64. When enabled (currently for ARM64), it clears the active state
+of interrupts forwarded to virtual machines (VMs) before handling other
+interrupt masking operations.
+
+Signed-off-by: Eliav Farber <farbere@amazon.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Link: https://lore.kernel.org/all/20241204142003.32859-2-farbere@amazon.com
+Stable-dep-of: 20197b967a6a ("powerpc/kexec/core: use big-endian types for crash variables")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/kernel/machine_kexec.c | 23 ------------------
+ arch/arm64/Kconfig | 1 +
+ arch/arm64/kernel/machine_kexec.c | 31 ------------------------
+ arch/powerpc/include/asm/kexec.h | 1 -
+ arch/powerpc/kexec/core.c | 22 -----------------
+ arch/powerpc/kexec/core_32.c | 1 +
+ arch/riscv/kernel/machine_kexec.c | 23 ------------------
+ include/linux/irq.h | 3 +++
+ kernel/irq/Kconfig | 6 +++++
+ kernel/irq/Makefile | 2 +-
+ kernel/irq/kexec.c | 40 +++++++++++++++++++++++++++++++
+ 11 files changed, 52 insertions(+), 101 deletions(-)
+ create mode 100644 kernel/irq/kexec.c
+
+diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
+index 80ceb5bd2680b..dd430477e7c13 100644
+--- a/arch/arm/kernel/machine_kexec.c
++++ b/arch/arm/kernel/machine_kexec.c
+@@ -127,29 +127,6 @@ void crash_smp_send_stop(void)
+ cpus_stopped = 1;
+ }
+
+-static void machine_kexec_mask_interrupts(void)
+-{
+- unsigned int i;
+- struct irq_desc *desc;
+-
+- for_each_irq_desc(i, desc) {
+- struct irq_chip *chip;
+-
+- chip = irq_desc_get_chip(desc);
+- if (!chip)
+- continue;
+-
+- if (chip->irq_eoi && irqd_irq_inprogress(&desc->irq_data))
+- chip->irq_eoi(&desc->irq_data);
+-
+- if (chip->irq_mask)
+- chip->irq_mask(&desc->irq_data);
+-
+- if (chip->irq_disable && !irqd_irq_disabled(&desc->irq_data))
+- chip->irq_disable(&desc->irq_data);
+- }
+-}
+-
+ void machine_crash_shutdown(struct pt_regs *regs)
+ {
+ local_irq_disable();
+diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
+index 0e2902f38e70e..f487c5e21e2f1 100644
+--- a/arch/arm64/Kconfig
++++ b/arch/arm64/Kconfig
+@@ -146,6 +146,7 @@ config ARM64
+ select GENERIC_IDLE_POLL_SETUP
+ select GENERIC_IOREMAP
+ select GENERIC_IRQ_IPI
++ select GENERIC_IRQ_KEXEC_CLEAR_VM_FORWARD
+ select GENERIC_IRQ_PROBE
+ select GENERIC_IRQ_SHOW
+ select GENERIC_IRQ_SHOW_LEVEL
+diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
+index 82e2203d86a31..6f121a0164a48 100644
+--- a/arch/arm64/kernel/machine_kexec.c
++++ b/arch/arm64/kernel/machine_kexec.c
+@@ -207,37 +207,6 @@ void machine_kexec(struct kimage *kimage)
+ BUG(); /* Should never get here. */
+ }
+
+-static void machine_kexec_mask_interrupts(void)
+-{
+- unsigned int i;
+- struct irq_desc *desc;
+-
+- for_each_irq_desc(i, desc) {
+- struct irq_chip *chip;
+- int ret;
+-
+- chip = irq_desc_get_chip(desc);
+- if (!chip)
+- continue;
+-
+- /*
+- * First try to remove the active state. If this
+- * fails, try to EOI the interrupt.
+- */
+- ret = irq_set_irqchip_state(i, IRQCHIP_STATE_ACTIVE, false);
+-
+- if (ret && irqd_irq_inprogress(&desc->irq_data) &&
+- chip->irq_eoi)
+- chip->irq_eoi(&desc->irq_data);
+-
+- if (chip->irq_mask)
+- chip->irq_mask(&desc->irq_data);
+-
+- if (chip->irq_disable && !irqd_irq_disabled(&desc->irq_data))
+- chip->irq_disable(&desc->irq_data);
+- }
+-}
+-
+ /**
+ * machine_crash_shutdown - shutdown non-crashing cpus and save registers
+ */
+diff --git a/arch/powerpc/include/asm/kexec.h b/arch/powerpc/include/asm/kexec.h
+index 270ee93a0f7d8..601e569303e1b 100644
+--- a/arch/powerpc/include/asm/kexec.h
++++ b/arch/powerpc/include/asm/kexec.h
+@@ -61,7 +61,6 @@ struct pt_regs;
+ extern void kexec_smp_wait(void); /* get and clear naca physid, wait for
+ master to copy new code to 0 */
+ extern void default_machine_kexec(struct kimage *image);
+-extern void machine_kexec_mask_interrupts(void);
+
+ void relocate_new_kernel(unsigned long indirection_page, unsigned long reboot_code_buffer,
+ unsigned long start_address) __noreturn;
+diff --git a/arch/powerpc/kexec/core.c b/arch/powerpc/kexec/core.c
+index b8333a49ea5da..58a930a47422b 100644
+--- a/arch/powerpc/kexec/core.c
++++ b/arch/powerpc/kexec/core.c
+@@ -22,28 +22,6 @@
+ #include <asm/setup.h>
+ #include <asm/firmware.h>
+
+-void machine_kexec_mask_interrupts(void) {
+- unsigned int i;
+- struct irq_desc *desc;
+-
+- for_each_irq_desc(i, desc) {
+- struct irq_chip *chip;
+-
+- chip = irq_desc_get_chip(desc);
+- if (!chip)
+- continue;
+-
+- if (chip->irq_eoi && irqd_irq_inprogress(&desc->irq_data))
+- chip->irq_eoi(&desc->irq_data);
+-
+- if (chip->irq_mask)
+- chip->irq_mask(&desc->irq_data);
+-
+- if (chip->irq_disable && !irqd_irq_disabled(&desc->irq_data))
+- chip->irq_disable(&desc->irq_data);
+- }
+-}
+-
+ #ifdef CONFIG_CRASH_DUMP
+ void machine_crash_shutdown(struct pt_regs *regs)
+ {
+diff --git a/arch/powerpc/kexec/core_32.c b/arch/powerpc/kexec/core_32.c
+index c95f96850c9e1..deb28eb44f30f 100644
+--- a/arch/powerpc/kexec/core_32.c
++++ b/arch/powerpc/kexec/core_32.c
+@@ -7,6 +7,7 @@
+ * Copyright (C) 2005 IBM Corporation.
+ */
+
++#include <linux/irq.h>
+ #include <linux/kexec.h>
+ #include <linux/mm.h>
+ #include <linux/string.h>
+diff --git a/arch/riscv/kernel/machine_kexec.c b/arch/riscv/kernel/machine_kexec.c
+index 3c830a6f7ef46..2306ce3e5f229 100644
+--- a/arch/riscv/kernel/machine_kexec.c
++++ b/arch/riscv/kernel/machine_kexec.c
+@@ -114,29 +114,6 @@ void machine_shutdown(void)
+ #endif
+ }
+
+-static void machine_kexec_mask_interrupts(void)
+-{
+- unsigned int i;
+- struct irq_desc *desc;
+-
+- for_each_irq_desc(i, desc) {
+- struct irq_chip *chip;
+-
+- chip = irq_desc_get_chip(desc);
+- if (!chip)
+- continue;
+-
+- if (chip->irq_eoi && irqd_irq_inprogress(&desc->irq_data))
+- chip->irq_eoi(&desc->irq_data);
+-
+- if (chip->irq_mask)
+- chip->irq_mask(&desc->irq_data);
+-
+- if (chip->irq_disable && !irqd_irq_disabled(&desc->irq_data))
+- chip->irq_disable(&desc->irq_data);
+- }
+-}
+-
+ /*
+ * machine_crash_shutdown - Prepare to kexec after a kernel crash
+ *
+diff --git a/include/linux/irq.h b/include/linux/irq.h
+index fa711f80957b6..25f51bf3c351f 100644
+--- a/include/linux/irq.h
++++ b/include/linux/irq.h
+@@ -694,6 +694,9 @@ extern int irq_chip_request_resources_parent(struct irq_data *data);
+ extern void irq_chip_release_resources_parent(struct irq_data *data);
+ #endif
+
++/* Disable or mask interrupts during a kernel kexec */
++extern void machine_kexec_mask_interrupts(void);
++
+ /* Handling of unhandled and spurious interrupts: */
+ extern void note_interrupt(struct irq_desc *desc, irqreturn_t action_ret);
+
+diff --git a/kernel/irq/Kconfig b/kernel/irq/Kconfig
+index 529adb1f58593..875f25ed6f710 100644
+--- a/kernel/irq/Kconfig
++++ b/kernel/irq/Kconfig
+@@ -141,6 +141,12 @@ config GENERIC_IRQ_DEBUGFS
+
+ If you don't know what to do here, say N.
+
++# Clear forwarded VM interrupts during kexec.
++# This option ensures the kernel clears active states for interrupts
++# forwarded to virtual machines (VMs) during a machine kexec.
++config GENERIC_IRQ_KEXEC_CLEAR_VM_FORWARD
++ bool
++
+ endmenu
+
+ config GENERIC_IRQ_MULTI_HANDLER
+diff --git a/kernel/irq/Makefile b/kernel/irq/Makefile
+index f19d3080bf11a..c0f44c06d69df 100644
+--- a/kernel/irq/Makefile
++++ b/kernel/irq/Makefile
+@@ -1,6 +1,6 @@
+ # SPDX-License-Identifier: GPL-2.0
+
+-obj-y := irqdesc.o handle.o manage.o spurious.o resend.o chip.o dummychip.o devres.o
++obj-y := irqdesc.o handle.o manage.o spurious.o resend.o chip.o dummychip.o devres.o kexec.o
+ obj-$(CONFIG_IRQ_TIMINGS) += timings.o
+ ifeq ($(CONFIG_TEST_IRQ_TIMINGS),y)
+ CFLAGS_timings.o += -DDEBUG
+diff --git a/kernel/irq/kexec.c b/kernel/irq/kexec.c
+new file mode 100644
+index 0000000000000..0f9548c1708dd
+--- /dev/null
++++ b/kernel/irq/kexec.c
+@@ -0,0 +1,40 @@
++// SPDX-License-Identifier: GPL-2.0
++
++#include <linux/interrupt.h>
++#include <linux/irq.h>
++#include <linux/irqdesc.h>
++#include <linux/irqnr.h>
++
++#include "internals.h"
++
++void machine_kexec_mask_interrupts(void)
++{
++ struct irq_desc *desc;
++ unsigned int i;
++
++ for_each_irq_desc(i, desc) {
++ struct irq_chip *chip;
++ int check_eoi = 1;
++
++ chip = irq_desc_get_chip(desc);
++ if (!chip)
++ continue;
++
++ if (IS_ENABLED(CONFIG_GENERIC_IRQ_KEXEC_CLEAR_VM_FORWARD)) {
++ /*
++ * First try to remove the active state from an interrupt which is forwarded
++ * to a VM. If the interrupt is not forwarded, try to EOI the interrupt.
++ */
++ check_eoi = irq_set_irqchip_state(i, IRQCHIP_STATE_ACTIVE, false);
++ }
++
++ if (check_eoi && chip->irq_eoi && irqd_irq_inprogress(&desc->irq_data))
++ chip->irq_eoi(&desc->irq_data);
++
++ if (chip->irq_mask)
++ chip->irq_mask(&desc->irq_data);
++
++ if (chip->irq_disable && !irqd_irq_disabled(&desc->irq_data))
++ chip->irq_disable(&desc->irq_data);
++ }
++}
+--
+2.51.0
+
--- /dev/null
+From 773810de10389cc507c81d32cc921c0c6720b58c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 21 Apr 2025 22:36:46 -0400
+Subject: kexec: Include kernel-end even without crashkernel
+
+From: Ben Collins <bcollins@kernel.org>
+
+[ Upstream commit 38c64dfe0af12778953846df5f259e913275cfe5 ]
+
+Certain versions of kexec don't even work without kernel-end being
+added to the device-tree. Add it even if crash-kernel is disabled.
+
+Signed-off-by: Ben Collins <bcollins@kernel.org>
+Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
+Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
+Link: https://patch.msgid.link/2025042122-inescapable-mandrill-8a5ff2@boujee-and-buff
+Stable-dep-of: 20197b967a6a ("powerpc/kexec/core: use big-endian types for crash variables")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/kexec/core.c | 27 +++++++++++++++------------
+ 1 file changed, 15 insertions(+), 12 deletions(-)
+
+diff --git a/arch/powerpc/kexec/core.c b/arch/powerpc/kexec/core.c
+index 58a930a47422b..50e7cf4b992b1 100644
+--- a/arch/powerpc/kexec/core.c
++++ b/arch/powerpc/kexec/core.c
+@@ -22,6 +22,8 @@
+ #include <asm/setup.h>
+ #include <asm/firmware.h>
+
++#define cpu_to_be_ulong __PASTE(cpu_to_be, BITS_PER_LONG)
++
+ #ifdef CONFIG_CRASH_DUMP
+ void machine_crash_shutdown(struct pt_regs *regs)
+ {
+@@ -156,17 +158,10 @@ int __init overlaps_crashkernel(unsigned long start, unsigned long size)
+ }
+
+ /* Values we need to export to the second kernel via the device tree. */
+-static phys_addr_t kernel_end;
+ static phys_addr_t crashk_base;
+ static phys_addr_t crashk_size;
+ static unsigned long long mem_limit;
+
+-static struct property kernel_end_prop = {
+- .name = "linux,kernel-end",
+- .length = sizeof(phys_addr_t),
+- .value = &kernel_end,
+-};
+-
+ static struct property crashk_base_prop = {
+ .name = "linux,crashkernel-base",
+ .length = sizeof(phys_addr_t),
+@@ -185,8 +180,6 @@ static struct property memory_limit_prop = {
+ .value = &mem_limit,
+ };
+
+-#define cpu_to_be_ulong __PASTE(cpu_to_be, BITS_PER_LONG)
+-
+ static void __init export_crashk_values(struct device_node *node)
+ {
+ /* There might be existing crash kernel properties, but we can't
+@@ -210,6 +203,15 @@ static void __init export_crashk_values(struct device_node *node)
+ mem_limit = cpu_to_be_ulong(memory_limit);
+ of_update_property(node, &memory_limit_prop);
+ }
++#endif /* CONFIG_CRASH_RESERVE */
++
++static phys_addr_t kernel_end;
++
++static struct property kernel_end_prop = {
++ .name = "linux,kernel-end",
++ .length = sizeof(phys_addr_t),
++ .value = &kernel_end,
++};
+
+ static int __init kexec_setup(void)
+ {
+@@ -220,16 +222,17 @@ static int __init kexec_setup(void)
+ return -ENOENT;
+
+ /* remove any stale properties so ours can be found */
+- of_remove_property(node, of_find_property(node, kernel_end_prop.name, NULL));
++ of_remove_property(node, of_find_property(node, kernel_end_prop.name,
++ NULL));
+
+ /* information needed by userspace when using default_machine_kexec */
+ kernel_end = cpu_to_be_ulong(__pa(_end));
+ of_add_property(node, &kernel_end_prop);
+
++#ifdef CONFIG_CRASH_RESERVE
+ export_crashk_values(node);
+-
++#endif
+ of_node_put(node);
+ return 0;
+ }
+ late_initcall(kexec_setup);
+-#endif /* CONFIG_CRASH_RESERVE */
+--
+2.51.0
+
--- /dev/null
+From ad95da2069f1dc875904ea7a95647d85cf358727 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 3 Mar 2026 16:31:42 +0100
+Subject: powerpc: 83xx: km83xx: Fix keymile vendor prefix
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: J. Neuschäfer <j.ne@posteo.net>
+
+[ Upstream commit 691417ffe7821721e0a28bd25ad8c0dc0d4ae4ad ]
+
+When kmeter.c was refactored into km83xx.c in 2011, the "keymile" vendor
+prefix was changed to upper-case "Keymile". The devicetree at
+arch/powerpc/boot/dts/kmeter1.dts never underwent the same change,
+suggesting that this was simply a mistake.
+
+Fixes: 93e2b95c81042d ("powerpc/83xx: rename and update kmeter1")
+Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
+Reviewed-by: Heiko Schocher <hs@nabladev.com>
+Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
+Link: https://patch.msgid.link/20260303-keymile-v1-1-463a11e71702@posteo.net
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/platforms/83xx/km83xx.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/arch/powerpc/platforms/83xx/km83xx.c b/arch/powerpc/platforms/83xx/km83xx.c
+index 2b5d187d9b62d..9ef8fb39dd1b1 100644
+--- a/arch/powerpc/platforms/83xx/km83xx.c
++++ b/arch/powerpc/platforms/83xx/km83xx.c
+@@ -155,8 +155,8 @@ machine_device_initcall(mpc83xx_km, mpc83xx_declare_of_platform_devices);
+
+ /* list of the supported boards */
+ static char *board[] __initdata = {
+- "Keymile,KMETER1",
+- "Keymile,kmpbec8321",
++ "keymile,KMETER1",
++ "keymile,kmpbec8321",
+ NULL
+ };
+
+--
+2.51.0
+
--- /dev/null
+From 7d99c5afe70d93f9a6aa8ded75a554bbf2a1095c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 27 Feb 2026 22:48:01 +0530
+Subject: powerpc/crash: adjust the elfcorehdr size
+
+From: Sourabh Jain <sourabhjain@linux.ibm.com>
+
+[ Upstream commit 04e707cb77c272cb0bb2e2e3c5c7f844d804a089 ]
+
+With crash hotplug support enabled, additional memory is allocated to
+the elfcorehdr kexec segment to accommodate resources added during
+memory hotplug events. However, the kdump FDT is not updated with the
+same size, which can result in elfcorehdr corruption in the kdump
+kernel.
+
+Update elf_headers_sz (the kimage member representing the size of the
+elfcorehdr kexec segment) to reflect the total memory allocated for the
+elfcorehdr segment instead of the elfcorehdr buffer size at the time of
+kdump load. This allows of_kexec_alloc_and_setup_fdt() to reserve the
+full elfcorehdr memory in the kdump FDT and prevents elfcorehdr
+corruption.
+
+Fixes: 849599b702ef8 ("powerpc/crash: add crash memory hotplug support")
+Reviewed-by: Hari Bathini <hbathini@linux.ibm.com>
+Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
+Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
+Link: https://patch.msgid.link/20260227171801.2238847-1-sourabhjain@linux.ibm.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/kexec/file_load_64.c | 14 +++++++++++++-
+ 1 file changed, 13 insertions(+), 1 deletion(-)
+
+diff --git a/arch/powerpc/kexec/file_load_64.c b/arch/powerpc/kexec/file_load_64.c
+index dc65c13911577..248a0f00a291f 100644
+--- a/arch/powerpc/kexec/file_load_64.c
++++ b/arch/powerpc/kexec/file_load_64.c
+@@ -633,6 +633,11 @@ static int load_elfcorehdr_segment(struct kimage *image, struct kexec_buf *kbuf)
+ kbuf->buffer = headers;
+ kbuf->mem = KEXEC_BUF_MEM_UNKNOWN;
+ kbuf->bufsz = headers_sz;
++
++ /*
++ * Account for extra space required to accommodate additional memory
++ * ranges in elfcorehdr due to memory hotplug events.
++ */
+ kbuf->memsz = headers_sz + kdump_extra_elfcorehdr_size(cmem);
+ kbuf->top_down = false;
+
+@@ -643,7 +648,14 @@ static int load_elfcorehdr_segment(struct kimage *image, struct kexec_buf *kbuf)
+ }
+
+ image->elf_load_addr = kbuf->mem;
+- image->elf_headers_sz = headers_sz;
++
++ /*
++ * If CONFIG_CRASH_HOTPLUG is enabled, the elfcorehdr kexec segment
++ * memsz can be larger than bufsz. Always initialize elf_headers_sz
++ * with memsz. This ensures the correct size is reserved for elfcorehdr
++ * memory in the FDT prepared for kdump.
++ */
++ image->elf_headers_sz = kbuf->memsz;
+ image->elf_headers = headers;
+ out:
+ kfree(cmem);
+--
+2.51.0
+
--- /dev/null
+From a1ed6995b930b00e25847fd1eda3d115af4ef7ae Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 24 Dec 2025 20:42:57 +0530
+Subject: powerpc/kexec/core: use big-endian types for crash variables
+
+From: Sourabh Jain <sourabhjain@linux.ibm.com>
+
+[ Upstream commit 20197b967a6a29dab81495f25a988515bda84cfe ]
+
+Use explicit word-sized big-endian types for kexec and crash related
+variables. This makes the endianness unambiguous and avoids type
+mismatches that trigger sparse warnings.
+
+The change addresses sparse warnings like below (seen on both 32-bit
+and 64-bit builds):
+
+CHECK ../arch/powerpc/kexec/core.c
+sparse: expected unsigned int static [addressable] [toplevel] [usertype] crashk_base
+sparse: got restricted __be32 [usertype]
+sparse: warning: incorrect type in assignment (different base types)
+sparse: expected unsigned int static [addressable] [toplevel] [usertype] crashk_size
+sparse: got restricted __be32 [usertype]
+sparse: warning: incorrect type in assignment (different base types)
+sparse: expected unsigned long long static [addressable] [toplevel] mem_limit
+sparse: got restricted __be32 [usertype]
+sparse: warning: incorrect type in assignment (different base types)
+sparse: expected unsigned int static [addressable] [toplevel] [usertype] kernel_end
+sparse: got restricted __be32 [usertype]
+
+No functional change intended.
+
+Fixes: ea961a828fe7 ("powerpc: Fix endian issues in kexec and crash dump code")
+Reported-by: kernel test robot <lkp@intel.com>
+Closes: https://lore.kernel.org/oe-kbuild-all/202512221405.VHPKPjnp-lkp@intel.com/
+Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
+Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
+Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
+Link: https://patch.msgid.link/20251224151257.28672-1-sourabhjain@linux.ibm.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/kexec/core.c | 17 +++++++++--------
+ 1 file changed, 9 insertions(+), 8 deletions(-)
+
+diff --git a/arch/powerpc/kexec/core.c b/arch/powerpc/kexec/core.c
+index 50e7cf4b992b1..31797f2145ec5 100644
+--- a/arch/powerpc/kexec/core.c
++++ b/arch/powerpc/kexec/core.c
+@@ -23,6 +23,7 @@
+ #include <asm/firmware.h>
+
+ #define cpu_to_be_ulong __PASTE(cpu_to_be, BITS_PER_LONG)
++#define __be_word __PASTE(__be, BITS_PER_LONG)
+
+ #ifdef CONFIG_CRASH_DUMP
+ void machine_crash_shutdown(struct pt_regs *regs)
+@@ -158,25 +159,25 @@ int __init overlaps_crashkernel(unsigned long start, unsigned long size)
+ }
+
+ /* Values we need to export to the second kernel via the device tree. */
+-static phys_addr_t crashk_base;
+-static phys_addr_t crashk_size;
+-static unsigned long long mem_limit;
++static __be_word crashk_base;
++static __be_word crashk_size;
++static __be_word mem_limit;
+
+ static struct property crashk_base_prop = {
+ .name = "linux,crashkernel-base",
+- .length = sizeof(phys_addr_t),
++ .length = sizeof(__be_word),
+ .value = &crashk_base
+ };
+
+ static struct property crashk_size_prop = {
+ .name = "linux,crashkernel-size",
+- .length = sizeof(phys_addr_t),
++ .length = sizeof(__be_word),
+ .value = &crashk_size,
+ };
+
+ static struct property memory_limit_prop = {
+ .name = "linux,memory-limit",
+- .length = sizeof(unsigned long long),
++ .length = sizeof(__be_word),
+ .value = &mem_limit,
+ };
+
+@@ -205,11 +206,11 @@ static void __init export_crashk_values(struct device_node *node)
+ }
+ #endif /* CONFIG_CRASH_RESERVE */
+
+-static phys_addr_t kernel_end;
++static __be_word kernel_end;
+
+ static struct property kernel_end_prop = {
+ .name = "linux,kernel-end",
+- .length = sizeof(phys_addr_t),
++ .length = sizeof(__be_word),
+ .value = &kernel_end,
+ };
+
+--
+2.51.0
+
--- /dev/null
+From 1567d0606d09c190f69731d494c55fd29d10d429 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 3 Feb 2026 08:30:41 +0100
+Subject: powerpc/uaccess: Fix inline assembly for clang build on PPC32
+
+From: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
+
+[ Upstream commit 0ee95a1d458630272d0415d0ffa9424fcb606c90 ]
+
+Test robot reports the following error with clang-16.0.6:
+
+ In file included from kernel/rseq.c:75:
+ include/linux/rseq_entry.h:141:3: error: invalid operand for instruction
+ unsafe_get_user(offset, &ucs->post_commit_offset, efault);
+ ^
+ include/linux/uaccess.h:608:2: note: expanded from macro 'unsafe_get_user'
+ arch_unsafe_get_user(x, ptr, local_label); \
+ ^
+ arch/powerpc/include/asm/uaccess.h:518:2: note: expanded from macro 'arch_unsafe_get_user'
+ __get_user_size_goto(__gu_val, __gu_addr, sizeof(*(p)), e); \
+ ^
+ arch/powerpc/include/asm/uaccess.h:284:2: note: expanded from macro '__get_user_size_goto'
+ __get_user_size_allowed(x, ptr, size, __gus_retval); \
+ ^
+ arch/powerpc/include/asm/uaccess.h:275:10: note: expanded from macro '__get_user_size_allowed'
+ case 8: __get_user_asm2(x, (u64 __user *)ptr, retval); break; \
+ ^
+ arch/powerpc/include/asm/uaccess.h:258:4: note: expanded from macro '__get_user_asm2'
+ " li %1+1,0\n" \
+ ^
+ <inline asm>:7:5: note: instantiated into assembly here
+ li 31+1,0
+ ^
+ 1 error generated.
+
+On PPC32, for 64 bits vars a pair of registers is used. Usually the
+lower register in the pair is the high part and the higher register is
+the low part. GCC uses r3/r4 ... r11/r12 ... r14/r15 ... r30/r31
+
+In older kernel code inline assembly was using %1 and %1+1 to represent
+64 bits values. However here it looks like clang uses r31 as high part,
+allthough r32 doesn't exist hence the error.
+
+Allthoug %1+1 should work, most places now use %L1 instead of %1+1, so
+let's do the same here.
+
+With that change, the build doesn't fail anymore and a disassembly shows
+clang uses r17/r18 and r31/r14 pair when GCC would have used r16/r17 and
+r30/r31:
+
+ Disassembly of section .fixup:
+
+ 00000000 <.fixup>:
+ 0: 38 a0 ff f2 li r5,-14
+ 4: 3a 20 00 00 li r17,0
+ 8: 3a 40 00 00 li r18,0
+ c: 48 00 00 00 b c <.fixup+0xc>
+ c: R_PPC_REL24 .text+0xbc
+ 10: 38 a0 ff f2 li r5,-14
+ 14: 3b e0 00 00 li r31,0
+ 18: 39 c0 00 00 li r14,0
+ 1c: 48 00 00 00 b 1c <.fixup+0x1c>
+ 1c: R_PPC_REL24 .text+0x144
+
+Reported-by: kernel test robot <lkp@intel.com>
+Closes: https://lore.kernel.org/oe-kbuild-all/202602021825.otcItxGi-lkp@intel.com/
+Fixes: c20beffeec3c ("powerpc/uaccess: Use flexible addressing with __put_user()/__get_user()")
+Signed-off-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
+Acked-by: Nathan Chancellor <nathan@kernel.org>
+Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
+Link: https://patch.msgid.link/8ca3a657a650e497a96bfe7acde2f637dadab344.1770103646.git.chleroy@kernel.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/include/asm/uaccess.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h
+index 3987a5c33558b..929f7050c73a6 100644
+--- a/arch/powerpc/include/asm/uaccess.h
++++ b/arch/powerpc/include/asm/uaccess.h
+@@ -253,7 +253,7 @@ __gus_failed: \
+ ".section .fixup,\"ax\"\n" \
+ "4: li %0,%3\n" \
+ " li %1,0\n" \
+- " li %1+1,0\n" \
++ " li %L1,0\n" \
+ " b 3b\n" \
+ ".previous\n" \
+ EX_TABLE(1b, 4b) \
+--
+2.51.0
+
--- /dev/null
+From 3a54c89565a7e451f44accb3ed1172aa49807e88 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 6 Feb 2026 03:30:33 +0000
+Subject: remoteproc: mediatek: Unprepare SCP clock during system suspend
+
+From: Tzung-Bi Shih <tzungbi@kernel.org>
+
+[ Upstream commit 35c3f72a2d55dbf52f28f4ecae51c76be1acf545 ]
+
+Prior to commit d935187cfb27 ("remoteproc: mediatek: Break lock
+dependency to prepare_lock"), `scp->clk` was prepared and enabled only
+when it needs to communicate with the SCP. The commit d935187cfb27
+moved the prepare operation to remoteproc's prepare(), keeping the clock
+prepared as long as the SCP is running.
+
+The power consumption due to the prolonged clock preparation can be
+negligible when the system is running, as SCP is designed to be a very
+power efficient processor.
+
+However, the clock remains prepared even when the system enters system
+suspend. This prevents the underlying clock controller (and potentially
+the parent PLLs) from shutting down, which increases power consumption
+and may block the system from entering deep sleep states.
+
+Add suspend and resume callbacks. Unprepare the clock in suspend() if
+it was active and re-prepare it in resume() to ensure the clock is
+properly disabled during system suspend, while maintaining the "always
+prepared" semantics while the system is active. The driver doesn't
+implement .attach() callback, hence it only checks for RPROC_RUNNING.
+
+Fixes: d935187cfb27 ("remoteproc: mediatek: Break lock dependency to prepare_lock")
+Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
+Link: https://lore.kernel.org/r/20260206033034.3031781-1-tzungbi@kernel.org
+Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/remoteproc/mtk_scp.c | 39 ++++++++++++++++++++++++++++++++++++
+ 1 file changed, 39 insertions(+)
+
+diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
+index ae20d2221c8e0..fcd2665f7abbc 100644
+--- a/drivers/remoteproc/mtk_scp.c
++++ b/drivers/remoteproc/mtk_scp.c
+@@ -1544,12 +1544,51 @@ static const struct of_device_id mtk_scp_of_match[] = {
+ };
+ MODULE_DEVICE_TABLE(of, mtk_scp_of_match);
+
++static int __maybe_unused scp_suspend(struct device *dev)
++{
++ struct mtk_scp *scp = dev_get_drvdata(dev);
++ struct rproc *rproc = scp->rproc;
++
++ /*
++ * Only unprepare if the SCP is running and holding the clock.
++ *
++ * Note: `scp_ops` doesn't implement .attach() callback, hence
++ * `rproc->state` can never be RPROC_ATTACHED. Otherwise, it
++ * should also be checked here.
++ */
++ if (rproc->state == RPROC_RUNNING)
++ clk_unprepare(scp->clk);
++ return 0;
++}
++
++static int __maybe_unused scp_resume(struct device *dev)
++{
++ struct mtk_scp *scp = dev_get_drvdata(dev);
++ struct rproc *rproc = scp->rproc;
++
++ /*
++ * Only prepare if the SCP was running and holding the clock.
++ *
++ * Note: `scp_ops` doesn't implement .attach() callback, hence
++ * `rproc->state` can never be RPROC_ATTACHED. Otherwise, it
++ * should also be checked here.
++ */
++ if (rproc->state == RPROC_RUNNING)
++ return clk_prepare(scp->clk);
++ return 0;
++}
++
++static const struct dev_pm_ops scp_pm_ops = {
++ SET_SYSTEM_SLEEP_PM_OPS(scp_suspend, scp_resume)
++};
++
+ static struct platform_driver mtk_scp_driver = {
+ .probe = scp_probe,
+ .remove_new = scp_remove,
+ .driver = {
+ .name = "mtk-scp",
+ .of_match_table = mtk_scp_of_match,
++ .pm = &scp_pm_ops,
+ },
+ };
+
+--
+2.51.0
+
--- /dev/null
+From 256247dc614c79efb1629f1affb5ea141647cace Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 20 Feb 2026 15:11:48 -0600
+Subject: remoteproc: sysmon: Correct subsys_name_len type in QMI request
+
+From: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
+
+[ Upstream commit da994db94e60f9a9411108ddf4d1836147ad4c9c ]
+
+The QMI message encoder has up until recently read a single byte (as
+elem_size == 1), but with the introduction of big endian support it's
+become apparent that this field is expected to be a full u32 -
+regardless of the size of the length in the encoded message (which is
+what elem_size specifies).
+
+The result is that the encoder now reads past the length byte and
+rejects the unreasonably large length formed when including the
+following 3 bytes from the subsys_name array.
+
+Fix this by changing to the expected type.
+
+Fixes: 1fb82ee806d1 ("remoteproc: qcom: Introduce sysmon")
+Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
+Reviewed-by: Chris Lew <christopher.lew@oss.qualcomm.com>
+Link: https://lore.kernel.org/r/20260220-qmi-encode-invalid-length-v2-1-5674be35ab29@oss.qualcomm.com
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/remoteproc/qcom_sysmon.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/remoteproc/qcom_sysmon.c b/drivers/remoteproc/qcom_sysmon.c
+index c24e4a8828738..db33a41051a3e 100644
+--- a/drivers/remoteproc/qcom_sysmon.c
++++ b/drivers/remoteproc/qcom_sysmon.c
+@@ -203,7 +203,7 @@ static const struct qmi_elem_info ssctl_shutdown_resp_ei[] = {
+ };
+
+ struct ssctl_subsys_event_req {
+- u8 subsys_name_len;
++ u32 subsys_name_len;
+ char subsys_name[SSCTL_SUBSYS_NAME_LENGTH];
+ u32 event;
+ u8 evt_driven_valid;
+--
+2.51.0
+
--- /dev/null
+From 019d19b772b9c550b89dd00d99bb858bdc817c43 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 12 Feb 2026 12:30:26 +0530
+Subject: scsi: mpi3mr: Add NULL checks when resetting request and reply queues
+
+From: Ranjan Kumar <ranjan.kumar@broadcom.com>
+
+[ Upstream commit fa96392ebebc8fade2b878acb14cce0f71016503 ]
+
+The driver encountered a crash during resource cleanup when the reply and
+request queues were NULL due to freed memory. This issue occurred when the
+creation of reply or request queues failed, and the driver freed the memory
+first, but attempted to mem set the content of the freed memory, leading to
+a system crash.
+
+Add NULL pointer checks for reply and request queues before accessing the
+reply/request memory during cleanup
+
+Signed-off-by: Ranjan Kumar <ranjan.kumar@broadcom.com>
+Link: https://patch.msgid.link/20260212070026.30263-1-ranjan.kumar@broadcom.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/mpi3mr/mpi3mr_fw.c | 34 ++++++++++++++++++---------------
+ 1 file changed, 19 insertions(+), 15 deletions(-)
+
+diff --git a/drivers/scsi/mpi3mr/mpi3mr_fw.c b/drivers/scsi/mpi3mr/mpi3mr_fw.c
+index 4198830bf10b7..3a057a0f0d809 100644
+--- a/drivers/scsi/mpi3mr/mpi3mr_fw.c
++++ b/drivers/scsi/mpi3mr/mpi3mr_fw.c
+@@ -4677,21 +4677,25 @@ void mpi3mr_memset_buffers(struct mpi3mr_ioc *mrioc)
+ }
+
+ for (i = 0; i < mrioc->num_queues; i++) {
+- mrioc->op_reply_qinfo[i].qid = 0;
+- mrioc->op_reply_qinfo[i].ci = 0;
+- mrioc->op_reply_qinfo[i].num_replies = 0;
+- mrioc->op_reply_qinfo[i].ephase = 0;
+- atomic_set(&mrioc->op_reply_qinfo[i].pend_ios, 0);
+- atomic_set(&mrioc->op_reply_qinfo[i].in_use, 0);
+- mpi3mr_memset_op_reply_q_buffers(mrioc, i);
+-
+- mrioc->req_qinfo[i].ci = 0;
+- mrioc->req_qinfo[i].pi = 0;
+- mrioc->req_qinfo[i].num_requests = 0;
+- mrioc->req_qinfo[i].qid = 0;
+- mrioc->req_qinfo[i].reply_qid = 0;
+- spin_lock_init(&mrioc->req_qinfo[i].q_lock);
+- mpi3mr_memset_op_req_q_buffers(mrioc, i);
++ if (mrioc->op_reply_qinfo) {
++ mrioc->op_reply_qinfo[i].qid = 0;
++ mrioc->op_reply_qinfo[i].ci = 0;
++ mrioc->op_reply_qinfo[i].num_replies = 0;
++ mrioc->op_reply_qinfo[i].ephase = 0;
++ atomic_set(&mrioc->op_reply_qinfo[i].pend_ios, 0);
++ atomic_set(&mrioc->op_reply_qinfo[i].in_use, 0);
++ mpi3mr_memset_op_reply_q_buffers(mrioc, i);
++ }
++
++ if (mrioc->req_qinfo) {
++ mrioc->req_qinfo[i].ci = 0;
++ mrioc->req_qinfo[i].pi = 0;
++ mrioc->req_qinfo[i].num_requests = 0;
++ mrioc->req_qinfo[i].qid = 0;
++ mrioc->req_qinfo[i].reply_qid = 0;
++ spin_lock_init(&mrioc->req_qinfo[i].q_lock);
++ mpi3mr_memset_op_req_q_buffers(mrioc, i);
++ }
+ }
+
+ atomic_set(&mrioc->pend_large_data_sz, 0);
+--
+2.51.0
+
--- /dev/null
+From faa7626adfe2e7b4871649c882a1b771b282b036 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 10 Feb 2026 20:18:50 +0100
+Subject: scsi: ses: Fix devices attaching to different hosts
+
+From: Tomas Henzl <thenzl@redhat.com>
+
+[ Upstream commit 70ca8caa96ce473647054f5c7b9dab5423902402 ]
+
+On a multipath SAS system some devices don't end up with correct symlinks
+from the SCSI device to its enclosure. Some devices even have enclosure
+links pointing to enclosures attached to different SCSI hosts.
+
+ses_match_to_enclosure() calls enclosure_for_each_device() which iterates
+over all enclosures on the system, not just enclosures attached to the
+current SCSI host.
+
+Replace the iteration with a direct call to ses_enclosure_find_by_addr().
+
+Reviewed-by: David Jeffery <djeffery@redhat.com>
+Signed-off-by: Tomas Henzl <thenzl@redhat.com>
+Link: https://patch.msgid.link/20260210191850.36784-1-thenzl@redhat.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/ses.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/scsi/ses.c b/drivers/scsi/ses.c
+index 2c61624cb4b03..50e744e891295 100644
+--- a/drivers/scsi/ses.c
++++ b/drivers/scsi/ses.c
+@@ -529,9 +529,8 @@ struct efd {
+ };
+
+ static int ses_enclosure_find_by_addr(struct enclosure_device *edev,
+- void *data)
++ struct efd *efd)
+ {
+- struct efd *efd = data;
+ int i;
+ struct ses_component *scomp;
+
+@@ -684,7 +683,7 @@ static void ses_match_to_enclosure(struct enclosure_device *edev,
+ if (efd.addr) {
+ efd.dev = &sdev->sdev_gendev;
+
+- enclosure_for_each_device(ses_enclosure_find_by_addr, &efd);
++ ses_enclosure_find_by_addr(edev, &efd);
+ }
+ }
+
+--
+2.51.0
+
--- /dev/null
+From 1c56e78cfc3e17abab7427b43ecb35e8b4d89723 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 29 Jan 2026 15:30:39 +0100
+Subject: scsi: storvsc: Fix scheduling while atomic on PREEMPT_RT
+
+From: Jan Kiszka <jan.kiszka@siemens.com>
+
+[ Upstream commit 57297736c08233987e5d29ce6584c6ca2a831b12 ]
+
+This resolves the follow splat and lock-up when running with PREEMPT_RT
+enabled on Hyper-V:
+
+[ 415.140818] BUG: scheduling while atomic: stress-ng-iomix/1048/0x00000002
+[ 415.140822] INFO: lockdep is turned off.
+[ 415.140823] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec ghash_clmulni_intel aesni_intel rapl binfmt_misc nls_ascii nls_cp437 vfat fat snd_pcm hyperv_drm snd_timer drm_client_lib drm_shmem_helper snd sg soundcore drm_kms_helper pcspkr hv_balloon hv_utils evdev joydev drm configfs efi_pstore nfnetlink vsock_loopback vmw_vsock_virtio_transport_common hv_sock vmw_vsock_vmci_transport vsock vmw_vmci efivarfs autofs4 ext4 crc16 mbcache jbd2 sr_mod sd_mod cdrom hv_storvsc serio_raw hid_generic scsi_transport_fc hid_hyperv scsi_mod hid hv_netvsc hyperv_keyboard scsi_common
+[ 415.140846] Preemption disabled at:
+[ 415.140847] [<ffffffffc0656171>] storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc]
+[ 415.140854] CPU: 8 UID: 0 PID: 1048 Comm: stress-ng-iomix Not tainted 6.19.0-rc7 #30 PREEMPT_{RT,(full)}
+[ 415.140856] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/04/2024
+[ 415.140857] Call Trace:
+[ 415.140861] <TASK>
+[ 415.140861] ? storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc]
+[ 415.140863] dump_stack_lvl+0x91/0xb0
+[ 415.140870] __schedule_bug+0x9c/0xc0
+[ 415.140875] __schedule+0xdf6/0x1300
+[ 415.140877] ? rtlock_slowlock_locked+0x56c/0x1980
+[ 415.140879] ? rcu_is_watching+0x12/0x60
+[ 415.140883] schedule_rtlock+0x21/0x40
+[ 415.140885] rtlock_slowlock_locked+0x502/0x1980
+[ 415.140891] rt_spin_lock+0x89/0x1e0
+[ 415.140893] hv_ringbuffer_write+0x87/0x2a0
+[ 415.140899] vmbus_sendpacket_mpb_desc+0xb6/0xe0
+[ 415.140900] ? rcu_is_watching+0x12/0x60
+[ 415.140902] storvsc_queuecommand+0x669/0xbe0 [hv_storvsc]
+[ 415.140904] ? HARDIRQ_verbose+0x10/0x10
+[ 415.140908] ? __rq_qos_issue+0x28/0x40
+[ 415.140911] scsi_queue_rq+0x760/0xd80 [scsi_mod]
+[ 415.140926] __blk_mq_issue_directly+0x4a/0xc0
+[ 415.140928] blk_mq_issue_direct+0x87/0x2b0
+[ 415.140931] blk_mq_dispatch_queue_requests+0x120/0x440
+[ 415.140933] blk_mq_flush_plug_list+0x7a/0x1a0
+[ 415.140935] __blk_flush_plug+0xf4/0x150
+[ 415.140940] __submit_bio+0x2b2/0x5c0
+[ 415.140944] ? submit_bio_noacct_nocheck+0x272/0x360
+[ 415.140946] submit_bio_noacct_nocheck+0x272/0x360
+[ 415.140951] ext4_read_bh_lock+0x3e/0x60 [ext4]
+[ 415.140995] ext4_block_write_begin+0x396/0x650 [ext4]
+[ 415.141018] ? __pfx_ext4_da_get_block_prep+0x10/0x10 [ext4]
+[ 415.141038] ext4_da_write_begin+0x1c4/0x350 [ext4]
+[ 415.141060] generic_perform_write+0x14e/0x2c0
+[ 415.141065] ext4_buffered_write_iter+0x6b/0x120 [ext4]
+[ 415.141083] vfs_write+0x2ca/0x570
+[ 415.141087] ksys_write+0x76/0xf0
+[ 415.141089] do_syscall_64+0x99/0x1490
+[ 415.141093] ? rcu_is_watching+0x12/0x60
+[ 415.141095] ? finish_task_switch.isra.0+0xdf/0x3d0
+[ 415.141097] ? rcu_is_watching+0x12/0x60
+[ 415.141098] ? lock_release+0x1f0/0x2a0
+[ 415.141100] ? rcu_is_watching+0x12/0x60
+[ 415.141101] ? finish_task_switch.isra.0+0xe4/0x3d0
+[ 415.141103] ? rcu_is_watching+0x12/0x60
+[ 415.141104] ? __schedule+0xb34/0x1300
+[ 415.141106] ? hrtimer_try_to_cancel+0x1d/0x170
+[ 415.141109] ? do_nanosleep+0x8b/0x160
+[ 415.141111] ? hrtimer_nanosleep+0x89/0x100
+[ 415.141114] ? __pfx_hrtimer_wakeup+0x10/0x10
+[ 415.141116] ? xfd_validate_state+0x26/0x90
+[ 415.141118] ? rcu_is_watching+0x12/0x60
+[ 415.141120] ? do_syscall_64+0x1e0/0x1490
+[ 415.141121] ? do_syscall_64+0x1e0/0x1490
+[ 415.141123] ? rcu_is_watching+0x12/0x60
+[ 415.141124] ? do_syscall_64+0x1e0/0x1490
+[ 415.141125] ? do_syscall_64+0x1e0/0x1490
+[ 415.141127] ? irqentry_exit+0x140/0x7e0
+[ 415.141129] entry_SYSCALL_64_after_hwframe+0x76/0x7e
+
+get_cpu() disables preemption while the spinlock hv_ringbuffer_write is
+using is converted to an rt-mutex under PREEMPT_RT.
+
+Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
+Tested-by: Florian Bezdeka <florian.bezdeka@siemens.com>
+Reviewed-by: Michael Kelley <mhklinux@outlook.com>
+Tested-by: Michael Kelley <mhklinux@outlook.com>
+Link: https://patch.msgid.link/0c7fb5cd-fb21-4760-8593-e04bade84744@siemens.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/storvsc_drv.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
+index 9dcad02ce4895..106bccaac4276 100644
+--- a/drivers/scsi/storvsc_drv.c
++++ b/drivers/scsi/storvsc_drv.c
+@@ -1861,8 +1861,9 @@ static int storvsc_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *scmnd)
+ cmd_request->payload_sz = payload_sz;
+
+ /* Invokes the vsc to start an IO */
+- ret = storvsc_do_io(dev, cmd_request, get_cpu());
+- put_cpu();
++ migrate_disable();
++ ret = storvsc_do_io(dev, cmd_request, smp_processor_id());
++ migrate_enable();
+
+ if (ret)
+ scsi_dma_unmap(scmnd);
+--
+2.51.0
+
--- /dev/null
+From 83ac28ad4912c576733e3dfc457b3d2e39dacffa Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 23 Feb 2026 14:56:09 +0800
+Subject: scsi: ufs: core: Fix possible NULL pointer dereference in
+ ufshcd_add_command_trace()
+
+From: Peter Wang <peter.wang@mediatek.com>
+
+[ Upstream commit 30df81f2228d65bddf492db3929d9fcaffd38fc5 ]
+
+The kernel log indicates a crash in ufshcd_add_command_trace, due to a NULL
+pointer dereference when accessing hwq->id. This can happen if
+ufshcd_mcq_req_to_hwq() returns NULL.
+
+This patch adds a NULL check for hwq before accessing its id field to
+prevent a kernel crash.
+
+Kernel log excerpt:
+[<ffffffd5d192dc4c>] notify_die+0x4c/0x8c
+[<ffffffd5d1814e58>] __die+0x60/0xb0
+[<ffffffd5d1814d64>] die+0x4c/0xe0
+[<ffffffd5d181575c>] die_kernel_fault+0x74/0x88
+[<ffffffd5d1864db4>] __do_kernel_fault+0x314/0x318
+[<ffffffd5d2a3cdf8>] do_page_fault+0xa4/0x5f8
+[<ffffffd5d2a3cd34>] do_translation_fault+0x34/0x54
+[<ffffffd5d1864524>] do_mem_abort+0x50/0xa8
+[<ffffffd5d2a297dc>] el1_abort+0x3c/0x64
+[<ffffffd5d2a29718>] el1h_64_sync_handler+0x44/0xcc
+[<ffffffd5d181133c>] el1h_64_sync+0x80/0x88
+[<ffffffd5d255c1dc>] ufshcd_add_command_trace+0x23c/0x320
+[<ffffffd5d255bad8>] ufshcd_compl_one_cqe+0xa4/0x404
+[<ffffffd5d2572968>] ufshcd_mcq_poll_cqe_lock+0xac/0x104
+[<ffffffd5d11c7460>] ufs_mtk_mcq_intr+0x54/0x74 [ufs_mediatek_mod]
+[<ffffffd5d19ab92c>] __handle_irq_event_percpu+0xc8/0x348
+[<ffffffd5d19abca8>] handle_irq_event+0x3c/0xa8
+[<ffffffd5d19b1f0c>] handle_fasteoi_irq+0xf8/0x294
+[<ffffffd5d19aa778>] generic_handle_domain_irq+0x54/0x80
+[<ffffffd5d18102bc>] gic_handle_irq+0x1d4/0x330
+[<ffffffd5d1838210>] call_on_irq_stack+0x44/0x68
+[<ffffffd5d183af30>] do_interrupt_handler+0x78/0xd8
+[<ffffffd5d2a29c00>] el1_interrupt+0x48/0xa8
+[<ffffffd5d2a29ba8>] el1h_64_irq_handler+0x14/0x24
+[<ffffffd5d18113c4>] el1h_64_irq+0x80/0x88
+[<ffffffd5d2527fb4>] arch_local_irq_enable+0x4/0x1c
+[<ffffffd5d25282e4>] cpuidle_enter+0x34/0x54
+[<ffffffd5d195a678>] do_idle+0x1dc/0x2f8
+[<ffffffd5d195a7c4>] cpu_startup_entry+0x30/0x3c
+[<ffffffd5d18155c4>] secondary_start_kernel+0x134/0x1ac
+[<ffffffd5d18640bc>] __secondary_switched+0xc4/0xcc
+
+Signed-off-by: Peter Wang <peter.wang@mediatek.com>
+Reviewed-by: Bart Van Assche <bvanassche@acm.org>
+Link: https://patch.msgid.link/20260223065657.2432447-1-peter.wang@mediatek.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/ufs/core/ufshcd.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
+index ad5866149e240..726bf4247f1fe 100644
+--- a/drivers/ufs/core/ufshcd.c
++++ b/drivers/ufs/core/ufshcd.c
+@@ -483,8 +483,8 @@ static void ufshcd_add_command_trace(struct ufs_hba *hba, unsigned int tag,
+
+ if (hba->mcq_enabled) {
+ struct ufs_hw_queue *hwq = ufshcd_mcq_req_to_hwq(hba, rq);
+-
+- hwq_id = hwq->id;
++ if (hwq)
++ hwq_id = hwq->id;
+ } else {
+ doorbell = ufshcd_readl(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL);
+ }
+--
+2.51.0
+
--- /dev/null
+From 6168eaebc4fb54084178972e473479ba636cc4ab Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 24 Feb 2026 14:32:28 +0800
+Subject: scsi: ufs: core: Fix shift out of bounds when MAXQ=32
+
+From: wangshuaiwei <wangshuaiwei1@xiaomi.com>
+
+[ Upstream commit 2f38fd99c0004676d835ae96ac4f3b54edc02c82 ]
+
+According to JESD223F, the maximum number of queues (MAXQ) is 32. When MCQ
+is enabled and ESI is disabled, nr_hw_queues=32 causes a shift overflow
+problem.
+
+Fix this by using 64-bit intermediate values to handle the nr_hw_queues=32
+case safely.
+
+Signed-off-by: wangshuaiwei <wangshuaiwei1@xiaomi.com>
+Reviewed-by: Bart Van Assche <bvanassche@acm.org>
+Link: https://patch.msgid.link/20260224063228.50112-1-wangshuaiwei1@xiaomi.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/ufs/core/ufshcd.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
+index 726bf4247f1fe..ea6e7c18e35cd 100644
+--- a/drivers/ufs/core/ufshcd.c
++++ b/drivers/ufs/core/ufshcd.c
+@@ -6974,7 +6974,7 @@ static irqreturn_t ufshcd_handle_mcq_cq_events(struct ufs_hba *hba)
+
+ ret = ufshcd_vops_get_outstanding_cqs(hba, &outstanding_cqs);
+ if (ret)
+- outstanding_cqs = (1U << hba->nr_hw_queues) - 1;
++ outstanding_cqs = (1ULL << hba->nr_hw_queues) - 1;
+
+ /* Exclude the poll queues */
+ nr_queues = hba->nr_hw_queues - hba->nr_queues[HCTX_TYPE_POLL];
+--
+2.51.0
+
--- /dev/null
+scsi-storvsc-fix-scheduling-while-atomic-on-preempt_.patch
+acpi-pm-save-nvs-memory-on-lenovo-g70-35.patch
+scsi-mpi3mr-add-null-checks-when-resetting-request-a.patch
+alsa-hda-realtek-fix-speaker-pop-on-star-labs-starfi.patch
+unshare-fix-unshare_fs-handling.patch
+wifi-mac80211-set-default-wmm-parameters-on-all-link.patch
+acpi-osi-add-dmi-quirk-for-acer-aspire-one-d255.patch
+scsi-ses-fix-devices-attaching-to-different-hosts.patch
+asoc-amd-yc-add-asus-expertbook-bm1503cda-to-quirk-t.patch
+asoc-cs42l43-report-insert-for-exotic-peripherals.patch
+scsi-ufs-core-fix-possible-null-pointer-dereference-.patch
+scsi-ufs-core-fix-shift-out-of-bounds-when-maxq-32.patch
+alsa-usb-audio-avoid-implicit-feedback-mode-on-diyin.patch
+drm-amdgpu-vcn5-add-smu-dpm-interface-type.patch
+alsa-usb-audio-check-max-frame-size-for-implicit-fee.patch
+powerpc-uaccess-fix-inline-assembly-for-clang-build-.patch
+kexec-consolidate-machine_kexec_mask_interrupts-impl.patch
+kexec-include-kernel-end-even-without-crashkernel.patch
+powerpc-kexec-core-use-big-endian-types-for-crash-va.patch
+powerpc-crash-adjust-the-elfcorehdr-size.patch
+remoteproc-sysmon-correct-subsys_name_len-type-in-qm.patch
+remoteproc-mediatek-unprepare-scp-clock-during-syste.patch
+powerpc-83xx-km83xx-fix-keymile-vendor-prefix.patch
+smb-server-fix-another-refcount-leak-in-smb2_open.patch
--- /dev/null
+From 822d5cd0fbd35d6a669a81e1b3438a1c4cd2800c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 26 Feb 2026 21:54:21 -0800
+Subject: smb/server: Fix another refcount leak in smb2_open()
+
+From: Guenter Roeck <linux@roeck-us.net>
+
+[ Upstream commit c15e7c62feb3751cbdd458555819df1d70374890 ]
+
+If ksmbd_override_fsids() fails, we jump to err_out2. At that point, fp is
+NULL because it hasn't been assigned dh_info.fp yet, so ksmbd_fd_put(work,
+fp) will not be called. However, dh_info.fp was already inserted into the
+session file table by ksmbd_reopen_durable_fd(), so it will leak in the
+session file table until the session is closed.
+
+Move fp = dh_info.fp; ahead of the ksmbd_override_fsids() check to fix the
+problem.
+
+Found by an experimental AI code review agent at Google.
+
+Fixes: c8efcc786146a ("ksmbd: add support for durable handles v1/v2")
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Reviewed-by: ChenXiaoSong <chenxiaosong@kylinos.cn>
+Acked-by: Namjae Jeon <linkinjeon@kernel.org>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/smb/server/smb2pdu.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c
+index 0d7ba57c1ca64..d1c2e8779ee18 100644
+--- a/fs/smb/server/smb2pdu.c
++++ b/fs/smb/server/smb2pdu.c
+@@ -3012,13 +3012,14 @@ int smb2_open(struct ksmbd_work *work)
+ goto err_out2;
+ }
+
++ fp = dh_info.fp;
++
+ if (ksmbd_override_fsids(work)) {
+ rc = -ENOMEM;
+ ksmbd_put_durable_fd(dh_info.fp);
+ goto err_out2;
+ }
+
+- fp = dh_info.fp;
+ file_info = FILE_OPENED;
+
+ rc = ksmbd_vfs_getattr(&fp->filp->f_path, &stat);
+--
+2.51.0
+
--- /dev/null
+From 3dacf0f36a328e8dd19c2d5caa2c4a0afb50eaa4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 7 Feb 2026 08:25:24 +0000
+Subject: unshare: fix unshare_fs() handling
+
+From: Al Viro <viro@zeniv.linux.org.uk>
+
+[ Upstream commit 6c4b2243cb6c0755159bd567130d5e12e7b10d9f ]
+
+There's an unpleasant corner case in unshare(2), when we have a
+CLONE_NEWNS in flags and current->fs hadn't been shared at all; in that
+case copy_mnt_ns() gets passed current->fs instead of a private copy,
+which causes interesting warts in proof of correctness]
+
+> I guess if private means fs->users == 1, the condition could still be true.
+
+Unfortunately, it's worse than just a convoluted proof of correctness.
+Consider the case when we have CLONE_NEWCGROUP in addition to CLONE_NEWNS
+(and current->fs->users == 1).
+
+We pass current->fs to copy_mnt_ns(), all right. Suppose it succeeds and
+flips current->fs->{pwd,root} to corresponding locations in the new namespace.
+Now we proceed to copy_cgroup_ns(), which fails (e.g. with -ENOMEM).
+We call put_mnt_ns() on the namespace created by copy_mnt_ns(), it's
+destroyed and its mount tree is dissolved, but... current->fs->root and
+current->fs->pwd are both left pointing to now detached mounts.
+
+They are pinning those, so it's not a UAF, but it leaves the calling
+process with unshare(2) failing with -ENOMEM _and_ leaving it with
+pwd and root on detached isolated mounts. The last part is clearly a bug.
+
+There is other fun related to that mess (races with pivot_root(), including
+the one between pivot_root() and fork(), of all things), but this one
+is easy to isolate and fix - treat CLONE_NEWNS as "allocate a new
+fs_struct even if it hadn't been shared in the first place". Sure, we could
+go for something like "if both CLONE_NEWNS *and* one of the things that might
+end up failing after copy_mnt_ns() call in create_new_namespaces() are set,
+force allocation of new fs_struct", but let's keep it simple - the cost
+of copy_fs_struct() is trivial.
+
+Another benefit is that copy_mnt_ns() with CLONE_NEWNS *always* gets
+a freshly allocated fs_struct, yet to be attached to anything. That
+seriously simplifies the analysis...
+
+FWIW, that bug had been there since the introduction of unshare(2) ;-/
+
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Link: https://patch.msgid.link/20260207082524.GE3183987@ZenIV
+Tested-by: Waiman Long <longman@redhat.com>
+Signed-off-by: Christian Brauner <brauner@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/fork.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/kernel/fork.c b/kernel/fork.c
+index e5ec098a6f61e..55086df4d24cb 100644
+--- a/kernel/fork.c
++++ b/kernel/fork.c
+@@ -3248,7 +3248,7 @@ static int unshare_fs(unsigned long unshare_flags, struct fs_struct **new_fsp)
+ return 0;
+
+ /* don't need lock here; in the worst case we'll do useless copy */
+- if (fs->users == 1)
++ if (!(unshare_flags & CLONE_NEWNS) && fs->users == 1)
+ return 0;
+
+ *new_fsp = copy_fs_struct(fs);
+--
+2.51.0
+
--- /dev/null
+From 434fc52c7023e8ee92f1e52f9cf9f4790e48e040 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 5 Feb 2026 15:12:16 +0530
+Subject: wifi: mac80211: set default WMM parameters on all links
+
+From: Ramanathan Choodamani <quic_rchoodam@quicinc.com>
+
+[ Upstream commit 2259d14499d16b115ef8d5d2ddc867e2be7cb5b5 ]
+
+Currently, mac80211 only initializes default WMM parameters
+on the deflink during do_open(). For MLO cases, this
+leaves the additional links without proper WMM defaults
+if hostapd does not supply per-link WMM parameters, leading
+to inconsistent QoS behavior across links.
+
+Set default WMM parameters for each link during
+ieee80211_vif_update_links(), because this ensures all
+individual links in an MLD have valid WMM settings during
+bring-up and behave consistently across different BSS.
+
+Signed-off-by: Ramanathan Choodamani <quic_rchoodam@quicinc.com>
+Signed-off-by: Aishwarya R <aishwarya.r@oss.qualcomm.com>
+Link: https://patch.msgid.link/20260205094216.3093542-1-aishwarya.r@oss.qualcomm.com
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/mac80211/link.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/net/mac80211/link.c b/net/mac80211/link.c
+index 28ce41356341f..df303496914ca 100644
+--- a/net/mac80211/link.c
++++ b/net/mac80211/link.c
+@@ -283,6 +283,7 @@ static int ieee80211_vif_update_links(struct ieee80211_sub_if_data *sdata,
+ struct ieee80211_bss_conf *old[IEEE80211_MLD_MAX_NUM_LINKS];
+ struct ieee80211_link_data *old_data[IEEE80211_MLD_MAX_NUM_LINKS];
+ bool use_deflink = old_links == 0; /* set for error case */
++ bool non_sta = sdata->vif.type != NL80211_IFTYPE_STATION;
+
+ lockdep_assert_wiphy(sdata->local->hw.wiphy);
+
+@@ -339,6 +340,7 @@ static int ieee80211_vif_update_links(struct ieee80211_sub_if_data *sdata,
+ link = links[link_id];
+ ieee80211_link_init(sdata, link_id, &link->data, &link->conf);
+ ieee80211_link_setup(&link->data);
++ ieee80211_set_wmm_default(&link->data, true, non_sta);
+ }
+
+ if (new_links == 0)
+--
+2.51.0
+
--- /dev/null
+From 2374c189be8930b1b97f0c2e1c586fa6aeafa245 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 22 Feb 2026 23:52:40 -0300
+Subject: ACPI: OSI: Add DMI quirk for Acer Aspire One D255
+
+From: Sofia Schneider <sofia@schn.dev>
+
+[ Upstream commit 5ede90206273ff156a778254f0f972a55e973c89 ]
+
+The screen backlight turns off during boot (specifically during udev device
+initialization) when returning true for _OSI("Windows 2009").
+
+Analyzing the device's DSDT reveals that the firmware takes a different
+code path when Windows 7 is reported, which leads to the backlight shutoff.
+Add a DMI quirk to invoke dmi_disable_osi_win7 for this model.
+
+Signed-off-by: Sofia Schneider <sofia@schn.dev>
+Link: https://patch.msgid.link/20260223025240.518509-1-sofia@schn.dev
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/acpi/osi.c | 13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+diff --git a/drivers/acpi/osi.c b/drivers/acpi/osi.c
+index f2c943b934be0..9470f1830ff50 100644
+--- a/drivers/acpi/osi.c
++++ b/drivers/acpi/osi.c
+@@ -389,6 +389,19 @@ static const struct dmi_system_id acpi_osi_dmi_table[] __initconst = {
+ },
+ },
+
++ /*
++ * The screen backlight turns off during udev device creation
++ * when returning true for _OSI("Windows 2009")
++ */
++ {
++ .callback = dmi_disable_osi_win7,
++ .ident = "Acer Aspire One D255",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "AOD255"),
++ },
++ },
++
+ /*
+ * The wireless hotkey does not work on those machines when
+ * returning true for _OSI("Windows 2012")
+--
+2.51.0
+
--- /dev/null
+From 0439608b2596661c76fe203d113f2dcbf7867160 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 5 Feb 2026 23:05:02 +0100
+Subject: ACPI: PM: Save NVS memory on Lenovo G70-35
+
+From: Piotr Mazek <pmazek@outlook.com>
+
+[ Upstream commit 023cd6d90f8aa2ef7b72d84be84a18e61ecebd64 ]
+
+[821d6f0359b0614792ab8e2fb93b503e25a65079] prevented machines
+produced later than 2012 from saving NVS region to accelerate S3.
+
+Despite being made after 2012, Lenovo G70-35 still needs NVS memory
+saving during S3. A quirk is introduced for this platform.
+
+Signed-off-by: Piotr Mazek <pmazek@outlook.com>
+[ rjw: Subject adjustment ]
+Link: https://patch.msgid.link/GV2PPF3CD5B63CC2442EE3F76F8443EAD90D499A@GV2PPF3CD5B63CC.EURP251.PROD.OUTLOOK.COM
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/acpi/sleep.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
+index c8ee8e42b0f64..0b7fa4a8c379c 100644
+--- a/drivers/acpi/sleep.c
++++ b/drivers/acpi/sleep.c
+@@ -386,6 +386,14 @@ static const struct dmi_system_id acpisleep_dmi_table[] __initconst = {
+ DMI_MATCH(DMI_PRODUCT_NAME, "80E1"),
+ },
+ },
++ {
++ .callback = init_nvs_save_s3,
++ .ident = "Lenovo G70-35",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "80Q5"),
++ },
++ },
+ /*
+ * ThinkPad X1 Tablet(2016) cannot do suspend-to-idle using
+ * the Low Power S0 Idle firmware interface (see
+--
+2.51.0
+
--- /dev/null
+From 5c3343cdd5146439677f6f4985f4fcd28bf2a946 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 19 Feb 2026 20:14:26 +0000
+Subject: ALSA: hda/realtek: Fix speaker pop on Star Labs StarFighter
+
+From: Sean Rhodes <sean@starlabs.systems>
+
+[ Upstream commit 1cb3c20688fc8380c9b365d03aea7e84faf6a9fd ]
+
+On Star Labs StarFighter (Realtek ALC233/235), the internal speakers can
+emit an audible pop when entering or leaving runtime suspend.
+
+Mute the speaker output paths via snd_hda_gen_shutup_speakers() in the
+Realtek shutup callback before the codec is powered down.
+
+This is enough to avoid the pop without special EAPD handling.
+
+Test results:
+- runtime PM pop fixed
+- still reaches D3 (PCI 0000:00:1f.3 power_state=D3hot)
+- does not address pops on cold boot (G3 exit) or around display manager
+ start/shutdown
+
+journalctl -k (boot):
+- snd_hda_codec_alc269 hdaudioC0D0: ALC233: picked fixup for PCI SSID
+ 7017:2014
+- snd_hda_codec_alc269 hdaudioC0D0: autoconfig for ALC233: line_outs=1
+ (0x1b/0x0/0x0/0x0/0x0) type:speaker
+
+Suggested-by: Takashi Iwai <tiwai@suse.com>
+Tested-by: Sean Rhodes <sean@starlabs.systems>
+Signed-off-by: Sean Rhodes <sean@starlabs.systems>
+Link: https://patch.msgid.link/4d5fb71b132bb283fd41c622b8413770b2065242.1771532060.git.sean@starlabs.systems
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/hda/codecs/realtek/alc269.c | 25 +++++++++++++++++++++++++
+ 1 file changed, 25 insertions(+)
+
+diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
+index f40e00a578d99..a32a966be8ba1 100644
+--- a/sound/hda/codecs/realtek/alc269.c
++++ b/sound/hda/codecs/realtek/alc269.c
+@@ -1017,6 +1017,24 @@ static int alc269_resume(struct hda_codec *codec)
+ return 0;
+ }
+
++#define STARLABS_STARFIGHTER_SHUTUP_DELAY_MS 30
++
++static void starlabs_starfighter_shutup(struct hda_codec *codec)
++{
++ if (snd_hda_gen_shutup_speakers(codec))
++ msleep(STARLABS_STARFIGHTER_SHUTUP_DELAY_MS);
++}
++
++static void alc233_fixup_starlabs_starfighter(struct hda_codec *codec,
++ const struct hda_fixup *fix,
++ int action)
++{
++ struct alc_spec *spec = codec->spec;
++
++ if (action == HDA_FIXUP_ACT_PRE_PROBE)
++ spec->shutup = starlabs_starfighter_shutup;
++}
++
+ static void alc269_fixup_pincfg_no_hp_to_lineout(struct hda_codec *codec,
+ const struct hda_fixup *fix, int action)
+ {
+@@ -3931,6 +3949,7 @@ enum {
+ ALC245_FIXUP_CLEVO_NOISY_MIC,
+ ALC269_FIXUP_VAIO_VJFH52_MIC_NO_PRESENCE,
+ ALC233_FIXUP_MEDION_MTL_SPK,
++ ALC233_FIXUP_STARLABS_STARFIGHTER,
+ ALC294_FIXUP_BASS_SPEAKER_15,
+ ALC283_FIXUP_DELL_HP_RESUME,
+ ALC294_FIXUP_ASUS_CS35L41_SPI_2,
+@@ -6380,6 +6399,10 @@ static const struct hda_fixup alc269_fixups[] = {
+ { }
+ },
+ },
++ [ALC233_FIXUP_STARLABS_STARFIGHTER] = {
++ .type = HDA_FIXUP_FUNC,
++ .v.func = alc233_fixup_starlabs_starfighter,
++ },
+ [ALC294_FIXUP_BASS_SPEAKER_15] = {
+ .type = HDA_FIXUP_FUNC,
+ .v.func = alc294_fixup_bass_speaker_15,
+@@ -7485,6 +7508,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
+ SND_PCI_QUIRK(0x2782, 0x1705, "MEDION E15433", ALC269VC_FIXUP_INFINIX_Y4_MAX),
+ SND_PCI_QUIRK(0x2782, 0x1707, "Vaio VJFE-ADL", ALC298_FIXUP_SPK_VOLUME),
+ SND_PCI_QUIRK(0x2782, 0x4900, "MEDION E15443", ALC233_FIXUP_MEDION_MTL_SPK),
++ SND_PCI_QUIRK(0x7017, 0x2014, "Star Labs StarFighter", ALC233_FIXUP_STARLABS_STARFIGHTER),
+ SND_PCI_QUIRK(0x8086, 0x2074, "Intel NUC 8", ALC233_FIXUP_INTEL_NUC8_DMIC),
+ SND_PCI_QUIRK(0x8086, 0x2080, "Intel NUC 8 Rugged", ALC256_FIXUP_INTEL_NUC8_RUGGED),
+ SND_PCI_QUIRK(0x8086, 0x2081, "Intel NUC 10", ALC256_FIXUP_INTEL_NUC10),
+@@ -7581,6 +7605,7 @@ static const struct hda_model_fixup alc269_fixup_models[] = {
+ {.id = ALC298_FIXUP_TPT470_DOCK_FIX, .name = "tpt470-dock-fix"},
+ {.id = ALC298_FIXUP_TPT470_DOCK, .name = "tpt470-dock"},
+ {.id = ALC233_FIXUP_LENOVO_MULTI_CODECS, .name = "dual-codecs"},
++ {.id = ALC233_FIXUP_STARLABS_STARFIGHTER, .name = "starlabs-starfighter"},
+ {.id = ALC700_FIXUP_INTEL_REFERENCE, .name = "alc700-ref"},
+ {.id = ALC269_FIXUP_SONY_VAIO, .name = "vaio"},
+ {.id = ALC269_FIXUP_DELL_M101Z, .name = "dell-m101z"},
+--
+2.51.0
+
--- /dev/null
+From 2795e1bb005096acc3c980e1b8fdba9a0509d803 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 25 Feb 2026 09:52:30 +0100
+Subject: ALSA: usb-audio: Avoid implicit feedback mode on DIYINHK USB Audio
+ 2.0
+
+From: Takashi Iwai <tiwai@suse.de>
+
+[ Upstream commit c5bf24c8aba1ff711226ee0f039ff01a5754692b ]
+
+Although DIYINHK USB Audio 2.0 (ID 20b1:2009) shows the implicit
+feedback source for the capture stream, this would cause several
+problems for the playback. Namely, the device can get wMaxPackSize
+1024 for 24/32 bit format with 6 channels, and when a high sample rate
+like 352.8kHz or 384kHz is played, the packet size overflows the max
+limit. Also, the device has another two playback altsets, and those
+aren't properly handled with the implicit feedback.
+
+Since the device has been working well even before introducing the
+implicit feedback, we can assume that it works fine in the async mode.
+This patch adds the explicit skip of the implicit fb detection to make
+the playback running in the async mode.
+
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=221076
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Link: https://patch.msgid.link/20260225085233.316306-4-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/usb/quirks.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
+index c411005cd4d87..fd50bf7c381d6 100644
+--- a/sound/usb/quirks.c
++++ b/sound/usb/quirks.c
+@@ -2362,6 +2362,8 @@ static const struct usb_audio_quirk_flags_table quirk_flags_table[] = {
+ QUIRK_FLAG_SHARE_MEDIA_DEVICE | QUIRK_FLAG_ALIGN_TRANSFER),
+ DEVICE_FLG(0x2040, 0x7281, /* Hauppauge HVR-950Q-MXL */
+ QUIRK_FLAG_SHARE_MEDIA_DEVICE | QUIRK_FLAG_ALIGN_TRANSFER),
++ DEVICE_FLG(0x20b1, 0x2009, /* XMOS Ltd DIYINHK USB Audio 2.0 */
++ QUIRK_FLAG_SKIP_IMPLICIT_FB | QUIRK_FLAG_DSD_RAW),
+ DEVICE_FLG(0x2040, 0x8200, /* Hauppauge Woodbury */
+ QUIRK_FLAG_SHARE_MEDIA_DEVICE | QUIRK_FLAG_ALIGN_TRANSFER),
+ DEVICE_FLG(0x21b4, 0x0081, /* AudioQuest DragonFly */
+--
+2.51.0
+
--- /dev/null
+From a21f6717a7125a6d92b2e626fd308032bcd82950 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 25 Feb 2026 09:52:29 +0100
+Subject: ALSA: usb-audio: Check max frame size for implicit feedback mode, too
+
+From: Takashi Iwai <tiwai@suse.de>
+
+[ Upstream commit 7cb2a5422f5bbdf1cf32eae0eda41000485b9346 ]
+
+When the packet sizes are taken from the capture stream in the
+implicit feedback mode, the sizes might be larger than the upper
+boundary defined by the descriptor. As already done for other
+transfer modes, we have to cap the sizes accordingly at sending,
+otherwise this would lead to an error in USB core at submission of
+URBs.
+
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=221076
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Link: https://patch.msgid.link/20260225085233.316306-3-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/usb/endpoint.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
+index eff3329d86b7e..77c4330d52953 100644
+--- a/sound/usb/endpoint.c
++++ b/sound/usb/endpoint.c
+@@ -221,6 +221,7 @@ int snd_usb_endpoint_next_packet_size(struct snd_usb_endpoint *ep,
+
+ packet = ctx->packet_size[idx];
+ if (packet) {
++ packet = min(packet, ep->maxframesize);
+ if (avail && packet >= avail)
+ return -EAGAIN;
+ return packet;
+--
+2.51.0
+
--- /dev/null
+From aa8807a73e1946bd68efc245715e94de6856f383 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 21 Feb 2026 12:48:13 +0100
+Subject: ASoC: amd: yc: Add ASUS EXPERTBOOK BM1503CDA to quirk table
+
+From: Azamat Almazbek uulu <almazbek1608@gmail.com>
+
+[ Upstream commit 32fc4168fa56f6301d858c778a3d712774e9657e ]
+
+The ASUS ExpertBook BM1503CDA (Ryzen 5 7535U, Barcelo-R) has an
+internal DMIC connected through the AMD ACP (Audio CoProcessor)
+but is missing from the DMI quirk table, so the acp6x machine
+driver probe returns -ENODEV and no DMIC capture device is created.
+
+Add the DMI entry so the internal microphone works out of the box.
+
+Signed-off-by: Azamat Almazbek uulu <almazbek1608@gmail.com>
+Reviewed-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
+Link: https://patch.msgid.link/20260221114813.5610-1-almazbek1608@gmail.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/soc/amd/yc/acp6x-mach.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c
+index f1a63475100d1..7af4daeb4c6ff 100644
+--- a/sound/soc/amd/yc/acp6x-mach.c
++++ b/sound/soc/amd/yc/acp6x-mach.c
+@@ -703,6 +703,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = {
+ DMI_MATCH(DMI_PRODUCT_NAME, "Vivobook_ASUSLaptop M6501RR_M6501RR"),
+ }
+ },
++ {
++ .driver_data = &acp6x_card,
++ .matches = {
++ DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK COMPUTER INC."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "ASUS EXPERTBOOK BM1503CDA"),
++ }
++ },
+ {}
+ };
+
+--
+2.51.0
+
--- /dev/null
+From 2c6e8a21af353bfa52b2a9afa346fac29bcdc195 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 23 Feb 2026 09:36:16 +0000
+Subject: ASoC: cs42l43: Report insert for exotic peripherals
+
+From: Charles Keepax <ckeepax@opensource.cirrus.com>
+
+[ Upstream commit 6510e1324bcdc8caf21f6d17efe27604c48f0d64 ]
+
+For some exotic peripherals the type detect can return a reserved value
+of 0x4. This will currently return an error and not report anything to
+user-space, update this to report the insert normally.
+
+Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
+Link: https://patch.msgid.link/20260223093616.3800350-1-ckeepax@opensource.cirrus.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/soc/codecs/cs42l43-jack.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/sound/soc/codecs/cs42l43-jack.c b/sound/soc/codecs/cs42l43-jack.c
+index 744488f371ea4..ecba6c7952384 100644
+--- a/sound/soc/codecs/cs42l43-jack.c
++++ b/sound/soc/codecs/cs42l43-jack.c
+@@ -699,6 +699,7 @@ static int cs42l43_run_type_detect(struct cs42l43_codec *priv)
+ switch (type & CS42L43_HSDET_TYPE_STS_MASK) {
+ case 0x0: // CTIA
+ case 0x1: // OMTP
++ case 0x4:
+ return cs42l43_run_load_detect(priv, true);
+ case 0x2: // 3-pole
+ return cs42l43_run_load_detect(priv, false);
+--
+2.51.0
+
--- /dev/null
+From dbcf10be4767453a1002d0d845dcc2ea60614c6f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 21 Feb 2026 10:03:32 +0530
+Subject: drm/amdgpu/vcn5: Add SMU dpm interface type
+
+From: sguttula <suresh.guttula@amd.com>
+
+[ Upstream commit a5fe1a54513196e4bc8f9170006057dc31e7155e ]
+
+This will set AMDGPU_VCN_SMU_DPM_INTERFACE_* smu_type
+based on soc type and fixing ring timeout issue seen
+for DPM enabled case.
+
+Signed-off-by: sguttula <suresh.guttula@amd.com>
+Reviewed-by: Pratik Vishwakarma <Pratik.Vishwakarma@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+(cherry picked from commit f0f23c315b38c55e8ce9484cf59b65811f350630)
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c b/drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c
+index 0202df5db1e12..6109124f852e5 100644
+--- a/drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c
++++ b/drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c
+@@ -174,6 +174,10 @@ static int vcn_v5_0_0_sw_init(struct amdgpu_ip_block *ip_block)
+ fw_shared->present_flag_0 = cpu_to_le32(AMDGPU_FW_SHARED_FLAG_0_UNIFIED_QUEUE);
+ fw_shared->sq.is_enabled = 1;
+
++ fw_shared->present_flag_0 |= cpu_to_le32(AMDGPU_VCN_SMU_DPM_INTERFACE_FLAG);
++ fw_shared->smu_dpm_interface.smu_interface_type = (adev->flags & AMD_IS_APU) ?
++ AMDGPU_VCN_SMU_DPM_INTERFACE_APU : AMDGPU_VCN_SMU_DPM_INTERFACE_DGPU;
++
+ if (amdgpu_vcnfw_log)
+ amdgpu_vcn_fwlog_init(&adev->vcn.inst[i]);
+
+--
+2.51.0
+
--- /dev/null
+From 979ce2f878335ed9e4261c9acf19aeb425a2f9e3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 6 Feb 2026 14:20:28 +0800
+Subject: fs: init flags_valid before calling vfs_fileattr_get
+
+From: Edward Adam Davis <eadavis@qq.com>
+
+[ Upstream commit cb184dd19154fc486fa3d9e02afe70a97e54e055 ]
+
+syzbot reported a uninit-value bug in [1].
+
+Similar to the "*get" context where the kernel's internal file_kattr
+structure is initialized before calling vfs_fileattr_get(), we should
+use the same mechanism when using fa.
+
+[1]
+BUG: KMSAN: uninit-value in fuse_fileattr_get+0xeb4/0x1450 fs/fuse/ioctl.c:517
+ fuse_fileattr_get+0xeb4/0x1450 fs/fuse/ioctl.c:517
+ vfs_fileattr_get fs/file_attr.c:94 [inline]
+ __do_sys_file_getattr fs/file_attr.c:416 [inline]
+
+Local variable fa.i created at:
+ __do_sys_file_getattr fs/file_attr.c:380 [inline]
+ __se_sys_file_getattr+0x8c/0xbd0 fs/file_attr.c:372
+
+Reported-by: syzbot+7c31755f2cea07838b0c@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=7c31755f2cea07838b0c
+Tested-by: syzbot+7c31755f2cea07838b0c@syzkaller.appspotmail.com
+Signed-off-by: Edward Adam Davis <eadavis@qq.com>
+Link: https://patch.msgid.link/tencent_B6C4583771D76766D71362A368696EC3B605@qq.com
+Signed-off-by: Christian Brauner <brauner@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/file_attr.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/fs/file_attr.c b/fs/file_attr.c
+index 1dcec88c06805..9d3e177ad7d1d 100644
+--- a/fs/file_attr.c
++++ b/fs/file_attr.c
+@@ -379,7 +379,7 @@ SYSCALL_DEFINE5(file_getattr, int, dfd, const char __user *, filename,
+ struct filename *name __free(putname) = NULL;
+ unsigned int lookup_flags = 0;
+ struct file_attr fattr;
+- struct file_kattr fa;
++ struct file_kattr fa = { .flags_valid = true }; /* hint only */
+ int error;
+
+ BUILD_BUG_ON(sizeof(struct file_attr) < FILE_ATTR_SIZE_VER0);
+--
+2.51.0
+
--- /dev/null
+From c99bddfba6215bea157c7e35489dc2610f04f806 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 21 Apr 2025 22:36:46 -0400
+Subject: kexec: Include kernel-end even without crashkernel
+
+From: Ben Collins <bcollins@kernel.org>
+
+[ Upstream commit 38c64dfe0af12778953846df5f259e913275cfe5 ]
+
+Certain versions of kexec don't even work without kernel-end being
+added to the device-tree. Add it even if crash-kernel is disabled.
+
+Signed-off-by: Ben Collins <bcollins@kernel.org>
+Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
+Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
+Link: https://patch.msgid.link/2025042122-inescapable-mandrill-8a5ff2@boujee-and-buff
+Stable-dep-of: 20197b967a6a ("powerpc/kexec/core: use big-endian types for crash variables")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/kexec/core.c | 27 +++++++++++++++------------
+ 1 file changed, 15 insertions(+), 12 deletions(-)
+
+diff --git a/arch/powerpc/kexec/core.c b/arch/powerpc/kexec/core.c
+index d1a2d755381ca..cf803d09c8e51 100644
+--- a/arch/powerpc/kexec/core.c
++++ b/arch/powerpc/kexec/core.c
+@@ -22,6 +22,8 @@
+ #include <asm/setup.h>
+ #include <asm/firmware.h>
+
++#define cpu_to_be_ulong __PASTE(cpu_to_be, BITS_PER_LONG)
++
+ #ifdef CONFIG_CRASH_DUMP
+ void machine_crash_shutdown(struct pt_regs *regs)
+ {
+@@ -136,17 +138,10 @@ int __init overlaps_crashkernel(unsigned long start, unsigned long size)
+ }
+
+ /* Values we need to export to the second kernel via the device tree. */
+-static phys_addr_t kernel_end;
+ static phys_addr_t crashk_base;
+ static phys_addr_t crashk_size;
+ static unsigned long long mem_limit;
+
+-static struct property kernel_end_prop = {
+- .name = "linux,kernel-end",
+- .length = sizeof(phys_addr_t),
+- .value = &kernel_end,
+-};
+-
+ static struct property crashk_base_prop = {
+ .name = "linux,crashkernel-base",
+ .length = sizeof(phys_addr_t),
+@@ -165,8 +160,6 @@ static struct property memory_limit_prop = {
+ .value = &mem_limit,
+ };
+
+-#define cpu_to_be_ulong __PASTE(cpu_to_be, BITS_PER_LONG)
+-
+ static void __init export_crashk_values(struct device_node *node)
+ {
+ /* There might be existing crash kernel properties, but we can't
+@@ -190,6 +183,15 @@ static void __init export_crashk_values(struct device_node *node)
+ mem_limit = cpu_to_be_ulong(memory_limit);
+ of_update_property(node, &memory_limit_prop);
+ }
++#endif /* CONFIG_CRASH_RESERVE */
++
++static phys_addr_t kernel_end;
++
++static struct property kernel_end_prop = {
++ .name = "linux,kernel-end",
++ .length = sizeof(phys_addr_t),
++ .value = &kernel_end,
++};
+
+ static int __init kexec_setup(void)
+ {
+@@ -200,16 +202,17 @@ static int __init kexec_setup(void)
+ return -ENOENT;
+
+ /* remove any stale properties so ours can be found */
+- of_remove_property(node, of_find_property(node, kernel_end_prop.name, NULL));
++ of_remove_property(node, of_find_property(node, kernel_end_prop.name,
++ NULL));
+
+ /* information needed by userspace when using default_machine_kexec */
+ kernel_end = cpu_to_be_ulong(__pa(_end));
+ of_add_property(node, &kernel_end_prop);
+
++#ifdef CONFIG_CRASH_RESERVE
+ export_crashk_values(node);
+-
++#endif
+ of_node_put(node);
+ return 0;
+ }
+ late_initcall(kexec_setup);
+-#endif /* CONFIG_CRASH_RESERVE */
+--
+2.51.0
+
--- /dev/null
+From 7c8e147874e477aae02e98a3de735a6fa082215f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 3 Mar 2026 16:31:42 +0100
+Subject: powerpc: 83xx: km83xx: Fix keymile vendor prefix
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: J. Neuschäfer <j.ne@posteo.net>
+
+[ Upstream commit 691417ffe7821721e0a28bd25ad8c0dc0d4ae4ad ]
+
+When kmeter.c was refactored into km83xx.c in 2011, the "keymile" vendor
+prefix was changed to upper-case "Keymile". The devicetree at
+arch/powerpc/boot/dts/kmeter1.dts never underwent the same change,
+suggesting that this was simply a mistake.
+
+Fixes: 93e2b95c81042d ("powerpc/83xx: rename and update kmeter1")
+Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
+Reviewed-by: Heiko Schocher <hs@nabladev.com>
+Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
+Link: https://patch.msgid.link/20260303-keymile-v1-1-463a11e71702@posteo.net
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/platforms/83xx/km83xx.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/arch/powerpc/platforms/83xx/km83xx.c b/arch/powerpc/platforms/83xx/km83xx.c
+index 2b5d187d9b62d..9ef8fb39dd1b1 100644
+--- a/arch/powerpc/platforms/83xx/km83xx.c
++++ b/arch/powerpc/platforms/83xx/km83xx.c
+@@ -155,8 +155,8 @@ machine_device_initcall(mpc83xx_km, mpc83xx_declare_of_platform_devices);
+
+ /* list of the supported boards */
+ static char *board[] __initdata = {
+- "Keymile,KMETER1",
+- "Keymile,kmpbec8321",
++ "keymile,KMETER1",
++ "keymile,kmpbec8321",
+ NULL
+ };
+
+--
+2.51.0
+
--- /dev/null
+From 81e6aa4a4612a3b0dbd2d9a1479ae13acd431c3d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 27 Feb 2026 22:48:01 +0530
+Subject: powerpc/crash: adjust the elfcorehdr size
+
+From: Sourabh Jain <sourabhjain@linux.ibm.com>
+
+[ Upstream commit 04e707cb77c272cb0bb2e2e3c5c7f844d804a089 ]
+
+With crash hotplug support enabled, additional memory is allocated to
+the elfcorehdr kexec segment to accommodate resources added during
+memory hotplug events. However, the kdump FDT is not updated with the
+same size, which can result in elfcorehdr corruption in the kdump
+kernel.
+
+Update elf_headers_sz (the kimage member representing the size of the
+elfcorehdr kexec segment) to reflect the total memory allocated for the
+elfcorehdr segment instead of the elfcorehdr buffer size at the time of
+kdump load. This allows of_kexec_alloc_and_setup_fdt() to reserve the
+full elfcorehdr memory in the kdump FDT and prevents elfcorehdr
+corruption.
+
+Fixes: 849599b702ef8 ("powerpc/crash: add crash memory hotplug support")
+Reviewed-by: Hari Bathini <hbathini@linux.ibm.com>
+Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
+Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
+Link: https://patch.msgid.link/20260227171801.2238847-1-sourabhjain@linux.ibm.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/kexec/file_load_64.c | 14 +++++++++++++-
+ 1 file changed, 13 insertions(+), 1 deletion(-)
+
+diff --git a/arch/powerpc/kexec/file_load_64.c b/arch/powerpc/kexec/file_load_64.c
+index e7ef8b2a25546..5f6d50e4c3d45 100644
+--- a/arch/powerpc/kexec/file_load_64.c
++++ b/arch/powerpc/kexec/file_load_64.c
+@@ -450,6 +450,11 @@ static int load_elfcorehdr_segment(struct kimage *image, struct kexec_buf *kbuf)
+ kbuf->buffer = headers;
+ kbuf->mem = KEXEC_BUF_MEM_UNKNOWN;
+ kbuf->bufsz = headers_sz;
++
++ /*
++ * Account for extra space required to accommodate additional memory
++ * ranges in elfcorehdr due to memory hotplug events.
++ */
+ kbuf->memsz = headers_sz + kdump_extra_elfcorehdr_size(cmem);
+ kbuf->top_down = false;
+
+@@ -460,7 +465,14 @@ static int load_elfcorehdr_segment(struct kimage *image, struct kexec_buf *kbuf)
+ }
+
+ image->elf_load_addr = kbuf->mem;
+- image->elf_headers_sz = headers_sz;
++
++ /*
++ * If CONFIG_CRASH_HOTPLUG is enabled, the elfcorehdr kexec segment
++ * memsz can be larger than bufsz. Always initialize elf_headers_sz
++ * with memsz. This ensures the correct size is reserved for elfcorehdr
++ * memory in the FDT prepared for kdump.
++ */
++ image->elf_headers_sz = kbuf->memsz;
+ image->elf_headers = headers;
+ out:
+ kfree(cmem);
+--
+2.51.0
+
--- /dev/null
+From a46bfed089dee11f127a4417932975eab3ccf1e2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 24 Dec 2025 20:42:57 +0530
+Subject: powerpc/kexec/core: use big-endian types for crash variables
+
+From: Sourabh Jain <sourabhjain@linux.ibm.com>
+
+[ Upstream commit 20197b967a6a29dab81495f25a988515bda84cfe ]
+
+Use explicit word-sized big-endian types for kexec and crash related
+variables. This makes the endianness unambiguous and avoids type
+mismatches that trigger sparse warnings.
+
+The change addresses sparse warnings like below (seen on both 32-bit
+and 64-bit builds):
+
+CHECK ../arch/powerpc/kexec/core.c
+sparse: expected unsigned int static [addressable] [toplevel] [usertype] crashk_base
+sparse: got restricted __be32 [usertype]
+sparse: warning: incorrect type in assignment (different base types)
+sparse: expected unsigned int static [addressable] [toplevel] [usertype] crashk_size
+sparse: got restricted __be32 [usertype]
+sparse: warning: incorrect type in assignment (different base types)
+sparse: expected unsigned long long static [addressable] [toplevel] mem_limit
+sparse: got restricted __be32 [usertype]
+sparse: warning: incorrect type in assignment (different base types)
+sparse: expected unsigned int static [addressable] [toplevel] [usertype] kernel_end
+sparse: got restricted __be32 [usertype]
+
+No functional change intended.
+
+Fixes: ea961a828fe7 ("powerpc: Fix endian issues in kexec and crash dump code")
+Reported-by: kernel test robot <lkp@intel.com>
+Closes: https://lore.kernel.org/oe-kbuild-all/202512221405.VHPKPjnp-lkp@intel.com/
+Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
+Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
+Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
+Link: https://patch.msgid.link/20251224151257.28672-1-sourabhjain@linux.ibm.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/kexec/core.c | 17 +++++++++--------
+ 1 file changed, 9 insertions(+), 8 deletions(-)
+
+diff --git a/arch/powerpc/kexec/core.c b/arch/powerpc/kexec/core.c
+index cf803d09c8e51..f86a6fc11e91c 100644
+--- a/arch/powerpc/kexec/core.c
++++ b/arch/powerpc/kexec/core.c
+@@ -23,6 +23,7 @@
+ #include <asm/firmware.h>
+
+ #define cpu_to_be_ulong __PASTE(cpu_to_be, BITS_PER_LONG)
++#define __be_word __PASTE(__be, BITS_PER_LONG)
+
+ #ifdef CONFIG_CRASH_DUMP
+ void machine_crash_shutdown(struct pt_regs *regs)
+@@ -138,25 +139,25 @@ int __init overlaps_crashkernel(unsigned long start, unsigned long size)
+ }
+
+ /* Values we need to export to the second kernel via the device tree. */
+-static phys_addr_t crashk_base;
+-static phys_addr_t crashk_size;
+-static unsigned long long mem_limit;
++static __be_word crashk_base;
++static __be_word crashk_size;
++static __be_word mem_limit;
+
+ static struct property crashk_base_prop = {
+ .name = "linux,crashkernel-base",
+- .length = sizeof(phys_addr_t),
++ .length = sizeof(__be_word),
+ .value = &crashk_base
+ };
+
+ static struct property crashk_size_prop = {
+ .name = "linux,crashkernel-size",
+- .length = sizeof(phys_addr_t),
++ .length = sizeof(__be_word),
+ .value = &crashk_size,
+ };
+
+ static struct property memory_limit_prop = {
+ .name = "linux,memory-limit",
+- .length = sizeof(unsigned long long),
++ .length = sizeof(__be_word),
+ .value = &mem_limit,
+ };
+
+@@ -185,11 +186,11 @@ static void __init export_crashk_values(struct device_node *node)
+ }
+ #endif /* CONFIG_CRASH_RESERVE */
+
+-static phys_addr_t kernel_end;
++static __be_word kernel_end;
+
+ static struct property kernel_end_prop = {
+ .name = "linux,kernel-end",
+- .length = sizeof(phys_addr_t),
++ .length = sizeof(__be_word),
+ .value = &kernel_end,
+ };
+
+--
+2.51.0
+
--- /dev/null
+From 14ef577996b469e672384553ac7942477e33e68a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 3 Feb 2026 08:30:41 +0100
+Subject: powerpc/uaccess: Fix inline assembly for clang build on PPC32
+
+From: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
+
+[ Upstream commit 0ee95a1d458630272d0415d0ffa9424fcb606c90 ]
+
+Test robot reports the following error with clang-16.0.6:
+
+ In file included from kernel/rseq.c:75:
+ include/linux/rseq_entry.h:141:3: error: invalid operand for instruction
+ unsafe_get_user(offset, &ucs->post_commit_offset, efault);
+ ^
+ include/linux/uaccess.h:608:2: note: expanded from macro 'unsafe_get_user'
+ arch_unsafe_get_user(x, ptr, local_label); \
+ ^
+ arch/powerpc/include/asm/uaccess.h:518:2: note: expanded from macro 'arch_unsafe_get_user'
+ __get_user_size_goto(__gu_val, __gu_addr, sizeof(*(p)), e); \
+ ^
+ arch/powerpc/include/asm/uaccess.h:284:2: note: expanded from macro '__get_user_size_goto'
+ __get_user_size_allowed(x, ptr, size, __gus_retval); \
+ ^
+ arch/powerpc/include/asm/uaccess.h:275:10: note: expanded from macro '__get_user_size_allowed'
+ case 8: __get_user_asm2(x, (u64 __user *)ptr, retval); break; \
+ ^
+ arch/powerpc/include/asm/uaccess.h:258:4: note: expanded from macro '__get_user_asm2'
+ " li %1+1,0\n" \
+ ^
+ <inline asm>:7:5: note: instantiated into assembly here
+ li 31+1,0
+ ^
+ 1 error generated.
+
+On PPC32, for 64 bits vars a pair of registers is used. Usually the
+lower register in the pair is the high part and the higher register is
+the low part. GCC uses r3/r4 ... r11/r12 ... r14/r15 ... r30/r31
+
+In older kernel code inline assembly was using %1 and %1+1 to represent
+64 bits values. However here it looks like clang uses r31 as high part,
+allthough r32 doesn't exist hence the error.
+
+Allthoug %1+1 should work, most places now use %L1 instead of %1+1, so
+let's do the same here.
+
+With that change, the build doesn't fail anymore and a disassembly shows
+clang uses r17/r18 and r31/r14 pair when GCC would have used r16/r17 and
+r30/r31:
+
+ Disassembly of section .fixup:
+
+ 00000000 <.fixup>:
+ 0: 38 a0 ff f2 li r5,-14
+ 4: 3a 20 00 00 li r17,0
+ 8: 3a 40 00 00 li r18,0
+ c: 48 00 00 00 b c <.fixup+0xc>
+ c: R_PPC_REL24 .text+0xbc
+ 10: 38 a0 ff f2 li r5,-14
+ 14: 3b e0 00 00 li r31,0
+ 18: 39 c0 00 00 li r14,0
+ 1c: 48 00 00 00 b 1c <.fixup+0x1c>
+ 1c: R_PPC_REL24 .text+0x144
+
+Reported-by: kernel test robot <lkp@intel.com>
+Closes: https://lore.kernel.org/oe-kbuild-all/202602021825.otcItxGi-lkp@intel.com/
+Fixes: c20beffeec3c ("powerpc/uaccess: Use flexible addressing with __put_user()/__get_user()")
+Signed-off-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
+Acked-by: Nathan Chancellor <nathan@kernel.org>
+Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
+Link: https://patch.msgid.link/8ca3a657a650e497a96bfe7acde2f637dadab344.1770103646.git.chleroy@kernel.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/include/asm/uaccess.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h
+index 3987a5c33558b..929f7050c73a6 100644
+--- a/arch/powerpc/include/asm/uaccess.h
++++ b/arch/powerpc/include/asm/uaccess.h
+@@ -253,7 +253,7 @@ __gus_failed: \
+ ".section .fixup,\"ax\"\n" \
+ "4: li %0,%3\n" \
+ " li %1,0\n" \
+- " li %1+1,0\n" \
++ " li %L1,0\n" \
+ " b 3b\n" \
+ ".previous\n" \
+ EX_TABLE(1b, 4b) \
+--
+2.51.0
+
--- /dev/null
+From 3cfad82757da930fbb37066bb93fddcf26265a8a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 6 Feb 2026 03:30:33 +0000
+Subject: remoteproc: mediatek: Unprepare SCP clock during system suspend
+
+From: Tzung-Bi Shih <tzungbi@kernel.org>
+
+[ Upstream commit 35c3f72a2d55dbf52f28f4ecae51c76be1acf545 ]
+
+Prior to commit d935187cfb27 ("remoteproc: mediatek: Break lock
+dependency to prepare_lock"), `scp->clk` was prepared and enabled only
+when it needs to communicate with the SCP. The commit d935187cfb27
+moved the prepare operation to remoteproc's prepare(), keeping the clock
+prepared as long as the SCP is running.
+
+The power consumption due to the prolonged clock preparation can be
+negligible when the system is running, as SCP is designed to be a very
+power efficient processor.
+
+However, the clock remains prepared even when the system enters system
+suspend. This prevents the underlying clock controller (and potentially
+the parent PLLs) from shutting down, which increases power consumption
+and may block the system from entering deep sleep states.
+
+Add suspend and resume callbacks. Unprepare the clock in suspend() if
+it was active and re-prepare it in resume() to ensure the clock is
+properly disabled during system suspend, while maintaining the "always
+prepared" semantics while the system is active. The driver doesn't
+implement .attach() callback, hence it only checks for RPROC_RUNNING.
+
+Fixes: d935187cfb27 ("remoteproc: mediatek: Break lock dependency to prepare_lock")
+Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
+Link: https://lore.kernel.org/r/20260206033034.3031781-1-tzungbi@kernel.org
+Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/remoteproc/mtk_scp.c | 39 ++++++++++++++++++++++++++++++++++++
+ 1 file changed, 39 insertions(+)
+
+diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
+index 2aeb0ded165cf..eb8908ea3bab0 100644
+--- a/drivers/remoteproc/mtk_scp.c
++++ b/drivers/remoteproc/mtk_scp.c
+@@ -1544,12 +1544,51 @@ static const struct of_device_id mtk_scp_of_match[] = {
+ };
+ MODULE_DEVICE_TABLE(of, mtk_scp_of_match);
+
++static int __maybe_unused scp_suspend(struct device *dev)
++{
++ struct mtk_scp *scp = dev_get_drvdata(dev);
++ struct rproc *rproc = scp->rproc;
++
++ /*
++ * Only unprepare if the SCP is running and holding the clock.
++ *
++ * Note: `scp_ops` doesn't implement .attach() callback, hence
++ * `rproc->state` can never be RPROC_ATTACHED. Otherwise, it
++ * should also be checked here.
++ */
++ if (rproc->state == RPROC_RUNNING)
++ clk_unprepare(scp->clk);
++ return 0;
++}
++
++static int __maybe_unused scp_resume(struct device *dev)
++{
++ struct mtk_scp *scp = dev_get_drvdata(dev);
++ struct rproc *rproc = scp->rproc;
++
++ /*
++ * Only prepare if the SCP was running and holding the clock.
++ *
++ * Note: `scp_ops` doesn't implement .attach() callback, hence
++ * `rproc->state` can never be RPROC_ATTACHED. Otherwise, it
++ * should also be checked here.
++ */
++ if (rproc->state == RPROC_RUNNING)
++ return clk_prepare(scp->clk);
++ return 0;
++}
++
++static const struct dev_pm_ops scp_pm_ops = {
++ SET_SYSTEM_SLEEP_PM_OPS(scp_suspend, scp_resume)
++};
++
+ static struct platform_driver mtk_scp_driver = {
+ .probe = scp_probe,
+ .remove = scp_remove,
+ .driver = {
+ .name = "mtk-scp",
+ .of_match_table = mtk_scp_of_match,
++ .pm = &scp_pm_ops,
+ },
+ };
+
+--
+2.51.0
+
--- /dev/null
+From 7427a9e08da150b8b9f7f7bec6621b7d8d862b31 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 20 Feb 2026 15:11:48 -0600
+Subject: remoteproc: sysmon: Correct subsys_name_len type in QMI request
+
+From: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
+
+[ Upstream commit da994db94e60f9a9411108ddf4d1836147ad4c9c ]
+
+The QMI message encoder has up until recently read a single byte (as
+elem_size == 1), but with the introduction of big endian support it's
+become apparent that this field is expected to be a full u32 -
+regardless of the size of the length in the encoded message (which is
+what elem_size specifies).
+
+The result is that the encoder now reads past the length byte and
+rejects the unreasonably large length formed when including the
+following 3 bytes from the subsys_name array.
+
+Fix this by changing to the expected type.
+
+Fixes: 1fb82ee806d1 ("remoteproc: qcom: Introduce sysmon")
+Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
+Reviewed-by: Chris Lew <christopher.lew@oss.qualcomm.com>
+Link: https://lore.kernel.org/r/20260220-qmi-encode-invalid-length-v2-1-5674be35ab29@oss.qualcomm.com
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/remoteproc/qcom_sysmon.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/remoteproc/qcom_sysmon.c b/drivers/remoteproc/qcom_sysmon.c
+index 660ac6fc40821..c6cc6e519fe56 100644
+--- a/drivers/remoteproc/qcom_sysmon.c
++++ b/drivers/remoteproc/qcom_sysmon.c
+@@ -203,7 +203,7 @@ static const struct qmi_elem_info ssctl_shutdown_resp_ei[] = {
+ };
+
+ struct ssctl_subsys_event_req {
+- u8 subsys_name_len;
++ u32 subsys_name_len;
+ char subsys_name[SSCTL_SUBSYS_NAME_LENGTH];
+ u32 event;
+ u8 evt_driven_valid;
+--
+2.51.0
+
--- /dev/null
+From ecd21e18a98e57129f054b5c34ec0c2f685f41e5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 12 Feb 2026 12:30:26 +0530
+Subject: scsi: mpi3mr: Add NULL checks when resetting request and reply queues
+
+From: Ranjan Kumar <ranjan.kumar@broadcom.com>
+
+[ Upstream commit fa96392ebebc8fade2b878acb14cce0f71016503 ]
+
+The driver encountered a crash during resource cleanup when the reply and
+request queues were NULL due to freed memory. This issue occurred when the
+creation of reply or request queues failed, and the driver freed the memory
+first, but attempted to mem set the content of the freed memory, leading to
+a system crash.
+
+Add NULL pointer checks for reply and request queues before accessing the
+reply/request memory during cleanup
+
+Signed-off-by: Ranjan Kumar <ranjan.kumar@broadcom.com>
+Link: https://patch.msgid.link/20260212070026.30263-1-ranjan.kumar@broadcom.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/mpi3mr/mpi3mr_fw.c | 34 ++++++++++++++++++---------------
+ 1 file changed, 19 insertions(+), 15 deletions(-)
+
+diff --git a/drivers/scsi/mpi3mr/mpi3mr_fw.c b/drivers/scsi/mpi3mr/mpi3mr_fw.c
+index 8c4bb7169a87c..8382afed12813 100644
+--- a/drivers/scsi/mpi3mr/mpi3mr_fw.c
++++ b/drivers/scsi/mpi3mr/mpi3mr_fw.c
+@@ -4705,21 +4705,25 @@ void mpi3mr_memset_buffers(struct mpi3mr_ioc *mrioc)
+ }
+
+ for (i = 0; i < mrioc->num_queues; i++) {
+- mrioc->op_reply_qinfo[i].qid = 0;
+- mrioc->op_reply_qinfo[i].ci = 0;
+- mrioc->op_reply_qinfo[i].num_replies = 0;
+- mrioc->op_reply_qinfo[i].ephase = 0;
+- atomic_set(&mrioc->op_reply_qinfo[i].pend_ios, 0);
+- atomic_set(&mrioc->op_reply_qinfo[i].in_use, 0);
+- mpi3mr_memset_op_reply_q_buffers(mrioc, i);
+-
+- mrioc->req_qinfo[i].ci = 0;
+- mrioc->req_qinfo[i].pi = 0;
+- mrioc->req_qinfo[i].num_requests = 0;
+- mrioc->req_qinfo[i].qid = 0;
+- mrioc->req_qinfo[i].reply_qid = 0;
+- spin_lock_init(&mrioc->req_qinfo[i].q_lock);
+- mpi3mr_memset_op_req_q_buffers(mrioc, i);
++ if (mrioc->op_reply_qinfo) {
++ mrioc->op_reply_qinfo[i].qid = 0;
++ mrioc->op_reply_qinfo[i].ci = 0;
++ mrioc->op_reply_qinfo[i].num_replies = 0;
++ mrioc->op_reply_qinfo[i].ephase = 0;
++ atomic_set(&mrioc->op_reply_qinfo[i].pend_ios, 0);
++ atomic_set(&mrioc->op_reply_qinfo[i].in_use, 0);
++ mpi3mr_memset_op_reply_q_buffers(mrioc, i);
++ }
++
++ if (mrioc->req_qinfo) {
++ mrioc->req_qinfo[i].ci = 0;
++ mrioc->req_qinfo[i].pi = 0;
++ mrioc->req_qinfo[i].num_requests = 0;
++ mrioc->req_qinfo[i].qid = 0;
++ mrioc->req_qinfo[i].reply_qid = 0;
++ spin_lock_init(&mrioc->req_qinfo[i].q_lock);
++ mpi3mr_memset_op_req_q_buffers(mrioc, i);
++ }
+ }
+
+ atomic_set(&mrioc->pend_large_data_sz, 0);
+--
+2.51.0
+
--- /dev/null
+From bc59b94fc0a98b509d13c339cfd0637a86bfa26a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 10 Feb 2026 20:18:50 +0100
+Subject: scsi: ses: Fix devices attaching to different hosts
+
+From: Tomas Henzl <thenzl@redhat.com>
+
+[ Upstream commit 70ca8caa96ce473647054f5c7b9dab5423902402 ]
+
+On a multipath SAS system some devices don't end up with correct symlinks
+from the SCSI device to its enclosure. Some devices even have enclosure
+links pointing to enclosures attached to different SCSI hosts.
+
+ses_match_to_enclosure() calls enclosure_for_each_device() which iterates
+over all enclosures on the system, not just enclosures attached to the
+current SCSI host.
+
+Replace the iteration with a direct call to ses_enclosure_find_by_addr().
+
+Reviewed-by: David Jeffery <djeffery@redhat.com>
+Signed-off-by: Tomas Henzl <thenzl@redhat.com>
+Link: https://patch.msgid.link/20260210191850.36784-1-thenzl@redhat.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/ses.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/scsi/ses.c b/drivers/scsi/ses.c
+index 2c61624cb4b03..50e744e891295 100644
+--- a/drivers/scsi/ses.c
++++ b/drivers/scsi/ses.c
+@@ -529,9 +529,8 @@ struct efd {
+ };
+
+ static int ses_enclosure_find_by_addr(struct enclosure_device *edev,
+- void *data)
++ struct efd *efd)
+ {
+- struct efd *efd = data;
+ int i;
+ struct ses_component *scomp;
+
+@@ -684,7 +683,7 @@ static void ses_match_to_enclosure(struct enclosure_device *edev,
+ if (efd.addr) {
+ efd.dev = &sdev->sdev_gendev;
+
+- enclosure_for_each_device(ses_enclosure_find_by_addr, &efd);
++ ses_enclosure_find_by_addr(edev, &efd);
+ }
+ }
+
+--
+2.51.0
+
--- /dev/null
+From 12f683b4bc3fcf5a8b1425b49e6c33df747bb937 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 29 Jan 2026 15:30:39 +0100
+Subject: scsi: storvsc: Fix scheduling while atomic on PREEMPT_RT
+
+From: Jan Kiszka <jan.kiszka@siemens.com>
+
+[ Upstream commit 57297736c08233987e5d29ce6584c6ca2a831b12 ]
+
+This resolves the follow splat and lock-up when running with PREEMPT_RT
+enabled on Hyper-V:
+
+[ 415.140818] BUG: scheduling while atomic: stress-ng-iomix/1048/0x00000002
+[ 415.140822] INFO: lockdep is turned off.
+[ 415.140823] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec ghash_clmulni_intel aesni_intel rapl binfmt_misc nls_ascii nls_cp437 vfat fat snd_pcm hyperv_drm snd_timer drm_client_lib drm_shmem_helper snd sg soundcore drm_kms_helper pcspkr hv_balloon hv_utils evdev joydev drm configfs efi_pstore nfnetlink vsock_loopback vmw_vsock_virtio_transport_common hv_sock vmw_vsock_vmci_transport vsock vmw_vmci efivarfs autofs4 ext4 crc16 mbcache jbd2 sr_mod sd_mod cdrom hv_storvsc serio_raw hid_generic scsi_transport_fc hid_hyperv scsi_mod hid hv_netvsc hyperv_keyboard scsi_common
+[ 415.140846] Preemption disabled at:
+[ 415.140847] [<ffffffffc0656171>] storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc]
+[ 415.140854] CPU: 8 UID: 0 PID: 1048 Comm: stress-ng-iomix Not tainted 6.19.0-rc7 #30 PREEMPT_{RT,(full)}
+[ 415.140856] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/04/2024
+[ 415.140857] Call Trace:
+[ 415.140861] <TASK>
+[ 415.140861] ? storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc]
+[ 415.140863] dump_stack_lvl+0x91/0xb0
+[ 415.140870] __schedule_bug+0x9c/0xc0
+[ 415.140875] __schedule+0xdf6/0x1300
+[ 415.140877] ? rtlock_slowlock_locked+0x56c/0x1980
+[ 415.140879] ? rcu_is_watching+0x12/0x60
+[ 415.140883] schedule_rtlock+0x21/0x40
+[ 415.140885] rtlock_slowlock_locked+0x502/0x1980
+[ 415.140891] rt_spin_lock+0x89/0x1e0
+[ 415.140893] hv_ringbuffer_write+0x87/0x2a0
+[ 415.140899] vmbus_sendpacket_mpb_desc+0xb6/0xe0
+[ 415.140900] ? rcu_is_watching+0x12/0x60
+[ 415.140902] storvsc_queuecommand+0x669/0xbe0 [hv_storvsc]
+[ 415.140904] ? HARDIRQ_verbose+0x10/0x10
+[ 415.140908] ? __rq_qos_issue+0x28/0x40
+[ 415.140911] scsi_queue_rq+0x760/0xd80 [scsi_mod]
+[ 415.140926] __blk_mq_issue_directly+0x4a/0xc0
+[ 415.140928] blk_mq_issue_direct+0x87/0x2b0
+[ 415.140931] blk_mq_dispatch_queue_requests+0x120/0x440
+[ 415.140933] blk_mq_flush_plug_list+0x7a/0x1a0
+[ 415.140935] __blk_flush_plug+0xf4/0x150
+[ 415.140940] __submit_bio+0x2b2/0x5c0
+[ 415.140944] ? submit_bio_noacct_nocheck+0x272/0x360
+[ 415.140946] submit_bio_noacct_nocheck+0x272/0x360
+[ 415.140951] ext4_read_bh_lock+0x3e/0x60 [ext4]
+[ 415.140995] ext4_block_write_begin+0x396/0x650 [ext4]
+[ 415.141018] ? __pfx_ext4_da_get_block_prep+0x10/0x10 [ext4]
+[ 415.141038] ext4_da_write_begin+0x1c4/0x350 [ext4]
+[ 415.141060] generic_perform_write+0x14e/0x2c0
+[ 415.141065] ext4_buffered_write_iter+0x6b/0x120 [ext4]
+[ 415.141083] vfs_write+0x2ca/0x570
+[ 415.141087] ksys_write+0x76/0xf0
+[ 415.141089] do_syscall_64+0x99/0x1490
+[ 415.141093] ? rcu_is_watching+0x12/0x60
+[ 415.141095] ? finish_task_switch.isra.0+0xdf/0x3d0
+[ 415.141097] ? rcu_is_watching+0x12/0x60
+[ 415.141098] ? lock_release+0x1f0/0x2a0
+[ 415.141100] ? rcu_is_watching+0x12/0x60
+[ 415.141101] ? finish_task_switch.isra.0+0xe4/0x3d0
+[ 415.141103] ? rcu_is_watching+0x12/0x60
+[ 415.141104] ? __schedule+0xb34/0x1300
+[ 415.141106] ? hrtimer_try_to_cancel+0x1d/0x170
+[ 415.141109] ? do_nanosleep+0x8b/0x160
+[ 415.141111] ? hrtimer_nanosleep+0x89/0x100
+[ 415.141114] ? __pfx_hrtimer_wakeup+0x10/0x10
+[ 415.141116] ? xfd_validate_state+0x26/0x90
+[ 415.141118] ? rcu_is_watching+0x12/0x60
+[ 415.141120] ? do_syscall_64+0x1e0/0x1490
+[ 415.141121] ? do_syscall_64+0x1e0/0x1490
+[ 415.141123] ? rcu_is_watching+0x12/0x60
+[ 415.141124] ? do_syscall_64+0x1e0/0x1490
+[ 415.141125] ? do_syscall_64+0x1e0/0x1490
+[ 415.141127] ? irqentry_exit+0x140/0x7e0
+[ 415.141129] entry_SYSCALL_64_after_hwframe+0x76/0x7e
+
+get_cpu() disables preemption while the spinlock hv_ringbuffer_write is
+using is converted to an rt-mutex under PREEMPT_RT.
+
+Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
+Tested-by: Florian Bezdeka <florian.bezdeka@siemens.com>
+Reviewed-by: Michael Kelley <mhklinux@outlook.com>
+Tested-by: Michael Kelley <mhklinux@outlook.com>
+Link: https://patch.msgid.link/0c7fb5cd-fb21-4760-8593-e04bade84744@siemens.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/storvsc_drv.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
+index b43d876747b76..68c837146b9ea 100644
+--- a/drivers/scsi/storvsc_drv.c
++++ b/drivers/scsi/storvsc_drv.c
+@@ -1855,8 +1855,9 @@ static int storvsc_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *scmnd)
+ cmd_request->payload_sz = payload_sz;
+
+ /* Invokes the vsc to start an IO */
+- ret = storvsc_do_io(dev, cmd_request, get_cpu());
+- put_cpu();
++ migrate_disable();
++ ret = storvsc_do_io(dev, cmd_request, smp_processor_id());
++ migrate_enable();
+
+ if (ret)
+ scsi_dma_unmap(scmnd);
+--
+2.51.0
+
--- /dev/null
+From 3192c09198a04f275c0b9d89bd5f7b24d0c439a3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 23 Feb 2026 14:56:09 +0800
+Subject: scsi: ufs: core: Fix possible NULL pointer dereference in
+ ufshcd_add_command_trace()
+
+From: Peter Wang <peter.wang@mediatek.com>
+
+[ Upstream commit 30df81f2228d65bddf492db3929d9fcaffd38fc5 ]
+
+The kernel log indicates a crash in ufshcd_add_command_trace, due to a NULL
+pointer dereference when accessing hwq->id. This can happen if
+ufshcd_mcq_req_to_hwq() returns NULL.
+
+This patch adds a NULL check for hwq before accessing its id field to
+prevent a kernel crash.
+
+Kernel log excerpt:
+[<ffffffd5d192dc4c>] notify_die+0x4c/0x8c
+[<ffffffd5d1814e58>] __die+0x60/0xb0
+[<ffffffd5d1814d64>] die+0x4c/0xe0
+[<ffffffd5d181575c>] die_kernel_fault+0x74/0x88
+[<ffffffd5d1864db4>] __do_kernel_fault+0x314/0x318
+[<ffffffd5d2a3cdf8>] do_page_fault+0xa4/0x5f8
+[<ffffffd5d2a3cd34>] do_translation_fault+0x34/0x54
+[<ffffffd5d1864524>] do_mem_abort+0x50/0xa8
+[<ffffffd5d2a297dc>] el1_abort+0x3c/0x64
+[<ffffffd5d2a29718>] el1h_64_sync_handler+0x44/0xcc
+[<ffffffd5d181133c>] el1h_64_sync+0x80/0x88
+[<ffffffd5d255c1dc>] ufshcd_add_command_trace+0x23c/0x320
+[<ffffffd5d255bad8>] ufshcd_compl_one_cqe+0xa4/0x404
+[<ffffffd5d2572968>] ufshcd_mcq_poll_cqe_lock+0xac/0x104
+[<ffffffd5d11c7460>] ufs_mtk_mcq_intr+0x54/0x74 [ufs_mediatek_mod]
+[<ffffffd5d19ab92c>] __handle_irq_event_percpu+0xc8/0x348
+[<ffffffd5d19abca8>] handle_irq_event+0x3c/0xa8
+[<ffffffd5d19b1f0c>] handle_fasteoi_irq+0xf8/0x294
+[<ffffffd5d19aa778>] generic_handle_domain_irq+0x54/0x80
+[<ffffffd5d18102bc>] gic_handle_irq+0x1d4/0x330
+[<ffffffd5d1838210>] call_on_irq_stack+0x44/0x68
+[<ffffffd5d183af30>] do_interrupt_handler+0x78/0xd8
+[<ffffffd5d2a29c00>] el1_interrupt+0x48/0xa8
+[<ffffffd5d2a29ba8>] el1h_64_irq_handler+0x14/0x24
+[<ffffffd5d18113c4>] el1h_64_irq+0x80/0x88
+[<ffffffd5d2527fb4>] arch_local_irq_enable+0x4/0x1c
+[<ffffffd5d25282e4>] cpuidle_enter+0x34/0x54
+[<ffffffd5d195a678>] do_idle+0x1dc/0x2f8
+[<ffffffd5d195a7c4>] cpu_startup_entry+0x30/0x3c
+[<ffffffd5d18155c4>] secondary_start_kernel+0x134/0x1ac
+[<ffffffd5d18640bc>] __secondary_switched+0xc4/0xcc
+
+Signed-off-by: Peter Wang <peter.wang@mediatek.com>
+Reviewed-by: Bart Van Assche <bvanassche@acm.org>
+Link: https://patch.msgid.link/20260223065657.2432447-1-peter.wang@mediatek.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/ufs/core/ufshcd.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
+index 4f7fc28207245..403f8989b1448 100644
+--- a/drivers/ufs/core/ufshcd.c
++++ b/drivers/ufs/core/ufshcd.c
+@@ -516,8 +516,8 @@ static void ufshcd_add_command_trace(struct ufs_hba *hba, unsigned int tag,
+
+ if (hba->mcq_enabled) {
+ struct ufs_hw_queue *hwq = ufshcd_mcq_req_to_hwq(hba, rq);
+-
+- hwq_id = hwq->id;
++ if (hwq)
++ hwq_id = hwq->id;
+ } else {
+ doorbell = ufshcd_readl(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL);
+ }
+--
+2.51.0
+
--- /dev/null
+From d55271681ee84caf6b2b239f8e43975a1a5676db Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 24 Feb 2026 14:32:28 +0800
+Subject: scsi: ufs: core: Fix shift out of bounds when MAXQ=32
+
+From: wangshuaiwei <wangshuaiwei1@xiaomi.com>
+
+[ Upstream commit 2f38fd99c0004676d835ae96ac4f3b54edc02c82 ]
+
+According to JESD223F, the maximum number of queues (MAXQ) is 32. When MCQ
+is enabled and ESI is disabled, nr_hw_queues=32 causes a shift overflow
+problem.
+
+Fix this by using 64-bit intermediate values to handle the nr_hw_queues=32
+case safely.
+
+Signed-off-by: wangshuaiwei <wangshuaiwei1@xiaomi.com>
+Reviewed-by: Bart Van Assche <bvanassche@acm.org>
+Link: https://patch.msgid.link/20260224063228.50112-1-wangshuaiwei1@xiaomi.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/ufs/core/ufshcd.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
+index 403f8989b1448..fe1425ea6718f 100644
+--- a/drivers/ufs/core/ufshcd.c
++++ b/drivers/ufs/core/ufshcd.c
+@@ -7078,7 +7078,7 @@ static irqreturn_t ufshcd_handle_mcq_cq_events(struct ufs_hba *hba)
+
+ ret = ufshcd_vops_get_outstanding_cqs(hba, &outstanding_cqs);
+ if (ret)
+- outstanding_cqs = (1U << hba->nr_hw_queues) - 1;
++ outstanding_cqs = (1ULL << hba->nr_hw_queues) - 1;
+
+ /* Exclude the poll queues */
+ nr_queues = hba->nr_hw_queues - hba->nr_queues[HCTX_TYPE_POLL];
+--
+2.51.0
+
--- /dev/null
+From 5e5ef687121cb10b169c55daca5a77d8d3da965e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 11 Feb 2026 15:01:05 +0900
+Subject: scsi: ufs: core: Reset urgent_bkops_lvl to allow runtime PM power
+ mode
+
+From: Won Jung <wone.jung@samsung.com>
+
+[ Upstream commit 5b313760059c9df7d60aba7832279bcb81b4aec0 ]
+
+Ensures that UFS Runtime PM can achieve power saving after System PM
+suspend by resetting hba->urgent_bkops_lvl. Also modify the
+ufshcd_bkops_exception_event_handler to avoid setting urgent_bkops_lvl when
+status is 0, which helps maintain optimal power management.
+
+On UFS devices supporting UFSHCD_CAP_AUTO_BKOPS_SUSPEND, a BKOPS exception
+event can lead to a situation where UFS Runtime PM can't enter low-power
+mode states even after the BKOPS exception has been resolved.
+
+BKOPS exception with bkops status 0 occurs, the driver logs:
+
+ "ufshcd_bkops_exception_event_handler: device raised urgent BKOPS exception for bkops status 0"
+
+When a BKOPS exception occurs, ufshcd_bkops_exception_event_handler() reads
+the BKOPS status and sets hba->urgent_bkops_lvl to BKOPS_STATUS_NO_OP(0).
+This allows the device to perform Runtime PM without changing the UFS power
+mode. (__ufshcd_wl_suspend(hba, UFS_RUNTIME_PM))
+
+During system PM suspend, ufshcd_disable_auto_bkops() is called, disabling
+auto bkops. After UFS System PM Resume, when runtime PM attempts to suspend
+again, ufshcd_urgent_bkops() is invoked. Since hba->urgent_bkops_lvl
+remains at BKOPS_STATUS_NO_OP(0), ufshcd_enable_auto_bkops() is triggered.
+
+However, in ufshcd_bkops_ctrl(), the driver compares the current BKOPS
+status with hba->urgent_bkops_lvl, and only enables auto bkops if
+curr_status >= hba->urgent_bkops_lvl. Since both values are 0, the
+condition is met
+
+As a result, __ufshcd_wl_suspend(hba, UFS_RUNTIME_PM) skips power mode
+transitions and remains in an active state, preventing power saving even
+though no urgent BKOPS condition exists.
+
+Signed-off-by: Won Jung <wone.jung@samsung.com>
+Reviewed-by: Peter Wang <peter.wang@mediatek.com>
+Link: https://patch.msgid.link/1891546521.01770806581968.JavaMail.epsvc@epcpadp2new
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/ufs/core/ufshcd.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
+index dae23ec4fcea8..4f7fc28207245 100644
+--- a/drivers/ufs/core/ufshcd.c
++++ b/drivers/ufs/core/ufshcd.c
+@@ -5946,6 +5946,7 @@ static int ufshcd_disable_auto_bkops(struct ufs_hba *hba)
+
+ hba->auto_bkops_enabled = false;
+ trace_ufshcd_auto_bkops_state(hba, "Disabled");
++ hba->urgent_bkops_lvl = BKOPS_STATUS_PERF_IMPACT;
+ hba->is_urgent_bkops_lvl_checked = false;
+ out:
+ return err;
+@@ -6049,7 +6050,7 @@ static void ufshcd_bkops_exception_event_handler(struct ufs_hba *hba)
+ * impacted or critical. Handle these device by determining their urgent
+ * bkops status at runtime.
+ */
+- if (curr_status < BKOPS_STATUS_PERF_IMPACT) {
++ if ((curr_status > BKOPS_STATUS_NO_OP) && (curr_status < BKOPS_STATUS_PERF_IMPACT)) {
+ dev_err(hba->dev, "%s: device raised urgent BKOPS exception for bkops status %d\n",
+ __func__, curr_status);
+ /* update the current status as the urgent bkops level */
+--
+2.51.0
+
--- /dev/null
+scsi-storvsc-fix-scheduling-while-atomic-on-preempt_.patch
+acpi-pm-save-nvs-memory-on-lenovo-g70-35.patch
+scsi-ufs-core-reset-urgent_bkops_lvl-to-allow-runtim.patch
+fs-init-flags_valid-before-calling-vfs_fileattr_get.patch
+scsi-mpi3mr-add-null-checks-when-resetting-request-a.patch
+alsa-hda-realtek-fix-speaker-pop-on-star-labs-starfi.patch
+unshare-fix-unshare_fs-handling.patch
+wifi-mac80211-set-default-wmm-parameters-on-all-link.patch
+acpi-osi-add-dmi-quirk-for-acer-aspire-one-d255.patch
+scsi-ses-fix-devices-attaching-to-different-hosts.patch
+asoc-amd-yc-add-asus-expertbook-bm1503cda-to-quirk-t.patch
+asoc-cs42l43-report-insert-for-exotic-peripherals.patch
+scsi-ufs-core-fix-possible-null-pointer-dereference-.patch
+scsi-ufs-core-fix-shift-out-of-bounds-when-maxq-32.patch
+alsa-usb-audio-avoid-implicit-feedback-mode-on-diyin.patch
+drm-amdgpu-vcn5-add-smu-dpm-interface-type.patch
+alsa-usb-audio-check-max-frame-size-for-implicit-fee.patch
+powerpc-uaccess-fix-inline-assembly-for-clang-build-.patch
+kexec-include-kernel-end-even-without-crashkernel.patch
+powerpc-kexec-core-use-big-endian-types-for-crash-va.patch
+powerpc-crash-adjust-the-elfcorehdr-size.patch
+remoteproc-sysmon-correct-subsys_name_len-type-in-qm.patch
+remoteproc-mediatek-unprepare-scp-clock-during-syste.patch
+powerpc-83xx-km83xx-fix-keymile-vendor-prefix.patch
+smb-server-fix-another-refcount-leak-in-smb2_open.patch
--- /dev/null
+From c58e53402d1ab4160276d0a05c5e06c783cb7091 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 26 Feb 2026 21:54:21 -0800
+Subject: smb/server: Fix another refcount leak in smb2_open()
+
+From: Guenter Roeck <linux@roeck-us.net>
+
+[ Upstream commit c15e7c62feb3751cbdd458555819df1d70374890 ]
+
+If ksmbd_override_fsids() fails, we jump to err_out2. At that point, fp is
+NULL because it hasn't been assigned dh_info.fp yet, so ksmbd_fd_put(work,
+fp) will not be called. However, dh_info.fp was already inserted into the
+session file table by ksmbd_reopen_durable_fd(), so it will leak in the
+session file table until the session is closed.
+
+Move fp = dh_info.fp; ahead of the ksmbd_override_fsids() check to fix the
+problem.
+
+Found by an experimental AI code review agent at Google.
+
+Fixes: c8efcc786146a ("ksmbd: add support for durable handles v1/v2")
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Reviewed-by: ChenXiaoSong <chenxiaosong@kylinos.cn>
+Acked-by: Namjae Jeon <linkinjeon@kernel.org>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/smb/server/smb2pdu.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c
+index e52b9136abbff..37b14a2396147 100644
+--- a/fs/smb/server/smb2pdu.c
++++ b/fs/smb/server/smb2pdu.c
+@@ -3020,13 +3020,14 @@ int smb2_open(struct ksmbd_work *work)
+ goto err_out2;
+ }
+
++ fp = dh_info.fp;
++
+ if (ksmbd_override_fsids(work)) {
+ rc = -ENOMEM;
+ ksmbd_put_durable_fd(dh_info.fp);
+ goto err_out2;
+ }
+
+- fp = dh_info.fp;
+ file_info = FILE_OPENED;
+
+ rc = ksmbd_vfs_getattr(&fp->filp->f_path, &stat);
+--
+2.51.0
+
--- /dev/null
+From 236130a4a1320bb00b278d2e2d6519f1013f32ef Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 7 Feb 2026 08:25:24 +0000
+Subject: unshare: fix unshare_fs() handling
+
+From: Al Viro <viro@zeniv.linux.org.uk>
+
+[ Upstream commit 6c4b2243cb6c0755159bd567130d5e12e7b10d9f ]
+
+There's an unpleasant corner case in unshare(2), when we have a
+CLONE_NEWNS in flags and current->fs hadn't been shared at all; in that
+case copy_mnt_ns() gets passed current->fs instead of a private copy,
+which causes interesting warts in proof of correctness]
+
+> I guess if private means fs->users == 1, the condition could still be true.
+
+Unfortunately, it's worse than just a convoluted proof of correctness.
+Consider the case when we have CLONE_NEWCGROUP in addition to CLONE_NEWNS
+(and current->fs->users == 1).
+
+We pass current->fs to copy_mnt_ns(), all right. Suppose it succeeds and
+flips current->fs->{pwd,root} to corresponding locations in the new namespace.
+Now we proceed to copy_cgroup_ns(), which fails (e.g. with -ENOMEM).
+We call put_mnt_ns() on the namespace created by copy_mnt_ns(), it's
+destroyed and its mount tree is dissolved, but... current->fs->root and
+current->fs->pwd are both left pointing to now detached mounts.
+
+They are pinning those, so it's not a UAF, but it leaves the calling
+process with unshare(2) failing with -ENOMEM _and_ leaving it with
+pwd and root on detached isolated mounts. The last part is clearly a bug.
+
+There is other fun related to that mess (races with pivot_root(), including
+the one between pivot_root() and fork(), of all things), but this one
+is easy to isolate and fix - treat CLONE_NEWNS as "allocate a new
+fs_struct even if it hadn't been shared in the first place". Sure, we could
+go for something like "if both CLONE_NEWNS *and* one of the things that might
+end up failing after copy_mnt_ns() call in create_new_namespaces() are set,
+force allocation of new fs_struct", but let's keep it simple - the cost
+of copy_fs_struct() is trivial.
+
+Another benefit is that copy_mnt_ns() with CLONE_NEWNS *always* gets
+a freshly allocated fs_struct, yet to be attached to anything. That
+seriously simplifies the analysis...
+
+FWIW, that bug had been there since the introduction of unshare(2) ;-/
+
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Link: https://patch.msgid.link/20260207082524.GE3183987@ZenIV
+Tested-by: Waiman Long <longman@redhat.com>
+Signed-off-by: Christian Brauner <brauner@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/fork.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/kernel/fork.c b/kernel/fork.c
+index 3da0f08615a95..924a9e10106b3 100644
+--- a/kernel/fork.c
++++ b/kernel/fork.c
+@@ -3040,7 +3040,7 @@ static int unshare_fs(unsigned long unshare_flags, struct fs_struct **new_fsp)
+ return 0;
+
+ /* don't need lock here; in the worst case we'll do useless copy */
+- if (fs->users == 1)
++ if (!(unshare_flags & CLONE_NEWNS) && fs->users == 1)
+ return 0;
+
+ *new_fsp = copy_fs_struct(fs);
+--
+2.51.0
+
--- /dev/null
+From 31fff3542dfc6405bcd9e8e8614d6e4feb5e01fb Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 5 Feb 2026 15:12:16 +0530
+Subject: wifi: mac80211: set default WMM parameters on all links
+
+From: Ramanathan Choodamani <quic_rchoodam@quicinc.com>
+
+[ Upstream commit 2259d14499d16b115ef8d5d2ddc867e2be7cb5b5 ]
+
+Currently, mac80211 only initializes default WMM parameters
+on the deflink during do_open(). For MLO cases, this
+leaves the additional links without proper WMM defaults
+if hostapd does not supply per-link WMM parameters, leading
+to inconsistent QoS behavior across links.
+
+Set default WMM parameters for each link during
+ieee80211_vif_update_links(), because this ensures all
+individual links in an MLD have valid WMM settings during
+bring-up and behave consistently across different BSS.
+
+Signed-off-by: Ramanathan Choodamani <quic_rchoodam@quicinc.com>
+Signed-off-by: Aishwarya R <aishwarya.r@oss.qualcomm.com>
+Link: https://patch.msgid.link/20260205094216.3093542-1-aishwarya.r@oss.qualcomm.com
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/mac80211/link.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/net/mac80211/link.c b/net/mac80211/link.c
+index 4a19b765ccb69..05b0472bda40e 100644
+--- a/net/mac80211/link.c
++++ b/net/mac80211/link.c
+@@ -286,6 +286,7 @@ static int ieee80211_vif_update_links(struct ieee80211_sub_if_data *sdata,
+ struct ieee80211_bss_conf *old[IEEE80211_MLD_MAX_NUM_LINKS];
+ struct ieee80211_link_data *old_data[IEEE80211_MLD_MAX_NUM_LINKS];
+ bool use_deflink = old_links == 0; /* set for error case */
++ bool non_sta = sdata->vif.type != NL80211_IFTYPE_STATION;
+
+ lockdep_assert_wiphy(sdata->local->hw.wiphy);
+
+@@ -342,6 +343,7 @@ static int ieee80211_vif_update_links(struct ieee80211_sub_if_data *sdata,
+ link = links[link_id];
+ ieee80211_link_init(sdata, link_id, &link->data, &link->conf);
+ ieee80211_link_setup(&link->data);
++ ieee80211_set_wmm_default(&link->data, true, non_sta);
+ }
+
+ if (new_links == 0)
+--
+2.51.0
+
--- /dev/null
+From c085f764b8ceea36bbf8901829c656af85152fd8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 22 Feb 2026 23:52:40 -0300
+Subject: ACPI: OSI: Add DMI quirk for Acer Aspire One D255
+
+From: Sofia Schneider <sofia@schn.dev>
+
+[ Upstream commit 5ede90206273ff156a778254f0f972a55e973c89 ]
+
+The screen backlight turns off during boot (specifically during udev device
+initialization) when returning true for _OSI("Windows 2009").
+
+Analyzing the device's DSDT reveals that the firmware takes a different
+code path when Windows 7 is reported, which leads to the backlight shutoff.
+Add a DMI quirk to invoke dmi_disable_osi_win7 for this model.
+
+Signed-off-by: Sofia Schneider <sofia@schn.dev>
+Link: https://patch.msgid.link/20260223025240.518509-1-sofia@schn.dev
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/acpi/osi.c | 13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+diff --git a/drivers/acpi/osi.c b/drivers/acpi/osi.c
+index f2c943b934be0..9470f1830ff50 100644
+--- a/drivers/acpi/osi.c
++++ b/drivers/acpi/osi.c
+@@ -389,6 +389,19 @@ static const struct dmi_system_id acpi_osi_dmi_table[] __initconst = {
+ },
+ },
+
++ /*
++ * The screen backlight turns off during udev device creation
++ * when returning true for _OSI("Windows 2009")
++ */
++ {
++ .callback = dmi_disable_osi_win7,
++ .ident = "Acer Aspire One D255",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "AOD255"),
++ },
++ },
++
+ /*
+ * The wireless hotkey does not work on those machines when
+ * returning true for _OSI("Windows 2012")
+--
+2.51.0
+
--- /dev/null
+From c8d8a4cde68777b3c924b922680184ef5dfe5f11 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 5 Feb 2026 23:05:02 +0100
+Subject: ACPI: PM: Save NVS memory on Lenovo G70-35
+
+From: Piotr Mazek <pmazek@outlook.com>
+
+[ Upstream commit 023cd6d90f8aa2ef7b72d84be84a18e61ecebd64 ]
+
+[821d6f0359b0614792ab8e2fb93b503e25a65079] prevented machines
+produced later than 2012 from saving NVS region to accelerate S3.
+
+Despite being made after 2012, Lenovo G70-35 still needs NVS memory
+saving during S3. A quirk is introduced for this platform.
+
+Signed-off-by: Piotr Mazek <pmazek@outlook.com>
+[ rjw: Subject adjustment ]
+Link: https://patch.msgid.link/GV2PPF3CD5B63CC2442EE3F76F8443EAD90D499A@GV2PPF3CD5B63CC.EURP251.PROD.OUTLOOK.COM
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/acpi/sleep.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
+index 66ec81e306d47..132a9df984713 100644
+--- a/drivers/acpi/sleep.c
++++ b/drivers/acpi/sleep.c
+@@ -386,6 +386,14 @@ static const struct dmi_system_id acpisleep_dmi_table[] __initconst = {
+ DMI_MATCH(DMI_PRODUCT_NAME, "80E1"),
+ },
+ },
++ {
++ .callback = init_nvs_save_s3,
++ .ident = "Lenovo G70-35",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "80Q5"),
++ },
++ },
+ /*
+ * ThinkPad X1 Tablet(2016) cannot do suspend-to-idle using
+ * the Low Power S0 Idle firmware interface (see
+--
+2.51.0
+
--- /dev/null
+From 5a7030d34dc493df688050806aa2cee58debb754 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 19 Feb 2026 20:14:26 +0000
+Subject: ALSA: hda/realtek: Fix speaker pop on Star Labs StarFighter
+
+From: Sean Rhodes <sean@starlabs.systems>
+
+[ Upstream commit 1cb3c20688fc8380c9b365d03aea7e84faf6a9fd ]
+
+On Star Labs StarFighter (Realtek ALC233/235), the internal speakers can
+emit an audible pop when entering or leaving runtime suspend.
+
+Mute the speaker output paths via snd_hda_gen_shutup_speakers() in the
+Realtek shutup callback before the codec is powered down.
+
+This is enough to avoid the pop without special EAPD handling.
+
+Test results:
+- runtime PM pop fixed
+- still reaches D3 (PCI 0000:00:1f.3 power_state=D3hot)
+- does not address pops on cold boot (G3 exit) or around display manager
+ start/shutdown
+
+journalctl -k (boot):
+- snd_hda_codec_alc269 hdaudioC0D0: ALC233: picked fixup for PCI SSID
+ 7017:2014
+- snd_hda_codec_alc269 hdaudioC0D0: autoconfig for ALC233: line_outs=1
+ (0x1b/0x0/0x0/0x0/0x0) type:speaker
+
+Suggested-by: Takashi Iwai <tiwai@suse.com>
+Tested-by: Sean Rhodes <sean@starlabs.systems>
+Signed-off-by: Sean Rhodes <sean@starlabs.systems>
+Link: https://patch.msgid.link/4d5fb71b132bb283fd41c622b8413770b2065242.1771532060.git.sean@starlabs.systems
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/hda/codecs/realtek/alc269.c | 25 +++++++++++++++++++++++++
+ 1 file changed, 25 insertions(+)
+
+diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
+index f5719e630d28a..4c49f1195e1bc 100644
+--- a/sound/hda/codecs/realtek/alc269.c
++++ b/sound/hda/codecs/realtek/alc269.c
+@@ -1017,6 +1017,24 @@ static int alc269_resume(struct hda_codec *codec)
+ return 0;
+ }
+
++#define STARLABS_STARFIGHTER_SHUTUP_DELAY_MS 30
++
++static void starlabs_starfighter_shutup(struct hda_codec *codec)
++{
++ if (snd_hda_gen_shutup_speakers(codec))
++ msleep(STARLABS_STARFIGHTER_SHUTUP_DELAY_MS);
++}
++
++static void alc233_fixup_starlabs_starfighter(struct hda_codec *codec,
++ const struct hda_fixup *fix,
++ int action)
++{
++ struct alc_spec *spec = codec->spec;
++
++ if (action == HDA_FIXUP_ACT_PRE_PROBE)
++ spec->shutup = starlabs_starfighter_shutup;
++}
++
+ static void alc269_fixup_pincfg_no_hp_to_lineout(struct hda_codec *codec,
+ const struct hda_fixup *fix, int action)
+ {
+@@ -4040,6 +4058,7 @@ enum {
+ ALC245_FIXUP_CLEVO_NOISY_MIC,
+ ALC269_FIXUP_VAIO_VJFH52_MIC_NO_PRESENCE,
+ ALC233_FIXUP_MEDION_MTL_SPK,
++ ALC233_FIXUP_STARLABS_STARFIGHTER,
+ ALC294_FIXUP_BASS_SPEAKER_15,
+ ALC283_FIXUP_DELL_HP_RESUME,
+ ALC294_FIXUP_ASUS_CS35L41_SPI_2,
+@@ -6500,6 +6519,10 @@ static const struct hda_fixup alc269_fixups[] = {
+ { }
+ },
+ },
++ [ALC233_FIXUP_STARLABS_STARFIGHTER] = {
++ .type = HDA_FIXUP_FUNC,
++ .v.func = alc233_fixup_starlabs_starfighter,
++ },
+ [ALC294_FIXUP_BASS_SPEAKER_15] = {
+ .type = HDA_FIXUP_FUNC,
+ .v.func = alc294_fixup_bass_speaker_15,
+@@ -7662,6 +7685,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
+ SND_PCI_QUIRK(0x2782, 0x1705, "MEDION E15433", ALC269VC_FIXUP_INFINIX_Y4_MAX),
+ SND_PCI_QUIRK(0x2782, 0x1707, "Vaio VJFE-ADL", ALC298_FIXUP_SPK_VOLUME),
+ SND_PCI_QUIRK(0x2782, 0x4900, "MEDION E15443", ALC233_FIXUP_MEDION_MTL_SPK),
++ SND_PCI_QUIRK(0x7017, 0x2014, "Star Labs StarFighter", ALC233_FIXUP_STARLABS_STARFIGHTER),
+ SND_PCI_QUIRK(0x8086, 0x2074, "Intel NUC 8", ALC233_FIXUP_INTEL_NUC8_DMIC),
+ SND_PCI_QUIRK(0x8086, 0x2080, "Intel NUC 8 Rugged", ALC256_FIXUP_INTEL_NUC8_RUGGED),
+ SND_PCI_QUIRK(0x8086, 0x2081, "Intel NUC 10", ALC256_FIXUP_INTEL_NUC10),
+@@ -7758,6 +7782,7 @@ static const struct hda_model_fixup alc269_fixup_models[] = {
+ {.id = ALC298_FIXUP_TPT470_DOCK_FIX, .name = "tpt470-dock-fix"},
+ {.id = ALC298_FIXUP_TPT470_DOCK, .name = "tpt470-dock"},
+ {.id = ALC233_FIXUP_LENOVO_MULTI_CODECS, .name = "dual-codecs"},
++ {.id = ALC233_FIXUP_STARLABS_STARFIGHTER, .name = "starlabs-starfighter"},
+ {.id = ALC700_FIXUP_INTEL_REFERENCE, .name = "alc700-ref"},
+ {.id = ALC269_FIXUP_SONY_VAIO, .name = "vaio"},
+ {.id = ALC269_FIXUP_DELL_M101Z, .name = "dell-m101z"},
+--
+2.51.0
+
--- /dev/null
+From b2eb2c5b8c02819c2451c4616f9c5ea4706fce3b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 25 Feb 2026 09:52:30 +0100
+Subject: ALSA: usb-audio: Avoid implicit feedback mode on DIYINHK USB Audio
+ 2.0
+
+From: Takashi Iwai <tiwai@suse.de>
+
+[ Upstream commit c5bf24c8aba1ff711226ee0f039ff01a5754692b ]
+
+Although DIYINHK USB Audio 2.0 (ID 20b1:2009) shows the implicit
+feedback source for the capture stream, this would cause several
+problems for the playback. Namely, the device can get wMaxPackSize
+1024 for 24/32 bit format with 6 channels, and when a high sample rate
+like 352.8kHz or 384kHz is played, the packet size overflows the max
+limit. Also, the device has another two playback altsets, and those
+aren't properly handled with the implicit feedback.
+
+Since the device has been working well even before introducing the
+implicit feedback, we can assume that it works fine in the async mode.
+This patch adds the explicit skip of the implicit fb detection to make
+the playback running in the async mode.
+
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=221076
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Link: https://patch.msgid.link/20260225085233.316306-4-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/usb/quirks.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
+index a89ea2233180a..caca0e586d832 100644
+--- a/sound/usb/quirks.c
++++ b/sound/usb/quirks.c
+@@ -2363,6 +2363,8 @@ static const struct usb_audio_quirk_flags_table quirk_flags_table[] = {
+ QUIRK_FLAG_SHARE_MEDIA_DEVICE | QUIRK_FLAG_ALIGN_TRANSFER),
+ DEVICE_FLG(0x2040, 0x7281, /* Hauppauge HVR-950Q-MXL */
+ QUIRK_FLAG_SHARE_MEDIA_DEVICE | QUIRK_FLAG_ALIGN_TRANSFER),
++ DEVICE_FLG(0x20b1, 0x2009, /* XMOS Ltd DIYINHK USB Audio 2.0 */
++ QUIRK_FLAG_SKIP_IMPLICIT_FB | QUIRK_FLAG_DSD_RAW),
+ DEVICE_FLG(0x2040, 0x8200, /* Hauppauge Woodbury */
+ QUIRK_FLAG_SHARE_MEDIA_DEVICE | QUIRK_FLAG_ALIGN_TRANSFER),
+ DEVICE_FLG(0x21b4, 0x0081, /* AudioQuest DragonFly */
+--
+2.51.0
+
--- /dev/null
+From 6d1d866de250be095805f8bdc364306314546bdc Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 25 Feb 2026 09:52:29 +0100
+Subject: ALSA: usb-audio: Check max frame size for implicit feedback mode, too
+
+From: Takashi Iwai <tiwai@suse.de>
+
+[ Upstream commit 7cb2a5422f5bbdf1cf32eae0eda41000485b9346 ]
+
+When the packet sizes are taken from the capture stream in the
+implicit feedback mode, the sizes might be larger than the upper
+boundary defined by the descriptor. As already done for other
+transfer modes, we have to cap the sizes accordingly at sending,
+otherwise this would lead to an error in USB core at submission of
+URBs.
+
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=221076
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Link: https://patch.msgid.link/20260225085233.316306-3-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/usb/endpoint.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
+index 686f095290673..1a020ea558755 100644
+--- a/sound/usb/endpoint.c
++++ b/sound/usb/endpoint.c
+@@ -221,6 +221,7 @@ int snd_usb_endpoint_next_packet_size(struct snd_usb_endpoint *ep,
+
+ packet = ctx->packet_size[idx];
+ if (packet) {
++ packet = min(packet, ep->maxframesize);
+ if (avail && packet >= avail)
+ return -EAGAIN;
+ return packet;
+--
+2.51.0
+
--- /dev/null
+From c3e3d434904d9807fbeeb2ac2f7bcf1a7f7caa7a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 21 Feb 2026 12:48:13 +0100
+Subject: ASoC: amd: yc: Add ASUS EXPERTBOOK BM1503CDA to quirk table
+
+From: Azamat Almazbek uulu <almazbek1608@gmail.com>
+
+[ Upstream commit 32fc4168fa56f6301d858c778a3d712774e9657e ]
+
+The ASUS ExpertBook BM1503CDA (Ryzen 5 7535U, Barcelo-R) has an
+internal DMIC connected through the AMD ACP (Audio CoProcessor)
+but is missing from the DMI quirk table, so the acp6x machine
+driver probe returns -ENODEV and no DMIC capture device is created.
+
+Add the DMI entry so the internal microphone works out of the box.
+
+Signed-off-by: Azamat Almazbek uulu <almazbek1608@gmail.com>
+Reviewed-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
+Link: https://patch.msgid.link/20260221114813.5610-1-almazbek1608@gmail.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/soc/amd/yc/acp6x-mach.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c
+index f1a63475100d1..7af4daeb4c6ff 100644
+--- a/sound/soc/amd/yc/acp6x-mach.c
++++ b/sound/soc/amd/yc/acp6x-mach.c
+@@ -703,6 +703,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = {
+ DMI_MATCH(DMI_PRODUCT_NAME, "Vivobook_ASUSLaptop M6501RR_M6501RR"),
+ }
+ },
++ {
++ .driver_data = &acp6x_card,
++ .matches = {
++ DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK COMPUTER INC."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "ASUS EXPERTBOOK BM1503CDA"),
++ }
++ },
+ {}
+ };
+
+--
+2.51.0
+
--- /dev/null
+From bd3b668e95280e9f2802938b612b732089c7a3e5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 23 Feb 2026 09:36:16 +0000
+Subject: ASoC: cs42l43: Report insert for exotic peripherals
+
+From: Charles Keepax <ckeepax@opensource.cirrus.com>
+
+[ Upstream commit 6510e1324bcdc8caf21f6d17efe27604c48f0d64 ]
+
+For some exotic peripherals the type detect can return a reserved value
+of 0x4. This will currently return an error and not report anything to
+user-space, update this to report the insert normally.
+
+Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
+Link: https://patch.msgid.link/20260223093616.3800350-1-ckeepax@opensource.cirrus.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/soc/codecs/cs42l43-jack.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/sound/soc/codecs/cs42l43-jack.c b/sound/soc/codecs/cs42l43-jack.c
+index b83bc4de1301d..3e04e6897b142 100644
+--- a/sound/soc/codecs/cs42l43-jack.c
++++ b/sound/soc/codecs/cs42l43-jack.c
+@@ -699,6 +699,7 @@ static int cs42l43_run_type_detect(struct cs42l43_codec *priv)
+ switch (type & CS42L43_HSDET_TYPE_STS_MASK) {
+ case 0x0: // CTIA
+ case 0x1: // OMTP
++ case 0x4:
+ return cs42l43_run_load_detect(priv, true);
+ case 0x2: // 3-pole
+ return cs42l43_run_load_detect(priv, false);
+--
+2.51.0
+
--- /dev/null
+From 803f0f130e1768f3eeb4f4b6ee2b647526704ed9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 21 Feb 2026 10:03:32 +0530
+Subject: drm/amdgpu/vcn5: Add SMU dpm interface type
+
+From: sguttula <suresh.guttula@amd.com>
+
+[ Upstream commit a5fe1a54513196e4bc8f9170006057dc31e7155e ]
+
+This will set AMDGPU_VCN_SMU_DPM_INTERFACE_* smu_type
+based on soc type and fixing ring timeout issue seen
+for DPM enabled case.
+
+Signed-off-by: sguttula <suresh.guttula@amd.com>
+Reviewed-by: Pratik Vishwakarma <Pratik.Vishwakarma@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+(cherry picked from commit f0f23c315b38c55e8ce9484cf59b65811f350630)
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c b/drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c
+index 0202df5db1e12..6109124f852e5 100644
+--- a/drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c
++++ b/drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c
+@@ -174,6 +174,10 @@ static int vcn_v5_0_0_sw_init(struct amdgpu_ip_block *ip_block)
+ fw_shared->present_flag_0 = cpu_to_le32(AMDGPU_FW_SHARED_FLAG_0_UNIFIED_QUEUE);
+ fw_shared->sq.is_enabled = 1;
+
++ fw_shared->present_flag_0 |= cpu_to_le32(AMDGPU_VCN_SMU_DPM_INTERFACE_FLAG);
++ fw_shared->smu_dpm_interface.smu_interface_type = (adev->flags & AMD_IS_APU) ?
++ AMDGPU_VCN_SMU_DPM_INTERFACE_APU : AMDGPU_VCN_SMU_DPM_INTERFACE_DGPU;
++
+ if (amdgpu_vcnfw_log)
+ amdgpu_vcn_fwlog_init(&adev->vcn.inst[i]);
+
+--
+2.51.0
+
--- /dev/null
+From e1904d60e7d26566fde80d8d607d6af53d838b09 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 6 Feb 2026 14:20:28 +0800
+Subject: fs: init flags_valid before calling vfs_fileattr_get
+
+From: Edward Adam Davis <eadavis@qq.com>
+
+[ Upstream commit cb184dd19154fc486fa3d9e02afe70a97e54e055 ]
+
+syzbot reported a uninit-value bug in [1].
+
+Similar to the "*get" context where the kernel's internal file_kattr
+structure is initialized before calling vfs_fileattr_get(), we should
+use the same mechanism when using fa.
+
+[1]
+BUG: KMSAN: uninit-value in fuse_fileattr_get+0xeb4/0x1450 fs/fuse/ioctl.c:517
+ fuse_fileattr_get+0xeb4/0x1450 fs/fuse/ioctl.c:517
+ vfs_fileattr_get fs/file_attr.c:94 [inline]
+ __do_sys_file_getattr fs/file_attr.c:416 [inline]
+
+Local variable fa.i created at:
+ __do_sys_file_getattr fs/file_attr.c:380 [inline]
+ __se_sys_file_getattr+0x8c/0xbd0 fs/file_attr.c:372
+
+Reported-by: syzbot+7c31755f2cea07838b0c@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=7c31755f2cea07838b0c
+Tested-by: syzbot+7c31755f2cea07838b0c@syzkaller.appspotmail.com
+Signed-off-by: Edward Adam Davis <eadavis@qq.com>
+Link: https://patch.msgid.link/tencent_B6C4583771D76766D71362A368696EC3B605@qq.com
+Signed-off-by: Christian Brauner <brauner@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/file_attr.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/fs/file_attr.c b/fs/file_attr.c
+index 13cdb31a3e947..4889cf59b2562 100644
+--- a/fs/file_attr.c
++++ b/fs/file_attr.c
+@@ -377,7 +377,7 @@ SYSCALL_DEFINE5(file_getattr, int, dfd, const char __user *, filename,
+ struct filename *name __free(putname) = NULL;
+ unsigned int lookup_flags = 0;
+ struct file_attr fattr;
+- struct file_kattr fa;
++ struct file_kattr fa = { .flags_valid = true }; /* hint only */
+ int error;
+
+ BUILD_BUG_ON(sizeof(struct file_attr) < FILE_ATTR_SIZE_VER0);
+--
+2.51.0
+
--- /dev/null
+From 832e46c6fb23e3ac108aeca6840a82bace8092b8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 3 Mar 2026 16:31:42 +0100
+Subject: powerpc: 83xx: km83xx: Fix keymile vendor prefix
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: J. Neuschäfer <j.ne@posteo.net>
+
+[ Upstream commit 691417ffe7821721e0a28bd25ad8c0dc0d4ae4ad ]
+
+When kmeter.c was refactored into km83xx.c in 2011, the "keymile" vendor
+prefix was changed to upper-case "Keymile". The devicetree at
+arch/powerpc/boot/dts/kmeter1.dts never underwent the same change,
+suggesting that this was simply a mistake.
+
+Fixes: 93e2b95c81042d ("powerpc/83xx: rename and update kmeter1")
+Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
+Reviewed-by: Heiko Schocher <hs@nabladev.com>
+Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
+Link: https://patch.msgid.link/20260303-keymile-v1-1-463a11e71702@posteo.net
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/platforms/83xx/km83xx.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/arch/powerpc/platforms/83xx/km83xx.c b/arch/powerpc/platforms/83xx/km83xx.c
+index 2b5d187d9b62d..9ef8fb39dd1b1 100644
+--- a/arch/powerpc/platforms/83xx/km83xx.c
++++ b/arch/powerpc/platforms/83xx/km83xx.c
+@@ -155,8 +155,8 @@ machine_device_initcall(mpc83xx_km, mpc83xx_declare_of_platform_devices);
+
+ /* list of the supported boards */
+ static char *board[] __initdata = {
+- "Keymile,KMETER1",
+- "Keymile,kmpbec8321",
++ "keymile,KMETER1",
++ "keymile,kmpbec8321",
+ NULL
+ };
+
+--
+2.51.0
+
--- /dev/null
+From b5da48f5d001b2b8812bbeca2a92aa0926c0ebf9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 27 Feb 2026 22:48:01 +0530
+Subject: powerpc/crash: adjust the elfcorehdr size
+
+From: Sourabh Jain <sourabhjain@linux.ibm.com>
+
+[ Upstream commit 04e707cb77c272cb0bb2e2e3c5c7f844d804a089 ]
+
+With crash hotplug support enabled, additional memory is allocated to
+the elfcorehdr kexec segment to accommodate resources added during
+memory hotplug events. However, the kdump FDT is not updated with the
+same size, which can result in elfcorehdr corruption in the kdump
+kernel.
+
+Update elf_headers_sz (the kimage member representing the size of the
+elfcorehdr kexec segment) to reflect the total memory allocated for the
+elfcorehdr segment instead of the elfcorehdr buffer size at the time of
+kdump load. This allows of_kexec_alloc_and_setup_fdt() to reserve the
+full elfcorehdr memory in the kdump FDT and prevents elfcorehdr
+corruption.
+
+Fixes: 849599b702ef8 ("powerpc/crash: add crash memory hotplug support")
+Reviewed-by: Hari Bathini <hbathini@linux.ibm.com>
+Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
+Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
+Link: https://patch.msgid.link/20260227171801.2238847-1-sourabhjain@linux.ibm.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/kexec/file_load_64.c | 14 +++++++++++++-
+ 1 file changed, 13 insertions(+), 1 deletion(-)
+
+diff --git a/arch/powerpc/kexec/file_load_64.c b/arch/powerpc/kexec/file_load_64.c
+index e7ef8b2a25546..5f6d50e4c3d45 100644
+--- a/arch/powerpc/kexec/file_load_64.c
++++ b/arch/powerpc/kexec/file_load_64.c
+@@ -450,6 +450,11 @@ static int load_elfcorehdr_segment(struct kimage *image, struct kexec_buf *kbuf)
+ kbuf->buffer = headers;
+ kbuf->mem = KEXEC_BUF_MEM_UNKNOWN;
+ kbuf->bufsz = headers_sz;
++
++ /*
++ * Account for extra space required to accommodate additional memory
++ * ranges in elfcorehdr due to memory hotplug events.
++ */
+ kbuf->memsz = headers_sz + kdump_extra_elfcorehdr_size(cmem);
+ kbuf->top_down = false;
+
+@@ -460,7 +465,14 @@ static int load_elfcorehdr_segment(struct kimage *image, struct kexec_buf *kbuf)
+ }
+
+ image->elf_load_addr = kbuf->mem;
+- image->elf_headers_sz = headers_sz;
++
++ /*
++ * If CONFIG_CRASH_HOTPLUG is enabled, the elfcorehdr kexec segment
++ * memsz can be larger than bufsz. Always initialize elf_headers_sz
++ * with memsz. This ensures the correct size is reserved for elfcorehdr
++ * memory in the FDT prepared for kdump.
++ */
++ image->elf_headers_sz = kbuf->memsz;
+ image->elf_headers = headers;
+ out:
+ kfree(cmem);
+--
+2.51.0
+
--- /dev/null
+From 8e537657ef20dd0e633d623b935b5c20b95065dc Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 24 Dec 2025 20:42:57 +0530
+Subject: powerpc/kexec/core: use big-endian types for crash variables
+
+From: Sourabh Jain <sourabhjain@linux.ibm.com>
+
+[ Upstream commit 20197b967a6a29dab81495f25a988515bda84cfe ]
+
+Use explicit word-sized big-endian types for kexec and crash related
+variables. This makes the endianness unambiguous and avoids type
+mismatches that trigger sparse warnings.
+
+The change addresses sparse warnings like below (seen on both 32-bit
+and 64-bit builds):
+
+CHECK ../arch/powerpc/kexec/core.c
+sparse: expected unsigned int static [addressable] [toplevel] [usertype] crashk_base
+sparse: got restricted __be32 [usertype]
+sparse: warning: incorrect type in assignment (different base types)
+sparse: expected unsigned int static [addressable] [toplevel] [usertype] crashk_size
+sparse: got restricted __be32 [usertype]
+sparse: warning: incorrect type in assignment (different base types)
+sparse: expected unsigned long long static [addressable] [toplevel] mem_limit
+sparse: got restricted __be32 [usertype]
+sparse: warning: incorrect type in assignment (different base types)
+sparse: expected unsigned int static [addressable] [toplevel] [usertype] kernel_end
+sparse: got restricted __be32 [usertype]
+
+No functional change intended.
+
+Fixes: ea961a828fe7 ("powerpc: Fix endian issues in kexec and crash dump code")
+Reported-by: kernel test robot <lkp@intel.com>
+Closes: https://lore.kernel.org/oe-kbuild-all/202512221405.VHPKPjnp-lkp@intel.com/
+Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
+Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
+Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
+Link: https://patch.msgid.link/20251224151257.28672-1-sourabhjain@linux.ibm.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/kexec/core.c | 17 +++++++++--------
+ 1 file changed, 9 insertions(+), 8 deletions(-)
+
+diff --git a/arch/powerpc/kexec/core.c b/arch/powerpc/kexec/core.c
+index 104c05520bf05..dc44f11be353e 100644
+--- a/arch/powerpc/kexec/core.c
++++ b/arch/powerpc/kexec/core.c
+@@ -23,6 +23,7 @@
+ #include <asm/firmware.h>
+
+ #define cpu_to_be_ulong __PASTE(cpu_to_be, BITS_PER_LONG)
++#define __be_word __PASTE(__be, BITS_PER_LONG)
+
+ #ifdef CONFIG_CRASH_DUMP
+ void machine_crash_shutdown(struct pt_regs *regs)
+@@ -146,25 +147,25 @@ int __init overlaps_crashkernel(unsigned long start, unsigned long size)
+ }
+
+ /* Values we need to export to the second kernel via the device tree. */
+-static phys_addr_t crashk_base;
+-static phys_addr_t crashk_size;
+-static unsigned long long mem_limit;
++static __be_word crashk_base;
++static __be_word crashk_size;
++static __be_word mem_limit;
+
+ static struct property crashk_base_prop = {
+ .name = "linux,crashkernel-base",
+- .length = sizeof(phys_addr_t),
++ .length = sizeof(__be_word),
+ .value = &crashk_base
+ };
+
+ static struct property crashk_size_prop = {
+ .name = "linux,crashkernel-size",
+- .length = sizeof(phys_addr_t),
++ .length = sizeof(__be_word),
+ .value = &crashk_size,
+ };
+
+ static struct property memory_limit_prop = {
+ .name = "linux,memory-limit",
+- .length = sizeof(unsigned long long),
++ .length = sizeof(__be_word),
+ .value = &mem_limit,
+ };
+
+@@ -193,11 +194,11 @@ static void __init export_crashk_values(struct device_node *node)
+ }
+ #endif /* CONFIG_CRASH_RESERVE */
+
+-static phys_addr_t kernel_end;
++static __be_word kernel_end;
+
+ static struct property kernel_end_prop = {
+ .name = "linux,kernel-end",
+- .length = sizeof(phys_addr_t),
++ .length = sizeof(__be_word),
+ .value = &kernel_end,
+ };
+
+--
+2.51.0
+
--- /dev/null
+From f3e62dba9e9197bb4b82f16761a34c500aa56604 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 3 Feb 2026 08:30:41 +0100
+Subject: powerpc/uaccess: Fix inline assembly for clang build on PPC32
+
+From: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
+
+[ Upstream commit 0ee95a1d458630272d0415d0ffa9424fcb606c90 ]
+
+Test robot reports the following error with clang-16.0.6:
+
+ In file included from kernel/rseq.c:75:
+ include/linux/rseq_entry.h:141:3: error: invalid operand for instruction
+ unsafe_get_user(offset, &ucs->post_commit_offset, efault);
+ ^
+ include/linux/uaccess.h:608:2: note: expanded from macro 'unsafe_get_user'
+ arch_unsafe_get_user(x, ptr, local_label); \
+ ^
+ arch/powerpc/include/asm/uaccess.h:518:2: note: expanded from macro 'arch_unsafe_get_user'
+ __get_user_size_goto(__gu_val, __gu_addr, sizeof(*(p)), e); \
+ ^
+ arch/powerpc/include/asm/uaccess.h:284:2: note: expanded from macro '__get_user_size_goto'
+ __get_user_size_allowed(x, ptr, size, __gus_retval); \
+ ^
+ arch/powerpc/include/asm/uaccess.h:275:10: note: expanded from macro '__get_user_size_allowed'
+ case 8: __get_user_asm2(x, (u64 __user *)ptr, retval); break; \
+ ^
+ arch/powerpc/include/asm/uaccess.h:258:4: note: expanded from macro '__get_user_asm2'
+ " li %1+1,0\n" \
+ ^
+ <inline asm>:7:5: note: instantiated into assembly here
+ li 31+1,0
+ ^
+ 1 error generated.
+
+On PPC32, for 64 bits vars a pair of registers is used. Usually the
+lower register in the pair is the high part and the higher register is
+the low part. GCC uses r3/r4 ... r11/r12 ... r14/r15 ... r30/r31
+
+In older kernel code inline assembly was using %1 and %1+1 to represent
+64 bits values. However here it looks like clang uses r31 as high part,
+allthough r32 doesn't exist hence the error.
+
+Allthoug %1+1 should work, most places now use %L1 instead of %1+1, so
+let's do the same here.
+
+With that change, the build doesn't fail anymore and a disassembly shows
+clang uses r17/r18 and r31/r14 pair when GCC would have used r16/r17 and
+r30/r31:
+
+ Disassembly of section .fixup:
+
+ 00000000 <.fixup>:
+ 0: 38 a0 ff f2 li r5,-14
+ 4: 3a 20 00 00 li r17,0
+ 8: 3a 40 00 00 li r18,0
+ c: 48 00 00 00 b c <.fixup+0xc>
+ c: R_PPC_REL24 .text+0xbc
+ 10: 38 a0 ff f2 li r5,-14
+ 14: 3b e0 00 00 li r31,0
+ 18: 39 c0 00 00 li r14,0
+ 1c: 48 00 00 00 b 1c <.fixup+0x1c>
+ 1c: R_PPC_REL24 .text+0x144
+
+Reported-by: kernel test robot <lkp@intel.com>
+Closes: https://lore.kernel.org/oe-kbuild-all/202602021825.otcItxGi-lkp@intel.com/
+Fixes: c20beffeec3c ("powerpc/uaccess: Use flexible addressing with __put_user()/__get_user()")
+Signed-off-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
+Acked-by: Nathan Chancellor <nathan@kernel.org>
+Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
+Link: https://patch.msgid.link/8ca3a657a650e497a96bfe7acde2f637dadab344.1770103646.git.chleroy@kernel.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/include/asm/uaccess.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h
+index 3e622e647d622..f77c503ecc102 100644
+--- a/arch/powerpc/include/asm/uaccess.h
++++ b/arch/powerpc/include/asm/uaccess.h
+@@ -253,7 +253,7 @@ __gus_failed: \
+ ".section .fixup,\"ax\"\n" \
+ "4: li %0,%3\n" \
+ " li %1,0\n" \
+- " li %1+1,0\n" \
++ " li %L1,0\n" \
+ " b 3b\n" \
+ ".previous\n" \
+ EX_TABLE(1b, 4b) \
+--
+2.51.0
+
--- /dev/null
+From f15f6db583459791fbbedfa107e1d4a0ffb68229 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 6 Feb 2026 03:30:33 +0000
+Subject: remoteproc: mediatek: Unprepare SCP clock during system suspend
+
+From: Tzung-Bi Shih <tzungbi@kernel.org>
+
+[ Upstream commit 35c3f72a2d55dbf52f28f4ecae51c76be1acf545 ]
+
+Prior to commit d935187cfb27 ("remoteproc: mediatek: Break lock
+dependency to prepare_lock"), `scp->clk` was prepared and enabled only
+when it needs to communicate with the SCP. The commit d935187cfb27
+moved the prepare operation to remoteproc's prepare(), keeping the clock
+prepared as long as the SCP is running.
+
+The power consumption due to the prolonged clock preparation can be
+negligible when the system is running, as SCP is designed to be a very
+power efficient processor.
+
+However, the clock remains prepared even when the system enters system
+suspend. This prevents the underlying clock controller (and potentially
+the parent PLLs) from shutting down, which increases power consumption
+and may block the system from entering deep sleep states.
+
+Add suspend and resume callbacks. Unprepare the clock in suspend() if
+it was active and re-prepare it in resume() to ensure the clock is
+properly disabled during system suspend, while maintaining the "always
+prepared" semantics while the system is active. The driver doesn't
+implement .attach() callback, hence it only checks for RPROC_RUNNING.
+
+Fixes: d935187cfb27 ("remoteproc: mediatek: Break lock dependency to prepare_lock")
+Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
+Link: https://lore.kernel.org/r/20260206033034.3031781-1-tzungbi@kernel.org
+Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/remoteproc/mtk_scp.c | 39 ++++++++++++++++++++++++++++++++++++
+ 1 file changed, 39 insertions(+)
+
+diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
+index 98d00bd5200cc..b0b65aefc7190 100644
+--- a/drivers/remoteproc/mtk_scp.c
++++ b/drivers/remoteproc/mtk_scp.c
+@@ -1597,12 +1597,51 @@ static const struct of_device_id mtk_scp_of_match[] = {
+ };
+ MODULE_DEVICE_TABLE(of, mtk_scp_of_match);
+
++static int __maybe_unused scp_suspend(struct device *dev)
++{
++ struct mtk_scp *scp = dev_get_drvdata(dev);
++ struct rproc *rproc = scp->rproc;
++
++ /*
++ * Only unprepare if the SCP is running and holding the clock.
++ *
++ * Note: `scp_ops` doesn't implement .attach() callback, hence
++ * `rproc->state` can never be RPROC_ATTACHED. Otherwise, it
++ * should also be checked here.
++ */
++ if (rproc->state == RPROC_RUNNING)
++ clk_unprepare(scp->clk);
++ return 0;
++}
++
++static int __maybe_unused scp_resume(struct device *dev)
++{
++ struct mtk_scp *scp = dev_get_drvdata(dev);
++ struct rproc *rproc = scp->rproc;
++
++ /*
++ * Only prepare if the SCP was running and holding the clock.
++ *
++ * Note: `scp_ops` doesn't implement .attach() callback, hence
++ * `rproc->state` can never be RPROC_ATTACHED. Otherwise, it
++ * should also be checked here.
++ */
++ if (rproc->state == RPROC_RUNNING)
++ return clk_prepare(scp->clk);
++ return 0;
++}
++
++static const struct dev_pm_ops scp_pm_ops = {
++ SET_SYSTEM_SLEEP_PM_OPS(scp_suspend, scp_resume)
++};
++
+ static struct platform_driver mtk_scp_driver = {
+ .probe = scp_probe,
+ .remove = scp_remove,
+ .driver = {
+ .name = "mtk-scp",
+ .of_match_table = mtk_scp_of_match,
++ .pm = &scp_pm_ops,
+ },
+ };
+
+--
+2.51.0
+
--- /dev/null
+From 2786b80d7c3dd245bafb61a84abfbe101cf13bb7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 28 Jan 2026 16:02:42 -0600
+Subject: remoteproc: qcom_wcnss: Fix reserved region mapping failure
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Rob Herring (Arm) <robh@kernel.org>
+
+[ Upstream commit f9b888599418951b8229bbb28851ed4da50c58e9 ]
+
+Commit c70b9d5fdcd7 ("remoteproc: qcom: Use of_reserved_mem_region_*
+functions for "memory-region"") switched from devm_ioremap_wc() to
+devm_ioremap_resource_wc(). The difference is devm_ioremap_resource_wc()
+also requests the resource which fails. Testing of both fixed and
+dynamic reserved regions indicates that requesting the resource should
+work, so I'm not sure why it doesn't work in this case. Fix the issue by
+reverting back to devm_ioremap_wc().
+
+Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
+Reported-by: André Apitzsch <git@apitzsch.eu>
+Fixes: c70b9d5fdcd7 ("remoteproc: qcom: Use of_reserved_mem_region_* functions for "memory-region"")
+Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
+Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
+Tested-by: André Apitzsch <git@apitzsch.eu> # on BQ Aquaris M5
+Link: https://lore.kernel.org/r/20260128220243.3018526-1-robh@kernel.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/remoteproc/qcom_wcnss.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/remoteproc/qcom_wcnss.c b/drivers/remoteproc/qcom_wcnss.c
+index ee18bf2e80549..4add9037dbd5a 100644
+--- a/drivers/remoteproc/qcom_wcnss.c
++++ b/drivers/remoteproc/qcom_wcnss.c
+@@ -537,7 +537,7 @@ static int wcnss_alloc_memory_region(struct qcom_wcnss *wcnss)
+
+ wcnss->mem_phys = wcnss->mem_reloc = res.start;
+ wcnss->mem_size = resource_size(&res);
+- wcnss->mem_region = devm_ioremap_resource_wc(wcnss->dev, &res);
++ wcnss->mem_region = devm_ioremap_wc(wcnss->dev, wcnss->mem_phys, wcnss->mem_size);
+ if (IS_ERR(wcnss->mem_region)) {
+ dev_err(wcnss->dev, "unable to map memory region: %pR\n", &res);
+ return PTR_ERR(wcnss->mem_region);
+--
+2.51.0
+
--- /dev/null
+From bff7598343a5c111a58af981dbb92fdee02b44ee Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 20 Feb 2026 15:11:48 -0600
+Subject: remoteproc: sysmon: Correct subsys_name_len type in QMI request
+
+From: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
+
+[ Upstream commit da994db94e60f9a9411108ddf4d1836147ad4c9c ]
+
+The QMI message encoder has up until recently read a single byte (as
+elem_size == 1), but with the introduction of big endian support it's
+become apparent that this field is expected to be a full u32 -
+regardless of the size of the length in the encoded message (which is
+what elem_size specifies).
+
+The result is that the encoder now reads past the length byte and
+rejects the unreasonably large length formed when including the
+following 3 bytes from the subsys_name array.
+
+Fix this by changing to the expected type.
+
+Fixes: 1fb82ee806d1 ("remoteproc: qcom: Introduce sysmon")
+Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
+Reviewed-by: Chris Lew <christopher.lew@oss.qualcomm.com>
+Link: https://lore.kernel.org/r/20260220-qmi-encode-invalid-length-v2-1-5674be35ab29@oss.qualcomm.com
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/remoteproc/qcom_sysmon.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/remoteproc/qcom_sysmon.c b/drivers/remoteproc/qcom_sysmon.c
+index 660ac6fc40821..c6cc6e519fe56 100644
+--- a/drivers/remoteproc/qcom_sysmon.c
++++ b/drivers/remoteproc/qcom_sysmon.c
+@@ -203,7 +203,7 @@ static const struct qmi_elem_info ssctl_shutdown_resp_ei[] = {
+ };
+
+ struct ssctl_subsys_event_req {
+- u8 subsys_name_len;
++ u32 subsys_name_len;
+ char subsys_name[SSCTL_SUBSYS_NAME_LENGTH];
+ u32 event;
+ u8 evt_driven_valid;
+--
+2.51.0
+
--- /dev/null
+From d90fc2f23c37bcfef5a7cc32d24527a897f2d791 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 12 Feb 2026 12:30:26 +0530
+Subject: scsi: mpi3mr: Add NULL checks when resetting request and reply queues
+
+From: Ranjan Kumar <ranjan.kumar@broadcom.com>
+
+[ Upstream commit fa96392ebebc8fade2b878acb14cce0f71016503 ]
+
+The driver encountered a crash during resource cleanup when the reply and
+request queues were NULL due to freed memory. This issue occurred when the
+creation of reply or request queues failed, and the driver freed the memory
+first, but attempted to mem set the content of the freed memory, leading to
+a system crash.
+
+Add NULL pointer checks for reply and request queues before accessing the
+reply/request memory during cleanup
+
+Signed-off-by: Ranjan Kumar <ranjan.kumar@broadcom.com>
+Link: https://patch.msgid.link/20260212070026.30263-1-ranjan.kumar@broadcom.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/mpi3mr/mpi3mr_fw.c | 34 ++++++++++++++++++---------------
+ 1 file changed, 19 insertions(+), 15 deletions(-)
+
+diff --git a/drivers/scsi/mpi3mr/mpi3mr_fw.c b/drivers/scsi/mpi3mr/mpi3mr_fw.c
+index 8c4bb7169a87c..8382afed12813 100644
+--- a/drivers/scsi/mpi3mr/mpi3mr_fw.c
++++ b/drivers/scsi/mpi3mr/mpi3mr_fw.c
+@@ -4705,21 +4705,25 @@ void mpi3mr_memset_buffers(struct mpi3mr_ioc *mrioc)
+ }
+
+ for (i = 0; i < mrioc->num_queues; i++) {
+- mrioc->op_reply_qinfo[i].qid = 0;
+- mrioc->op_reply_qinfo[i].ci = 0;
+- mrioc->op_reply_qinfo[i].num_replies = 0;
+- mrioc->op_reply_qinfo[i].ephase = 0;
+- atomic_set(&mrioc->op_reply_qinfo[i].pend_ios, 0);
+- atomic_set(&mrioc->op_reply_qinfo[i].in_use, 0);
+- mpi3mr_memset_op_reply_q_buffers(mrioc, i);
+-
+- mrioc->req_qinfo[i].ci = 0;
+- mrioc->req_qinfo[i].pi = 0;
+- mrioc->req_qinfo[i].num_requests = 0;
+- mrioc->req_qinfo[i].qid = 0;
+- mrioc->req_qinfo[i].reply_qid = 0;
+- spin_lock_init(&mrioc->req_qinfo[i].q_lock);
+- mpi3mr_memset_op_req_q_buffers(mrioc, i);
++ if (mrioc->op_reply_qinfo) {
++ mrioc->op_reply_qinfo[i].qid = 0;
++ mrioc->op_reply_qinfo[i].ci = 0;
++ mrioc->op_reply_qinfo[i].num_replies = 0;
++ mrioc->op_reply_qinfo[i].ephase = 0;
++ atomic_set(&mrioc->op_reply_qinfo[i].pend_ios, 0);
++ atomic_set(&mrioc->op_reply_qinfo[i].in_use, 0);
++ mpi3mr_memset_op_reply_q_buffers(mrioc, i);
++ }
++
++ if (mrioc->req_qinfo) {
++ mrioc->req_qinfo[i].ci = 0;
++ mrioc->req_qinfo[i].pi = 0;
++ mrioc->req_qinfo[i].num_requests = 0;
++ mrioc->req_qinfo[i].qid = 0;
++ mrioc->req_qinfo[i].reply_qid = 0;
++ spin_lock_init(&mrioc->req_qinfo[i].q_lock);
++ mpi3mr_memset_op_req_q_buffers(mrioc, i);
++ }
+ }
+
+ atomic_set(&mrioc->pend_large_data_sz, 0);
+--
+2.51.0
+
--- /dev/null
+From 662d13bc1fe75414a75fffa4d7e15e320e030140 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 10 Feb 2026 20:18:50 +0100
+Subject: scsi: ses: Fix devices attaching to different hosts
+
+From: Tomas Henzl <thenzl@redhat.com>
+
+[ Upstream commit 70ca8caa96ce473647054f5c7b9dab5423902402 ]
+
+On a multipath SAS system some devices don't end up with correct symlinks
+from the SCSI device to its enclosure. Some devices even have enclosure
+links pointing to enclosures attached to different SCSI hosts.
+
+ses_match_to_enclosure() calls enclosure_for_each_device() which iterates
+over all enclosures on the system, not just enclosures attached to the
+current SCSI host.
+
+Replace the iteration with a direct call to ses_enclosure_find_by_addr().
+
+Reviewed-by: David Jeffery <djeffery@redhat.com>
+Signed-off-by: Tomas Henzl <thenzl@redhat.com>
+Link: https://patch.msgid.link/20260210191850.36784-1-thenzl@redhat.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/ses.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/scsi/ses.c b/drivers/scsi/ses.c
+index 2c61624cb4b03..50e744e891295 100644
+--- a/drivers/scsi/ses.c
++++ b/drivers/scsi/ses.c
+@@ -529,9 +529,8 @@ struct efd {
+ };
+
+ static int ses_enclosure_find_by_addr(struct enclosure_device *edev,
+- void *data)
++ struct efd *efd)
+ {
+- struct efd *efd = data;
+ int i;
+ struct ses_component *scomp;
+
+@@ -684,7 +683,7 @@ static void ses_match_to_enclosure(struct enclosure_device *edev,
+ if (efd.addr) {
+ efd.dev = &sdev->sdev_gendev;
+
+- enclosure_for_each_device(ses_enclosure_find_by_addr, &efd);
++ ses_enclosure_find_by_addr(edev, &efd);
+ }
+ }
+
+--
+2.51.0
+
--- /dev/null
+From 8d277ea59733be51007e33c4b2c78672246ddfbd Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 29 Jan 2026 15:30:39 +0100
+Subject: scsi: storvsc: Fix scheduling while atomic on PREEMPT_RT
+
+From: Jan Kiszka <jan.kiszka@siemens.com>
+
+[ Upstream commit 57297736c08233987e5d29ce6584c6ca2a831b12 ]
+
+This resolves the follow splat and lock-up when running with PREEMPT_RT
+enabled on Hyper-V:
+
+[ 415.140818] BUG: scheduling while atomic: stress-ng-iomix/1048/0x00000002
+[ 415.140822] INFO: lockdep is turned off.
+[ 415.140823] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec ghash_clmulni_intel aesni_intel rapl binfmt_misc nls_ascii nls_cp437 vfat fat snd_pcm hyperv_drm snd_timer drm_client_lib drm_shmem_helper snd sg soundcore drm_kms_helper pcspkr hv_balloon hv_utils evdev joydev drm configfs efi_pstore nfnetlink vsock_loopback vmw_vsock_virtio_transport_common hv_sock vmw_vsock_vmci_transport vsock vmw_vmci efivarfs autofs4 ext4 crc16 mbcache jbd2 sr_mod sd_mod cdrom hv_storvsc serio_raw hid_generic scsi_transport_fc hid_hyperv scsi_mod hid hv_netvsc hyperv_keyboard scsi_common
+[ 415.140846] Preemption disabled at:
+[ 415.140847] [<ffffffffc0656171>] storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc]
+[ 415.140854] CPU: 8 UID: 0 PID: 1048 Comm: stress-ng-iomix Not tainted 6.19.0-rc7 #30 PREEMPT_{RT,(full)}
+[ 415.140856] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/04/2024
+[ 415.140857] Call Trace:
+[ 415.140861] <TASK>
+[ 415.140861] ? storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc]
+[ 415.140863] dump_stack_lvl+0x91/0xb0
+[ 415.140870] __schedule_bug+0x9c/0xc0
+[ 415.140875] __schedule+0xdf6/0x1300
+[ 415.140877] ? rtlock_slowlock_locked+0x56c/0x1980
+[ 415.140879] ? rcu_is_watching+0x12/0x60
+[ 415.140883] schedule_rtlock+0x21/0x40
+[ 415.140885] rtlock_slowlock_locked+0x502/0x1980
+[ 415.140891] rt_spin_lock+0x89/0x1e0
+[ 415.140893] hv_ringbuffer_write+0x87/0x2a0
+[ 415.140899] vmbus_sendpacket_mpb_desc+0xb6/0xe0
+[ 415.140900] ? rcu_is_watching+0x12/0x60
+[ 415.140902] storvsc_queuecommand+0x669/0xbe0 [hv_storvsc]
+[ 415.140904] ? HARDIRQ_verbose+0x10/0x10
+[ 415.140908] ? __rq_qos_issue+0x28/0x40
+[ 415.140911] scsi_queue_rq+0x760/0xd80 [scsi_mod]
+[ 415.140926] __blk_mq_issue_directly+0x4a/0xc0
+[ 415.140928] blk_mq_issue_direct+0x87/0x2b0
+[ 415.140931] blk_mq_dispatch_queue_requests+0x120/0x440
+[ 415.140933] blk_mq_flush_plug_list+0x7a/0x1a0
+[ 415.140935] __blk_flush_plug+0xf4/0x150
+[ 415.140940] __submit_bio+0x2b2/0x5c0
+[ 415.140944] ? submit_bio_noacct_nocheck+0x272/0x360
+[ 415.140946] submit_bio_noacct_nocheck+0x272/0x360
+[ 415.140951] ext4_read_bh_lock+0x3e/0x60 [ext4]
+[ 415.140995] ext4_block_write_begin+0x396/0x650 [ext4]
+[ 415.141018] ? __pfx_ext4_da_get_block_prep+0x10/0x10 [ext4]
+[ 415.141038] ext4_da_write_begin+0x1c4/0x350 [ext4]
+[ 415.141060] generic_perform_write+0x14e/0x2c0
+[ 415.141065] ext4_buffered_write_iter+0x6b/0x120 [ext4]
+[ 415.141083] vfs_write+0x2ca/0x570
+[ 415.141087] ksys_write+0x76/0xf0
+[ 415.141089] do_syscall_64+0x99/0x1490
+[ 415.141093] ? rcu_is_watching+0x12/0x60
+[ 415.141095] ? finish_task_switch.isra.0+0xdf/0x3d0
+[ 415.141097] ? rcu_is_watching+0x12/0x60
+[ 415.141098] ? lock_release+0x1f0/0x2a0
+[ 415.141100] ? rcu_is_watching+0x12/0x60
+[ 415.141101] ? finish_task_switch.isra.0+0xe4/0x3d0
+[ 415.141103] ? rcu_is_watching+0x12/0x60
+[ 415.141104] ? __schedule+0xb34/0x1300
+[ 415.141106] ? hrtimer_try_to_cancel+0x1d/0x170
+[ 415.141109] ? do_nanosleep+0x8b/0x160
+[ 415.141111] ? hrtimer_nanosleep+0x89/0x100
+[ 415.141114] ? __pfx_hrtimer_wakeup+0x10/0x10
+[ 415.141116] ? xfd_validate_state+0x26/0x90
+[ 415.141118] ? rcu_is_watching+0x12/0x60
+[ 415.141120] ? do_syscall_64+0x1e0/0x1490
+[ 415.141121] ? do_syscall_64+0x1e0/0x1490
+[ 415.141123] ? rcu_is_watching+0x12/0x60
+[ 415.141124] ? do_syscall_64+0x1e0/0x1490
+[ 415.141125] ? do_syscall_64+0x1e0/0x1490
+[ 415.141127] ? irqentry_exit+0x140/0x7e0
+[ 415.141129] entry_SYSCALL_64_after_hwframe+0x76/0x7e
+
+get_cpu() disables preemption while the spinlock hv_ringbuffer_write is
+using is converted to an rt-mutex under PREEMPT_RT.
+
+Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
+Tested-by: Florian Bezdeka <florian.bezdeka@siemens.com>
+Reviewed-by: Michael Kelley <mhklinux@outlook.com>
+Tested-by: Michael Kelley <mhklinux@outlook.com>
+Link: https://patch.msgid.link/0c7fb5cd-fb21-4760-8593-e04bade84744@siemens.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/storvsc_drv.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
+index b43d876747b76..68c837146b9ea 100644
+--- a/drivers/scsi/storvsc_drv.c
++++ b/drivers/scsi/storvsc_drv.c
+@@ -1855,8 +1855,9 @@ static int storvsc_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *scmnd)
+ cmd_request->payload_sz = payload_sz;
+
+ /* Invokes the vsc to start an IO */
+- ret = storvsc_do_io(dev, cmd_request, get_cpu());
+- put_cpu();
++ migrate_disable();
++ ret = storvsc_do_io(dev, cmd_request, smp_processor_id());
++ migrate_enable();
+
+ if (ret)
+ scsi_dma_unmap(scmnd);
+--
+2.51.0
+
--- /dev/null
+From fc3487769835dcfd0007e08635d640922a279b6c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 23 Feb 2026 14:56:09 +0800
+Subject: scsi: ufs: core: Fix possible NULL pointer dereference in
+ ufshcd_add_command_trace()
+
+From: Peter Wang <peter.wang@mediatek.com>
+
+[ Upstream commit 30df81f2228d65bddf492db3929d9fcaffd38fc5 ]
+
+The kernel log indicates a crash in ufshcd_add_command_trace, due to a NULL
+pointer dereference when accessing hwq->id. This can happen if
+ufshcd_mcq_req_to_hwq() returns NULL.
+
+This patch adds a NULL check for hwq before accessing its id field to
+prevent a kernel crash.
+
+Kernel log excerpt:
+[<ffffffd5d192dc4c>] notify_die+0x4c/0x8c
+[<ffffffd5d1814e58>] __die+0x60/0xb0
+[<ffffffd5d1814d64>] die+0x4c/0xe0
+[<ffffffd5d181575c>] die_kernel_fault+0x74/0x88
+[<ffffffd5d1864db4>] __do_kernel_fault+0x314/0x318
+[<ffffffd5d2a3cdf8>] do_page_fault+0xa4/0x5f8
+[<ffffffd5d2a3cd34>] do_translation_fault+0x34/0x54
+[<ffffffd5d1864524>] do_mem_abort+0x50/0xa8
+[<ffffffd5d2a297dc>] el1_abort+0x3c/0x64
+[<ffffffd5d2a29718>] el1h_64_sync_handler+0x44/0xcc
+[<ffffffd5d181133c>] el1h_64_sync+0x80/0x88
+[<ffffffd5d255c1dc>] ufshcd_add_command_trace+0x23c/0x320
+[<ffffffd5d255bad8>] ufshcd_compl_one_cqe+0xa4/0x404
+[<ffffffd5d2572968>] ufshcd_mcq_poll_cqe_lock+0xac/0x104
+[<ffffffd5d11c7460>] ufs_mtk_mcq_intr+0x54/0x74 [ufs_mediatek_mod]
+[<ffffffd5d19ab92c>] __handle_irq_event_percpu+0xc8/0x348
+[<ffffffd5d19abca8>] handle_irq_event+0x3c/0xa8
+[<ffffffd5d19b1f0c>] handle_fasteoi_irq+0xf8/0x294
+[<ffffffd5d19aa778>] generic_handle_domain_irq+0x54/0x80
+[<ffffffd5d18102bc>] gic_handle_irq+0x1d4/0x330
+[<ffffffd5d1838210>] call_on_irq_stack+0x44/0x68
+[<ffffffd5d183af30>] do_interrupt_handler+0x78/0xd8
+[<ffffffd5d2a29c00>] el1_interrupt+0x48/0xa8
+[<ffffffd5d2a29ba8>] el1h_64_irq_handler+0x14/0x24
+[<ffffffd5d18113c4>] el1h_64_irq+0x80/0x88
+[<ffffffd5d2527fb4>] arch_local_irq_enable+0x4/0x1c
+[<ffffffd5d25282e4>] cpuidle_enter+0x34/0x54
+[<ffffffd5d195a678>] do_idle+0x1dc/0x2f8
+[<ffffffd5d195a7c4>] cpu_startup_entry+0x30/0x3c
+[<ffffffd5d18155c4>] secondary_start_kernel+0x134/0x1ac
+[<ffffffd5d18640bc>] __secondary_switched+0xc4/0xcc
+
+Signed-off-by: Peter Wang <peter.wang@mediatek.com>
+Reviewed-by: Bart Van Assche <bvanassche@acm.org>
+Link: https://patch.msgid.link/20260223065657.2432447-1-peter.wang@mediatek.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/ufs/core/ufshcd.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
+index 6f9c5d7012812..d5628ed086381 100644
+--- a/drivers/ufs/core/ufshcd.c
++++ b/drivers/ufs/core/ufshcd.c
+@@ -516,8 +516,8 @@ static void ufshcd_add_command_trace(struct ufs_hba *hba, struct scsi_cmnd *cmd,
+
+ if (hba->mcq_enabled) {
+ struct ufs_hw_queue *hwq = ufshcd_mcq_req_to_hwq(hba, rq);
+-
+- hwq_id = hwq->id;
++ if (hwq)
++ hwq_id = hwq->id;
+ } else {
+ doorbell = ufshcd_readl(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL);
+ }
+--
+2.51.0
+
--- /dev/null
+From 5ce088748215490ff04ec6cc7cd7b0d90ead592f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 24 Feb 2026 14:32:28 +0800
+Subject: scsi: ufs: core: Fix shift out of bounds when MAXQ=32
+
+From: wangshuaiwei <wangshuaiwei1@xiaomi.com>
+
+[ Upstream commit 2f38fd99c0004676d835ae96ac4f3b54edc02c82 ]
+
+According to JESD223F, the maximum number of queues (MAXQ) is 32. When MCQ
+is enabled and ESI is disabled, nr_hw_queues=32 causes a shift overflow
+problem.
+
+Fix this by using 64-bit intermediate values to handle the nr_hw_queues=32
+case safely.
+
+Signed-off-by: wangshuaiwei <wangshuaiwei1@xiaomi.com>
+Reviewed-by: Bart Van Assche <bvanassche@acm.org>
+Link: https://patch.msgid.link/20260224063228.50112-1-wangshuaiwei1@xiaomi.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/ufs/core/ufshcd.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
+index d5628ed086381..2048ebc86590e 100644
+--- a/drivers/ufs/core/ufshcd.c
++++ b/drivers/ufs/core/ufshcd.c
+@@ -7106,7 +7106,7 @@ static irqreturn_t ufshcd_handle_mcq_cq_events(struct ufs_hba *hba)
+
+ ret = ufshcd_vops_get_outstanding_cqs(hba, &outstanding_cqs);
+ if (ret)
+- outstanding_cqs = (1U << hba->nr_hw_queues) - 1;
++ outstanding_cqs = (1ULL << hba->nr_hw_queues) - 1;
+
+ /* Exclude the poll queues */
+ nr_queues = hba->nr_hw_queues - hba->nr_queues[HCTX_TYPE_POLL];
+--
+2.51.0
+
--- /dev/null
+From 88248d6931a08c7a11d550456c7634629ad924c0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 11 Feb 2026 15:01:05 +0900
+Subject: scsi: ufs: core: Reset urgent_bkops_lvl to allow runtime PM power
+ mode
+
+From: Won Jung <wone.jung@samsung.com>
+
+[ Upstream commit 5b313760059c9df7d60aba7832279bcb81b4aec0 ]
+
+Ensures that UFS Runtime PM can achieve power saving after System PM
+suspend by resetting hba->urgent_bkops_lvl. Also modify the
+ufshcd_bkops_exception_event_handler to avoid setting urgent_bkops_lvl when
+status is 0, which helps maintain optimal power management.
+
+On UFS devices supporting UFSHCD_CAP_AUTO_BKOPS_SUSPEND, a BKOPS exception
+event can lead to a situation where UFS Runtime PM can't enter low-power
+mode states even after the BKOPS exception has been resolved.
+
+BKOPS exception with bkops status 0 occurs, the driver logs:
+
+ "ufshcd_bkops_exception_event_handler: device raised urgent BKOPS exception for bkops status 0"
+
+When a BKOPS exception occurs, ufshcd_bkops_exception_event_handler() reads
+the BKOPS status and sets hba->urgent_bkops_lvl to BKOPS_STATUS_NO_OP(0).
+This allows the device to perform Runtime PM without changing the UFS power
+mode. (__ufshcd_wl_suspend(hba, UFS_RUNTIME_PM))
+
+During system PM suspend, ufshcd_disable_auto_bkops() is called, disabling
+auto bkops. After UFS System PM Resume, when runtime PM attempts to suspend
+again, ufshcd_urgent_bkops() is invoked. Since hba->urgent_bkops_lvl
+remains at BKOPS_STATUS_NO_OP(0), ufshcd_enable_auto_bkops() is triggered.
+
+However, in ufshcd_bkops_ctrl(), the driver compares the current BKOPS
+status with hba->urgent_bkops_lvl, and only enables auto bkops if
+curr_status >= hba->urgent_bkops_lvl. Since both values are 0, the
+condition is met
+
+As a result, __ufshcd_wl_suspend(hba, UFS_RUNTIME_PM) skips power mode
+transitions and remains in an active state, preventing power saving even
+though no urgent BKOPS condition exists.
+
+Signed-off-by: Won Jung <wone.jung@samsung.com>
+Reviewed-by: Peter Wang <peter.wang@mediatek.com>
+Link: https://patch.msgid.link/1891546521.01770806581968.JavaMail.epsvc@epcpadp2new
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/ufs/core/ufshcd.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
+index 80fafad339c75..6f9c5d7012812 100644
+--- a/drivers/ufs/core/ufshcd.c
++++ b/drivers/ufs/core/ufshcd.c
+@@ -5971,6 +5971,7 @@ static int ufshcd_disable_auto_bkops(struct ufs_hba *hba)
+
+ hba->auto_bkops_enabled = false;
+ trace_ufshcd_auto_bkops_state(hba, "Disabled");
++ hba->urgent_bkops_lvl = BKOPS_STATUS_PERF_IMPACT;
+ hba->is_urgent_bkops_lvl_checked = false;
+ out:
+ return err;
+@@ -6074,7 +6075,7 @@ static void ufshcd_bkops_exception_event_handler(struct ufs_hba *hba)
+ * impacted or critical. Handle these device by determining their urgent
+ * bkops status at runtime.
+ */
+- if (curr_status < BKOPS_STATUS_PERF_IMPACT) {
++ if ((curr_status > BKOPS_STATUS_NO_OP) && (curr_status < BKOPS_STATUS_PERF_IMPACT)) {
+ dev_err(hba->dev, "%s: device raised urgent BKOPS exception for bkops status %d\n",
+ __func__, curr_status);
+ /* update the current status as the urgent bkops level */
+--
+2.51.0
+
--- /dev/null
+remoteproc-qcom_wcnss-fix-reserved-region-mapping-fa.patch
+powerpc-uaccess-fix-inline-assembly-for-clang-build-.patch
+powerpc-kexec-core-use-big-endian-types-for-crash-va.patch
+powerpc-crash-adjust-the-elfcorehdr-size.patch
+remoteproc-sysmon-correct-subsys_name_len-type-in-qm.patch
+remoteproc-mediatek-unprepare-scp-clock-during-syste.patch
+powerpc-83xx-km83xx-fix-keymile-vendor-prefix.patch
+smb-server-fix-another-refcount-leak-in-smb2_open.patch
+scsi-storvsc-fix-scheduling-while-atomic-on-preempt_.patch
+acpi-pm-save-nvs-memory-on-lenovo-g70-35.patch
+scsi-ufs-core-reset-urgent_bkops_lvl-to-allow-runtim.patch
+fs-init-flags_valid-before-calling-vfs_fileattr_get.patch
+scsi-mpi3mr-add-null-checks-when-resetting-request-a.patch
+alsa-hda-realtek-fix-speaker-pop-on-star-labs-starfi.patch
+unshare-fix-unshare_fs-handling.patch
+wifi-mac80211-set-default-wmm-parameters-on-all-link.patch
+acpi-osi-add-dmi-quirk-for-acer-aspire-one-d255.patch
+scsi-ses-fix-devices-attaching-to-different-hosts.patch
+asoc-amd-yc-add-asus-expertbook-bm1503cda-to-quirk-t.patch
+asoc-cs42l43-report-insert-for-exotic-peripherals.patch
+scsi-ufs-core-fix-possible-null-pointer-dereference-.patch
+scsi-ufs-core-fix-shift-out-of-bounds-when-maxq-32.patch
+alsa-usb-audio-avoid-implicit-feedback-mode-on-diyin.patch
+drm-amdgpu-vcn5-add-smu-dpm-interface-type.patch
+alsa-usb-audio-check-max-frame-size-for-implicit-fee.patch
--- /dev/null
+From 472bf815bc69a7180072ed86addf6599909e87ed Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 26 Feb 2026 21:54:21 -0800
+Subject: smb/server: Fix another refcount leak in smb2_open()
+
+From: Guenter Roeck <linux@roeck-us.net>
+
+[ Upstream commit c15e7c62feb3751cbdd458555819df1d70374890 ]
+
+If ksmbd_override_fsids() fails, we jump to err_out2. At that point, fp is
+NULL because it hasn't been assigned dh_info.fp yet, so ksmbd_fd_put(work,
+fp) will not be called. However, dh_info.fp was already inserted into the
+session file table by ksmbd_reopen_durable_fd(), so it will leak in the
+session file table until the session is closed.
+
+Move fp = dh_info.fp; ahead of the ksmbd_override_fsids() check to fix the
+problem.
+
+Found by an experimental AI code review agent at Google.
+
+Fixes: c8efcc786146a ("ksmbd: add support for durable handles v1/v2")
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Reviewed-by: ChenXiaoSong <chenxiaosong@kylinos.cn>
+Acked-by: Namjae Jeon <linkinjeon@kernel.org>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/smb/server/smb2pdu.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c
+index b682e8160504a..302a716e30438 100644
+--- a/fs/smb/server/smb2pdu.c
++++ b/fs/smb/server/smb2pdu.c
+@@ -3011,13 +3011,14 @@ int smb2_open(struct ksmbd_work *work)
+ goto err_out2;
+ }
+
++ fp = dh_info.fp;
++
+ if (ksmbd_override_fsids(work)) {
+ rc = -ENOMEM;
+ ksmbd_put_durable_fd(dh_info.fp);
+ goto err_out2;
+ }
+
+- fp = dh_info.fp;
+ file_info = FILE_OPENED;
+
+ rc = ksmbd_vfs_getattr(&fp->filp->f_path, &stat);
+--
+2.51.0
+
--- /dev/null
+From 1e4e206cc08f37651b7a7f3784ea8f9f0c34fef2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 7 Feb 2026 08:25:24 +0000
+Subject: unshare: fix unshare_fs() handling
+
+From: Al Viro <viro@zeniv.linux.org.uk>
+
+[ Upstream commit 6c4b2243cb6c0755159bd567130d5e12e7b10d9f ]
+
+There's an unpleasant corner case in unshare(2), when we have a
+CLONE_NEWNS in flags and current->fs hadn't been shared at all; in that
+case copy_mnt_ns() gets passed current->fs instead of a private copy,
+which causes interesting warts in proof of correctness]
+
+> I guess if private means fs->users == 1, the condition could still be true.
+
+Unfortunately, it's worse than just a convoluted proof of correctness.
+Consider the case when we have CLONE_NEWCGROUP in addition to CLONE_NEWNS
+(and current->fs->users == 1).
+
+We pass current->fs to copy_mnt_ns(), all right. Suppose it succeeds and
+flips current->fs->{pwd,root} to corresponding locations in the new namespace.
+Now we proceed to copy_cgroup_ns(), which fails (e.g. with -ENOMEM).
+We call put_mnt_ns() on the namespace created by copy_mnt_ns(), it's
+destroyed and its mount tree is dissolved, but... current->fs->root and
+current->fs->pwd are both left pointing to now detached mounts.
+
+They are pinning those, so it's not a UAF, but it leaves the calling
+process with unshare(2) failing with -ENOMEM _and_ leaving it with
+pwd and root on detached isolated mounts. The last part is clearly a bug.
+
+There is other fun related to that mess (races with pivot_root(), including
+the one between pivot_root() and fork(), of all things), but this one
+is easy to isolate and fix - treat CLONE_NEWNS as "allocate a new
+fs_struct even if it hadn't been shared in the first place". Sure, we could
+go for something like "if both CLONE_NEWNS *and* one of the things that might
+end up failing after copy_mnt_ns() call in create_new_namespaces() are set,
+force allocation of new fs_struct", but let's keep it simple - the cost
+of copy_fs_struct() is trivial.
+
+Another benefit is that copy_mnt_ns() with CLONE_NEWNS *always* gets
+a freshly allocated fs_struct, yet to be attached to anything. That
+seriously simplifies the analysis...
+
+FWIW, that bug had been there since the introduction of unshare(2) ;-/
+
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Link: https://patch.msgid.link/20260207082524.GE3183987@ZenIV
+Tested-by: Waiman Long <longman@redhat.com>
+Signed-off-by: Christian Brauner <brauner@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/fork.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/kernel/fork.c b/kernel/fork.c
+index b1f3915d5f8ec..68ccbaea7398a 100644
+--- a/kernel/fork.c
++++ b/kernel/fork.c
+@@ -3082,7 +3082,7 @@ static int unshare_fs(unsigned long unshare_flags, struct fs_struct **new_fsp)
+ return 0;
+
+ /* don't need lock here; in the worst case we'll do useless copy */
+- if (fs->users == 1)
++ if (!(unshare_flags & CLONE_NEWNS) && fs->users == 1)
+ return 0;
+
+ *new_fsp = copy_fs_struct(fs);
+--
+2.51.0
+
--- /dev/null
+From a094915ab688de0a224de94e0983bc740d376c56 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 5 Feb 2026 15:12:16 +0530
+Subject: wifi: mac80211: set default WMM parameters on all links
+
+From: Ramanathan Choodamani <quic_rchoodam@quicinc.com>
+
+[ Upstream commit 2259d14499d16b115ef8d5d2ddc867e2be7cb5b5 ]
+
+Currently, mac80211 only initializes default WMM parameters
+on the deflink during do_open(). For MLO cases, this
+leaves the additional links without proper WMM defaults
+if hostapd does not supply per-link WMM parameters, leading
+to inconsistent QoS behavior across links.
+
+Set default WMM parameters for each link during
+ieee80211_vif_update_links(), because this ensures all
+individual links in an MLD have valid WMM settings during
+bring-up and behave consistently across different BSS.
+
+Signed-off-by: Ramanathan Choodamani <quic_rchoodam@quicinc.com>
+Signed-off-by: Aishwarya R <aishwarya.r@oss.qualcomm.com>
+Link: https://patch.msgid.link/20260205094216.3093542-1-aishwarya.r@oss.qualcomm.com
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/mac80211/link.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/net/mac80211/link.c b/net/mac80211/link.c
+index 1e05845872afc..b659497680b51 100644
+--- a/net/mac80211/link.c
++++ b/net/mac80211/link.c
+@@ -281,6 +281,7 @@ static int ieee80211_vif_update_links(struct ieee80211_sub_if_data *sdata,
+ struct ieee80211_bss_conf *old[IEEE80211_MLD_MAX_NUM_LINKS];
+ struct ieee80211_link_data *old_data[IEEE80211_MLD_MAX_NUM_LINKS];
+ bool use_deflink = old_links == 0; /* set for error case */
++ bool non_sta = sdata->vif.type != NL80211_IFTYPE_STATION;
+
+ lockdep_assert_wiphy(sdata->local->hw.wiphy);
+
+@@ -337,6 +338,7 @@ static int ieee80211_vif_update_links(struct ieee80211_sub_if_data *sdata,
+ link = links[link_id];
+ ieee80211_link_init(sdata, link_id, &link->data, &link->conf);
+ ieee80211_link_setup(&link->data);
++ ieee80211_set_wmm_default(&link->data, true, non_sta);
+ }
+
+ if (new_links == 0)
+--
+2.51.0
+
--- /dev/null
+From fbf1a9012f36145d347e74f27039f242b44a9531 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 22 Feb 2026 23:52:40 -0300
+Subject: ACPI: OSI: Add DMI quirk for Acer Aspire One D255
+
+From: Sofia Schneider <sofia@schn.dev>
+
+[ Upstream commit 5ede90206273ff156a778254f0f972a55e973c89 ]
+
+The screen backlight turns off during boot (specifically during udev device
+initialization) when returning true for _OSI("Windows 2009").
+
+Analyzing the device's DSDT reveals that the firmware takes a different
+code path when Windows 7 is reported, which leads to the backlight shutoff.
+Add a DMI quirk to invoke dmi_disable_osi_win7 for this model.
+
+Signed-off-by: Sofia Schneider <sofia@schn.dev>
+Link: https://patch.msgid.link/20260223025240.518509-1-sofia@schn.dev
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/acpi/osi.c | 13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+diff --git a/drivers/acpi/osi.c b/drivers/acpi/osi.c
+index ae9620757865b..600af8814038a 100644
+--- a/drivers/acpi/osi.c
++++ b/drivers/acpi/osi.c
+@@ -389,6 +389,19 @@ static const struct dmi_system_id acpi_osi_dmi_table[] __initconst = {
+ },
+ },
+
++ /*
++ * The screen backlight turns off during udev device creation
++ * when returning true for _OSI("Windows 2009")
++ */
++ {
++ .callback = dmi_disable_osi_win7,
++ .ident = "Acer Aspire One D255",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "AOD255"),
++ },
++ },
++
+ /*
+ * The wireless hotkey does not work on those machines when
+ * returning true for _OSI("Windows 2012")
+--
+2.51.0
+
--- /dev/null
+From 8aec5cedd10c67e2de51e1ea823ed3a593d81d89 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 5 Feb 2026 23:05:02 +0100
+Subject: ACPI: PM: Save NVS memory on Lenovo G70-35
+
+From: Piotr Mazek <pmazek@outlook.com>
+
+[ Upstream commit 023cd6d90f8aa2ef7b72d84be84a18e61ecebd64 ]
+
+[821d6f0359b0614792ab8e2fb93b503e25a65079] prevented machines
+produced later than 2012 from saving NVS region to accelerate S3.
+
+Despite being made after 2012, Lenovo G70-35 still needs NVS memory
+saving during S3. A quirk is introduced for this platform.
+
+Signed-off-by: Piotr Mazek <pmazek@outlook.com>
+[ rjw: Subject adjustment ]
+Link: https://patch.msgid.link/GV2PPF3CD5B63CC2442EE3F76F8443EAD90D499A@GV2PPF3CD5B63CC.EURP251.PROD.OUTLOOK.COM
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/acpi/sleep.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
+index 728acfeb774d8..2fd51b18d13c4 100644
+--- a/drivers/acpi/sleep.c
++++ b/drivers/acpi/sleep.c
+@@ -372,6 +372,14 @@ static const struct dmi_system_id acpisleep_dmi_table[] __initconst = {
+ DMI_MATCH(DMI_PRODUCT_NAME, "80E1"),
+ },
+ },
++ {
++ .callback = init_nvs_save_s3,
++ .ident = "Lenovo G70-35",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "80Q5"),
++ },
++ },
+ /*
+ * ThinkPad X1 Tablet(2016) cannot do suspend-to-idle using
+ * the Low Power S0 Idle firmware interface (see
+--
+2.51.0
+
--- /dev/null
+From a62c952815a422118e4144bba6ae514d857a47d1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 25 Feb 2026 09:52:30 +0100
+Subject: ALSA: usb-audio: Avoid implicit feedback mode on DIYINHK USB Audio
+ 2.0
+
+From: Takashi Iwai <tiwai@suse.de>
+
+[ Upstream commit c5bf24c8aba1ff711226ee0f039ff01a5754692b ]
+
+Although DIYINHK USB Audio 2.0 (ID 20b1:2009) shows the implicit
+feedback source for the capture stream, this would cause several
+problems for the playback. Namely, the device can get wMaxPackSize
+1024 for 24/32 bit format with 6 channels, and when a high sample rate
+like 352.8kHz or 384kHz is played, the packet size overflows the max
+limit. Also, the device has another two playback altsets, and those
+aren't properly handled with the implicit feedback.
+
+Since the device has been working well even before introducing the
+implicit feedback, we can assume that it works fine in the async mode.
+This patch adds the explicit skip of the implicit fb detection to make
+the playback running in the async mode.
+
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=221076
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Link: https://patch.msgid.link/20260225085233.316306-4-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/usb/quirks.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
+index 15e72c419dbc2..04896ab01f372 100644
+--- a/sound/usb/quirks.c
++++ b/sound/usb/quirks.c
+@@ -2251,6 +2251,8 @@ static const struct usb_audio_quirk_flags_table quirk_flags_table[] = {
+ QUIRK_FLAG_SHARE_MEDIA_DEVICE | QUIRK_FLAG_ALIGN_TRANSFER),
+ DEVICE_FLG(0x2040, 0x7281, /* Hauppauge HVR-950Q-MXL */
+ QUIRK_FLAG_SHARE_MEDIA_DEVICE | QUIRK_FLAG_ALIGN_TRANSFER),
++ DEVICE_FLG(0x20b1, 0x2009, /* XMOS Ltd DIYINHK USB Audio 2.0 */
++ QUIRK_FLAG_SKIP_IMPLICIT_FB | QUIRK_FLAG_DSD_RAW),
+ DEVICE_FLG(0x2040, 0x8200, /* Hauppauge Woodbury */
+ QUIRK_FLAG_SHARE_MEDIA_DEVICE | QUIRK_FLAG_ALIGN_TRANSFER),
+ DEVICE_FLG(0x21b4, 0x0081, /* AudioQuest DragonFly */
+--
+2.51.0
+
--- /dev/null
+From ed230b5cf64b8f3e4653937f6aa613960f399b69 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 25 Feb 2026 09:52:29 +0100
+Subject: ALSA: usb-audio: Check max frame size for implicit feedback mode, too
+
+From: Takashi Iwai <tiwai@suse.de>
+
+[ Upstream commit 7cb2a5422f5bbdf1cf32eae0eda41000485b9346 ]
+
+When the packet sizes are taken from the capture stream in the
+implicit feedback mode, the sizes might be larger than the upper
+boundary defined by the descriptor. As already done for other
+transfer modes, we have to cap the sizes accordingly at sending,
+otherwise this would lead to an error in USB core at submission of
+URBs.
+
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=221076
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Link: https://patch.msgid.link/20260225085233.316306-3-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/usb/endpoint.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
+index 806755a65fc05..f6cef6aaca773 100644
+--- a/sound/usb/endpoint.c
++++ b/sound/usb/endpoint.c
+@@ -224,6 +224,7 @@ int snd_usb_endpoint_next_packet_size(struct snd_usb_endpoint *ep,
+
+ packet = ctx->packet_size[idx];
+ if (packet) {
++ packet = min(packet, ep->maxframesize);
+ if (avail && packet >= avail)
+ return -EAGAIN;
+ return packet;
+--
+2.51.0
+
--- /dev/null
+From 80bec64dcd63590fb88f36046a4a0f48bd3d42e4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 21 Feb 2026 12:48:13 +0100
+Subject: ASoC: amd: yc: Add ASUS EXPERTBOOK BM1503CDA to quirk table
+
+From: Azamat Almazbek uulu <almazbek1608@gmail.com>
+
+[ Upstream commit 32fc4168fa56f6301d858c778a3d712774e9657e ]
+
+The ASUS ExpertBook BM1503CDA (Ryzen 5 7535U, Barcelo-R) has an
+internal DMIC connected through the AMD ACP (Audio CoProcessor)
+but is missing from the DMI quirk table, so the acp6x machine
+driver probe returns -ENODEV and no DMIC capture device is created.
+
+Add the DMI entry so the internal microphone works out of the box.
+
+Signed-off-by: Azamat Almazbek uulu <almazbek1608@gmail.com>
+Reviewed-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
+Link: https://patch.msgid.link/20260221114813.5610-1-almazbek1608@gmail.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/soc/amd/yc/acp6x-mach.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c
+index 5aeacbcb1f6ad..106012da7443e 100644
+--- a/sound/soc/amd/yc/acp6x-mach.c
++++ b/sound/soc/amd/yc/acp6x-mach.c
+@@ -696,6 +696,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = {
+ DMI_MATCH(DMI_PRODUCT_NAME, "Vivobook_ASUSLaptop M6501RR_M6501RR"),
+ }
+ },
++ {
++ .driver_data = &acp6x_card,
++ .matches = {
++ DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK COMPUTER INC."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "ASUS EXPERTBOOK BM1503CDA"),
++ }
++ },
+ {}
+ };
+
+--
+2.51.0
+
--- /dev/null
+From 92b6480fcd4a9a6c46b9ab5a11437c029873e9af Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 23 Feb 2026 09:36:16 +0000
+Subject: ASoC: cs42l43: Report insert for exotic peripherals
+
+From: Charles Keepax <ckeepax@opensource.cirrus.com>
+
+[ Upstream commit 6510e1324bcdc8caf21f6d17efe27604c48f0d64 ]
+
+For some exotic peripherals the type detect can return a reserved value
+of 0x4. This will currently return an error and not report anything to
+user-space, update this to report the insert normally.
+
+Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
+Link: https://patch.msgid.link/20260223093616.3800350-1-ckeepax@opensource.cirrus.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/soc/codecs/cs42l43-jack.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/sound/soc/codecs/cs42l43-jack.c b/sound/soc/codecs/cs42l43-jack.c
+index f58d55d77693f..ba60acc4b2f09 100644
+--- a/sound/soc/codecs/cs42l43-jack.c
++++ b/sound/soc/codecs/cs42l43-jack.c
+@@ -699,6 +699,7 @@ static int cs42l43_run_type_detect(struct cs42l43_codec *priv)
+ switch (type & CS42L43_HSDET_TYPE_STS_MASK) {
+ case 0x0: // CTIA
+ case 0x1: // OMTP
++ case 0x4:
+ return cs42l43_run_load_detect(priv, true);
+ case 0x2: // 3-pole
+ return cs42l43_run_load_detect(priv, false);
+--
+2.51.0
+
--- /dev/null
+From d2085a5db0acf2f65e0927a7446425d61aecf05b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 3 Mar 2026 16:31:42 +0100
+Subject: powerpc: 83xx: km83xx: Fix keymile vendor prefix
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: J. Neuschäfer <j.ne@posteo.net>
+
+[ Upstream commit 691417ffe7821721e0a28bd25ad8c0dc0d4ae4ad ]
+
+When kmeter.c was refactored into km83xx.c in 2011, the "keymile" vendor
+prefix was changed to upper-case "Keymile". The devicetree at
+arch/powerpc/boot/dts/kmeter1.dts never underwent the same change,
+suggesting that this was simply a mistake.
+
+Fixes: 93e2b95c81042d ("powerpc/83xx: rename and update kmeter1")
+Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
+Reviewed-by: Heiko Schocher <hs@nabladev.com>
+Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
+Link: https://patch.msgid.link/20260303-keymile-v1-1-463a11e71702@posteo.net
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/platforms/83xx/km83xx.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/arch/powerpc/platforms/83xx/km83xx.c b/arch/powerpc/platforms/83xx/km83xx.c
+index 2b5d187d9b62d..9ef8fb39dd1b1 100644
+--- a/arch/powerpc/platforms/83xx/km83xx.c
++++ b/arch/powerpc/platforms/83xx/km83xx.c
+@@ -155,8 +155,8 @@ machine_device_initcall(mpc83xx_km, mpc83xx_declare_of_platform_devices);
+
+ /* list of the supported boards */
+ static char *board[] __initdata = {
+- "Keymile,KMETER1",
+- "Keymile,kmpbec8321",
++ "keymile,KMETER1",
++ "keymile,kmpbec8321",
+ NULL
+ };
+
+--
+2.51.0
+
--- /dev/null
+From 54f1d7f916d3f6e1af38f79e2c997db60e1036eb Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 3 Feb 2026 08:30:41 +0100
+Subject: powerpc/uaccess: Fix inline assembly for clang build on PPC32
+
+From: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
+
+[ Upstream commit 0ee95a1d458630272d0415d0ffa9424fcb606c90 ]
+
+Test robot reports the following error with clang-16.0.6:
+
+ In file included from kernel/rseq.c:75:
+ include/linux/rseq_entry.h:141:3: error: invalid operand for instruction
+ unsafe_get_user(offset, &ucs->post_commit_offset, efault);
+ ^
+ include/linux/uaccess.h:608:2: note: expanded from macro 'unsafe_get_user'
+ arch_unsafe_get_user(x, ptr, local_label); \
+ ^
+ arch/powerpc/include/asm/uaccess.h:518:2: note: expanded from macro 'arch_unsafe_get_user'
+ __get_user_size_goto(__gu_val, __gu_addr, sizeof(*(p)), e); \
+ ^
+ arch/powerpc/include/asm/uaccess.h:284:2: note: expanded from macro '__get_user_size_goto'
+ __get_user_size_allowed(x, ptr, size, __gus_retval); \
+ ^
+ arch/powerpc/include/asm/uaccess.h:275:10: note: expanded from macro '__get_user_size_allowed'
+ case 8: __get_user_asm2(x, (u64 __user *)ptr, retval); break; \
+ ^
+ arch/powerpc/include/asm/uaccess.h:258:4: note: expanded from macro '__get_user_asm2'
+ " li %1+1,0\n" \
+ ^
+ <inline asm>:7:5: note: instantiated into assembly here
+ li 31+1,0
+ ^
+ 1 error generated.
+
+On PPC32, for 64 bits vars a pair of registers is used. Usually the
+lower register in the pair is the high part and the higher register is
+the low part. GCC uses r3/r4 ... r11/r12 ... r14/r15 ... r30/r31
+
+In older kernel code inline assembly was using %1 and %1+1 to represent
+64 bits values. However here it looks like clang uses r31 as high part,
+allthough r32 doesn't exist hence the error.
+
+Allthoug %1+1 should work, most places now use %L1 instead of %1+1, so
+let's do the same here.
+
+With that change, the build doesn't fail anymore and a disassembly shows
+clang uses r17/r18 and r31/r14 pair when GCC would have used r16/r17 and
+r30/r31:
+
+ Disassembly of section .fixup:
+
+ 00000000 <.fixup>:
+ 0: 38 a0 ff f2 li r5,-14
+ 4: 3a 20 00 00 li r17,0
+ 8: 3a 40 00 00 li r18,0
+ c: 48 00 00 00 b c <.fixup+0xc>
+ c: R_PPC_REL24 .text+0xbc
+ 10: 38 a0 ff f2 li r5,-14
+ 14: 3b e0 00 00 li r31,0
+ 18: 39 c0 00 00 li r14,0
+ 1c: 48 00 00 00 b 1c <.fixup+0x1c>
+ 1c: R_PPC_REL24 .text+0x144
+
+Reported-by: kernel test robot <lkp@intel.com>
+Closes: https://lore.kernel.org/oe-kbuild-all/202602021825.otcItxGi-lkp@intel.com/
+Fixes: c20beffeec3c ("powerpc/uaccess: Use flexible addressing with __put_user()/__get_user()")
+Signed-off-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
+Acked-by: Nathan Chancellor <nathan@kernel.org>
+Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
+Link: https://patch.msgid.link/8ca3a657a650e497a96bfe7acde2f637dadab344.1770103646.git.chleroy@kernel.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/include/asm/uaccess.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h
+index ec7f001d03d01..fa6d8410bc07d 100644
+--- a/arch/powerpc/include/asm/uaccess.h
++++ b/arch/powerpc/include/asm/uaccess.h
+@@ -242,7 +242,7 @@ __gus_failed: \
+ ".section .fixup,\"ax\"\n" \
+ "4: li %0,%3\n" \
+ " li %1,0\n" \
+- " li %1+1,0\n" \
++ " li %L1,0\n" \
+ " b 3b\n" \
+ ".previous\n" \
+ EX_TABLE(1b, 4b) \
+--
+2.51.0
+
--- /dev/null
+From 80d4bd5b575421e7d3ec6b6b9186295c0cbe76e9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 6 Feb 2026 03:30:33 +0000
+Subject: remoteproc: mediatek: Unprepare SCP clock during system suspend
+
+From: Tzung-Bi Shih <tzungbi@kernel.org>
+
+[ Upstream commit 35c3f72a2d55dbf52f28f4ecae51c76be1acf545 ]
+
+Prior to commit d935187cfb27 ("remoteproc: mediatek: Break lock
+dependency to prepare_lock"), `scp->clk` was prepared and enabled only
+when it needs to communicate with the SCP. The commit d935187cfb27
+moved the prepare operation to remoteproc's prepare(), keeping the clock
+prepared as long as the SCP is running.
+
+The power consumption due to the prolonged clock preparation can be
+negligible when the system is running, as SCP is designed to be a very
+power efficient processor.
+
+However, the clock remains prepared even when the system enters system
+suspend. This prevents the underlying clock controller (and potentially
+the parent PLLs) from shutting down, which increases power consumption
+and may block the system from entering deep sleep states.
+
+Add suspend and resume callbacks. Unprepare the clock in suspend() if
+it was active and re-prepare it in resume() to ensure the clock is
+properly disabled during system suspend, while maintaining the "always
+prepared" semantics while the system is active. The driver doesn't
+implement .attach() callback, hence it only checks for RPROC_RUNNING.
+
+Fixes: d935187cfb27 ("remoteproc: mediatek: Break lock dependency to prepare_lock")
+Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
+Link: https://lore.kernel.org/r/20260206033034.3031781-1-tzungbi@kernel.org
+Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/remoteproc/mtk_scp.c | 39 ++++++++++++++++++++++++++++++++++++
+ 1 file changed, 39 insertions(+)
+
+diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
+index ecbece2b5ce7c..bf7a4b975e7e1 100644
+--- a/drivers/remoteproc/mtk_scp.c
++++ b/drivers/remoteproc/mtk_scp.c
+@@ -1024,12 +1024,51 @@ static const struct of_device_id mtk_scp_of_match[] = {
+ };
+ MODULE_DEVICE_TABLE(of, mtk_scp_of_match);
+
++static int __maybe_unused scp_suspend(struct device *dev)
++{
++ struct mtk_scp *scp = dev_get_drvdata(dev);
++ struct rproc *rproc = scp->rproc;
++
++ /*
++ * Only unprepare if the SCP is running and holding the clock.
++ *
++ * Note: `scp_ops` doesn't implement .attach() callback, hence
++ * `rproc->state` can never be RPROC_ATTACHED. Otherwise, it
++ * should also be checked here.
++ */
++ if (rproc->state == RPROC_RUNNING)
++ clk_unprepare(scp->clk);
++ return 0;
++}
++
++static int __maybe_unused scp_resume(struct device *dev)
++{
++ struct mtk_scp *scp = dev_get_drvdata(dev);
++ struct rproc *rproc = scp->rproc;
++
++ /*
++ * Only prepare if the SCP was running and holding the clock.
++ *
++ * Note: `scp_ops` doesn't implement .attach() callback, hence
++ * `rproc->state` can never be RPROC_ATTACHED. Otherwise, it
++ * should also be checked here.
++ */
++ if (rproc->state == RPROC_RUNNING)
++ return clk_prepare(scp->clk);
++ return 0;
++}
++
++static const struct dev_pm_ops scp_pm_ops = {
++ SET_SYSTEM_SLEEP_PM_OPS(scp_suspend, scp_resume)
++};
++
+ static struct platform_driver mtk_scp_driver = {
+ .probe = scp_probe,
+ .remove_new = scp_remove,
+ .driver = {
+ .name = "mtk-scp",
+ .of_match_table = mtk_scp_of_match,
++ .pm = &scp_pm_ops,
+ },
+ };
+
+--
+2.51.0
+
--- /dev/null
+From 7129a9a4cb6b97ecea50d1ea86cedf0a3aac8cbd Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 20 Feb 2026 15:11:48 -0600
+Subject: remoteproc: sysmon: Correct subsys_name_len type in QMI request
+
+From: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
+
+[ Upstream commit da994db94e60f9a9411108ddf4d1836147ad4c9c ]
+
+The QMI message encoder has up until recently read a single byte (as
+elem_size == 1), but with the introduction of big endian support it's
+become apparent that this field is expected to be a full u32 -
+regardless of the size of the length in the encoded message (which is
+what elem_size specifies).
+
+The result is that the encoder now reads past the length byte and
+rejects the unreasonably large length formed when including the
+following 3 bytes from the subsys_name array.
+
+Fix this by changing to the expected type.
+
+Fixes: 1fb82ee806d1 ("remoteproc: qcom: Introduce sysmon")
+Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
+Reviewed-by: Chris Lew <christopher.lew@oss.qualcomm.com>
+Link: https://lore.kernel.org/r/20260220-qmi-encode-invalid-length-v2-1-5674be35ab29@oss.qualcomm.com
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/remoteproc/qcom_sysmon.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/remoteproc/qcom_sysmon.c b/drivers/remoteproc/qcom_sysmon.c
+index c24e4a8828738..db33a41051a3e 100644
+--- a/drivers/remoteproc/qcom_sysmon.c
++++ b/drivers/remoteproc/qcom_sysmon.c
+@@ -203,7 +203,7 @@ static const struct qmi_elem_info ssctl_shutdown_resp_ei[] = {
+ };
+
+ struct ssctl_subsys_event_req {
+- u8 subsys_name_len;
++ u32 subsys_name_len;
+ char subsys_name[SSCTL_SUBSYS_NAME_LENGTH];
+ u32 event;
+ u8 evt_driven_valid;
+--
+2.51.0
+
--- /dev/null
+From db9481dd5cd5dbefeaae718ddbf139f6f564e50c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 12 Feb 2026 12:30:26 +0530
+Subject: scsi: mpi3mr: Add NULL checks when resetting request and reply queues
+
+From: Ranjan Kumar <ranjan.kumar@broadcom.com>
+
+[ Upstream commit fa96392ebebc8fade2b878acb14cce0f71016503 ]
+
+The driver encountered a crash during resource cleanup when the reply and
+request queues were NULL due to freed memory. This issue occurred when the
+creation of reply or request queues failed, and the driver freed the memory
+first, but attempted to mem set the content of the freed memory, leading to
+a system crash.
+
+Add NULL pointer checks for reply and request queues before accessing the
+reply/request memory during cleanup
+
+Signed-off-by: Ranjan Kumar <ranjan.kumar@broadcom.com>
+Link: https://patch.msgid.link/20260212070026.30263-1-ranjan.kumar@broadcom.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/mpi3mr/mpi3mr_fw.c | 34 ++++++++++++++++++---------------
+ 1 file changed, 19 insertions(+), 15 deletions(-)
+
+diff --git a/drivers/scsi/mpi3mr/mpi3mr_fw.c b/drivers/scsi/mpi3mr/mpi3mr_fw.c
+index b6ae7ba6de523..b742ece3f0507 100644
+--- a/drivers/scsi/mpi3mr/mpi3mr_fw.c
++++ b/drivers/scsi/mpi3mr/mpi3mr_fw.c
+@@ -4262,21 +4262,25 @@ void mpi3mr_memset_buffers(struct mpi3mr_ioc *mrioc)
+ }
+
+ for (i = 0; i < mrioc->num_queues; i++) {
+- mrioc->op_reply_qinfo[i].qid = 0;
+- mrioc->op_reply_qinfo[i].ci = 0;
+- mrioc->op_reply_qinfo[i].num_replies = 0;
+- mrioc->op_reply_qinfo[i].ephase = 0;
+- atomic_set(&mrioc->op_reply_qinfo[i].pend_ios, 0);
+- atomic_set(&mrioc->op_reply_qinfo[i].in_use, 0);
+- mpi3mr_memset_op_reply_q_buffers(mrioc, i);
+-
+- mrioc->req_qinfo[i].ci = 0;
+- mrioc->req_qinfo[i].pi = 0;
+- mrioc->req_qinfo[i].num_requests = 0;
+- mrioc->req_qinfo[i].qid = 0;
+- mrioc->req_qinfo[i].reply_qid = 0;
+- spin_lock_init(&mrioc->req_qinfo[i].q_lock);
+- mpi3mr_memset_op_req_q_buffers(mrioc, i);
++ if (mrioc->op_reply_qinfo) {
++ mrioc->op_reply_qinfo[i].qid = 0;
++ mrioc->op_reply_qinfo[i].ci = 0;
++ mrioc->op_reply_qinfo[i].num_replies = 0;
++ mrioc->op_reply_qinfo[i].ephase = 0;
++ atomic_set(&mrioc->op_reply_qinfo[i].pend_ios, 0);
++ atomic_set(&mrioc->op_reply_qinfo[i].in_use, 0);
++ mpi3mr_memset_op_reply_q_buffers(mrioc, i);
++ }
++
++ if (mrioc->req_qinfo) {
++ mrioc->req_qinfo[i].ci = 0;
++ mrioc->req_qinfo[i].pi = 0;
++ mrioc->req_qinfo[i].num_requests = 0;
++ mrioc->req_qinfo[i].qid = 0;
++ mrioc->req_qinfo[i].reply_qid = 0;
++ spin_lock_init(&mrioc->req_qinfo[i].q_lock);
++ mpi3mr_memset_op_req_q_buffers(mrioc, i);
++ }
+ }
+
+ atomic_set(&mrioc->pend_large_data_sz, 0);
+--
+2.51.0
+
--- /dev/null
+From 4b825b0ca7440f48f2bb413e0a049ffdacdbe80e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 10 Feb 2026 20:18:50 +0100
+Subject: scsi: ses: Fix devices attaching to different hosts
+
+From: Tomas Henzl <thenzl@redhat.com>
+
+[ Upstream commit 70ca8caa96ce473647054f5c7b9dab5423902402 ]
+
+On a multipath SAS system some devices don't end up with correct symlinks
+from the SCSI device to its enclosure. Some devices even have enclosure
+links pointing to enclosures attached to different SCSI hosts.
+
+ses_match_to_enclosure() calls enclosure_for_each_device() which iterates
+over all enclosures on the system, not just enclosures attached to the
+current SCSI host.
+
+Replace the iteration with a direct call to ses_enclosure_find_by_addr().
+
+Reviewed-by: David Jeffery <djeffery@redhat.com>
+Signed-off-by: Tomas Henzl <thenzl@redhat.com>
+Link: https://patch.msgid.link/20260210191850.36784-1-thenzl@redhat.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/ses.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/scsi/ses.c b/drivers/scsi/ses.c
+index d7d0c35c58b80..05e462f328e75 100644
+--- a/drivers/scsi/ses.c
++++ b/drivers/scsi/ses.c
+@@ -503,9 +503,8 @@ struct efd {
+ };
+
+ static int ses_enclosure_find_by_addr(struct enclosure_device *edev,
+- void *data)
++ struct efd *efd)
+ {
+- struct efd *efd = data;
+ int i;
+ struct ses_component *scomp;
+
+@@ -658,7 +657,7 @@ static void ses_match_to_enclosure(struct enclosure_device *edev,
+ if (efd.addr) {
+ efd.dev = &sdev->sdev_gendev;
+
+- enclosure_for_each_device(ses_enclosure_find_by_addr, &efd);
++ ses_enclosure_find_by_addr(edev, &efd);
+ }
+ }
+
+--
+2.51.0
+
--- /dev/null
+From 3993331c3215e5caada534a60632ff9b94155541 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 29 Jan 2026 15:30:39 +0100
+Subject: scsi: storvsc: Fix scheduling while atomic on PREEMPT_RT
+
+From: Jan Kiszka <jan.kiszka@siemens.com>
+
+[ Upstream commit 57297736c08233987e5d29ce6584c6ca2a831b12 ]
+
+This resolves the follow splat and lock-up when running with PREEMPT_RT
+enabled on Hyper-V:
+
+[ 415.140818] BUG: scheduling while atomic: stress-ng-iomix/1048/0x00000002
+[ 415.140822] INFO: lockdep is turned off.
+[ 415.140823] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec ghash_clmulni_intel aesni_intel rapl binfmt_misc nls_ascii nls_cp437 vfat fat snd_pcm hyperv_drm snd_timer drm_client_lib drm_shmem_helper snd sg soundcore drm_kms_helper pcspkr hv_balloon hv_utils evdev joydev drm configfs efi_pstore nfnetlink vsock_loopback vmw_vsock_virtio_transport_common hv_sock vmw_vsock_vmci_transport vsock vmw_vmci efivarfs autofs4 ext4 crc16 mbcache jbd2 sr_mod sd_mod cdrom hv_storvsc serio_raw hid_generic scsi_transport_fc hid_hyperv scsi_mod hid hv_netvsc hyperv_keyboard scsi_common
+[ 415.140846] Preemption disabled at:
+[ 415.140847] [<ffffffffc0656171>] storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc]
+[ 415.140854] CPU: 8 UID: 0 PID: 1048 Comm: stress-ng-iomix Not tainted 6.19.0-rc7 #30 PREEMPT_{RT,(full)}
+[ 415.140856] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/04/2024
+[ 415.140857] Call Trace:
+[ 415.140861] <TASK>
+[ 415.140861] ? storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc]
+[ 415.140863] dump_stack_lvl+0x91/0xb0
+[ 415.140870] __schedule_bug+0x9c/0xc0
+[ 415.140875] __schedule+0xdf6/0x1300
+[ 415.140877] ? rtlock_slowlock_locked+0x56c/0x1980
+[ 415.140879] ? rcu_is_watching+0x12/0x60
+[ 415.140883] schedule_rtlock+0x21/0x40
+[ 415.140885] rtlock_slowlock_locked+0x502/0x1980
+[ 415.140891] rt_spin_lock+0x89/0x1e0
+[ 415.140893] hv_ringbuffer_write+0x87/0x2a0
+[ 415.140899] vmbus_sendpacket_mpb_desc+0xb6/0xe0
+[ 415.140900] ? rcu_is_watching+0x12/0x60
+[ 415.140902] storvsc_queuecommand+0x669/0xbe0 [hv_storvsc]
+[ 415.140904] ? HARDIRQ_verbose+0x10/0x10
+[ 415.140908] ? __rq_qos_issue+0x28/0x40
+[ 415.140911] scsi_queue_rq+0x760/0xd80 [scsi_mod]
+[ 415.140926] __blk_mq_issue_directly+0x4a/0xc0
+[ 415.140928] blk_mq_issue_direct+0x87/0x2b0
+[ 415.140931] blk_mq_dispatch_queue_requests+0x120/0x440
+[ 415.140933] blk_mq_flush_plug_list+0x7a/0x1a0
+[ 415.140935] __blk_flush_plug+0xf4/0x150
+[ 415.140940] __submit_bio+0x2b2/0x5c0
+[ 415.140944] ? submit_bio_noacct_nocheck+0x272/0x360
+[ 415.140946] submit_bio_noacct_nocheck+0x272/0x360
+[ 415.140951] ext4_read_bh_lock+0x3e/0x60 [ext4]
+[ 415.140995] ext4_block_write_begin+0x396/0x650 [ext4]
+[ 415.141018] ? __pfx_ext4_da_get_block_prep+0x10/0x10 [ext4]
+[ 415.141038] ext4_da_write_begin+0x1c4/0x350 [ext4]
+[ 415.141060] generic_perform_write+0x14e/0x2c0
+[ 415.141065] ext4_buffered_write_iter+0x6b/0x120 [ext4]
+[ 415.141083] vfs_write+0x2ca/0x570
+[ 415.141087] ksys_write+0x76/0xf0
+[ 415.141089] do_syscall_64+0x99/0x1490
+[ 415.141093] ? rcu_is_watching+0x12/0x60
+[ 415.141095] ? finish_task_switch.isra.0+0xdf/0x3d0
+[ 415.141097] ? rcu_is_watching+0x12/0x60
+[ 415.141098] ? lock_release+0x1f0/0x2a0
+[ 415.141100] ? rcu_is_watching+0x12/0x60
+[ 415.141101] ? finish_task_switch.isra.0+0xe4/0x3d0
+[ 415.141103] ? rcu_is_watching+0x12/0x60
+[ 415.141104] ? __schedule+0xb34/0x1300
+[ 415.141106] ? hrtimer_try_to_cancel+0x1d/0x170
+[ 415.141109] ? do_nanosleep+0x8b/0x160
+[ 415.141111] ? hrtimer_nanosleep+0x89/0x100
+[ 415.141114] ? __pfx_hrtimer_wakeup+0x10/0x10
+[ 415.141116] ? xfd_validate_state+0x26/0x90
+[ 415.141118] ? rcu_is_watching+0x12/0x60
+[ 415.141120] ? do_syscall_64+0x1e0/0x1490
+[ 415.141121] ? do_syscall_64+0x1e0/0x1490
+[ 415.141123] ? rcu_is_watching+0x12/0x60
+[ 415.141124] ? do_syscall_64+0x1e0/0x1490
+[ 415.141125] ? do_syscall_64+0x1e0/0x1490
+[ 415.141127] ? irqentry_exit+0x140/0x7e0
+[ 415.141129] entry_SYSCALL_64_after_hwframe+0x76/0x7e
+
+get_cpu() disables preemption while the spinlock hv_ringbuffer_write is
+using is converted to an rt-mutex under PREEMPT_RT.
+
+Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
+Tested-by: Florian Bezdeka <florian.bezdeka@siemens.com>
+Reviewed-by: Michael Kelley <mhklinux@outlook.com>
+Tested-by: Michael Kelley <mhklinux@outlook.com>
+Link: https://patch.msgid.link/0c7fb5cd-fb21-4760-8593-e04bade84744@siemens.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/storvsc_drv.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
+index 9dcad02ce4895..106bccaac4276 100644
+--- a/drivers/scsi/storvsc_drv.c
++++ b/drivers/scsi/storvsc_drv.c
+@@ -1861,8 +1861,9 @@ static int storvsc_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *scmnd)
+ cmd_request->payload_sz = payload_sz;
+
+ /* Invokes the vsc to start an IO */
+- ret = storvsc_do_io(dev, cmd_request, get_cpu());
+- put_cpu();
++ migrate_disable();
++ ret = storvsc_do_io(dev, cmd_request, smp_processor_id());
++ migrate_enable();
+
+ if (ret)
+ scsi_dma_unmap(scmnd);
+--
+2.51.0
+
--- /dev/null
+From a75a58a077c684db31907d8ce763c7bea6beb868 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 23 Feb 2026 14:56:09 +0800
+Subject: scsi: ufs: core: Fix possible NULL pointer dereference in
+ ufshcd_add_command_trace()
+
+From: Peter Wang <peter.wang@mediatek.com>
+
+[ Upstream commit 30df81f2228d65bddf492db3929d9fcaffd38fc5 ]
+
+The kernel log indicates a crash in ufshcd_add_command_trace, due to a NULL
+pointer dereference when accessing hwq->id. This can happen if
+ufshcd_mcq_req_to_hwq() returns NULL.
+
+This patch adds a NULL check for hwq before accessing its id field to
+prevent a kernel crash.
+
+Kernel log excerpt:
+[<ffffffd5d192dc4c>] notify_die+0x4c/0x8c
+[<ffffffd5d1814e58>] __die+0x60/0xb0
+[<ffffffd5d1814d64>] die+0x4c/0xe0
+[<ffffffd5d181575c>] die_kernel_fault+0x74/0x88
+[<ffffffd5d1864db4>] __do_kernel_fault+0x314/0x318
+[<ffffffd5d2a3cdf8>] do_page_fault+0xa4/0x5f8
+[<ffffffd5d2a3cd34>] do_translation_fault+0x34/0x54
+[<ffffffd5d1864524>] do_mem_abort+0x50/0xa8
+[<ffffffd5d2a297dc>] el1_abort+0x3c/0x64
+[<ffffffd5d2a29718>] el1h_64_sync_handler+0x44/0xcc
+[<ffffffd5d181133c>] el1h_64_sync+0x80/0x88
+[<ffffffd5d255c1dc>] ufshcd_add_command_trace+0x23c/0x320
+[<ffffffd5d255bad8>] ufshcd_compl_one_cqe+0xa4/0x404
+[<ffffffd5d2572968>] ufshcd_mcq_poll_cqe_lock+0xac/0x104
+[<ffffffd5d11c7460>] ufs_mtk_mcq_intr+0x54/0x74 [ufs_mediatek_mod]
+[<ffffffd5d19ab92c>] __handle_irq_event_percpu+0xc8/0x348
+[<ffffffd5d19abca8>] handle_irq_event+0x3c/0xa8
+[<ffffffd5d19b1f0c>] handle_fasteoi_irq+0xf8/0x294
+[<ffffffd5d19aa778>] generic_handle_domain_irq+0x54/0x80
+[<ffffffd5d18102bc>] gic_handle_irq+0x1d4/0x330
+[<ffffffd5d1838210>] call_on_irq_stack+0x44/0x68
+[<ffffffd5d183af30>] do_interrupt_handler+0x78/0xd8
+[<ffffffd5d2a29c00>] el1_interrupt+0x48/0xa8
+[<ffffffd5d2a29ba8>] el1h_64_irq_handler+0x14/0x24
+[<ffffffd5d18113c4>] el1h_64_irq+0x80/0x88
+[<ffffffd5d2527fb4>] arch_local_irq_enable+0x4/0x1c
+[<ffffffd5d25282e4>] cpuidle_enter+0x34/0x54
+[<ffffffd5d195a678>] do_idle+0x1dc/0x2f8
+[<ffffffd5d195a7c4>] cpu_startup_entry+0x30/0x3c
+[<ffffffd5d18155c4>] secondary_start_kernel+0x134/0x1ac
+[<ffffffd5d18640bc>] __secondary_switched+0xc4/0xcc
+
+Signed-off-by: Peter Wang <peter.wang@mediatek.com>
+Reviewed-by: Bart Van Assche <bvanassche@acm.org>
+Link: https://patch.msgid.link/20260223065657.2432447-1-peter.wang@mediatek.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/ufs/core/ufshcd.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
+index 0b74ef63e6721..4b34f65e6d8e2 100644
+--- a/drivers/ufs/core/ufshcd.c
++++ b/drivers/ufs/core/ufshcd.c
+@@ -461,8 +461,8 @@ static void ufshcd_add_command_trace(struct ufs_hba *hba, unsigned int tag,
+
+ if (is_mcq_enabled(hba)) {
+ struct ufs_hw_queue *hwq = ufshcd_mcq_req_to_hwq(hba, rq);
+-
+- hwq_id = hwq->id;
++ if (hwq)
++ hwq_id = hwq->id;
+ } else {
+ doorbell = ufshcd_readl(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL);
+ }
+--
+2.51.0
+
--- /dev/null
+From fb8f32c3696bcf947618b920f9d8d67f6910a287 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 24 Feb 2026 14:32:28 +0800
+Subject: scsi: ufs: core: Fix shift out of bounds when MAXQ=32
+
+From: wangshuaiwei <wangshuaiwei1@xiaomi.com>
+
+[ Upstream commit 2f38fd99c0004676d835ae96ac4f3b54edc02c82 ]
+
+According to JESD223F, the maximum number of queues (MAXQ) is 32. When MCQ
+is enabled and ESI is disabled, nr_hw_queues=32 causes a shift overflow
+problem.
+
+Fix this by using 64-bit intermediate values to handle the nr_hw_queues=32
+case safely.
+
+Signed-off-by: wangshuaiwei <wangshuaiwei1@xiaomi.com>
+Reviewed-by: Bart Van Assche <bvanassche@acm.org>
+Link: https://patch.msgid.link/20260224063228.50112-1-wangshuaiwei1@xiaomi.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/ufs/core/ufshcd.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
+index 4b34f65e6d8e2..d109a0c8f75ff 100644
+--- a/drivers/ufs/core/ufshcd.c
++++ b/drivers/ufs/core/ufshcd.c
+@@ -6960,7 +6960,7 @@ static irqreturn_t ufshcd_handle_mcq_cq_events(struct ufs_hba *hba)
+
+ ret = ufshcd_vops_get_outstanding_cqs(hba, &outstanding_cqs);
+ if (ret)
+- outstanding_cqs = (1U << hba->nr_hw_queues) - 1;
++ outstanding_cqs = (1ULL << hba->nr_hw_queues) - 1;
+
+ /* Exclude the poll queues */
+ nr_queues = hba->nr_hw_queues - hba->nr_queues[HCTX_TYPE_POLL];
+--
+2.51.0
+
apparmor-fix-differential-encoding-verification.patch
apparmor-fix-race-on-rawdata-dereference.patch
apparmor-fix-race-between-freeing-data-and-fs-accessing-it.patch
+scsi-storvsc-fix-scheduling-while-atomic-on-preempt_.patch
+acpi-pm-save-nvs-memory-on-lenovo-g70-35.patch
+scsi-mpi3mr-add-null-checks-when-resetting-request-a.patch
+unshare-fix-unshare_fs-handling.patch
+wifi-mac80211-set-default-wmm-parameters-on-all-link.patch
+acpi-osi-add-dmi-quirk-for-acer-aspire-one-d255.patch
+scsi-ses-fix-devices-attaching-to-different-hosts.patch
+asoc-amd-yc-add-asus-expertbook-bm1503cda-to-quirk-t.patch
+asoc-cs42l43-report-insert-for-exotic-peripherals.patch
+scsi-ufs-core-fix-possible-null-pointer-dereference-.patch
+scsi-ufs-core-fix-shift-out-of-bounds-when-maxq-32.patch
+alsa-usb-audio-avoid-implicit-feedback-mode-on-diyin.patch
+alsa-usb-audio-check-max-frame-size-for-implicit-fee.patch
+powerpc-uaccess-fix-inline-assembly-for-clang-build-.patch
+remoteproc-sysmon-correct-subsys_name_len-type-in-qm.patch
+remoteproc-mediatek-unprepare-scp-clock-during-syste.patch
+powerpc-83xx-km83xx-fix-keymile-vendor-prefix.patch
+smb-server-fix-another-refcount-leak-in-smb2_open.patch
--- /dev/null
+From 6040733a56e347516cba6675cff758a29df681f7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 26 Feb 2026 21:54:21 -0800
+Subject: smb/server: Fix another refcount leak in smb2_open()
+
+From: Guenter Roeck <linux@roeck-us.net>
+
+[ Upstream commit c15e7c62feb3751cbdd458555819df1d70374890 ]
+
+If ksmbd_override_fsids() fails, we jump to err_out2. At that point, fp is
+NULL because it hasn't been assigned dh_info.fp yet, so ksmbd_fd_put(work,
+fp) will not be called. However, dh_info.fp was already inserted into the
+session file table by ksmbd_reopen_durable_fd(), so it will leak in the
+session file table until the session is closed.
+
+Move fp = dh_info.fp; ahead of the ksmbd_override_fsids() check to fix the
+problem.
+
+Found by an experimental AI code review agent at Google.
+
+Fixes: c8efcc786146a ("ksmbd: add support for durable handles v1/v2")
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Reviewed-by: ChenXiaoSong <chenxiaosong@kylinos.cn>
+Acked-by: Namjae Jeon <linkinjeon@kernel.org>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/smb/server/smb2pdu.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c
+index da4d914c87ad2..5a112211a7111 100644
+--- a/fs/smb/server/smb2pdu.c
++++ b/fs/smb/server/smb2pdu.c
+@@ -2990,13 +2990,14 @@ int smb2_open(struct ksmbd_work *work)
+ goto err_out2;
+ }
+
++ fp = dh_info.fp;
++
+ if (ksmbd_override_fsids(work)) {
+ rc = -ENOMEM;
+ ksmbd_put_durable_fd(dh_info.fp);
+ goto err_out2;
+ }
+
+- fp = dh_info.fp;
+ file_info = FILE_OPENED;
+
+ rc = ksmbd_vfs_getattr(&fp->filp->f_path, &stat);
+--
+2.51.0
+
--- /dev/null
+From e442c2ba95d52f16b173014ec45b66e15ea982be Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 7 Feb 2026 08:25:24 +0000
+Subject: unshare: fix unshare_fs() handling
+
+From: Al Viro <viro@zeniv.linux.org.uk>
+
+[ Upstream commit 6c4b2243cb6c0755159bd567130d5e12e7b10d9f ]
+
+There's an unpleasant corner case in unshare(2), when we have a
+CLONE_NEWNS in flags and current->fs hadn't been shared at all; in that
+case copy_mnt_ns() gets passed current->fs instead of a private copy,
+which causes interesting warts in proof of correctness]
+
+> I guess if private means fs->users == 1, the condition could still be true.
+
+Unfortunately, it's worse than just a convoluted proof of correctness.
+Consider the case when we have CLONE_NEWCGROUP in addition to CLONE_NEWNS
+(and current->fs->users == 1).
+
+We pass current->fs to copy_mnt_ns(), all right. Suppose it succeeds and
+flips current->fs->{pwd,root} to corresponding locations in the new namespace.
+Now we proceed to copy_cgroup_ns(), which fails (e.g. with -ENOMEM).
+We call put_mnt_ns() on the namespace created by copy_mnt_ns(), it's
+destroyed and its mount tree is dissolved, but... current->fs->root and
+current->fs->pwd are both left pointing to now detached mounts.
+
+They are pinning those, so it's not a UAF, but it leaves the calling
+process with unshare(2) failing with -ENOMEM _and_ leaving it with
+pwd and root on detached isolated mounts. The last part is clearly a bug.
+
+There is other fun related to that mess (races with pivot_root(), including
+the one between pivot_root() and fork(), of all things), but this one
+is easy to isolate and fix - treat CLONE_NEWNS as "allocate a new
+fs_struct even if it hadn't been shared in the first place". Sure, we could
+go for something like "if both CLONE_NEWNS *and* one of the things that might
+end up failing after copy_mnt_ns() call in create_new_namespaces() are set,
+force allocation of new fs_struct", but let's keep it simple - the cost
+of copy_fs_struct() is trivial.
+
+Another benefit is that copy_mnt_ns() with CLONE_NEWNS *always* gets
+a freshly allocated fs_struct, yet to be attached to anything. That
+seriously simplifies the analysis...
+
+FWIW, that bug had been there since the introduction of unshare(2) ;-/
+
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Link: https://patch.msgid.link/20260207082524.GE3183987@ZenIV
+Tested-by: Waiman Long <longman@redhat.com>
+Signed-off-by: Christian Brauner <brauner@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/fork.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/kernel/fork.c b/kernel/fork.c
+index 2141ebb2ef92a..ce6f6e1e39057 100644
+--- a/kernel/fork.c
++++ b/kernel/fork.c
+@@ -3350,7 +3350,7 @@ static int unshare_fs(unsigned long unshare_flags, struct fs_struct **new_fsp)
+ return 0;
+
+ /* don't need lock here; in the worst case we'll do useless copy */
+- if (fs->users == 1)
++ if (!(unshare_flags & CLONE_NEWNS) && fs->users == 1)
+ return 0;
+
+ *new_fsp = copy_fs_struct(fs);
+--
+2.51.0
+
--- /dev/null
+From dcec9f5beb5d534a8e000c1c3032fbdcc1708e90 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 5 Feb 2026 15:12:16 +0530
+Subject: wifi: mac80211: set default WMM parameters on all links
+
+From: Ramanathan Choodamani <quic_rchoodam@quicinc.com>
+
+[ Upstream commit 2259d14499d16b115ef8d5d2ddc867e2be7cb5b5 ]
+
+Currently, mac80211 only initializes default WMM parameters
+on the deflink during do_open(). For MLO cases, this
+leaves the additional links without proper WMM defaults
+if hostapd does not supply per-link WMM parameters, leading
+to inconsistent QoS behavior across links.
+
+Set default WMM parameters for each link during
+ieee80211_vif_update_links(), because this ensures all
+individual links in an MLD have valid WMM settings during
+bring-up and behave consistently across different BSS.
+
+Signed-off-by: Ramanathan Choodamani <quic_rchoodam@quicinc.com>
+Signed-off-by: Aishwarya R <aishwarya.r@oss.qualcomm.com>
+Link: https://patch.msgid.link/20260205094216.3093542-1-aishwarya.r@oss.qualcomm.com
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/mac80211/link.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/net/mac80211/link.c b/net/mac80211/link.c
+index af4d2b2e9a26f..2b44f1fe2031a 100644
+--- a/net/mac80211/link.c
++++ b/net/mac80211/link.c
+@@ -201,6 +201,7 @@ static int ieee80211_vif_update_links(struct ieee80211_sub_if_data *sdata,
+ struct ieee80211_bss_conf *old[IEEE80211_MLD_MAX_NUM_LINKS];
+ struct ieee80211_link_data *old_data[IEEE80211_MLD_MAX_NUM_LINKS];
+ bool use_deflink = old_links == 0; /* set for error case */
++ bool non_sta = sdata->vif.type != NL80211_IFTYPE_STATION;
+
+ sdata_assert_lock(sdata);
+
+@@ -254,6 +255,7 @@ static int ieee80211_vif_update_links(struct ieee80211_sub_if_data *sdata,
+ link = links[link_id];
+ ieee80211_link_init(sdata, link_id, &link->data, &link->conf);
+ ieee80211_link_setup(&link->data);
++ ieee80211_set_wmm_default(&link->data, true, non_sta);
+ }
+
+ if (new_links == 0)
+--
+2.51.0
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
