--- /dev/null
+From b4f60a053a2534c3e510ba0c1f8727566adf8317 Mon Sep 17 00:00:00 2001
+From: Shyam Prasad N <sprasad@microsoft.com>
+Date: Mon, 2 Jun 2025 22:37:16 +0530
+Subject: cifs: dns resolution is needed only for primary channel
+
+From: Shyam Prasad N <sprasad@microsoft.com>
+
+commit b4f60a053a2534c3e510ba0c1f8727566adf8317 upstream.
+
+When calling cifs_reconnect, before the connection to the
+server is reestablished, the code today does a DNS resolution and
+updates server->dstaddr.
+
+However, this is not necessary for secondary channels. Secondary
+channels use the interface list returned by the server to decide
+which address to connect to. And that happens after tcon is reconnected
+and server interfaces are requested.
+
+Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/smb/client/connect.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/fs/smb/client/connect.c
++++ b/fs/smb/client/connect.c
+@@ -408,7 +408,8 @@ static int __cifs_reconnect(struct TCP_S
+ try_to_freeze();
+ cifs_server_lock(server);
+
+- if (!cifs_swn_set_server_dstaddr(server)) {
++ if (!cifs_swn_set_server_dstaddr(server) &&
++ !SERVER_IS_CHAN(server)) {
+ /* resolve the hostname again to make sure that IP address is up-to-date */
+ rc = reconn_set_ipaddr_from_hostname(server);
+ cifs_dbg(FYI, "%s: reconn_set_ipaddr_from_hostname: rc=%d\n", __func__, rc);
--- /dev/null
+From 1f396b9bfe39aaf55ea74a7005806164b236653d Mon Sep 17 00:00:00 2001
+From: Shyam Prasad N <sprasad@microsoft.com>
+Date: Mon, 2 Jun 2025 22:37:13 +0530
+Subject: cifs: reset connections for all channels when reconnect requested
+
+From: Shyam Prasad N <sprasad@microsoft.com>
+
+commit 1f396b9bfe39aaf55ea74a7005806164b236653d upstream.
+
+cifs_reconnect can be called with a flag to mark the session as needing
+reconnect too. When this is done, we expect the connections of all
+channels to be reconnected too, which is not happening today.
+
+Without doing this, we have seen bad things happen when primary and
+secondary channels are connected to different servers (in case of cloud
+services like Azure Files SMB).
+
+This change would force all connections to reconnect as well, not just
+the sessions and tcons.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/smb/client/connect.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/fs/smb/client/connect.c
++++ b/fs/smb/client/connect.c
+@@ -393,6 +393,13 @@ static int __cifs_reconnect(struct TCP_S
+ if (!cifs_tcp_ses_needs_reconnect(server, 1))
+ return 0;
+
++ /*
++ * if smb session has been marked for reconnect, also reconnect all
++ * connections. This way, the other connections do not end up bad.
++ */
++ if (mark_smb_session)
++ cifs_signal_cifsd_for_reconnect(server, mark_smb_session);
++
+ cifs_mark_tcp_ses_conns_for_reconnect(server, mark_smb_session);
+
+ cifs_abort_connection(server);
--- /dev/null
+From c1846893991f3b4ec8a0cc12219ada153f0814d6 Mon Sep 17 00:00:00 2001
+From: Shyam Prasad N <sprasad@microsoft.com>
+Date: Mon, 2 Jun 2025 22:37:14 +0530
+Subject: cifs: update dstaddr whenever channel iface is updated
+
+From: Shyam Prasad N <sprasad@microsoft.com>
+
+commit c1846893991f3b4ec8a0cc12219ada153f0814d6 upstream.
+
+When the server interface info changes (more common in clustered
+servers like Azure Files), the per-channel iface gets updated.
+However, this did not update the corresponding dstaddr. As a result
+these channels will still connect (or try connecting) to older addresses.
+
+Fixes: b54034a73baf ("cifs: during reconnect, update interface if necessary")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/smb/client/sess.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/fs/smb/client/sess.c
++++ b/fs/smb/client/sess.c
+@@ -473,6 +473,10 @@ cifs_chan_update_iface(struct cifs_ses *
+
+ ses->chans[chan_index].iface = iface;
+ spin_unlock(&ses->chan_lock);
++
++ spin_lock(&server->srv_lock);
++ memcpy(&server->dstaddr, &iface->sockaddr, sizeof(server->dstaddr));
++ spin_unlock(&server->srv_lock);
+ }
+
+ static int
--- /dev/null
+From abb4cf2f4c1c1b637cad04d726f2e13fd3051e03 Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Tue, 22 Apr 2025 21:17:36 +0200
+Subject: dm: lock limits when reading them
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit abb4cf2f4c1c1b637cad04d726f2e13fd3051e03 upstream.
+
+Lock queue limits when reading them, so that we don't read halfway
+modified values.
+
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/dm-table.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/drivers/md/dm-table.c
++++ b/drivers/md/dm-table.c
+@@ -431,6 +431,7 @@ static int dm_set_device_limits(struct d
+ return 0;
+ }
+
++ mutex_lock(&q->limits_lock);
+ if (blk_stack_limits(limits, &q->limits,
+ get_start_sect(bdev) + start) < 0)
+ DMWARN("%s: adding target device %pg caused an alignment inconsistency: "
+@@ -448,6 +449,7 @@ static int dm_set_device_limits(struct d
+ */
+ if (!dm_target_has_integrity(ti->type))
+ queue_limits_stack_integrity_bdev(limits, bdev);
++ mutex_unlock(&q->limits_lock);
+ return 0;
+ }
+
+@@ -1734,8 +1736,12 @@ static int device_not_write_zeroes_capab
+ sector_t start, sector_t len, void *data)
+ {
+ struct request_queue *q = bdev_get_queue(dev->bdev);
++ int b;
+
+- return !q->limits.max_write_zeroes_sectors;
++ mutex_lock(&q->limits_lock);
++ b = !q->limits.max_write_zeroes_sectors;
++ mutex_unlock(&q->limits_lock);
++ return b;
+ }
+
+ static bool dm_table_supports_write_zeroes(struct dm_table *t)
--- /dev/null
+From 829451beaed6165eb11d7a9fb4e28eb17f489980 Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Tue, 3 Jun 2025 18:53:17 +0200
+Subject: dm-mirror: fix a tiny race condition
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit 829451beaed6165eb11d7a9fb4e28eb17f489980 upstream.
+
+There's a tiny race condition in dm-mirror. The functions queue_bio and
+write_callback grab a spinlock, add a bio to the list, drop the spinlock
+and wake up the mirrord thread that processes bios in the list.
+
+It may be possible that the mirrord thread processes the bio just after
+spin_unlock_irqrestore is called, before wakeup_mirrord. This spurious
+wake-up is normally harmless, however if the device mapper device is
+unloaded just after the bio was processed, it may be possible that
+wakeup_mirrord(ms) uses invalid "ms" pointer.
+
+Fix this bug by moving wakeup_mirrord inside the spinlock.
+
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/dm-raid1.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/drivers/md/dm-raid1.c
++++ b/drivers/md/dm-raid1.c
+@@ -133,10 +133,9 @@ static void queue_bio(struct mirror_set
+ spin_lock_irqsave(&ms->lock, flags);
+ should_wake = !(bl->head);
+ bio_list_add(bl, bio);
+- spin_unlock_irqrestore(&ms->lock, flags);
+-
+ if (should_wake)
+ wakeup_mirrord(ms);
++ spin_unlock_irqrestore(&ms->lock, flags);
+ }
+
+ static void dispatch_bios(void *context, struct bio_list *bio_list)
+@@ -646,9 +645,9 @@ static void write_callback(unsigned long
+ if (!ms->failures.head)
+ should_wake = 1;
+ bio_list_add(&ms->failures, bio);
+- spin_unlock_irqrestore(&ms->lock, flags);
+ if (should_wake)
+ wakeup_mirrord(ms);
++ spin_unlock_irqrestore(&ms->lock, flags);
+ }
+
+ static void do_write(struct mirror_set *ms, struct bio *bio)
--- /dev/null
+From 66be40a14e496689e1f0add50118408e22c96169 Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Tue, 3 Jun 2025 18:55:50 +0200
+Subject: dm-verity: fix a memory leak if some arguments are specified multiple times
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit 66be40a14e496689e1f0add50118408e22c96169 upstream.
+
+If some of the arguments "check_at_most_once", "ignore_zero_blocks",
+"use_fec_from_device", "root_hash_sig_key_desc" were specified more than
+once on the target line, a memory leak would happen.
+
+This commit fixes the memory leak. It also fixes error handling in
+verity_verify_sig_parse_opt_args.
+
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/dm-verity-fec.c | 4 ++++
+ drivers/md/dm-verity-target.c | 8 +++++++-
+ drivers/md/dm-verity-verify-sig.c | 17 +++++++++++++----
+ 3 files changed, 24 insertions(+), 5 deletions(-)
+
+--- a/drivers/md/dm-verity-fec.c
++++ b/drivers/md/dm-verity-fec.c
+@@ -604,6 +604,10 @@ int verity_fec_parse_opt_args(struct dm_
+ (*argc)--;
+
+ if (!strcasecmp(arg_name, DM_VERITY_OPT_FEC_DEV)) {
++ if (v->fec->dev) {
++ ti->error = "FEC device already specified";
++ return -EINVAL;
++ }
+ r = dm_get_device(ti, arg_value, BLK_OPEN_READ, &v->fec->dev);
+ if (r) {
+ ti->error = "FEC device lookup failed";
+--- a/drivers/md/dm-verity-target.c
++++ b/drivers/md/dm-verity-target.c
+@@ -1080,6 +1080,9 @@ static int verity_alloc_most_once(struct
+ {
+ struct dm_target *ti = v->ti;
+
++ if (v->validated_blocks)
++ return 0;
++
+ /* the bitset can only handle INT_MAX blocks */
+ if (v->data_blocks > INT_MAX) {
+ ti->error = "device too large to use check_at_most_once";
+@@ -1103,6 +1106,9 @@ static int verity_alloc_zero_digest(stru
+ struct dm_verity_io *io;
+ u8 *zero_data;
+
++ if (v->zero_digest)
++ return 0;
++
+ v->zero_digest = kmalloc(v->digest_size, GFP_KERNEL);
+
+ if (!v->zero_digest)
+@@ -1537,7 +1543,7 @@ static int verity_ctr(struct dm_target *
+ goto bad;
+ }
+
+- /* Root hash signature is a optional parameter*/
++ /* Root hash signature is an optional parameter */
+ r = verity_verify_root_hash(root_hash_digest_to_validate,
+ strlen(root_hash_digest_to_validate),
+ verify_args.sig,
+--- a/drivers/md/dm-verity-verify-sig.c
++++ b/drivers/md/dm-verity-verify-sig.c
+@@ -71,9 +71,14 @@ int verity_verify_sig_parse_opt_args(str
+ const char *arg_name)
+ {
+ struct dm_target *ti = v->ti;
+- int ret = 0;
++ int ret;
+ const char *sig_key = NULL;
+
++ if (v->signature_key_desc) {
++ ti->error = DM_VERITY_VERIFY_ERR("root_hash_sig_key_desc already specified");
++ return -EINVAL;
++ }
++
+ if (!*argc) {
+ ti->error = DM_VERITY_VERIFY_ERR("Signature key not specified");
+ return -EINVAL;
+@@ -83,14 +88,18 @@ int verity_verify_sig_parse_opt_args(str
+ (*argc)--;
+
+ ret = verity_verify_get_sig_from_key(sig_key, sig_opts);
+- if (ret < 0)
++ if (ret < 0) {
+ ti->error = DM_VERITY_VERIFY_ERR("Invalid key specified");
++ return ret;
++ }
+
+ v->signature_key_desc = kstrdup(sig_key, GFP_KERNEL);
+- if (!v->signature_key_desc)
++ if (!v->signature_key_desc) {
++ ti->error = DM_VERITY_VERIFY_ERR("Could not allocate memory for signature key");
+ return -ENOMEM;
++ }
+
+- return ret;
++ return 0;
+ }
+
+ /*
--- /dev/null
+From 09eea7ad0b8e973dcf5ed49902838e5d68177f8e Mon Sep 17 00:00:00 2001
+From: Long Li <longli@microsoft.com>
+Date: Mon, 5 May 2025 17:56:33 -0700
+Subject: Drivers: hv: Allocate interrupt and monitor pages aligned to system page boundary
+
+From: Long Li <longli@microsoft.com>
+
+commit 09eea7ad0b8e973dcf5ed49902838e5d68177f8e upstream.
+
+There are use cases that interrupt and monitor pages are mapped to
+user-mode through UIO, so they need to be system page aligned. Some
+Hyper-V allocation APIs introduced earlier broke those requirements.
+
+Fix this by using page allocation functions directly for interrupt
+and monitor pages.
+
+Cc: stable@vger.kernel.org
+Fixes: ca48739e59df ("Drivers: hv: vmbus: Move Hyper-V page allocator to arch neutral code")
+Signed-off-by: Long Li <longli@microsoft.com>
+Reviewed-by: Michael Kelley <mhklinux@outlook.com>
+Link: https://lore.kernel.org/r/1746492997-4599-2-git-send-email-longli@linuxonhyperv.com
+Signed-off-by: Wei Liu <wei.liu@kernel.org>
+Message-ID: <1746492997-4599-2-git-send-email-longli@linuxonhyperv.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/hv/connection.c | 23 +++++++++++++++++------
+ 1 file changed, 17 insertions(+), 6 deletions(-)
+
+--- a/drivers/hv/connection.c
++++ b/drivers/hv/connection.c
+@@ -207,10 +207,19 @@ int vmbus_connect(void)
+ mutex_init(&vmbus_connection.channel_mutex);
+
+ /*
++ * The following Hyper-V interrupt and monitor pages can be used by
++ * UIO for mapping to user-space, so they should always be allocated on
++ * system page boundaries. The system page size must be >= the Hyper-V
++ * page size.
++ */
++ BUILD_BUG_ON(PAGE_SIZE < HV_HYP_PAGE_SIZE);
++
++ /*
+ * Setup the vmbus event connection for channel interrupt
+ * abstraction stuff
+ */
+- vmbus_connection.int_page = hv_alloc_hyperv_zeroed_page();
++ vmbus_connection.int_page =
++ (void *)__get_free_page(GFP_KERNEL | __GFP_ZERO);
+ if (vmbus_connection.int_page == NULL) {
+ ret = -ENOMEM;
+ goto cleanup;
+@@ -225,8 +234,8 @@ int vmbus_connect(void)
+ * Setup the monitor notification facility. The 1st page for
+ * parent->child and the 2nd page for child->parent
+ */
+- vmbus_connection.monitor_pages[0] = hv_alloc_hyperv_page();
+- vmbus_connection.monitor_pages[1] = hv_alloc_hyperv_page();
++ vmbus_connection.monitor_pages[0] = (void *)__get_free_page(GFP_KERNEL);
++ vmbus_connection.monitor_pages[1] = (void *)__get_free_page(GFP_KERNEL);
+ if ((vmbus_connection.monitor_pages[0] == NULL) ||
+ (vmbus_connection.monitor_pages[1] == NULL)) {
+ ret = -ENOMEM;
+@@ -342,21 +351,23 @@ void vmbus_disconnect(void)
+ destroy_workqueue(vmbus_connection.work_queue);
+
+ if (vmbus_connection.int_page) {
+- hv_free_hyperv_page(vmbus_connection.int_page);
++ free_page((unsigned long)vmbus_connection.int_page);
+ vmbus_connection.int_page = NULL;
+ }
+
+ if (vmbus_connection.monitor_pages[0]) {
+ if (!set_memory_encrypted(
+ (unsigned long)vmbus_connection.monitor_pages[0], 1))
+- hv_free_hyperv_page(vmbus_connection.monitor_pages[0]);
++ free_page((unsigned long)
++ vmbus_connection.monitor_pages[0]);
+ vmbus_connection.monitor_pages[0] = NULL;
+ }
+
+ if (vmbus_connection.monitor_pages[1]) {
+ if (!set_memory_encrypted(
+ (unsigned long)vmbus_connection.monitor_pages[1], 1))
+- hv_free_hyperv_page(vmbus_connection.monitor_pages[1]);
++ free_page((unsigned long)
++ vmbus_connection.monitor_pages[1]);
+ vmbus_connection.monitor_pages[1] = NULL;
+ }
+ }
--- /dev/null
+From f914b52c379c12288b7623bb814d0508dbe7481d Mon Sep 17 00:00:00 2001
+From: Ye Bin <yebin10@huawei.com>
+Date: Thu, 29 May 2025 19:19:54 +0800
+Subject: ftrace: Fix UAF when lookup kallsym after ftrace disabled
+
+From: Ye Bin <yebin10@huawei.com>
+
+commit f914b52c379c12288b7623bb814d0508dbe7481d upstream.
+
+The following issue happens with a buggy module:
+
+BUG: unable to handle page fault for address: ffffffffc05d0218
+PGD 1bd66f067 P4D 1bd66f067 PUD 1bd671067 PMD 101808067 PTE 0
+Oops: Oops: 0000 [#1] SMP KASAN PTI
+Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
+RIP: 0010:sized_strscpy+0x81/0x2f0
+RSP: 0018:ffff88812d76fa08 EFLAGS: 00010246
+RAX: 0000000000000000 RBX: ffffffffc0601010 RCX: dffffc0000000000
+RDX: 0000000000000038 RSI: dffffc0000000000 RDI: ffff88812608da2d
+RBP: 8080808080808080 R08: ffff88812608da2d R09: ffff88812608da68
+R10: ffff88812608d82d R11: ffff88812608d810 R12: 0000000000000038
+R13: ffff88812608da2d R14: ffffffffc05d0218 R15: fefefefefefefeff
+FS: 00007fef552de740(0000) GS:ffff8884251c7000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: ffffffffc05d0218 CR3: 00000001146f0000 CR4: 00000000000006f0
+DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+Call Trace:
+ <TASK>
+ ftrace_mod_get_kallsym+0x1ac/0x590
+ update_iter_mod+0x239/0x5b0
+ s_next+0x5b/0xa0
+ seq_read_iter+0x8c9/0x1070
+ seq_read+0x249/0x3b0
+ proc_reg_read+0x1b0/0x280
+ vfs_read+0x17f/0x920
+ ksys_read+0xf3/0x1c0
+ do_syscall_64+0x5f/0x2e0
+ entry_SYSCALL_64_after_hwframe+0x76/0x7e
+
+The above issue may happen as follows:
+(1) Add kprobe tracepoint;
+(2) insmod test.ko;
+(3) Module triggers ftrace disabled;
+(4) rmmod test.ko;
+(5) cat /proc/kallsyms; --> Will trigger UAF as test.ko already removed;
+ftrace_mod_get_kallsym()
+...
+strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN);
+...
+
+The problem is when a module triggers an issue with ftrace and
+sets ftrace_disable. The ftrace_disable is set when an anomaly is
+discovered and to prevent any more damage, ftrace stops all text
+modification. The issue that happened was that the ftrace_disable stops
+more than just the text modification.
+
+When a module is loaded, its init functions can also be traced. Because
+kallsyms deletes the init functions after a module has loaded, ftrace
+saves them when the module is loaded and function tracing is enabled. This
+allows the output of the function trace to show the init function names
+instead of just their raw memory addresses.
+
+When a module is removed, ftrace_release_mod() is called, and if
+ftrace_disable is set, it just returns without doing anything more. The
+problem here is that it leaves the mod_list still around and if kallsyms
+is called, it will call into this code and access the module memory that
+has already been freed as it will return:
+
+ strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN);
+
+Where the "mod" no longer exists and triggers a UAF bug.
+
+Link: https://lore.kernel.org/all/20250523135452.626d8dcd@gandalf.local.home/
+
+Cc: stable@vger.kernel.org
+Fixes: aba4b5c22cba ("ftrace: Save module init functions kallsyms symbols for tracing")
+Link: https://lore.kernel.org/20250529111955.2349189-2-yebin@huaweicloud.com
+Signed-off-by: Ye Bin <yebin10@huawei.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/ftrace.c | 10 +++++++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+--- a/kernel/trace/ftrace.c
++++ b/kernel/trace/ftrace.c
+@@ -7295,9 +7295,10 @@ void ftrace_release_mod(struct module *m
+
+ mutex_lock(&ftrace_lock);
+
+- if (ftrace_disabled)
+- goto out_unlock;
+-
++ /*
++ * To avoid the UAF problem after the module is unloaded, the
++ * 'mod_map' resource needs to be released unconditionally.
++ */
+ list_for_each_entry_safe(mod_map, n, &ftrace_mod_maps, list) {
+ if (mod_map->mod == mod) {
+ list_del_rcu(&mod_map->list);
+@@ -7306,6 +7307,9 @@ void ftrace_release_mod(struct module *m
+ }
+ }
+
++ if (ftrace_disabled)
++ goto out_unlock;
++
+ /*
+ * Each module has its own ftrace_pages, remove
+ * them from the list.
--- /dev/null
+From 15ac613f124e51a6623975efad9657b1f3ee47e7 Mon Sep 17 00:00:00 2001
+From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
+Date: Mon, 19 May 2025 15:56:57 +0100
+Subject: KVM: s390: rename PROT_NONE to PROT_TYPE_DUMMY
+
+From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
+
+commit 15ac613f124e51a6623975efad9657b1f3ee47e7 upstream.
+
+The enum type prot_type declared in arch/s390/kvm/gaccess.c declares an
+unfortunate identifier within it - PROT_NONE.
+
+This clashes with the protection bit define from the uapi for mmap()
+declared in include/uapi/asm-generic/mman-common.h, which is indeed what
+those casually reading this code would assume this to refer to.
+
+This means that any changes which subsequently alter headers in any way
+which results in the uapi header being imported here will cause build
+errors.
+
+Resolve the issue by renaming PROT_NONE to PROT_TYPE_DUMMY.
+
+Link: https://lkml.kernel.org/r/20250519145657.178365-1-lorenzo.stoakes@oracle.com
+Fixes: b3cefd6bf16e ("KVM: s390: Pass initialized arg even if unused")
+Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
+Suggested-by: Ignacio Moreno Gonzalez <Ignacio.MorenoGonzalez@kuka.com>
+Reported-by: kernel test robot <lkp@intel.com>
+Closes: https://lore.kernel.org/oe-kbuild-all/202505140943.IgHDa9s7-lkp@intel.com/
+Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com>
+Acked-by: Ignacio Moreno Gonzalez <Ignacio.MorenoGonzalez@kuka.com>
+Acked-by: Yang Shi <yang@os.amperecomputing.com>
+Reviewed-by: David Hildenbrand <david@redhat.com>
+Acked-by: Liam R. Howlett <Liam.Howlett@oracle.com>
+Reviewed-by: Oscar Salvador <osalvador@suse.de>
+Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
+Cc: <stable@vger.kernel.org>
+Cc: Alexander Gordeev <agordeev@linux.ibm.com>
+Cc: Heiko Carstens <hca@linux.ibm.com>
+Cc: James Houghton <jthoughton@google.com>
+Cc: Janosch Frank <frankja@linux.ibm.com>
+Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
+Cc: Paolo Bonzini <pbonzini@redhat.com>
+Cc: Sven Schnelle <svens@linux.ibm.com>
+Cc: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/s390/kvm/gaccess.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/arch/s390/kvm/gaccess.c
++++ b/arch/s390/kvm/gaccess.c
+@@ -317,7 +317,7 @@ enum prot_type {
+ PROT_TYPE_DAT = 3,
+ PROT_TYPE_IEP = 4,
+ /* Dummy value for passing an initialized value when code != PGM_PROTECTION */
+- PROT_NONE,
++ PROT_TYPE_DUMMY,
+ };
+
+ static int trans_exc_ending(struct kvm_vcpu *vcpu, int code, unsigned long gva, u8 ar,
+@@ -333,7 +333,7 @@ static int trans_exc_ending(struct kvm_v
+ switch (code) {
+ case PGM_PROTECTION:
+ switch (prot) {
+- case PROT_NONE:
++ case PROT_TYPE_DUMMY:
+ /* We should never get here, acts like termination */
+ WARN_ON_ONCE(1);
+ break;
+@@ -803,7 +803,7 @@ static int guest_range_to_gpas(struct kv
+ gpa = kvm_s390_real_to_abs(vcpu, ga);
+ if (!kvm_is_gpa_in_memslot(vcpu->kvm, gpa)) {
+ rc = PGM_ADDRESSING;
+- prot = PROT_NONE;
++ prot = PROT_TYPE_DUMMY;
+ }
+ }
+ if (rc)
+@@ -961,7 +961,7 @@ int access_guest_with_key(struct kvm_vcp
+ if (rc == PGM_PROTECTION)
+ prot = PROT_TYPE_KEYC;
+ else
+- prot = PROT_NONE;
++ prot = PROT_TYPE_DUMMY;
+ rc = trans_exc_ending(vcpu, rc, ga, ar, mode, prot, terminate);
+ }
+ out_unlock:
--- /dev/null
+From 1bee4838eb3a2c689f23c7170ea66ae87ea7d93a Mon Sep 17 00:00:00 2001
+From: Yosry Ahmed <yosry.ahmed@linux.dev>
+Date: Tue, 29 Apr 2025 08:32:15 -0700
+Subject: KVM: SVM: Clear current_vmcb during vCPU free for all *possible* CPUs
+
+From: Yosry Ahmed <yosry.ahmed@linux.dev>
+
+commit 1bee4838eb3a2c689f23c7170ea66ae87ea7d93a upstream.
+
+When freeing a vCPU and thus its VMCB, clear current_vmcb for all possible
+CPUs, not just online CPUs, as it's theoretically possible a CPU could go
+offline and come back online in conjunction with KVM reusing the page for
+a new VMCB.
+
+Link: https://lore.kernel.org/all/20250320013759.3965869-1-yosry.ahmed@linux.dev
+Fixes: fd65d3142f73 ("kvm: svm: Ensure an IBPB on all affected CPUs when freeing a vmcb")
+Cc: stable@vger.kernel.org
+Cc: Jim Mattson <jmattson@google.com>
+Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev>
+[sean: split to separate patch, write changelog]
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/svm/svm.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/kvm/svm/svm.c
++++ b/arch/x86/kvm/svm/svm.c
+@@ -1483,7 +1483,7 @@ static void svm_clear_current_vmcb(struc
+ {
+ int i;
+
+- for_each_online_cpu(i)
++ for_each_possible_cpu(i)
+ cmpxchg(per_cpu_ptr(&svm_data.current_vmcb, i), vmcb, NULL);
+ }
+
--- /dev/null
+From a0ee1d5faff135e28810f29e0f06328c66f89852 Mon Sep 17 00:00:00 2001
+From: Chao Gao <chao.gao@intel.com>
+Date: Mon, 24 Mar 2025 22:08:48 +0800
+Subject: KVM: VMX: Flush shadow VMCS on emergency reboot
+
+From: Chao Gao <chao.gao@intel.com>
+
+commit a0ee1d5faff135e28810f29e0f06328c66f89852 upstream.
+
+Ensure the shadow VMCS cache is evicted during an emergency reboot to
+prevent potential memory corruption if the cache is evicted after reboot.
+
+This issue was identified through code inspection, as __loaded_vmcs_clear()
+flushes both the normal VMCS and the shadow VMCS.
+
+Avoid checking the "launched" state during an emergency reboot, unlike the
+behavior in __loaded_vmcs_clear(). This is important because reboot NMIs
+can interfere with operations like copy_shadow_to_vmcs12(), where shadow
+VMCSes are loaded directly using VMPTRLD. In such cases, if NMIs occur
+right after the VMCS load, the shadow VMCSes will be active but the
+"launched" state may not be set.
+
+Fixes: 16f5b9034b69 ("KVM: nVMX: Copy processor-specific shadow-vmcs to VMCS12")
+Cc: stable@vger.kernel.org
+Signed-off-by: Chao Gao <chao.gao@intel.com>
+Reviewed-by: Kai Huang <kai.huang@intel.com>
+Link: https://lore.kernel.org/r/20250324140849.2099723-1-chao.gao@intel.com
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/vmx/vmx.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/kvm/vmx/vmx.c
++++ b/arch/x86/kvm/vmx/vmx.c
+@@ -770,8 +770,11 @@ void vmx_emergency_disable_virtualizatio
+ return;
+
+ list_for_each_entry(v, &per_cpu(loaded_vmcss_on_cpu, cpu),
+- loaded_vmcss_on_cpu_link)
++ loaded_vmcss_on_cpu_link) {
+ vmcs_clear(v->vmcs);
++ if (v->shadow_vmcs)
++ vmcs_clear(v->shadow_vmcs);
++ }
+
+ kvm_cpu_vmxoff();
+ }
--- /dev/null
+From 0f4ae7c6ecb89bfda026d210dcf8216fb67d2333 Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@gmail.com>
+Date: Sat, 29 Mar 2025 08:39:03 -0700
+Subject: mips: Add -std= flag specified in KBUILD_CFLAGS to vdso CFLAGS
+
+From: Khem Raj <raj.khem@gmail.com>
+
+commit 0f4ae7c6ecb89bfda026d210dcf8216fb67d2333 upstream.
+
+GCC 15 changed the default C standard dialect from gnu17 to gnu23,
+which should not have impacted the kernel because it explicitly requests
+the gnu11 standard in the main Makefile. However, mips/vdso code uses
+its own CFLAGS without a '-std=' value, which break with this dialect
+change because of the kernel's own definitions of bool, false, and true
+conflicting with the C23 reserved keywords.
+
+ include/linux/stddef.h:11:9: error: cannot use keyword 'false' as enumeration constant
+ 11 | false = 0,
+ | ^~~~~
+ include/linux/stddef.h:11:9: note: 'false' is a keyword with '-std=c23' onwards
+ include/linux/types.h:35:33: error: 'bool' cannot be defined via 'typedef'
+ 35 | typedef _Bool bool;
+ | ^~~~
+ include/linux/types.h:35:33: note: 'bool' is a keyword with '-std=c23' onwards
+
+Add -std as specified in KBUILD_CFLAGS to the decompressor and purgatory
+CFLAGS to eliminate these errors and make the C standard version of these
+areas match the rest of the kernel.
+
+Signed-off-by: Khem Raj <raj.khem@gmail.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/mips/vdso/Makefile | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/mips/vdso/Makefile
++++ b/arch/mips/vdso/Makefile
+@@ -27,6 +27,7 @@ endif
+ # offsets.
+ cflags-vdso := $(ccflags-vdso) \
+ $(filter -W%,$(filter-out -Wa$(comma)%,$(KBUILD_CFLAGS))) \
++ $(filter -std=%,$(KBUILD_CFLAGS)) \
+ -O3 -g -fPIC -fno-strict-aliasing -fno-common -fno-builtin -G 0 \
+ -mrelax-pic-calls $(call cc-option, -mexplicit-relocs) \
+ -fno-stack-protector -fno-jump-tables -DDISABLE_BRANCH_PROFILING \
--- /dev/null
+From 4a5a99bc79cdc4be63933653682b0261a67a0c9f Mon Sep 17 00:00:00 2001
+From: Wentao Liang <vulab@iscas.ac.cn>
+Date: Mon, 19 May 2025 23:42:24 +0800
+Subject: mtd: nand: sunxi: Add randomizer configuration before randomizer enable
+
+From: Wentao Liang <vulab@iscas.ac.cn>
+
+commit 4a5a99bc79cdc4be63933653682b0261a67a0c9f upstream.
+
+In sunxi_nfc_hw_ecc_read_chunk(), the sunxi_nfc_randomizer_enable() is
+called without the config of randomizer. A proper implementation can be
+found in sunxi_nfc_hw_ecc_read_chunks_dma().
+
+Add sunxi_nfc_randomizer_config() before the start of randomization.
+
+Fixes: 4be4e03efc7f ("mtd: nand: sunxi: add randomizer support")
+Cc: stable@vger.kernel.org # v4.6
+Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/nand/raw/sunxi_nand.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/mtd/nand/raw/sunxi_nand.c
++++ b/drivers/mtd/nand/raw/sunxi_nand.c
+@@ -817,6 +817,7 @@ static int sunxi_nfc_hw_ecc_read_chunk(s
+ if (ret)
+ return ret;
+
++ sunxi_nfc_randomizer_config(nand, page, false);
+ sunxi_nfc_randomizer_enable(nand);
+ writel(NFC_DATA_TRANS | NFC_DATA_SWAP_METHOD | NFC_ECC_OP,
+ nfc->regs + NFC_REG_CMD);
--- /dev/null
+From e6031b11544b44966ba020c867fe438bccd3bdfa Mon Sep 17 00:00:00 2001
+From: Md Sadre Alam <quic_mdalam@quicinc.com>
+Date: Thu, 10 Apr 2025 15:30:19 +0530
+Subject: mtd: rawnand: qcom: Fix read len for onfi param page
+
+From: Md Sadre Alam <quic_mdalam@quicinc.com>
+
+commit e6031b11544b44966ba020c867fe438bccd3bdfa upstream.
+
+The minimum size to fetch the data from device to QPIC buffer
+is 512-bytes. If size is less than 512-bytes the data will not be
+protected by ECC as per QPIC standard. So while reading onfi parameter
+page from NAND device set nandc->buf_count = 512.
+
+Cc: stable@vger.kernel.org
+Fixes: 89550beb098e ("mtd: rawnand: qcom: Implement exec_op()")
+Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Tested-by: Lakshmi Sowjanya D <quic_laksd@quicinc.com>
+Signed-off-by: Md Sadre Alam <quic_mdalam@quicinc.com>
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/nand/raw/qcom_nandc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/mtd/nand/raw/qcom_nandc.c
++++ b/drivers/mtd/nand/raw/qcom_nandc.c
+@@ -2917,7 +2917,7 @@ static int qcom_param_page_type_exec(str
+ write_reg_dma(nandc, NAND_DEV_CMD1, 1, NAND_BAM_NEXT_SGL);
+ }
+
+- nandc->buf_count = len;
++ nandc->buf_count = 512;
+ memset(nandc->data_buffer, 0xff, nandc->buf_count);
+
+ config_nand_single_cw_page_read(chip, false, 0);
--- /dev/null
+From 44ed1f5ff73e9e115b6f5411744d5a22ea1c855b Mon Sep 17 00:00:00 2001
+From: Wentao Liang <vulab@iscas.ac.cn>
+Date: Mon, 26 May 2025 11:43:44 +0800
+Subject: mtd: rawnand: sunxi: Add randomizer configuration in sunxi_nfc_hw_ecc_write_chunk
+
+From: Wentao Liang <vulab@iscas.ac.cn>
+
+commit 44ed1f5ff73e9e115b6f5411744d5a22ea1c855b upstream.
+
+The function sunxi_nfc_hw_ecc_write_chunk() calls the
+sunxi_nfc_hw_ecc_write_chunk(), but does not call the configuration
+function sunxi_nfc_randomizer_config(). Consequently, the randomization
+might not conduct correctly, which will affect the lifespan of NAND flash.
+A proper implementation can be found in sunxi_nfc_hw_ecc_write_page_dma().
+
+Add the sunxi_nfc_randomizer_config() to config randomizer.
+
+Fixes: 4be4e03efc7f ("mtd: nand: sunxi: add randomizer support")
+Cc: stable@vger.kernel.org # v4.6
+Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/nand/raw/sunxi_nand.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/mtd/nand/raw/sunxi_nand.c
++++ b/drivers/mtd/nand/raw/sunxi_nand.c
+@@ -1049,6 +1049,7 @@ static int sunxi_nfc_hw_ecc_write_chunk(
+ if (ret)
+ return ret;
+
++ sunxi_nfc_randomizer_config(nand, page, false);
+ sunxi_nfc_randomizer_enable(nand);
+ sunxi_nfc_hw_ecc_set_prot_oob_bytes(nand, oob, 0, bbm, page);
+
--- /dev/null
+From 9ad0452c0277b816a435433cca601304cfac7c21 Mon Sep 17 00:00:00 2001
+From: Qasim Ijaz <qasdev00@gmail.com>
+Date: Mon, 26 May 2025 19:36:07 +0100
+Subject: net: ch9200: fix uninitialised access during mii_nway_restart
+
+From: Qasim Ijaz <qasdev00@gmail.com>
+
+commit 9ad0452c0277b816a435433cca601304cfac7c21 upstream.
+
+In mii_nway_restart() the code attempts to call
+mii->mdio_read which is ch9200_mdio_read(). ch9200_mdio_read()
+utilises a local buffer called "buff", which is initialised
+with control_read(). However "buff" is conditionally
+initialised inside control_read():
+
+ if (err == size) {
+ memcpy(data, buf, size);
+ }
+
+If the condition of "err == size" is not met, then
+"buff" remains uninitialised. Once this happens the
+uninitialised "buff" is accessed and returned during
+ch9200_mdio_read():
+
+ return (buff[0] | buff[1] << 8);
+
+The problem stems from the fact that ch9200_mdio_read()
+ignores the return value of control_read(), leading to
+uinit-access of "buff".
+
+To fix this we should check the return value of
+control_read() and return early on error.
+
+Reported-by: syzbot <syzbot+3361c2d6f78a3e0892f9@syzkaller.appspotmail.com>
+Closes: https://syzkaller.appspot.com/bug?extid=3361c2d6f78a3e0892f9
+Tested-by: syzbot <syzbot+3361c2d6f78a3e0892f9@syzkaller.appspotmail.com>
+Fixes: 4a476bd6d1d9 ("usbnet: New driver for QinHeng CH9200 devices")
+Cc: stable@vger.kernel.org
+Signed-off-by: Qasim Ijaz <qasdev00@gmail.com>
+Link: https://patch.msgid.link/20250526183607.66527-1-qasdev00@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/usb/ch9200.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/usb/ch9200.c
++++ b/drivers/net/usb/ch9200.c
+@@ -178,6 +178,7 @@ static int ch9200_mdio_read(struct net_d
+ {
+ struct usbnet *dev = netdev_priv(netdev);
+ unsigned char buff[2];
++ int ret;
+
+ netdev_dbg(netdev, "%s phy_id:%02x loc:%02x\n",
+ __func__, phy_id, loc);
+@@ -185,8 +186,10 @@ static int ch9200_mdio_read(struct net_d
+ if (phy_id != 0)
+ return -ENODEV;
+
+- control_read(dev, REQUEST_READ, 0, loc * 2, buff, 0x02,
+- CONTROL_TIMEOUT_MS);
++ ret = control_read(dev, REQUEST_READ, 0, loc * 2, buff, 0x02,
++ CONTROL_TIMEOUT_MS);
++ if (ret < 0)
++ return ret;
+
+ return (buff[0] | buff[1] << 8);
+ }
--- /dev/null
+From 924577e4f6ca473de1528953a0e13505fae61d7b Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andr=C3=A9=20Almeida?= <andrealmeid@igalia.com>
+Date: Tue, 29 Apr 2025 15:38:50 -0300
+Subject: ovl: Fix nested backing file paths
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: André Almeida <andrealmeid@igalia.com>
+
+commit 924577e4f6ca473de1528953a0e13505fae61d7b upstream.
+
+When the lowerdir of an overlayfs is a merged directory of another
+overlayfs, ovl_open_realfile() will fail to open the real file and point
+to a lower dentry copy, without the proper parent path. After this,
+d_path() will then display the path incorrectly as if the file is placed
+in the root directory.
+
+This bug can be triggered with the following setup:
+
+ mkdir -p ovl-A/lower ovl-A/upper ovl-A/merge ovl-A/work
+ mkdir -p ovl-B/upper ovl-B/merge ovl-B/work
+
+ cp /bin/cat ovl-A/lower/
+
+ mount -t overlay overlay -o \
+ lowerdir=ovl-A/lower,upperdir=ovl-A/upper,workdir=ovl-A/work \
+ ovl-A/merge
+
+ mount -t overlay overlay -o \
+ lowerdir=ovl-A/merge,upperdir=ovl-B/upper,workdir=ovl-B/work \
+ ovl-B/merge
+
+ ovl-A/merge/cat /proc/self/maps | grep --color cat
+ ovl-B/merge/cat /proc/self/maps | grep --color cat
+
+The first cat will correctly show `/ovl-A/merge/cat`, while the second
+one shows just `/cat`.
+
+To fix that, uses file_user_path() inside of backing_file_open() to get
+the correct file path for the dentry.
+
+Co-developed-by: John Schoenick <johns@valvesoftware.com>
+Signed-off-by: John Schoenick <johns@valvesoftware.com>
+Signed-off-by: André Almeida <andrealmeid@igalia.com>
+Fixes: def3ae83da02 ("fs: store real path instead of fake path in backing file f_path")
+Cc: <stable@vger.kernel.org> # v6.7
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/overlayfs/file.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/overlayfs/file.c
++++ b/fs/overlayfs/file.c
+@@ -48,8 +48,8 @@ static struct file *ovl_open_realfile(co
+ if (!inode_owner_or_capable(real_idmap, realinode))
+ flags &= ~O_NOATIME;
+
+- realfile = backing_file_open(&file->f_path, flags, realpath,
+- current_cred());
++ realfile = backing_file_open(file_user_path((struct file *) file),
++ flags, realpath, current_cred());
+ }
+ revert_creds(old_cred);
+
--- /dev/null
+From 1f3303aa92e15fa273779acac2d0023609de30f1 Mon Sep 17 00:00:00 2001
+From: Huacai Chen <chenhuacai@loongson.cn>
+Date: Thu, 3 Apr 2025 12:07:56 +0800
+Subject: PCI: Add ACS quirk for Loongson PCIe
+
+From: Huacai Chen <chenhuacai@loongson.cn>
+
+commit 1f3303aa92e15fa273779acac2d0023609de30f1 upstream.
+
+Loongson PCIe Root Ports don't advertise an ACS capability, but they do not
+allow peer-to-peer transactions between Root Ports. Add an ACS quirk so
+each Root Port can be in a separate IOMMU group.
+
+Signed-off-by: Xianglai Li <lixianglai@loongson.cn>
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20250403040756.720409-1-chenhuacai@loongson.cn
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/quirks.c | 23 +++++++++++++++++++++++
+ 1 file changed, 23 insertions(+)
+
+--- a/drivers/pci/quirks.c
++++ b/drivers/pci/quirks.c
+@@ -4995,6 +4995,18 @@ static int pci_quirk_brcm_acs(struct pci
+ PCI_ACS_SV | PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_UF);
+ }
+
++static int pci_quirk_loongson_acs(struct pci_dev *dev, u16 acs_flags)
++{
++ /*
++ * Loongson PCIe Root Ports don't advertise an ACS capability, but
++ * they do not allow peer-to-peer transactions between Root Ports.
++ * Allow each Root Port to be in a separate IOMMU group by masking
++ * SV/RR/CR/UF bits.
++ */
++ return pci_acs_ctrl_enabled(acs_flags,
++ PCI_ACS_SV | PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_UF);
++}
++
+ /*
+ * Wangxun 40G/25G/10G/1G NICs have no ACS capability, but on
+ * multi-function devices, the hardware isolates the functions by
+@@ -5128,6 +5140,17 @@ static const struct pci_dev_acs_enabled
+ { PCI_VENDOR_ID_BROADCOM, 0x1762, pci_quirk_mf_endpoint_acs },
+ { PCI_VENDOR_ID_BROADCOM, 0x1763, pci_quirk_mf_endpoint_acs },
+ { PCI_VENDOR_ID_BROADCOM, 0xD714, pci_quirk_brcm_acs },
++ /* Loongson PCIe Root Ports */
++ { PCI_VENDOR_ID_LOONGSON, 0x3C09, pci_quirk_loongson_acs },
++ { PCI_VENDOR_ID_LOONGSON, 0x3C19, pci_quirk_loongson_acs },
++ { PCI_VENDOR_ID_LOONGSON, 0x3C29, pci_quirk_loongson_acs },
++ { PCI_VENDOR_ID_LOONGSON, 0x7A09, pci_quirk_loongson_acs },
++ { PCI_VENDOR_ID_LOONGSON, 0x7A19, pci_quirk_loongson_acs },
++ { PCI_VENDOR_ID_LOONGSON, 0x7A29, pci_quirk_loongson_acs },
++ { PCI_VENDOR_ID_LOONGSON, 0x7A39, pci_quirk_loongson_acs },
++ { PCI_VENDOR_ID_LOONGSON, 0x7A49, pci_quirk_loongson_acs },
++ { PCI_VENDOR_ID_LOONGSON, 0x7A59, pci_quirk_loongson_acs },
++ { PCI_VENDOR_ID_LOONGSON, 0x7A69, pci_quirk_loongson_acs },
+ /* Amazon Annapurna Labs */
+ { PCI_VENDOR_ID_AMAZON_ANNAPURNA_LABS, 0x0031, pci_quirk_al_acs },
+ /* Zhaoxin multi-function devices */
--- /dev/null
+From c8bcb01352a86bc5592403904109c22b66bd916e Mon Sep 17 00:00:00 2001
+From: Niklas Cassel <cassel@kernel.org>
+Date: Wed, 14 May 2025 09:43:15 +0200
+Subject: PCI: cadence-ep: Correct PBA offset in .set_msix() callback
+
+From: Niklas Cassel <cassel@kernel.org>
+
+commit c8bcb01352a86bc5592403904109c22b66bd916e upstream.
+
+While cdns_pcie_ep_set_msix() writes the Table Size field correctly (N-1),
+the calculation of the PBA offset is wrong because it calculates space for
+(N-1) entries instead of N.
+
+This results in the following QEMU error when using PCI passthrough on a
+device which relies on the PCI endpoint subsystem:
+
+ failed to add PCI capability 0x11[0x50]@0xb0: table & pba overlap, or they don't fit in BARs, or don't align
+
+Fix the calculation of PBA offset in the MSI-X capability.
+
+[bhelgaas: more specific subject and commit log]
+
+Fixes: 3ef5d16f50f8 ("PCI: cadence: Add MSI-X support to Endpoint driver")
+Signed-off-by: Niklas Cassel <cassel@kernel.org>
+Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
+Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20250514074313.283156-10-cassel@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/controller/cadence/pcie-cadence-ep.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/pci/controller/cadence/pcie-cadence-ep.c
++++ b/drivers/pci/controller/cadence/pcie-cadence-ep.c
+@@ -292,13 +292,14 @@ static int cdns_pcie_ep_set_msix(struct
+ struct cdns_pcie *pcie = &ep->pcie;
+ u32 cap = CDNS_PCIE_EP_FUNC_MSIX_CAP_OFFSET;
+ u32 val, reg;
++ u16 actual_interrupts = interrupts + 1;
+
+ fn = cdns_pcie_get_fn_from_vfn(pcie, fn, vfn);
+
+ reg = cap + PCI_MSIX_FLAGS;
+ val = cdns_pcie_ep_fn_readw(pcie, fn, reg);
+ val &= ~PCI_MSIX_FLAGS_QSIZE;
+- val |= interrupts;
++ val |= interrupts; /* 0's based value */
+ cdns_pcie_ep_fn_writew(pcie, fn, reg, val);
+
+ /* Set MSIX BAR and offset */
+@@ -308,7 +309,7 @@ static int cdns_pcie_ep_set_msix(struct
+
+ /* Set PBA BAR and offset. BAR must match MSIX BAR */
+ reg = cap + PCI_MSIX_PBA;
+- val = (offset + (interrupts * PCI_MSIX_ENTRY_SIZE)) | bir;
++ val = (offset + (actual_interrupts * PCI_MSIX_ENTRY_SIZE)) | bir;
+ cdns_pcie_ep_fn_writel(pcie, fn, reg, val);
+
+ return 0;
--- /dev/null
+From 286ed198b899739862456f451eda884558526a9d Mon Sep 17 00:00:00 2001
+From: Diederik de Haas <didi.debian@cknow.org>
+Date: Thu, 17 Apr 2025 16:21:18 +0200
+Subject: PCI: dw-rockchip: Fix PHY function call sequence in rockchip_pcie_phy_deinit()
+
+From: Diederik de Haas <didi.debian@cknow.org>
+
+commit 286ed198b899739862456f451eda884558526a9d upstream.
+
+The documentation for the phy_power_off() function explicitly says that it
+must be called before phy_exit().
+
+Hence, follow the same rule in rockchip_pcie_phy_deinit().
+
+Fixes: 0e898eb8df4e ("PCI: rockchip-dwc: Add Rockchip RK356X host controller driver")
+Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
+[mani: commit message change]
+Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Reviewed-by: Niklas Cassel <cassel@kernel.org>
+Reviewed-by: Dragan Simic <dsimic@manjaro.org>
+Acked-by: Shawn Lin <shawn.lin@rock-chips.com>
+Cc: stable@vger.kernel.org # v5.15+
+Link: https://patch.msgid.link/20250417142138.1377451-1-didi.debian@cknow.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/controller/dwc/pcie-dw-rockchip.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
++++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
+@@ -377,8 +377,8 @@ static int rockchip_pcie_phy_init(struct
+
+ static void rockchip_pcie_phy_deinit(struct rockchip_pcie *rockchip)
+ {
+- phy_exit(rockchip->phy);
+ phy_power_off(rockchip->phy);
++ phy_exit(rockchip->phy);
+ }
+
+ static const struct dw_pcie_ops dw_pcie_ops = {
--- /dev/null
+From 7d9b5d6115532cf90a789ed6afd3f4c70ebbd827 Mon Sep 17 00:00:00 2001
+From: Shawn Lin <shawn.lin@rock-chips.com>
+Date: Thu, 17 Apr 2025 08:35:09 +0800
+Subject: PCI: dw-rockchip: Remove PCIE_L0S_ENTRY check from rockchip_pcie_link_up()
+
+From: Shawn Lin <shawn.lin@rock-chips.com>
+
+commit 7d9b5d6115532cf90a789ed6afd3f4c70ebbd827 upstream.
+
+rockchip_pcie_link_up() currently has two issues:
+1. Value 0x11 of PCIE_L0S_ENTRY corresponds to L0 state, not L0S. So the
+naming is wrong from the very beginning.
+2. Checking for value 0x11 treats other states like L0S and L1 as link
+down, which is wrong.
+
+Hence, remove the PCIE_L0S_ENTRY check and also its definition. This allows
+adding ASPM support in the successive commits.
+
+Fixes: 0e898eb8df4e ("PCI: rockchip-dwc: Add Rockchip RK356X host controller driver")
+Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
+[mani: commit message rewording]
+Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Reviewed-by: Niklas Cassel <cassel@kernel.org>
+Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/1744850111-236269-1-git-send-email-shawn.lin@rock-chips.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/controller/dwc/pcie-dw-rockchip.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
++++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
+@@ -44,7 +44,6 @@
+ #define PCIE_LINKUP (PCIE_SMLH_LINKUP | PCIE_RDLH_LINKUP)
+ #define PCIE_RDLH_LINK_UP_CHGED BIT(1)
+ #define PCIE_LINK_REQ_RST_NOT_INT BIT(2)
+-#define PCIE_L0S_ENTRY 0x11
+ #define PCIE_CLIENT_GENERAL_CONTROL 0x0
+ #define PCIE_CLIENT_INTR_STATUS_LEGACY 0x8
+ #define PCIE_CLIENT_INTR_MASK_LEGACY 0x1c
+@@ -177,8 +176,7 @@ static int rockchip_pcie_link_up(struct
+ struct rockchip_pcie *rockchip = to_rockchip_pcie(pci);
+ u32 val = rockchip_pcie_get_ltssm(rockchip);
+
+- if ((val & PCIE_LINKUP) == PCIE_LINKUP &&
+- (val & PCIE_LTSSM_STATUS_MASK) == PCIE_L0S_ENTRY)
++ if ((val & PCIE_LINKUP) == PCIE_LINKUP)
+ return 1;
+
+ return 0;
--- /dev/null
+From 810276362bad172d063d1f6be1cc2cb425b90103 Mon Sep 17 00:00:00 2001
+From: Niklas Cassel <cassel@kernel.org>
+Date: Wed, 14 May 2025 09:43:14 +0200
+Subject: PCI: dwc: ep: Correct PBA offset in .set_msix() callback
+
+From: Niklas Cassel <cassel@kernel.org>
+
+commit 810276362bad172d063d1f6be1cc2cb425b90103 upstream.
+
+While dw_pcie_ep_set_msix() writes the Table Size field correctly (N-1),
+the calculation of the PBA offset is wrong because it calculates space for
+(N-1) entries instead of N.
+
+This results in the following QEMU error when using PCI passthrough on a
+device which relies on the PCI endpoint subsystem:
+
+ failed to add PCI capability 0x11[0x50]@0xb0: table & pba overlap, or they don't fit in BARs, or don't align
+
+Fix the calculation of PBA offset in the MSI-X capability.
+
+[bhelgaas: more specific subject and commit log]
+
+Fixes: 83153d9f36e2 ("PCI: endpoint: Fix ->set_msix() to take BIR and offset as arguments")
+Signed-off-by: Niklas Cassel <cassel@kernel.org>
+Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
+Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20250514074313.283156-9-cassel@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/controller/dwc/pcie-designware-ep.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
++++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
+@@ -398,6 +398,7 @@ static int dw_pcie_ep_set_msix(struct pc
+ struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+ struct dw_pcie_ep_func *ep_func;
+ u32 val, reg;
++ u16 actual_interrupts = interrupts + 1;
+
+ ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
+ if (!ep_func || !ep_func->msix_cap)
+@@ -408,7 +409,7 @@ static int dw_pcie_ep_set_msix(struct pc
+ reg = ep_func->msix_cap + PCI_MSIX_FLAGS;
+ val = dw_pcie_ep_readw_dbi(ep, func_no, reg);
+ val &= ~PCI_MSIX_FLAGS_QSIZE;
+- val |= interrupts;
++ val |= interrupts; /* 0's based value */
+ dw_pcie_writew_dbi(pci, reg, val);
+
+ reg = ep_func->msix_cap + PCI_MSIX_TABLE;
+@@ -416,7 +417,7 @@ static int dw_pcie_ep_set_msix(struct pc
+ dw_pcie_ep_writel_dbi(ep, func_no, reg, val);
+
+ reg = ep_func->msix_cap + PCI_MSIX_PBA;
+- val = (offset + (interrupts * PCI_MSIX_ENTRY_SIZE)) | bir;
++ val = (offset + (actual_interrupts * PCI_MSIX_ENTRY_SIZE)) | bir;
+ dw_pcie_ep_writel_dbi(ep, func_no, reg, val);
+
+ dw_pcie_dbi_ro_wr_dis(pci);
--- /dev/null
+From f3efb9569b4a21354ef2caf7ab0608a3e14cc6e4 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>
+Date: Mon, 5 May 2025 14:54:12 +0300
+Subject: PCI: Fix lock symmetry in pci_slot_unlock()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+
+commit f3efb9569b4a21354ef2caf7ab0608a3e14cc6e4 upstream.
+
+The commit a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()")
+made the lock function to call depend on dev->subordinate but left
+pci_slot_unlock() unmodified creating locking asymmetry compared with
+pci_slot_lock().
+
+Because of the asymmetric lock handling, the same bridge device is unlocked
+twice. First pci_bus_unlock() unlocks bus->self and then pci_slot_unlock()
+will unconditionally unlock the same bridge device.
+
+Move pci_dev_unlock() inside an else branch to match the logic in
+pci_slot_lock().
+
+Fixes: a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()")
+Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Lukas Wunner <lukas@wunner.de>
+Reviewed-by: Dave Jiang <dave.jiang@intel.com>
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20250505115412.37628-1-ilpo.jarvinen@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/pci.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/pci/pci.c
++++ b/drivers/pci/pci.c
+@@ -5643,7 +5643,8 @@ static void pci_slot_unlock(struct pci_s
+ continue;
+ if (dev->subordinate)
+ pci_bus_unlock(dev->subordinate);
+- pci_dev_unlock(dev);
++ else
++ pci_dev_unlock(dev);
+ }
+ }
+
--- /dev/null
+From b15ee09ddb987a122e74fb0fdf1bd6e864959fd3 Mon Sep 17 00:00:00 2001
+From: Xu Yang <xu.yang_2@nxp.com>
+Date: Wed, 30 Apr 2025 17:45:01 +0800
+Subject: phy: fsl-imx8mq-usb: fix phy_tx_vboost_level_from_property()
+
+From: Xu Yang <xu.yang_2@nxp.com>
+
+commit b15ee09ddb987a122e74fb0fdf1bd6e864959fd3 upstream.
+
+The description of TX_VBOOST_LVL is wrong in register PHY_CTRL3
+bit[31:29].
+
+The updated description as below:
+ 011: Corresponds to a launch amplitude of 0.844 V.
+ 100: Corresponds to a launch amplitude of 1.008 V.
+ 101: Corresponds to a launch amplitude of 1.156 V.
+
+This will fix the parsing function
+phy_tx_vboost_level_from_property() to return correct value.
+
+Fixes: 63c85ad0cd81 ("phy: fsl-imx8mp-usb: add support for phy tuning")
+Cc: stable@vger.kernel.org
+Reviewed-by: Jun Li <jun.li@nxp.com>
+Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
+Link: https://lore.kernel.org/r/20250430094502.2723983-3-xu.yang_2@nxp.com
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
++++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
+@@ -95,12 +95,12 @@ static u32 phy_tx_preemp_amp_tune_from_p
+ static u32 phy_tx_vboost_level_from_property(u32 microvolt)
+ {
+ switch (microvolt) {
+- case 0 ... 960:
+- return 0;
+- case 961 ... 1160:
+- return 2;
+- default:
++ case 1156:
++ return 5;
++ case 844:
+ return 3;
++ default:
++ return 4;
+ }
+ }
+
--- /dev/null
+From a8841dc3dfbf127a19c3612204bd336ee559b9a1 Mon Sep 17 00:00:00 2001
+From: David Lechner <dlechner@baylibre.com>
+Date: Thu, 29 May 2025 11:53:20 -0500
+Subject: pwm: axi-pwmgen: fix missing separate external clock
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: David Lechner <dlechner@baylibre.com>
+
+commit a8841dc3dfbf127a19c3612204bd336ee559b9a1 upstream.
+
+Add proper support for external clock to the AXI PWM generator driver.
+
+In most cases, the HDL for this IP block is compiled with the default
+ASYNC_CLK_EN=1. With this option, there is a separate external clock
+that drives the PWM output separate from the peripheral clock. So the
+driver should be enabling the "axi" clock to power the peripheral and
+the "ext" clock to drive the PWM output.
+
+When ASYNC_CLK_EN=0, the "axi" clock is also used to drive the PWM
+output and there is no "ext" clock.
+
+Previously, if there was a separate external clock, users had to specify
+only the external clock and (incorrectly) omit the AXI clock in order
+to get the correct operating frequency for the PWM output.
+
+The devicetree bindings are updated to fix this shortcoming and this
+patch changes the driver to match the new bindings. To preserve
+compatibility with any existing dtbs that specify only one clock, we
+don't require the clock name on the first clock.
+
+Fixes: 41814fe5c782 ("pwm: Add driver for AXI PWM generator")
+Cc: stable@vger.kernel.org
+Acked-by: Nuno Sá <nuno.sa@analog.com>
+Reviewed-by: Trevor Gamblin <tgamblin@baylibre.com>
+Signed-off-by: David Lechner <dlechner@baylibre.com>
+Link: https://lore.kernel.org/r/20250529-pwm-axi-pwmgen-add-external-clock-v3-3-5d8809a7da91@baylibre.com
+Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pwm/pwm-axi-pwmgen.c | 23 ++++++++++++++++++++---
+ 1 file changed, 20 insertions(+), 3 deletions(-)
+
+--- a/drivers/pwm/pwm-axi-pwmgen.c
++++ b/drivers/pwm/pwm-axi-pwmgen.c
+@@ -174,7 +174,7 @@ static int axi_pwmgen_probe(struct platf
+ struct regmap *regmap;
+ struct pwm_chip *chip;
+ struct axi_pwmgen_ddata *ddata;
+- struct clk *clk;
++ struct clk *axi_clk, *clk;
+ void __iomem *io_base;
+ int ret;
+
+@@ -197,9 +197,26 @@ static int axi_pwmgen_probe(struct platf
+ ddata = pwmchip_get_drvdata(chip);
+ ddata->regmap = regmap;
+
+- clk = devm_clk_get_enabled(dev, NULL);
++ /*
++ * Using NULL here instead of "axi" for backwards compatibility. There
++ * are some dtbs that don't give clock-names and have the "ext" clock
++ * as the one and only clock (due to mistake in the original bindings).
++ */
++ axi_clk = devm_clk_get_enabled(dev, NULL);
++ if (IS_ERR(axi_clk))
++ return dev_err_probe(dev, PTR_ERR(axi_clk), "failed to get axi clock\n");
++
++ clk = devm_clk_get_optional_enabled(dev, "ext");
+ if (IS_ERR(clk))
+- return dev_err_probe(dev, PTR_ERR(clk), "failed to get clock\n");
++ return dev_err_probe(dev, PTR_ERR(clk), "failed to get ext clock\n");
++
++ /*
++ * If there is no "ext" clock, it means the HDL was compiled with
++ * ASYNC_CLK_EN=0. In this case, the AXI clock is also used for the
++ * PWM output clock.
++ */
++ if (!clk)
++ clk = axi_clk;
+
+ ret = devm_clk_rate_exclusive_get(dev, clk);
+ if (ret)
--- /dev/null
+From 65271f868cb1dca709ff69e45939bbef8d6d0b70 Mon Sep 17 00:00:00 2001
+From: Wentao Liang <vulab@iscas.ac.cn>
+Date: Mon, 26 May 2025 10:56:27 +0800
+Subject: regulator: max14577: Add error check for max14577_read_reg()
+
+From: Wentao Liang <vulab@iscas.ac.cn>
+
+commit 65271f868cb1dca709ff69e45939bbef8d6d0b70 upstream.
+
+The function max14577_reg_get_current_limit() calls the function
+max14577_read_reg(), but does not check its return value. A proper
+implementation can be found in max14577_get_online().
+
+Add a error check for the max14577_read_reg() and return error code
+if the function fails.
+
+Fixes: b0902bbeb768 ("regulator: max14577: Add regulator driver for Maxim 14577")
+Cc: stable@vger.kernel.org # v3.14
+Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
+Link: https://patch.msgid.link/20250526025627.407-1-vulab@iscas.ac.cn
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/regulator/max14577-regulator.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/regulator/max14577-regulator.c
++++ b/drivers/regulator/max14577-regulator.c
+@@ -40,11 +40,14 @@ static int max14577_reg_get_current_limi
+ struct max14577 *max14577 = rdev_get_drvdata(rdev);
+ const struct maxim_charger_current *limits =
+ &maxim_charger_currents[max14577->dev_type];
++ int ret;
+
+ if (rdev_get_id(rdev) != MAX14577_CHARGER)
+ return -EINVAL;
+
+- max14577_read_reg(rmap, MAX14577_CHG_REG_CHG_CTRL4, ®_data);
++ ret = max14577_read_reg(rmap, MAX14577_CHG_REG_CHG_CTRL4, ®_data);
++ if (ret < 0)
++ return ret;
+
+ if ((reg_data & CHGCTRL4_MBCICHWRCL_MASK) == 0)
+ return limits->min;
--- /dev/null
+From 7692c9fbedd9087dc9050903f58095915458d9b1 Mon Sep 17 00:00:00 2001
+From: Xiaolei Wang <xiaolei.wang@windriver.com>
+Date: Wed, 30 Apr 2025 17:20:42 +0800
+Subject: remoteproc: core: Cleanup acquired resources when rproc_handle_resources() fails in rproc_attach()
+
+From: Xiaolei Wang <xiaolei.wang@windriver.com>
+
+commit 7692c9fbedd9087dc9050903f58095915458d9b1 upstream.
+
+When rproc->state = RPROC_DETACHED and rproc_attach() is used
+to attach to the remote processor, if rproc_handle_resources()
+returns a failure, the resources allocated by imx_rproc_prepare()
+should be released, otherwise the following memory leak will occur.
+
+Since almost the same thing is done in imx_rproc_prepare() and
+rproc_resource_cleanup(), Function rproc_resource_cleanup() is able
+to deal with empty lists so it is better to fix the "goto" statements
+in rproc_attach(). replace the "unprepare_device" goto statement with
+"clean_up_resources" and get rid of the "unprepare_device" label.
+
+unreferenced object 0xffff0000861c5d00 (size 128):
+comm "kworker/u12:3", pid 59, jiffies 4294893509 (age 149.220s)
+hex dump (first 32 bytes):
+00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+00 00 02 88 00 00 00 00 00 00 10 00 00 00 00 00 ............
+backtrace:
+ [<00000000f949fe18>] slab_post_alloc_hook+0x98/0x37c
+ [<00000000adbfb3e7>] __kmem_cache_alloc_node+0x138/0x2e0
+ [<00000000521c0345>] kmalloc_trace+0x40/0x158
+ [<000000004e330a49>] rproc_mem_entry_init+0x60/0xf8
+ [<000000002815755e>] imx_rproc_prepare+0xe0/0x180
+ [<0000000003f61b4e>] rproc_boot+0x2ec/0x528
+ [<00000000e7e994ac>] rproc_add+0x124/0x17c
+ [<0000000048594076>] imx_rproc_probe+0x4ec/0x5d4
+ [<00000000efc298a1>] platform_probe+0x68/0xd8
+ [<00000000110be6fe>] really_probe+0x110/0x27c
+ [<00000000e245c0ae>] __driver_probe_device+0x78/0x12c
+ [<00000000f61f6f5e>] driver_probe_device+0x3c/0x118
+ [<00000000a7874938>] __device_attach_driver+0xb8/0xf8
+ [<0000000065319e69>] bus_for_each_drv+0x84/0xe4
+ [<00000000db3eb243>] __device_attach+0xfc/0x18c
+ [<0000000072e4e1a4>] device_initial_probe+0x14/0x20
+
+Fixes: 10a3d4079eae ("remoteproc: imx_rproc: move memory parsing to rproc_ops")
+Suggested-by: Mathieu Poirier <mathieu.poirier@linaro.org>
+Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
+Reviewed-by: Peng Fan <peng.fan@nxp.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20250430092043.1819308-2-xiaolei.wang@windriver.com
+Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/remoteproc/remoteproc_core.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/drivers/remoteproc/remoteproc_core.c
++++ b/drivers/remoteproc/remoteproc_core.c
+@@ -1617,7 +1617,7 @@ static int rproc_attach(struct rproc *rp
+ ret = rproc_set_rsc_table(rproc);
+ if (ret) {
+ dev_err(dev, "can't load resource table: %d\n", ret);
+- goto unprepare_device;
++ goto clean_up_resources;
+ }
+
+ /* reset max_notifyid */
+@@ -1634,7 +1634,7 @@ static int rproc_attach(struct rproc *rp
+ ret = rproc_handle_resources(rproc, rproc_loading_handlers);
+ if (ret) {
+ dev_err(dev, "Failed to process resources: %d\n", ret);
+- goto unprepare_device;
++ goto clean_up_resources;
+ }
+
+ /* Allocate carveout resources associated to rproc */
+@@ -1653,7 +1653,6 @@ static int rproc_attach(struct rproc *rp
+
+ clean_up_resources:
+ rproc_resource_cleanup(rproc);
+-unprepare_device:
+ /* release HW resources if needed */
+ rproc_unprepare_device(rproc);
+ disable_iommu:
--- /dev/null
+From bcd241230fdbc6005230f80a4f8646ff5a84f15b Mon Sep 17 00:00:00 2001
+From: Xiaolei Wang <xiaolei.wang@windriver.com>
+Date: Wed, 30 Apr 2025 17:20:43 +0800
+Subject: remoteproc: core: Release rproc->clean_table after rproc_attach() fails
+
+From: Xiaolei Wang <xiaolei.wang@windriver.com>
+
+commit bcd241230fdbc6005230f80a4f8646ff5a84f15b upstream.
+
+When rproc->state = RPROC_DETACHED is attached to remote processor
+through rproc_attach(), if rproc_handle_resources() returns failure,
+then the clean table should be released, otherwise the following
+memory leak will occur.
+
+unreferenced object 0xffff000086a99800 (size 1024):
+comm "kworker/u12:3", pid 59, jiffies 4294893670 (age 121.140s)
+hex dump (first 32 bytes):
+00 00 00 00 00 80 00 00 00 00 00 00 00 00 10 00 ............
+00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 ............
+backtrace:
+ [<000000008bbe4ca8>] slab_post_alloc_hook+0x98/0x3fc
+ [<000000003b8a272b>] __kmem_cache_alloc_node+0x13c/0x230
+ [<000000007a507c51>] __kmalloc_node_track_caller+0x5c/0x260
+ [<0000000037818dae>] kmemdup+0x34/0x60
+ [<00000000610f7f57>] rproc_boot+0x35c/0x56c
+ [<0000000065f8871a>] rproc_add+0x124/0x17c
+ [<00000000497416ee>] imx_rproc_probe+0x4ec/0x5d4
+ [<000000003bcaa37d>] platform_probe+0x68/0xd8
+ [<00000000771577f9>] really_probe+0x110/0x27c
+ [<00000000531fea59>] __driver_probe_device+0x78/0x12c
+ [<0000000080036a04>] driver_probe_device+0x3c/0x118
+ [<000000007e0bddcb>] __device_attach_driver+0xb8/0xf8
+ [<000000000cf1fa33>] bus_for_each_drv+0x84/0xe4
+ [<000000001a53b53e>] __device_attach+0xfc/0x18c
+ [<00000000d1a2a32c>] device_initial_probe+0x14/0x20
+ [<00000000d8f8b7ae>] bus_probe_device+0xb0/0xb4
+ unreferenced object 0xffff0000864c9690 (size 16):
+
+Fixes: 9dc9507f1880 ("remoteproc: Properly deal with the resource table when detaching")
+Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
+Reviewed-by: Peng Fan <peng.fan@nxp.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20250430092043.1819308-3-xiaolei.wang@windriver.com
+Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/remoteproc/remoteproc_core.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/remoteproc/remoteproc_core.c
++++ b/drivers/remoteproc/remoteproc_core.c
+@@ -1655,6 +1655,7 @@ clean_up_resources:
+ rproc_resource_cleanup(rproc);
+ /* release HW resources if needed */
+ rproc_unprepare_device(rproc);
++ kfree(rproc->clean_table);
+ disable_iommu:
+ rproc_disable_iommu(rproc);
+ return ret;
--- /dev/null
+From 23532524594c211871054a15c425812a4ac35102 Mon Sep 17 00:00:00 2001
+From: Beleswar Padhi <b-padhi@ti.com>
+Date: Tue, 13 May 2025 11:14:38 +0530
+Subject: remoteproc: k3-m4: Don't assert reset in detach routine
+
+From: Beleswar Padhi <b-padhi@ti.com>
+
+commit 23532524594c211871054a15c425812a4ac35102 upstream.
+
+The rproc_detach() function invokes __rproc_detach() before
+rproc_unprepare_device(). The __rproc_detach() function sets the
+rproc->state to "RPROC_DETACHED".
+
+However, the TI K3 M4 driver erroneously looks for "RPROC_ATTACHED"
+state in its .unprepare ops to identify IPC-only mode; which leads to
+resetting the rproc in detach routine.
+
+Therefore, correct the IPC-only mode detection logic to look for
+"RPROC_DETACHED" in k3_m4_rproc_unprepare() function.
+
+Fixes: ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem")
+Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
+Reviewed-by: Hari Nagalla <hnagalla@ti.com>
+Reviewed-by: Martyn Welch <martyn.welch@collabora.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20250513054510.3439842-5-b-padhi@ti.com
+Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/remoteproc/ti_k3_m4_remoteproc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/remoteproc/ti_k3_m4_remoteproc.c
++++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
+@@ -228,7 +228,7 @@ static int k3_m4_rproc_unprepare(struct
+ int ret;
+
+ /* If the core is going to be detached do not assert the module reset */
+- if (rproc->state == RPROC_ATTACHED)
++ if (rproc->state == RPROC_DETACHED)
+ return 0;
+
+ ret = kproc->ti_sci->ops.dev_ops.put_device(kproc->ti_sci,
soc-qcom-pmic_glink_altmode-fix-spurious-dp-hotplug-events.patch
configfs-tsm-report-fix-null-dereference-of-tsm_ops.patch
firmware-arm_scmi-ensure-that-the-message-id-supports-fastchannel.patch
+mtd-rawnand-sunxi-add-randomizer-configuration-in-sunxi_nfc_hw_ecc_write_chunk.patch
+mtd-nand-sunxi-add-randomizer-configuration-before-randomizer-enable.patch
+kvm-svm-clear-current_vmcb-during-vcpu-free-for-all-possible-cpus.patch
+kvm-vmx-flush-shadow-vmcs-on-emergency-reboot.patch
+dm-mirror-fix-a-tiny-race-condition.patch
+dm-verity-fix-a-memory-leak-if-some-arguments-are-specified-multiple-times.patch
+mtd-rawnand-qcom-fix-read-len-for-onfi-param-page.patch
+ftrace-fix-uaf-when-lookup-kallsym-after-ftrace-disabled.patch
+dm-lock-limits-when-reading-them.patch
+phy-fsl-imx8mq-usb-fix-phy_tx_vboost_level_from_property.patch
+net-ch9200-fix-uninitialised-access-during-mii_nway_restart.patch
+kvm-s390-rename-prot_none-to-prot_type_dummy.patch
+sysfb-fix-screen_info-type-check-for-vga.patch
+video-screen_info-relocate-framebuffers-behind-pci-bridges.patch
+pwm-axi-pwmgen-fix-missing-separate-external-clock.patch
+staging-iio-ad5933-correct-settling-cycles-encoding-per-datasheet.patch
+mips-add-std-flag-specified-in-kbuild_cflags-to-vdso-cflags.patch
+ovl-fix-nested-backing-file-paths.patch
+regulator-max14577-add-error-check-for-max14577_read_reg.patch
+remoteproc-core-cleanup-acquired-resources-when-rproc_handle_resources-fails-in-rproc_attach.patch
+remoteproc-core-release-rproc-clean_table-after-rproc_attach-fails.patch
+remoteproc-k3-m4-don-t-assert-reset-in-detach-routine.patch
+cifs-reset-connections-for-all-channels-when-reconnect-requested.patch
+cifs-update-dstaddr-whenever-channel-iface-is-updated.patch
+cifs-dns-resolution-is-needed-only-for-primary-channel.patch
+smb-client-add-null-check-in-automount_fullpath.patch
+drivers-hv-allocate-interrupt-and-monitor-pages-aligned-to-system-page-boundary.patch
+uio_hv_generic-use-correct-size-for-interrupt-and-monitor-pages.patch
+uio_hv_generic-align-ring-size-to-system-page.patch
+pci-cadence-ep-correct-pba-offset-in-.set_msix-callback.patch
+pci-dwc-ep-correct-pba-offset-in-.set_msix-callback.patch
+pci-add-acs-quirk-for-loongson-pcie.patch
+pci-fix-lock-symmetry-in-pci_slot_unlock.patch
+pci-dw-rockchip-remove-pcie_l0s_entry-check-from-rockchip_pcie_link_up.patch
+pci-dw-rockchip-fix-phy-function-call-sequence-in-rockchip_pcie_phy_deinit.patch
--- /dev/null
+From f1e7a277a1736e12cc4bd6d93b8a5c439b8ca20c Mon Sep 17 00:00:00 2001
+From: Ruben Devos <devosruben6@gmail.com>
+Date: Sun, 1 Jun 2025 19:18:55 +0200
+Subject: smb: client: add NULL check in automount_fullpath
+
+From: Ruben Devos <devosruben6@gmail.com>
+
+commit f1e7a277a1736e12cc4bd6d93b8a5c439b8ca20c upstream.
+
+page is checked for null in __build_path_from_dentry_optional_prefix
+when tcon->origin_fullpath is not set. However, the check is missing when
+it is set.
+Add a check to prevent a potential NULL pointer dereference.
+
+Signed-off-by: Ruben Devos <devosruben6@gmail.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/smb/client/namespace.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/fs/smb/client/namespace.c
++++ b/fs/smb/client/namespace.c
+@@ -146,6 +146,9 @@ static char *automount_fullpath(struct d
+ }
+ spin_unlock(&tcon->tc_lock);
+
++ if (unlikely(!page))
++ return ERR_PTR(-ENOMEM);
++
+ s = dentry_path_raw(dentry, page, PATH_MAX);
+ if (IS_ERR(s))
+ return s;
--- /dev/null
+From 60638e2a2d4bc03798f00d5ab65ce9b83cb8b03b Mon Sep 17 00:00:00 2001
+From: Gabriel Shahrouzi <gshahrouzi@gmail.com>
+Date: Sat, 19 Apr 2025 21:30:09 -0400
+Subject: staging: iio: ad5933: Correct settling cycles encoding per datasheet
+
+From: Gabriel Shahrouzi <gshahrouzi@gmail.com>
+
+commit 60638e2a2d4bc03798f00d5ab65ce9b83cb8b03b upstream.
+
+The AD5933 datasheet (Table 13) lists the maximum cycles to be 0x7FC
+(2044).
+
+Clamp the user input to the maximum effective value of 0x7FC cycles.
+
+Fixes: f94aa354d676 ("iio: impedance-analyzer: New driver for AD5933/4 Impedance Converter, Network Analyzer")
+Cc: stable@vger.kernel.org
+Signed-off-by: Gabriel Shahrouzi <gshahrouzi@gmail.com>
+Reviewed-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
+Link: https://patch.msgid.link/20250420013009.847851-1-gshahrouzi@gmail.com
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/staging/iio/impedance-analyzer/ad5933.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/staging/iio/impedance-analyzer/ad5933.c
++++ b/drivers/staging/iio/impedance-analyzer/ad5933.c
+@@ -411,7 +411,7 @@ static ssize_t ad5933_store(struct devic
+ ret = ad5933_cmd(st, 0);
+ break;
+ case AD5933_OUT_SETTLING_CYCLES:
+- val = clamp(val, (u16)0, (u16)0x7FF);
++ val = clamp(val, (u16)0, (u16)0x7FC);
+ st->settling_cycles = val;
+
+ /* 2x, 4x handling, see datasheet */
--- /dev/null
+From f670b50ef5e4a69bf4d2ec5ac6a9228d93b13a7a Mon Sep 17 00:00:00 2001
+From: Thomas Zimmermann <tzimmermann@suse.de>
+Date: Tue, 3 Jun 2025 17:48:20 +0200
+Subject: sysfb: Fix screen_info type check for VGA
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Thomas Zimmermann <tzimmermann@suse.de>
+
+commit f670b50ef5e4a69bf4d2ec5ac6a9228d93b13a7a upstream.
+
+Use the helper screen_info_video_type() to get the framebuffer
+type from struct screen_info. Handle supported values in sorted
+switch statement.
+
+Reading orig_video_isVGA is unreliable. On most systems it is a
+VIDEO_TYPE_ constant. On some systems with VGA it is simply set
+to 1 to signal the presence of a VGA output. See vga_probe() for
+an example. Retrieving the screen_info type with the helper
+screen_info_video_type() detects these cases and returns the
+appropriate VIDEO_TYPE_ constant. For VGA, sysfb creates a device
+named "vga-framebuffer".
+
+The sysfb code has been taken from vga16fb, where it likely didn't
+work correctly either. With this bugfix applied, vga16fb loads for
+compatible vga-framebuffer devices.
+
+Fixes: 0db5b61e0dc0 ("fbdev/vga16fb: Create EGA/VGA devices in sysfb code")
+Cc: Thomas Zimmermann <tzimmermann@suse.de>
+Cc: Javier Martinez Canillas <javierm@redhat.com>
+Cc: Alex Deucher <alexander.deucher@amd.com>
+Cc: Tzung-Bi Shih <tzungbi@kernel.org>
+Cc: Helge Deller <deller@gmx.de>
+Cc: "Uwe Kleine-König" <u.kleine-koenig@baylibre.com>
+Cc: Zsolt Kajtar <soci@c64.rulez.org>
+Cc: <stable@vger.kernel.org> # v6.1+
+Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
+Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org>
+Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
+Link: https://lore.kernel.org/r/20250603154838.401882-1-tzimmermann@suse.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/firmware/sysfb.c | 26 ++++++++++++++++++--------
+ 1 file changed, 18 insertions(+), 8 deletions(-)
+
+--- a/drivers/firmware/sysfb.c
++++ b/drivers/firmware/sysfb.c
+@@ -124,6 +124,7 @@ static __init int sysfb_init(void)
+ {
+ struct screen_info *si = &screen_info;
+ struct device *parent;
++ unsigned int type;
+ struct simplefb_platform_data mode;
+ const char *name;
+ bool compatible;
+@@ -151,17 +152,26 @@ static __init int sysfb_init(void)
+ goto put_device;
+ }
+
++ type = screen_info_video_type(si);
++
+ /* if the FB is incompatible, create a legacy framebuffer device */
+- if (si->orig_video_isVGA == VIDEO_TYPE_EFI)
+- name = "efi-framebuffer";
+- else if (si->orig_video_isVGA == VIDEO_TYPE_VLFB)
+- name = "vesa-framebuffer";
+- else if (si->orig_video_isVGA == VIDEO_TYPE_VGAC)
+- name = "vga-framebuffer";
+- else if (si->orig_video_isVGA == VIDEO_TYPE_EGAC)
++ switch (type) {
++ case VIDEO_TYPE_EGAC:
+ name = "ega-framebuffer";
+- else
++ break;
++ case VIDEO_TYPE_VGAC:
++ name = "vga-framebuffer";
++ break;
++ case VIDEO_TYPE_VLFB:
++ name = "vesa-framebuffer";
++ break;
++ case VIDEO_TYPE_EFI:
++ name = "efi-framebuffer";
++ break;
++ default:
+ name = "platform-framebuffer";
++ break;
++ }
+
+ pd = platform_device_alloc(name, 0);
+ if (!pd) {
--- /dev/null
+From 0315fef2aff9f251ddef8a4b53db9187429c3553 Mon Sep 17 00:00:00 2001
+From: Long Li <longli@microsoft.com>
+Date: Mon, 5 May 2025 17:56:35 -0700
+Subject: uio_hv_generic: Align ring size to system page
+
+From: Long Li <longli@microsoft.com>
+
+commit 0315fef2aff9f251ddef8a4b53db9187429c3553 upstream.
+
+Following the ring header, the ring data should align to system page
+boundary. Adjust the size if necessary.
+
+Cc: stable@vger.kernel.org
+Fixes: 95096f2fbd10 ("uio-hv-generic: new userspace i/o driver for VMBus")
+Signed-off-by: Long Li <longli@microsoft.com>
+Reviewed-by: Michael Kelley <mhklinux@outlook.com>
+Link: https://lore.kernel.org/r/1746492997-4599-4-git-send-email-longli@linuxonhyperv.com
+Signed-off-by: Wei Liu <wei.liu@kernel.org>
+Message-ID: <1746492997-4599-4-git-send-email-longli@linuxonhyperv.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/uio/uio_hv_generic.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/uio/uio_hv_generic.c
++++ b/drivers/uio/uio_hv_generic.c
+@@ -243,6 +243,9 @@ hv_uio_probe(struct hv_device *dev,
+ if (!ring_size)
+ ring_size = SZ_2M;
+
++ /* Adjust ring size if necessary to have it page aligned */
++ ring_size = VMBUS_RING_SIZE(ring_size);
++
+ pdata = devm_kzalloc(&dev->device, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
--- /dev/null
+From c951ab8fd3589cf6991ed4111d2130816f2e3ac2 Mon Sep 17 00:00:00 2001
+From: Long Li <longli@microsoft.com>
+Date: Mon, 5 May 2025 17:56:34 -0700
+Subject: uio_hv_generic: Use correct size for interrupt and monitor pages
+
+From: Long Li <longli@microsoft.com>
+
+commit c951ab8fd3589cf6991ed4111d2130816f2e3ac2 upstream.
+
+Interrupt and monitor pages should be in Hyper-V page size (4k bytes).
+This can be different from the system page size.
+
+This size is read and used by the user-mode program to determine the
+mapped data region. An example of such user-mode program is the VMBus
+driver in DPDK.
+
+Cc: stable@vger.kernel.org
+Fixes: 95096f2fbd10 ("uio-hv-generic: new userspace i/o driver for VMBus")
+Signed-off-by: Long Li <longli@microsoft.com>
+Reviewed-by: Michael Kelley <mhklinux@outlook.com>
+Link: https://lore.kernel.org/r/1746492997-4599-3-git-send-email-longli@linuxonhyperv.com
+Signed-off-by: Wei Liu <wei.liu@kernel.org>
+Message-ID: <1746492997-4599-3-git-send-email-longli@linuxonhyperv.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/uio/uio_hv_generic.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/uio/uio_hv_generic.c
++++ b/drivers/uio/uio_hv_generic.c
+@@ -274,13 +274,13 @@ hv_uio_probe(struct hv_device *dev,
+ pdata->info.mem[INT_PAGE_MAP].name = "int_page";
+ pdata->info.mem[INT_PAGE_MAP].addr
+ = (uintptr_t)vmbus_connection.int_page;
+- pdata->info.mem[INT_PAGE_MAP].size = PAGE_SIZE;
++ pdata->info.mem[INT_PAGE_MAP].size = HV_HYP_PAGE_SIZE;
+ pdata->info.mem[INT_PAGE_MAP].memtype = UIO_MEM_LOGICAL;
+
+ pdata->info.mem[MON_PAGE_MAP].name = "monitor_page";
+ pdata->info.mem[MON_PAGE_MAP].addr
+ = (uintptr_t)vmbus_connection.monitor_pages[1];
+- pdata->info.mem[MON_PAGE_MAP].size = PAGE_SIZE;
++ pdata->info.mem[MON_PAGE_MAP].size = HV_HYP_PAGE_SIZE;
+ pdata->info.mem[MON_PAGE_MAP].memtype = UIO_MEM_LOGICAL;
+
+ pdata->recv_buf = vzalloc(RECV_BUFFER_SIZE);
--- /dev/null
+From 2f29b5c231011b94007d2c8a6d793992f2275db1 Mon Sep 17 00:00:00 2001
+From: Thomas Zimmermann <tzimmermann@suse.de>
+Date: Wed, 28 May 2025 10:02:08 +0200
+Subject: video: screen_info: Relocate framebuffers behind PCI bridges
+
+From: Thomas Zimmermann <tzimmermann@suse.de>
+
+commit 2f29b5c231011b94007d2c8a6d793992f2275db1 upstream.
+
+Apply PCI host-bridge window offsets to screen_info framebuffers. Fixes
+invalid access to I/O memory.
+
+Resources behind a PCI host bridge can be relocated by a certain offset
+in the kernel's CPU address range used for I/O. The framebuffer memory
+range stored in screen_info refers to the CPU addresses as seen during
+boot (where the offset is 0). During boot up, firmware may assign a
+different memory offset to the PCI host bridge and thereby relocating
+the framebuffer address of the PCI graphics device as seen by the kernel.
+The information in screen_info must be updated as well.
+
+The helper pcibios_bus_to_resource() performs the relocation of the
+screen_info's framebuffer resource (given in PCI bus addresses). The
+result matches the I/O-memory resource of the PCI graphics device (given
+in CPU addresses). As before, we store away the information necessary to
+later update the information in screen_info itself.
+
+Commit 78aa89d1dfba ("firmware/sysfb: Update screen_info for relocated
+EFI framebuffers") added the code for updating screen_info. It is based
+on similar functionality that pre-existed in efifb. Efifb uses a pointer
+to the PCI resource, while the newer code does a memcpy of the region.
+Hence efifb sees any updates to the PCI resource and avoids the issue.
+
+v3:
+- Only use struct pci_bus_region for PCI bus addresses (Bjorn)
+- Clarify address semantics in commit messages and comments (Bjorn)
+v2:
+- Fixed tags (Takashi, Ivan)
+- Updated information on efifb
+
+Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
+Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
+Reported-by: "Ivan T. Ivanov" <iivanov@suse.de>
+Closes: https://bugzilla.suse.com/show_bug.cgi?id=1240696
+Tested-by: "Ivan T. Ivanov" <iivanov@suse.de>
+Fixes: 78aa89d1dfba ("firmware/sysfb: Update screen_info for relocated EFI framebuffers")
+Cc: dri-devel@lists.freedesktop.org
+Cc: <stable@vger.kernel.org> # v6.9+
+Link: https://lore.kernel.org/r/20250528080234.7380-1-tzimmermann@suse.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/video/screen_info_pci.c | 79 +++++++++++++++++++++++++---------------
+ 1 file changed, 50 insertions(+), 29 deletions(-)
+
+--- a/drivers/video/screen_info_pci.c
++++ b/drivers/video/screen_info_pci.c
+@@ -7,8 +7,8 @@
+
+ static struct pci_dev *screen_info_lfb_pdev;
+ static size_t screen_info_lfb_bar;
+-static resource_size_t screen_info_lfb_offset;
+-static struct resource screen_info_lfb_res = DEFINE_RES_MEM(0, 0);
++static resource_size_t screen_info_lfb_res_start; // original start of resource
++static resource_size_t screen_info_lfb_offset; // framebuffer offset within resource
+
+ static bool __screen_info_relocation_is_valid(const struct screen_info *si, struct resource *pr)
+ {
+@@ -31,7 +31,7 @@ void screen_info_apply_fixups(void)
+ if (screen_info_lfb_pdev) {
+ struct resource *pr = &screen_info_lfb_pdev->resource[screen_info_lfb_bar];
+
+- if (pr->start != screen_info_lfb_res.start) {
++ if (pr->start != screen_info_lfb_res_start) {
+ if (__screen_info_relocation_is_valid(si, pr)) {
+ /*
+ * Only update base if we have an actual
+@@ -47,46 +47,67 @@ void screen_info_apply_fixups(void)
+ }
+ }
+
++static int __screen_info_lfb_pci_bus_region(const struct screen_info *si, unsigned int type,
++ struct pci_bus_region *r)
++{
++ u64 base, size;
++
++ base = __screen_info_lfb_base(si);
++ if (!base)
++ return -EINVAL;
++
++ size = __screen_info_lfb_size(si, type);
++ if (!size)
++ return -EINVAL;
++
++ r->start = base;
++ r->end = base + size - 1;
++
++ return 0;
++}
++
+ static void screen_info_fixup_lfb(struct pci_dev *pdev)
+ {
+ unsigned int type;
+- struct resource res[SCREEN_INFO_MAX_RESOURCES];
+- size_t i, numres;
++ struct pci_bus_region bus_region;
+ int ret;
++ struct resource r = {
++ .flags = IORESOURCE_MEM,
++ };
++ const struct resource *pr;
+ const struct screen_info *si = &screen_info;
+
+ if (screen_info_lfb_pdev)
+ return; // already found
+
+ type = screen_info_video_type(si);
+- if (type != VIDEO_TYPE_EFI)
+- return; // only applies to EFI
++ if (!__screen_info_has_lfb(type))
++ return; // only applies to EFI; maybe VESA
+
+- ret = screen_info_resources(si, res, ARRAY_SIZE(res));
++ ret = __screen_info_lfb_pci_bus_region(si, type, &bus_region);
+ if (ret < 0)
+ return;
+- numres = ret;
+
+- for (i = 0; i < numres; ++i) {
+- struct resource *r = &res[i];
+- const struct resource *pr;
+-
+- if (!(r->flags & IORESOURCE_MEM))
+- continue;
+- pr = pci_find_resource(pdev, r);
+- if (!pr)
+- continue;
+-
+- /*
+- * We've found a PCI device with the framebuffer
+- * resource. Store away the parameters to track
+- * relocation of the framebuffer aperture.
+- */
+- screen_info_lfb_pdev = pdev;
+- screen_info_lfb_bar = pr - pdev->resource;
+- screen_info_lfb_offset = r->start - pr->start;
+- memcpy(&screen_info_lfb_res, r, sizeof(screen_info_lfb_res));
+- }
++ /*
++ * Translate the PCI bus address to resource. Account
++ * for an offset if the framebuffer is behind a PCI host
++ * bridge.
++ */
++ pcibios_bus_to_resource(pdev->bus, &r, &bus_region);
++
++ pr = pci_find_resource(pdev, &r);
++ if (!pr)
++ return;
++
++ /*
++ * We've found a PCI device with the framebuffer
++ * resource. Store away the parameters to track
++ * relocation of the framebuffer aperture.
++ */
++ screen_info_lfb_pdev = pdev;
++ screen_info_lfb_bar = pr - pdev->resource;
++ screen_info_lfb_offset = r.start - pr->start;
++ screen_info_lfb_res_start = bus_region.start;
+ }
+ DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_ANY_ID, PCI_ANY_ID, PCI_BASE_CLASS_DISPLAY, 16,
+ screen_info_fixup_lfb);
projects / thirdparty / kernel / stable-queue.git / commitdiff
