--- /dev/null
+From 31643d84b8c3d9c846aa0e20bc033e46c68c7e7d Mon Sep 17 00:00:00 2001
+From: Carlos Llamas <cmllamas@google.com>
+Date: Thu, 11 Jul 2024 20:14:51 +0000
+Subject: binder: fix hang of unregistered readers
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Carlos Llamas <cmllamas@google.com>
+
+commit 31643d84b8c3d9c846aa0e20bc033e46c68c7e7d upstream.
+
+With the introduction of binder_available_for_proc_work_ilocked() in
+commit 1b77e9dcc3da ("ANDROID: binder: remove proc waitqueue") a binder
+thread can only "wait_for_proc_work" after its thread->looper has been
+marked as BINDER_LOOPER_STATE_{ENTERED|REGISTERED}.
+
+This means an unregistered reader risks waiting indefinitely for work
+since it never gets added to the proc->waiting_threads. If there are no
+further references to its waitqueue either the task will hang. The same
+applies to readers using the (e)poll interface.
+
+I couldn't find the rationale behind this restriction. So this patch
+restores the previous behavior of allowing unregistered threads to
+"wait_for_proc_work". Note that an error message for this scenario,
+which had previously become unreachable, is now re-enabled.
+
+Fixes: 1b77e9dcc3da ("ANDROID: binder: remove proc waitqueue")
+Cc: stable@vger.kernel.org
+Cc: Martijn Coenen <maco@google.com>
+Cc: Arve Hjønnevåg <arve@google.com>
+Signed-off-by: Carlos Llamas <cmllamas@google.com>
+Link: https://lore.kernel.org/r/20240711201452.2017543-1-cmllamas@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/android/binder.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/drivers/android/binder.c
++++ b/drivers/android/binder.c
+@@ -570,9 +570,7 @@ static bool binder_has_work(struct binde
+ static bool binder_available_for_proc_work_ilocked(struct binder_thread *thread)
+ {
+ return !thread->transaction_stack &&
+- binder_worklist_empty_ilocked(&thread->todo) &&
+- (thread->looper & (BINDER_LOOPER_STATE_ENTERED |
+- BINDER_LOOPER_STATE_REGISTERED));
++ binder_worklist_empty_ilocked(&thread->todo);
+ }
+
+ static void binder_wakeup_poll_threads_ilocked(struct binder_proc *proc,
--- /dev/null
+From ab11dac93d2d568d151b1918d7b84c2d02bacbd5 Mon Sep 17 00:00:00 2001
+From: tuhaowen <tuhaowen@uniontech.com>
+Date: Mon, 8 Jul 2024 16:04:30 +0800
+Subject: dev/parport: fix the array out-of-bounds risk
+
+From: tuhaowen <tuhaowen@uniontech.com>
+
+commit ab11dac93d2d568d151b1918d7b84c2d02bacbd5 upstream.
+
+Fixed array out-of-bounds issues caused by sprintf
+by replacing it with snprintf for safer data copying,
+ensuring the destination buffer is not overflowed.
+
+Below is the stack trace I encountered during the actual issue:
+
+[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector:
+Kernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport]
+[ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm:
+QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2
+[ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp
+[ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun
+PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024
+[ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace:
+[ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0
+[ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20
+[ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c
+[ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc
+[ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38
+[ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport]
+
+Signed-off-by: tuhaowen <tuhaowen@uniontech.com>
+Cc: stable <stable@kernel.org>
+Link: https://lore.kernel.org/r/20240708080430.8221-1-tuhaowen@uniontech.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/parport/procfs.c | 24 ++++++++++++------------
+ 1 file changed, 12 insertions(+), 12 deletions(-)
+
+--- a/drivers/parport/procfs.c
++++ b/drivers/parport/procfs.c
+@@ -51,12 +51,12 @@ static int do_active_device(struct ctl_t
+
+ for (dev = port->devices; dev ; dev = dev->next) {
+ if(dev == port->cad) {
+- len += sprintf(buffer, "%s\n", dev->name);
++ len += snprintf(buffer, sizeof(buffer), "%s\n", dev->name);
+ }
+ }
+
+ if(!len) {
+- len += sprintf(buffer, "%s\n", "none");
++ len += snprintf(buffer, sizeof(buffer), "%s\n", "none");
+ }
+
+ if (len > *lenp)
+@@ -87,19 +87,19 @@ static int do_autoprobe(struct ctl_table
+ }
+
+ if ((str = info->class_name) != NULL)
+- len += sprintf (buffer + len, "CLASS:%s;\n", str);
++ len += snprintf (buffer + len, sizeof(buffer) - len, "CLASS:%s;\n", str);
+
+ if ((str = info->model) != NULL)
+- len += sprintf (buffer + len, "MODEL:%s;\n", str);
++ len += snprintf (buffer + len, sizeof(buffer) - len, "MODEL:%s;\n", str);
+
+ if ((str = info->mfr) != NULL)
+- len += sprintf (buffer + len, "MANUFACTURER:%s;\n", str);
++ len += snprintf (buffer + len, sizeof(buffer) - len, "MANUFACTURER:%s;\n", str);
+
+ if ((str = info->description) != NULL)
+- len += sprintf (buffer + len, "DESCRIPTION:%s;\n", str);
++ len += snprintf (buffer + len, sizeof(buffer) - len, "DESCRIPTION:%s;\n", str);
+
+ if ((str = info->cmdset) != NULL)
+- len += sprintf (buffer + len, "COMMAND SET:%s;\n", str);
++ len += snprintf (buffer + len, sizeof(buffer) - len, "COMMAND SET:%s;\n", str);
+
+ if (len > *lenp)
+ len = *lenp;
+@@ -117,7 +117,7 @@ static int do_hardware_base_addr(struct
+ void *result, size_t *lenp, loff_t *ppos)
+ {
+ struct parport *port = (struct parport *)table->extra1;
+- char buffer[20];
++ char buffer[64];
+ int len = 0;
+
+ if (*ppos) {
+@@ -128,7 +128,7 @@ static int do_hardware_base_addr(struct
+ if (write) /* permissions prevent this anyway */
+ return -EACCES;
+
+- len += sprintf (buffer, "%lu\t%lu\n", port->base, port->base_hi);
++ len += snprintf (buffer, sizeof(buffer), "%lu\t%lu\n", port->base, port->base_hi);
+
+ if (len > *lenp)
+ len = *lenp;
+@@ -155,7 +155,7 @@ static int do_hardware_irq(struct ctl_ta
+ if (write) /* permissions prevent this anyway */
+ return -EACCES;
+
+- len += sprintf (buffer, "%d\n", port->irq);
++ len += snprintf (buffer, sizeof(buffer), "%d\n", port->irq);
+
+ if (len > *lenp)
+ len = *lenp;
+@@ -182,7 +182,7 @@ static int do_hardware_dma(struct ctl_ta
+ if (write) /* permissions prevent this anyway */
+ return -EACCES;
+
+- len += sprintf (buffer, "%d\n", port->dma);
++ len += snprintf (buffer, sizeof(buffer), "%d\n", port->dma);
+
+ if (len > *lenp)
+ len = *lenp;
+@@ -213,7 +213,7 @@ static int do_hardware_modes(struct ctl_
+ #define printmode(x) \
+ do { \
+ if (port->modes & PARPORT_MODE_##x) \
+- len += sprintf(buffer + len, "%s%s", f++ ? "," : "", #x); \
++ len += snprintf(buffer + len, sizeof(buffer) - len, "%s%s", f++ ? "," : "", #x); \
+ } while (0)
+ int f = 0;
+ printmode(PCSPP);
--- /dev/null
+From cb31c58e8c294ff31ea842ee1fa2c06c9a9f1cc3 Mon Sep 17 00:00:00 2001
+From: Thomas Huth <thuth@redhat.com>
+Date: Tue, 2 Jul 2024 14:17:37 +0200
+Subject: drm/fbdev-dma: Fix framebuffer mode for big endian devices
+
+From: Thomas Huth <thuth@redhat.com>
+
+commit cb31c58e8c294ff31ea842ee1fa2c06c9a9f1cc3 upstream.
+
+The drm_mode_legacy_fb_format() function only generates formats suitable
+for little endian devices. switch to drm_driver_legacy_fb_format() here
+instead to take the device endianness into consideration, too.
+
+Suggested-by: Thomas Zimmermann <tzimmermann@suse.de>
+Signed-off-by: Thomas Huth <thuth@redhat.com>
+Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
+Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
+Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
+Fixes: 6ae2ff23aa43 ("drm/client: Convert drm_client_buffer_addfb() to drm_mode_addfb2()")
+Cc: Geert Uytterhoeven <geert@linux-m68k.org>
+Cc: Javier Martinez Canillas <javierm@redhat.com>
+Cc: Hamza Mahfooz <hamza.mahfooz@amd.com>
+Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
+Cc: Maxime Ripard <mripard@kernel.org>
+Cc: Thomas Zimmermann <tzimmermann@suse.de>
+Cc: <stable@vger.kernel.org> # v6.7+
+Link: https://patchwork.freedesktop.org/patch/msgid/20240702121737.522878-1-thuth@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/drm_fbdev_dma.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/drm_fbdev_dma.c
++++ b/drivers/gpu/drm/drm_fbdev_dma.c
+@@ -90,7 +90,8 @@ static int drm_fbdev_dma_helper_fb_probe
+ sizes->surface_width, sizes->surface_height,
+ sizes->surface_bpp);
+
+- format = drm_mode_legacy_fb_format(sizes->surface_bpp, sizes->surface_depth);
++ format = drm_driver_legacy_fb_format(dev, sizes->surface_bpp,
++ sizes->surface_depth);
+ buffer = drm_client_framebuffer_create(client, sizes->surface_width,
+ sizes->surface_height, format);
+ if (IS_ERR(buffer))
--- /dev/null
+From ee8b8f5d83eb2c9caaebcf633310905ee76856e9 Mon Sep 17 00:00:00 2001
+From: Qiang Ma <maqianga@uniontech.com>
+Date: Wed, 17 Jul 2024 15:00:43 +0800
+Subject: efi/libstub: Zero initialize heap allocated struct screen_info
+
+From: Qiang Ma <maqianga@uniontech.com>
+
+commit ee8b8f5d83eb2c9caaebcf633310905ee76856e9 upstream.
+
+After calling uefi interface allocate_pool to apply for memory, we
+should clear 0 to prevent the possibility of using random values.
+
+Signed-off-by: Qiang Ma <maqianga@uniontech.com>
+Cc: <stable@vger.kernel.org> # v6.6+
+Fixes: 732ea9db9d8a ("efi: libstub: Move screen_info handling to common code")
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/firmware/efi/libstub/screen_info.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/firmware/efi/libstub/screen_info.c
++++ b/drivers/firmware/efi/libstub/screen_info.c
+@@ -32,6 +32,8 @@ struct screen_info *__alloc_screen_info(
+ if (status != EFI_SUCCESS)
+ return NULL;
+
++ memset(si, 0, sizeof(*si));
++
+ status = efi_bs_call(install_configuration_table,
+ &screen_info_guid, si);
+ if (status == EFI_SUCCESS)
--- /dev/null
+From 7dc5537c3f8be87e005f0844a7626c987914f8fd Mon Sep 17 00:00:00 2001
+From: Gao Xiang <hsiangkao@linux.alibaba.com>
+Date: Mon, 22 Jul 2024 11:51:10 +0800
+Subject: erofs: fix race in z_erofs_get_gbuf()
+
+From: Gao Xiang <hsiangkao@linux.alibaba.com>
+
+commit 7dc5537c3f8be87e005f0844a7626c987914f8fd upstream.
+
+In z_erofs_get_gbuf(), the current task may be migrated to another
+CPU between `z_erofs_gbuf_id()` and `spin_lock(&gbuf->lock)`.
+
+Therefore, z_erofs_put_gbuf() will trigger the following issue
+which was found by stress test:
+
+<2>[772156.434168] kernel BUG at fs/erofs/zutil.c:58!
+..
+<4>[772156.435007]
+<4>[772156.439237] CPU: 0 PID: 3078 Comm: stress Kdump: loaded Tainted: G E 6.10.0-rc7+ #2
+<4>[772156.439239] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 1.0.0 01/01/2017
+<4>[772156.439241] pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
+<4>[772156.439243] pc : z_erofs_put_gbuf+0x64/0x70 [erofs]
+<4>[772156.439252] lr : z_erofs_lz4_decompress+0x600/0x6a0 [erofs]
+..
+<6>[772156.445958] stress (3127): drop_caches: 1
+<4>[772156.446120] Call trace:
+<4>[772156.446121] z_erofs_put_gbuf+0x64/0x70 [erofs]
+<4>[772156.446761] z_erofs_lz4_decompress+0x600/0x6a0 [erofs]
+<4>[772156.446897] z_erofs_decompress_queue+0x740/0xa10 [erofs]
+<4>[772156.447036] z_erofs_runqueue+0x428/0x8c0 [erofs]
+<4>[772156.447160] z_erofs_readahead+0x224/0x390 [erofs]
+..
+
+Fixes: f36f3010f676 ("erofs: rename per-CPU buffers to global buffer pool and make it configurable")
+Cc: <stable@vger.kernel.org> # 6.10+
+Reviewed-by: Chunhai Guo <guochunhai@vivo.com>
+Reviewed-by: Sandeep Dhavale <dhavale@google.com>
+Reviewed-by: Chao Yu <chao@kernel.org>
+Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
+Link: https://lore.kernel.org/r/20240722035110.3456740-1-hsiangkao@linux.alibaba.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/erofs/zutil.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/fs/erofs/zutil.c b/fs/erofs/zutil.c
+index b80f612867c2..9b53883e5caf 100644
+--- a/fs/erofs/zutil.c
++++ b/fs/erofs/zutil.c
+@@ -38,11 +38,13 @@ void *z_erofs_get_gbuf(unsigned int requiredpages)
+ {
+ struct z_erofs_gbuf *gbuf;
+
++ migrate_disable();
+ gbuf = &z_erofs_gbufpool[z_erofs_gbuf_id()];
+ spin_lock(&gbuf->lock);
+ /* check if the buffer is too small */
+ if (requiredpages > gbuf->nrpages) {
+ spin_unlock(&gbuf->lock);
++ migrate_enable();
+ /* (for sparse checker) pretend gbuf->lock is still taken */
+ __acquire(gbuf->lock);
+ return NULL;
+@@ -57,6 +59,7 @@ void z_erofs_put_gbuf(void *ptr) __releases(gbuf->lock)
+ gbuf = &z_erofs_gbufpool[z_erofs_gbuf_id()];
+ DBG_BUGON(gbuf->ptr != ptr);
+ spin_unlock(&gbuf->lock);
++ migrate_enable();
+ }
+
+ int z_erofs_gbuf_growsize(unsigned int nrpages)
+--
+2.45.2
+
--- /dev/null
+From c2bc958b2b03e361f14df99983bc64a39a7323a3 Mon Sep 17 00:00:00 2001
+From: Thomas Zimmermann <tzimmermann@suse.de>
+Date: Mon, 17 Jun 2024 13:06:27 +0200
+Subject: fbdev: vesafb: Detect VGA compatibility from screen info's VESA attributes
+
+From: Thomas Zimmermann <tzimmermann@suse.de>
+
+commit c2bc958b2b03e361f14df99983bc64a39a7323a3 upstream.
+
+Test the vesa_attributes field in struct screen_info for compatibility
+with VGA hardware. Vesafb currently tests bit 1 in screen_info's
+capabilities field which indicates a 64-bit lfb address and is
+unrelated to VGA compatibility.
+
+Section 4.4 of the Vesa VBE 2.0 specifications defines that bit 5 in
+the mode's attributes field signals VGA compatibility. The mode is
+compatible with VGA hardware if the bit is clear. In that case, the
+driver can access VGA state of the VBE's underlying hardware. The
+vesafb driver uses this feature to program the color LUT in palette
+modes. Without, colors might be incorrect.
+
+The problem got introduced in commit 89ec4c238e7a ("[PATCH] vesafb: Fix
+incorrect logo colors in x86_64"). It incorrectly stores the mode
+attributes in the screen_info's capabilities field and updates vesafb
+accordingly. Later, commit 5e8ddcbe8692 ("Video mode probing support for
+the new x86 setup code") fixed the screen_info, but did not update vesafb.
+Color output still tends to work, because bit 1 in capabilities is
+usually 0.
+
+Besides fixing the bug in vesafb, this commit introduces a helper that
+reads the correct bit from screen_info.
+
+Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
+Fixes: 5e8ddcbe8692 ("Video mode probing support for the new x86 setup code")
+Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
+Cc: <stable@vger.kernel.org> # v2.6.23+
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/video/fbdev/vesafb.c | 2 +-
+ include/linux/screen_info.h | 10 ++++++++++
+ 2 files changed, 11 insertions(+), 1 deletion(-)
+
+--- a/drivers/video/fbdev/vesafb.c
++++ b/drivers/video/fbdev/vesafb.c
+@@ -271,7 +271,7 @@ static int vesafb_probe(struct platform_
+ if (si->orig_video_isVGA != VIDEO_TYPE_VLFB)
+ return -ENODEV;
+
+- vga_compat = (si->capabilities & 2) ? 0 : 1;
++ vga_compat = !__screen_info_vbe_mode_nonvga(si);
+ vesafb_fix.smem_start = si->lfb_base;
+ vesafb_defined.bits_per_pixel = si->lfb_depth;
+ if (15 == vesafb_defined.bits_per_pixel)
+--- a/include/linux/screen_info.h
++++ b/include/linux/screen_info.h
+@@ -49,6 +49,16 @@ static inline u64 __screen_info_lfb_size
+ return lfb_size;
+ }
+
++static inline bool __screen_info_vbe_mode_nonvga(const struct screen_info *si)
++{
++ /*
++ * VESA modes typically run on VGA hardware. Set bit 5 signals that this
++ * is not the case. Drivers can then not make use of VGA resources. See
++ * Sec 4.4 of the VBE 2.0 spec.
++ */
++ return si->vesa_attributes & BIT(5);
++}
++
+ static inline unsigned int __screen_info_video_type(unsigned int type)
+ {
+ switch (type) {
--- /dev/null
+From 267ed02c2121b75e0eaaa338240453b576039e4a Mon Sep 17 00:00:00 2001
+From: Johannes Berg <johannes.berg@intel.com>
+Date: Tue, 2 Jul 2024 09:24:41 +0200
+Subject: hostfs: fix dev_t handling
+
+From: Johannes Berg <johannes.berg@intel.com>
+
+commit 267ed02c2121b75e0eaaa338240453b576039e4a upstream.
+
+dev_t is a kernel type and may have different definitions
+in kernel and userspace. On 32-bit x86 this currently makes
+the stat structure being 4 bytes longer in the user code,
+causing stack corruption.
+
+However, this is (potentially) not the only problem, since
+dev_t is a different type on user/kernel side, so we don't
+know that the major/minor encoding isn't also different.
+Decode/encode it instead to address both problems.
+
+Cc: stable@vger.kernel.org
+Fixes: 74ce793bcbde ("hostfs: Fix ephemeral inodes")
+Link: https://patch.msgid.link/20240702092440.acc960585dd5.Id0767e12f562a69c6cd3c3262dc3d765db350cf6@changeid
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/hostfs/hostfs.h | 7 ++++---
+ fs/hostfs/hostfs_kern.c | 10 ++++++----
+ fs/hostfs/hostfs_user.c | 7 ++++---
+ 3 files changed, 14 insertions(+), 10 deletions(-)
+
+--- a/fs/hostfs/hostfs.h
++++ b/fs/hostfs/hostfs.h
+@@ -63,9 +63,10 @@ struct hostfs_stat {
+ struct hostfs_timespec atime, mtime, ctime;
+ unsigned int blksize;
+ unsigned long long blocks;
+- unsigned int maj;
+- unsigned int min;
+- dev_t dev;
++ struct {
++ unsigned int maj;
++ unsigned int min;
++ } rdev, dev;
+ };
+
+ extern int stat_file(const char *path, struct hostfs_stat *p, int fd);
+--- a/fs/hostfs/hostfs_kern.c
++++ b/fs/hostfs/hostfs_kern.c
+@@ -530,10 +530,11 @@ static int hostfs_inode_update(struct in
+ static int hostfs_inode_set(struct inode *ino, void *data)
+ {
+ struct hostfs_stat *st = data;
+- dev_t rdev;
++ dev_t dev, rdev;
+
+ /* Reencode maj and min with the kernel encoding.*/
+- rdev = MKDEV(st->maj, st->min);
++ rdev = MKDEV(st->rdev.maj, st->rdev.min);
++ dev = MKDEV(st->dev.maj, st->dev.min);
+
+ switch (st->mode & S_IFMT) {
+ case S_IFLNK:
+@@ -559,7 +560,7 @@ static int hostfs_inode_set(struct inode
+ return -EIO;
+ }
+
+- HOSTFS_I(ino)->dev = st->dev;
++ HOSTFS_I(ino)->dev = dev;
+ ino->i_ino = st->ino;
+ ino->i_mode = st->mode;
+ return hostfs_inode_update(ino, st);
+@@ -568,8 +569,9 @@ static int hostfs_inode_set(struct inode
+ static int hostfs_inode_test(struct inode *inode, void *data)
+ {
+ const struct hostfs_stat *st = data;
++ dev_t dev = MKDEV(st->dev.maj, st->dev.min);
+
+- return inode->i_ino == st->ino && HOSTFS_I(inode)->dev == st->dev;
++ return inode->i_ino == st->ino && HOSTFS_I(inode)->dev == dev;
+ }
+
+ static struct inode *hostfs_iget(struct super_block *sb, char *name)
+--- a/fs/hostfs/hostfs_user.c
++++ b/fs/hostfs/hostfs_user.c
+@@ -34,9 +34,10 @@ static void stat64_to_hostfs(const struc
+ p->mtime.tv_nsec = 0;
+ p->blksize = buf->st_blksize;
+ p->blocks = buf->st_blocks;
+- p->maj = os_major(buf->st_rdev);
+- p->min = os_minor(buf->st_rdev);
+- p->dev = buf->st_dev;
++ p->rdev.maj = os_major(buf->st_rdev);
++ p->rdev.min = os_minor(buf->st_rdev);
++ p->dev.maj = os_major(buf->st_dev);
++ p->dev.min = os_minor(buf->st_dev);
+ }
+
+ int stat_file(const char *path, struct hostfs_stat *p, int fd)
--- /dev/null
+From 14cba6ace79627a57fb9058582b03f0ed3832390 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>
+Date: Mon, 27 May 2024 16:26:15 +0300
+Subject: hwrng: amd - Convert PCIBIOS_* return codes to errnos
+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 14cba6ace79627a57fb9058582b03f0ed3832390 upstream.
+
+amd_rng_mod_init() uses pci_read_config_dword() that returns PCIBIOS_*
+codes. The return code is then returned as is but amd_rng_mod_init() is
+a module_init() function that should return normal errnos.
+
+Convert PCIBIOS_* returns code using pcibios_err_to_errno() into normal
+errno before returning it.
+
+Fixes: 96d63c0297cc ("[PATCH] Add AMD HW RNG driver")
+Cc: stable@vger.kernel.org
+Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/char/hw_random/amd-rng.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/char/hw_random/amd-rng.c
++++ b/drivers/char/hw_random/amd-rng.c
+@@ -143,8 +143,10 @@ static int __init amd_rng_mod_init(void)
+
+ found:
+ err = pci_read_config_dword(pdev, 0x58, &pmbase);
+- if (err)
++ if (err) {
++ err = pcibios_err_to_errno(err);
+ goto put_dev;
++ }
+
+ pmbase &= 0x0000FF00;
+ if (pmbase == 0) {
--- /dev/null
+From 4c29ab84cfec17081aae7a7a28f8d2c93c42dcae Mon Sep 17 00:00:00 2001
+From: John David Anglin <dave@mx3210.local>
+Date: Mon, 1 Jul 2024 09:42:41 -0400
+Subject: parisc: Fix warning at drivers/pci/msi/msi.h:121
+
+From: John David Anglin <dave@mx3210.local>
+
+commit 4c29ab84cfec17081aae7a7a28f8d2c93c42dcae upstream.
+
+Fix warning at drivers/pci/msi/msi.h:121.
+
+Recently, I added a PCI to PCIe bridge adaptor and a PCIe NVME card
+to my rp3440. Then, I noticed this warning at boot:
+
+ WARNING: CPU: 0 PID: 10 at drivers/pci/msi/msi.h:121 pci_msi_setup_msi_irqs+0x68/0x90
+ CPU: 0 PID: 10 Comm: kworker/u32:0 Not tainted 6.9.7-parisc64 #1 Debian 6.9.7-1
+ Hardware name: 9000/800/rp3440
+ Workqueue: async async_run_entry_fn
+
+We need to select PCI_MSI_ARCH_FALLBACKS when PCI_MSI is selected.
+
+Signed-off-by: John David Anglin <dave.anglin@bell.net>
+Cc: stable@vger.kernel.org # v6.0+
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/parisc/Kconfig | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/parisc/Kconfig
++++ b/arch/parisc/Kconfig
+@@ -86,6 +86,7 @@ config PARISC
+ select HAVE_SOFTIRQ_ON_OWN_STACK if IRQSTACKS
+ select TRACE_IRQFLAGS_SUPPORT
+ select HAVE_FUNCTION_DESCRIPTORS if 64BIT
++ select PCI_MSI_ARCH_FALLBACKS if PCI_MSI
+
+ help
+ The PA-RISC microprocessor is designed by Hewlett-Packard and used
--- /dev/null
+From 11a1f4bc47362700fcbde717292158873fb847ed Mon Sep 17 00:00:00 2001
+From: Lukas Wunner <lukas@wunner.de>
+Date: Tue, 18 Jun 2024 12:54:55 +0200
+Subject: PCI/DPC: Fix use-after-free on concurrent DPC and hot-removal
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Lukas Wunner <lukas@wunner.de>
+
+commit 11a1f4bc47362700fcbde717292158873fb847ed upstream.
+
+Keith reports a use-after-free when a DPC event occurs concurrently to
+hot-removal of the same portion of the hierarchy:
+
+The dpc_handler() awaits readiness of the secondary bus below the
+Downstream Port where the DPC event occurred. To do so, it polls the
+config space of the first child device on the secondary bus. If that
+child device is concurrently removed, accesses to its struct pci_dev
+cause the kernel to oops.
+
+That's because pci_bridge_wait_for_secondary_bus() neglects to hold a
+reference on the child device. Before v6.3, the function was only
+called on resume from system sleep or on runtime resume. Holding a
+reference wasn't necessary back then because the pciehp IRQ thread
+could never run concurrently. (On resume from system sleep, IRQs are
+not enabled until after the resume_noirq phase. And runtime resume is
+always awaited before a PCI device is removed.)
+
+However starting with v6.3, pci_bridge_wait_for_secondary_bus() is also
+called on a DPC event. Commit 53b54ad074de ("PCI/DPC: Await readiness
+of secondary bus after reset"), which introduced that, failed to
+appreciate that pci_bridge_wait_for_secondary_bus() now needs to hold a
+reference on the child device because dpc_handler() and pciehp may
+indeed run concurrently. The commit was backported to v5.10+ stable
+kernels, so that's the oldest one affected.
+
+Add the missing reference acquisition.
+
+Abridged stack trace:
+
+ BUG: unable to handle page fault for address: 00000000091400c0
+ CPU: 15 PID: 2464 Comm: irq/53-pcie-dpc 6.9.0
+ RIP: pci_bus_read_config_dword+0x17/0x50
+ pci_dev_wait()
+ pci_bridge_wait_for_secondary_bus()
+ dpc_reset_link()
+ pcie_do_recovery()
+ dpc_handler()
+
+Fixes: 53b54ad074de ("PCI/DPC: Await readiness of secondary bus after reset")
+Closes: https://lore.kernel.org/r/20240612181625.3604512-3-kbusch@meta.com/
+Link: https://lore.kernel.org/linux-pci/8e4bcd4116fd94f592f2bf2749f168099c480ddf.1718707743.git.lukas@wunner.de
+Reported-by: Keith Busch <kbusch@kernel.org>
+Tested-by: Keith Busch <kbusch@kernel.org>
+Signed-off-by: Lukas Wunner <lukas@wunner.de>
+Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
+Reviewed-by: Keith Busch <kbusch@kernel.org>
+Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Cc: stable@vger.kernel.org # v5.10+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/pci.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/pci/pci.c
++++ b/drivers/pci/pci.c
+@@ -4753,7 +4753,7 @@ static int pci_bus_max_d3cold_delay(cons
+ */
+ int pci_bridge_wait_for_secondary_bus(struct pci_dev *dev, char *reset_type)
+ {
+- struct pci_dev *child;
++ struct pci_dev *child __free(pci_dev_put) = NULL;
+ int delay;
+
+ if (pci_dev_is_disconnected(dev))
+@@ -4782,8 +4782,8 @@ int pci_bridge_wait_for_secondary_bus(st
+ return 0;
+ }
+
+- child = list_first_entry(&dev->subordinate->devices, struct pci_dev,
+- bus_list);
++ child = pci_dev_get(list_first_entry(&dev->subordinate->devices,
++ struct pci_dev, bus_list));
+ up_read(&pci_bus_sem);
+
+ /*
--- /dev/null
+From 28b8d7793b8573563b3d45321376f36168d77b1e Mon Sep 17 00:00:00 2001
+From: Niklas Cassel <cassel@kernel.org>
+Date: Wed, 17 Apr 2024 18:42:26 +0200
+Subject: PCI: dw-rockchip: Fix initial PERST# GPIO value
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Niklas Cassel <cassel@kernel.org>
+
+commit 28b8d7793b8573563b3d45321376f36168d77b1e upstream.
+
+PERST# is active low according to the PCIe specification.
+
+However, the existing pcie-dw-rockchip.c driver does:
+
+ gpiod_set_value(..., 0); msleep(100); gpiod_set_value(..., 1);
+
+when asserting + deasserting PERST#.
+
+This is of course wrong, but because all the device trees for this
+compatible string have also incorrectly marked this GPIO as ACTIVE_HIGH:
+
+ $ git grep -B 10 reset-gpios arch/arm64/boot/dts/rockchip/rk3568*
+ $ git grep -B 10 reset-gpios arch/arm64/boot/dts/rockchip/rk3588*
+
+The actual toggling of PERST# is correct, and we cannot change it anyway,
+since that would break device tree compatibility.
+
+However, this driver does request the GPIO to be initialized as
+GPIOD_OUT_HIGH, which does cause a silly sequence where PERST# gets
+toggled back and forth for no good reason.
+
+Fix this by requesting the GPIO to be initialized as GPIOD_OUT_LOW (which
+for this driver means PERST# asserted).
+
+This will avoid an unnecessary signal change where PERST# gets deasserted
+(by devm_gpiod_get_optional()) and then gets asserted (by
+rockchip_pcie_start_link()) just a few instructions later.
+
+Before patch, debug prints on EP side, when booting RC:
+
+ [ 845.606810] pci: PERST# asserted by host!
+ [ 852.483985] pci: PERST# de-asserted by host!
+ [ 852.503041] pci: PERST# asserted by host!
+ [ 852.610318] pci: PERST# de-asserted by host!
+
+After patch, debug prints on EP side, when booting RC:
+
+ [ 125.107921] pci: PERST# asserted by host!
+ [ 132.111429] pci: PERST# de-asserted by host!
+
+This extra, very short, PERST# assertion + deassertion has been reported to
+cause issues with certain WLAN controllers, e.g. RTL8822CE.
+
+Fixes: 0e898eb8df4e ("PCI: rockchip-dwc: Add Rockchip RK356X host controller driver")
+Link: https://lore.kernel.org/linux-pci/20240417164227.398901-1-cassel@kernel.org
+Tested-by: Heiko Stuebner <heiko@sntech.de>
+Tested-by: Jianfeng Liu <liujianfeng1994@gmail.com>
+Signed-off-by: Niklas Cassel <cassel@kernel.org>
+Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Heiko Stuebner <heiko@sntech.de>
+Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Cc: stable@vger.kernel.org # v5.15+
+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
+@@ -240,7 +240,7 @@ static int rockchip_pcie_resource_get(st
+ return PTR_ERR(rockchip->apb_base);
+
+ rockchip->rst_gpio = devm_gpiod_get_optional(&pdev->dev, "reset",
+- GPIOD_OUT_HIGH);
++ GPIOD_OUT_LOW);
+ if (IS_ERR(rockchip->rst_gpio))
+ return PTR_ERR(rockchip->rst_gpio);
+
--- /dev/null
+From fea93a3e5d5e6a09eb153866d2ce60ea3287a70d Mon Sep 17 00:00:00 2001
+From: Wei Liu <wei.liu@kernel.org>
+Date: Mon, 1 Jul 2024 20:26:05 +0000
+Subject: PCI: hv: Return zero, not garbage, when reading PCI_INTERRUPT_PIN
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Wei Liu <wei.liu@kernel.org>
+
+commit fea93a3e5d5e6a09eb153866d2ce60ea3287a70d upstream.
+
+The intent of the code snippet is to always return 0 for both
+PCI_INTERRUPT_LINE and PCI_INTERRUPT_PIN.
+
+The check misses PCI_INTERRUPT_PIN. This patch fixes that.
+
+This is discovered by this call in VFIO:
+
+ pci_read_config_byte(vdev->pdev, PCI_INTERRUPT_PIN, &pin);
+
+The old code does not set *val to 0 because it misses the check for
+PCI_INTERRUPT_PIN. Garbage is returned in that case.
+
+Fixes: 4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs")
+Link: https://lore.kernel.org/linux-pci/20240701202606.129606-1-wei.liu@kernel.org
+Signed-off-by: Wei Liu <wei.liu@kernel.org>
+Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
+Reviewed-by: Michael Kelley <mhklinux@outlook.com>
+Cc: stable@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/controller/pci-hyperv.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/pci/controller/pci-hyperv.c
++++ b/drivers/pci/controller/pci-hyperv.c
+@@ -1130,8 +1130,8 @@ static void _hv_pcifront_read_config(str
+ PCI_CAPABILITY_LIST) {
+ /* ROM BARs are unimplemented */
+ *val = 0;
+- } else if (where >= PCI_INTERRUPT_LINE && where + size <=
+- PCI_INTERRUPT_PIN) {
++ } else if ((where >= PCI_INTERRUPT_LINE && where + size <= PCI_INTERRUPT_PIN) ||
++ (where >= PCI_INTERRUPT_PIN && where + size <= PCI_MIN_GNT)) {
+ /*
+ * Interrupt Line and Interrupt PIN are hard-wired to zero
+ * because this front-end only supports message-signaled
--- /dev/null
+From a4bbcac11d3cea85822af8b40daed7e96bca5068 Mon Sep 17 00:00:00 2001
+From: Huacai Chen <chenhuacai@loongson.cn>
+Date: Wed, 12 Jun 2024 14:53:15 +0800
+Subject: PCI: loongson: Enable MSI in LS7A Root Complex
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Huacai Chen <chenhuacai@loongson.cn>
+
+commit a4bbcac11d3cea85822af8b40daed7e96bca5068 upstream.
+
+The LS7A chipset can be used as part of a PCIe Root Complex with
+Loongson-3C6000 and similar CPUs. In this case, DEV_LS7A_PCIE_PORT5 has a
+PCI_CLASS_BRIDGE_HOST class code, and it is a Type 0 Function whose config
+space provides access to Root Complex registers.
+
+The DEV_LS7A_PCIE_PORT5 has an MSI Capability, and its MSI Enable bit must
+be set before other devices below the Root Complex can use MSI. This is
+not the standard PCI behavior of MSI Enable, so the normal PCI MSI code
+does not set it.
+
+Set the DEV_LS7A_PCIE_PORT5 MSI Enable bit via a quirk so other devices
+below the Root Complex can use MSI.
+
+[kwilczynski: exit early to reduce indentation; commit log]
+Link: https://lore.kernel.org/linux-pci/20240612065315.2048110-1-chenhuacai@loongson.cn
+Signed-off-by: Sheng Wu <wusheng@loongson.cn>
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
+[bhelgaas: commit log]
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/controller/pci-loongson.c | 13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+--- a/drivers/pci/controller/pci-loongson.c
++++ b/drivers/pci/controller/pci-loongson.c
+@@ -163,6 +163,19 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LO
+ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LOONGSON,
+ DEV_LS7A_HDMI, loongson_pci_pin_quirk);
+
++static void loongson_pci_msi_quirk(struct pci_dev *dev)
++{
++ u16 val, class = dev->class >> 8;
++
++ if (class != PCI_CLASS_BRIDGE_HOST)
++ return;
++
++ pci_read_config_word(dev, dev->msi_cap + PCI_MSI_FLAGS, &val);
++ val |= PCI_MSI_FLAGS_ENABLE;
++ pci_write_config_word(dev, dev->msi_cap + PCI_MSI_FLAGS, val);
++}
++DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LOONGSON, DEV_LS7A_PCIE_PORT5, loongson_pci_msi_quirk);
++
+ static struct loongson_pci *pci_bus_to_loongson_pci(struct pci_bus *bus)
+ {
+ struct pci_config_window *cfg;
--- /dev/null
+From 840b7a5edf88fe678c60dee88a135647c0ea4375 Mon Sep 17 00:00:00 2001
+From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Date: Tue, 16 Apr 2024 11:12:35 +0530
+Subject: PCI: rockchip: Use GPIOD_OUT_LOW flag while requesting ep_gpio
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+commit 840b7a5edf88fe678c60dee88a135647c0ea4375 upstream.
+
+Rockchip platforms use 'GPIO_ACTIVE_HIGH' flag in the devicetree definition
+for ep_gpio. This means, whatever the logical value set by the driver for
+the ep_gpio, physical line will output the same logic level.
+
+For instance,
+
+ gpiod_set_value_cansleep(rockchip->ep_gpio, 0); --> Level low
+ gpiod_set_value_cansleep(rockchip->ep_gpio, 1); --> Level high
+
+But while requesting the ep_gpio, GPIOD_OUT_HIGH flag is currently used.
+Now, this also causes the physical line to output 'high' creating trouble
+for endpoint devices during host reboot.
+
+When host reboot happens, the ep_gpio will initially output 'low' due to
+the GPIO getting reset to its POR value. Then during host controller probe,
+it will output 'high' due to GPIOD_OUT_HIGH flag. Then during
+rockchip_pcie_host_init_port(), it will first output 'low' and then 'high'
+indicating the completion of controller initialization.
+
+On the endpoint side, each output 'low' of ep_gpio is accounted for PERST#
+assert and 'high' for PERST# deassert. With the above mentioned flow during
+host reboot, endpoint will witness below state changes for PERST#:
+
+ (1) PERST# assert - GPIO POR state
+ (2) PERST# deassert - GPIOD_OUT_HIGH while requesting GPIO
+ (3) PERST# assert - rockchip_pcie_host_init_port()
+ (4) PERST# deassert - rockchip_pcie_host_init_port()
+
+Now the time interval between (2) and (3) is very short as both happen
+during the driver probe(), and this results in a race in the endpoint.
+Because, before completing the PERST# deassertion in (2), endpoint got
+another PERST# assert in (3).
+
+A proper way to fix this issue is to change the GPIOD_OUT_HIGH flag in (2)
+to GPIOD_OUT_LOW. Because the usual convention is to request the GPIO with
+a state corresponding to its 'initial/default' value and let the driver
+change the state of the GPIO when required.
+
+As per that, the ep_gpio should be requested with GPIOD_OUT_LOW as it
+corresponds to the POR value of '0' (PERST# assert in the endpoint). Then
+the driver can change the state of the ep_gpio later in
+rockchip_pcie_host_init_port() as per the initialization sequence.
+
+This fixes the firmware crash issue in Qcom based modems connected to
+Rockpro64 based board.
+
+Fixes: e77f847df54c ("PCI: rockchip: Add Rockchip PCIe controller support")
+Closes: https://lore.kernel.org/mhi/20240402045647.GG2933@thinkpad/
+Link: https://lore.kernel.org/linux-pci/20240416-pci-rockchip-perst-fix-v1-1-4800b1d4d954@linaro.org
+Reported-by: Slark Xiao <slark_xiao@163.com>
+Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Niklas Cassel <cassel@kernel.org>
+Cc: stable@vger.kernel.org # v4.9
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/controller/pcie-rockchip.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/pci/controller/pcie-rockchip.c
++++ b/drivers/pci/controller/pcie-rockchip.c
+@@ -121,7 +121,7 @@ int rockchip_pcie_parse_dt(struct rockch
+
+ if (rockchip->is_rc) {
+ rockchip->ep_gpio = devm_gpiod_get_optional(dev, "ep",
+- GPIOD_OUT_HIGH);
++ GPIOD_OUT_LOW);
+ if (IS_ERR(rockchip->ep_gpio))
+ return dev_err_probe(dev, PTR_ERR(rockchip->ep_gpio),
+ "failed to get ep GPIO\n");
alsa-usb-audio-fix-microphone-sound-on-hd-webcam.patch
alsa-usb-audio-move-hd-webcam-quirk-to-the-right-place.patch
alsa-usb-audio-add-a-quirk-for-sonix-hd-usb-camera.patch
+tools-memory-model-fix-bug-in-lock.cat.patch
+fbdev-vesafb-detect-vga-compatibility-from-screen-info-s-vesa-attributes.patch
+drm-fbdev-dma-fix-framebuffer-mode-for-big-endian-devices.patch
+hwrng-amd-convert-pcibios_-return-codes-to-errnos.patch
+parisc-fix-warning-at-drivers-pci-msi-msi.h-121.patch
+pci-dpc-fix-use-after-free-on-concurrent-dpc-and-hot-removal.patch
+pci-hv-return-zero-not-garbage-when-reading-pci_interrupt_pin.patch
+pci-dw-rockchip-fix-initial-perst-gpio-value.patch
+pci-rockchip-use-gpiod_out_low-flag-while-requesting-ep_gpio.patch
+pci-loongson-enable-msi-in-ls7a-root-complex.patch
+binder-fix-hang-of-unregistered-readers.patch
+xhci-apply-xhci_reset_to_default-quirk-to-tgl.patch
+dev-parport-fix-the-array-out-of-bounds-risk.patch
+hostfs-fix-dev_t-handling.patch
+efi-libstub-zero-initialize-heap-allocated-struct-screen_info.patch
+erofs-fix-race-in-z_erofs_get_gbuf.patch
--- /dev/null
+From 4c830eef806679dc243e191f962c488dd9d00708 Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Thu, 6 Jun 2024 09:57:55 -0400
+Subject: tools/memory-model: Fix bug in lock.cat
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit 4c830eef806679dc243e191f962c488dd9d00708 upstream.
+
+Andrea reported that the following innocuous litmus test:
+
+C T
+
+{}
+
+P0(spinlock_t *x)
+{
+ int r0;
+
+ spin_lock(x);
+ spin_unlock(x);
+ r0 = spin_is_locked(x);
+}
+
+gives rise to a nonsensical empty result with no executions:
+
+$ herd7 -conf linux-kernel.cfg T.litmus
+Test T Required
+States 0
+Ok
+Witnesses
+Positive: 0 Negative: 0
+Condition forall (true)
+Observation T Never 0 0
+Time T 0.00
+Hash=6fa204e139ddddf2cb6fa963bad117c0
+
+The problem is caused by a bug in the lock.cat part of the LKMM. Its
+computation of the rf relation for RU (read-unlocked) events is
+faulty; it implicitly assumes that every RU event must read from
+either a UL (unlock) event in another thread or from the lock's
+initial state. Neither is true in the litmus test above, so the
+computation yields no possible executions.
+
+The lock.cat code tries to make up for this deficiency by allowing RU
+events outside of critical sections to read from the last po-previous
+UL event. But it does this incorrectly, trying to keep these rfi links
+separate from the rfe links that might also be needed, and passing only
+the latter to herd7's cross() macro.
+
+The problem is fixed by merging the two sets of possible rf links for
+RU events and using them all in the call to cross().
+
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Reported-by: Andrea Parri <parri.andrea@gmail.com>
+Closes: https://lore.kernel.org/linux-arch/ZlC0IkzpQdeGj+a3@andrea/
+Tested-by: Andrea Parri <parri.andrea@gmail.com>
+Acked-by: Andrea Parri <parri.andrea@gmail.com>
+Fixes: 15553dcbca06 ("tools/memory-model: Add model support for spin_is_locked()")
+CC: <stable@vger.kernel.org>
+Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/memory-model/lock.cat | 20 ++++++++++----------
+ 1 file changed, 10 insertions(+), 10 deletions(-)
+
+--- a/tools/memory-model/lock.cat
++++ b/tools/memory-model/lock.cat
+@@ -102,19 +102,19 @@ let rf-lf = rfe-lf | rfi-lf
+ * within one of the lock's critical sections returns False.
+ *)
+
+-(* rfi for RU events: an RU may read from the last po-previous UL *)
+-let rfi-ru = ([UL] ; po-loc ; [RU]) \ ([UL] ; po-loc ; [LKW] ; po-loc)
+-
+-(* rfe for RU events: an RU may read from an external UL or the initial write *)
+-let all-possible-rfe-ru =
+- let possible-rfe-ru r =
++(*
++ * rf for RU events: an RU may read from an external UL or the initial write,
++ * or from the last po-previous UL
++ *)
++let all-possible-rf-ru =
++ let possible-rf-ru r =
+ let pair-to-relation p = p ++ 0
+- in map pair-to-relation (((UL | IW) * {r}) & loc & ext)
+- in map possible-rfe-ru RU
++ in map pair-to-relation ((((UL | IW) * {r}) & loc & ext) |
++ (((UL * {r}) & po-loc) \ ([UL] ; po-loc ; [LKW] ; po-loc)))
++ in map possible-rf-ru RU
+
+ (* Generate all rf relations for RU events *)
+-with rfe-ru from cross(all-possible-rfe-ru)
+-let rf-ru = rfe-ru | rfi-ru
++with rf-ru from cross(all-possible-rf-ru)
+
+ (* Final rf relation *)
+ let rf = rf | rf-lf | rf-ru
--- /dev/null
+From b4c87bc5ce9292d494d9354e25cc8ea152fbcbbd Mon Sep 17 00:00:00 2001
+From: Reka Norman <rekanorman@chromium.org>
+Date: Wed, 26 Jun 2024 15:48:34 +0300
+Subject: xhci: Apply XHCI_RESET_TO_DEFAULT quirk to TGL
+
+From: Reka Norman <rekanorman@chromium.org>
+
+commit b4c87bc5ce9292d494d9354e25cc8ea152fbcbbd upstream.
+
+TGL systems have the same issue as ADL, where a large boot firmware
+delay is seen if USB ports are left in U3 at shutdown. So apply the
+XHCI_RESET_TO_DEFAULT quirk to TGL as well.
+
+The issue it fixes is a ~20s boot time delay when booting from S5. It
+affects TGL devices, and TGL support was added starting from v5.3.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Reka Norman <rekanorman@chromium.org>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Link: https://lore.kernel.org/r/20240626124835.1023046-21-mathias.nyman@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/host/xhci-pci.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/host/xhci-pci.c
++++ b/drivers/usb/host/xhci-pci.c
+@@ -50,6 +50,7 @@
+ #define PCI_DEVICE_ID_INTEL_DENVERTON_XHCI 0x19d0
+ #define PCI_DEVICE_ID_INTEL_ICE_LAKE_XHCI 0x8a13
+ #define PCI_DEVICE_ID_INTEL_TIGER_LAKE_XHCI 0x9a13
++#define PCI_DEVICE_ID_INTEL_TIGER_LAKE_PCH_XHCI 0xa0ed
+ #define PCI_DEVICE_ID_INTEL_COMET_LAKE_XHCI 0xa3af
+ #define PCI_DEVICE_ID_INTEL_ALDER_LAKE_PCH_XHCI 0x51ed
+ #define PCI_DEVICE_ID_INTEL_ALDER_LAKE_N_PCH_XHCI 0x54ed
+@@ -373,7 +374,8 @@ static void xhci_pci_quirks(struct devic
+ xhci->quirks |= XHCI_MISSING_CAS;
+
+ if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
+- (pdev->device == PCI_DEVICE_ID_INTEL_ALDER_LAKE_PCH_XHCI ||
++ (pdev->device == PCI_DEVICE_ID_INTEL_TIGER_LAKE_PCH_XHCI ||
++ pdev->device == PCI_DEVICE_ID_INTEL_ALDER_LAKE_PCH_XHCI ||
+ pdev->device == PCI_DEVICE_ID_INTEL_ALDER_LAKE_N_PCH_XHCI))
+ xhci->quirks |= XHCI_RESET_TO_DEFAULT;
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
