--- /dev/null
+From 9cb636b5f6a8cc6d1b50809ec8f8d33ae0c84c95 Mon Sep 17 00:00:00 2001
+From: Hyunwoo Kim <imv4bel@gmail.com>
+Date: Wed, 7 Sep 2022 09:07:14 -0700
+Subject: efi: capsule-loader: Fix use-after-free in efi_capsule_write
+
+From: Hyunwoo Kim <imv4bel@gmail.com>
+
+commit 9cb636b5f6a8cc6d1b50809ec8f8d33ae0c84c95 upstream.
+
+A race condition may occur if the user calls close() on another thread
+during a write() operation on the device node of the efi capsule.
+
+This is a race condition that occurs between the efi_capsule_write() and
+efi_capsule_flush() functions of efi_capsule_fops, which ultimately
+results in UAF.
+
+So, the page freeing process is modified to be done in
+efi_capsule_release() instead of efi_capsule_flush().
+
+Cc: <stable@vger.kernel.org> # v4.9+
+Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
+Link: https://lore.kernel.org/all/20220907102920.GA88602@ubuntu/
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/firmware/efi/capsule-loader.c | 31 +++++++------------------------
+ 1 file changed, 7 insertions(+), 24 deletions(-)
+
+--- a/drivers/firmware/efi/capsule-loader.c
++++ b/drivers/firmware/efi/capsule-loader.c
+@@ -243,29 +243,6 @@ failed:
+ }
+
+ /**
+- * efi_capsule_flush - called by file close or file flush
+- * @file: file pointer
+- * @id: not used
+- *
+- * If a capsule is being partially uploaded then calling this function
+- * will be treated as upload termination and will free those completed
+- * buffer pages and -ECANCELED will be returned.
+- **/
+-static int efi_capsule_flush(struct file *file, fl_owner_t id)
+-{
+- int ret = 0;
+- struct capsule_info *cap_info = file->private_data;
+-
+- if (cap_info->index > 0) {
+- pr_err("capsule upload not complete\n");
+- efi_free_all_buff_pages(cap_info);
+- ret = -ECANCELED;
+- }
+-
+- return ret;
+-}
+-
+-/**
+ * efi_capsule_release - called by file close
+ * @inode: not used
+ * @file: file pointer
+@@ -277,6 +254,13 @@ static int efi_capsule_release(struct in
+ {
+ struct capsule_info *cap_info = file->private_data;
+
++ if (cap_info->index > 0 &&
++ (cap_info->header.headersize == 0 ||
++ cap_info->count < cap_info->total_size)) {
++ pr_err("capsule upload not complete\n");
++ efi_free_all_buff_pages(cap_info);
++ }
++
+ kfree(cap_info->pages);
+ kfree(cap_info->phys);
+ kfree(file->private_data);
+@@ -324,7 +308,6 @@ static const struct file_operations efi_
+ .owner = THIS_MODULE,
+ .open = efi_capsule_open,
+ .write = efi_capsule_write,
+- .flush = efi_capsule_flush,
+ .release = efi_capsule_release,
+ .llseek = no_llseek,
+ };
--- /dev/null
+From 1a3887924a7e6edd331be76da7bf4c1e8eab4b1e Mon Sep 17 00:00:00 2001
+From: Ard Biesheuvel <ardb@kernel.org>
+Date: Mon, 22 Aug 2022 19:20:33 +0200
+Subject: efi: libstub: Disable struct randomization
+
+From: Ard Biesheuvel <ardb@kernel.org>
+
+commit 1a3887924a7e6edd331be76da7bf4c1e8eab4b1e upstream.
+
+The EFI stub is a wrapper around the core kernel that makes it look like
+a EFI compatible PE/COFF application to the EFI firmware. EFI
+applications run on top of the EFI runtime, which is heavily based on
+so-called protocols, which are struct types consisting [mostly] of
+function pointer members that are instantiated and recorded in a
+protocol database.
+
+These structs look like the ideal randomization candidates to the
+randstruct plugin (as they only carry function pointers), but of course,
+these protocols are contracts between the firmware that exposes them,
+and the EFI applications (including our stubbed kernel) that invoke
+them. This means that struct randomization for EFI protocols is not a
+great idea, and given that the stub shares very little data with the
+core kernel that is represented as a randomizable struct, we're better
+off just disabling it completely here.
+
+Cc: <stable@vger.kernel.org> # v4.14+
+Reported-by: Daniel Marth <daniel.marth@inso.tuwien.ac.at>
+Tested-by: Daniel Marth <daniel.marth@inso.tuwien.ac.at>
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+Acked-by: Kees Cook <keescook@chromium.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/firmware/efi/libstub/Makefile | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/firmware/efi/libstub/Makefile
++++ b/drivers/firmware/efi/libstub/Makefile
+@@ -37,6 +37,13 @@ KBUILD_CFLAGS := $(cflags-y) -Os -DDIS
+ $(call cc-option,-fno-addrsig) \
+ -D__DISABLE_EXPORTS
+
++#
++# struct randomization only makes sense for Linux internal types, which the EFI
++# stub code never touches, so let's turn off struct randomization for the stub
++# altogether
++#
++KBUILD_CFLAGS := $(filter-out $(RANDSTRUCT_CFLAGS), $(KBUILD_CFLAGS))
++
+ # remove SCS flags from all objects in this directory
+ KBUILD_CFLAGS := $(filter-out $(CC_FLAGS_SCS), $(KBUILD_CFLAGS))
+ # disable LTO
--- /dev/null
+From 2f79cdfe58c13949bbbb65ba5926abfe9561d0ec Mon Sep 17 00:00:00 2001
+From: Linus Torvalds <torvalds@linux-foundation.org>
+Date: Wed, 31 Aug 2022 09:46:12 -0700
+Subject: fs: only do a memory barrier for the first set_buffer_uptodate()
+
+From: Linus Torvalds <torvalds@linux-foundation.org>
+
+commit 2f79cdfe58c13949bbbb65ba5926abfe9561d0ec upstream.
+
+Commit d4252071b97d ("add barriers to buffer_uptodate and
+set_buffer_uptodate") added proper memory barriers to the buffer head
+BH_Uptodate bit, so that anybody who tests a buffer for being up-to-date
+will be guaranteed to actually see initialized state.
+
+However, that commit didn't _just_ add the memory barrier, it also ended
+up dropping the "was it already set" logic that the BUFFER_FNS() macro
+had.
+
+That's conceptually the right thing for a generic "this is a memory
+barrier" operation, but in the case of the buffer contents, we really
+only care about the memory barrier for the _first_ time we set the bit,
+in that the only memory ordering protection we need is to avoid anybody
+seeing uninitialized memory contents.
+
+Any other access ordering wouldn't be about the BH_Uptodate bit anyway,
+and would require some other proper lock (typically BH_Lock or the folio
+lock). A reader that races with somebody invalidating the buffer head
+isn't an issue wrt the memory ordering, it's a serialization issue.
+
+Now, you'd think that the buffer head operations don't matter in this
+day and age (and I certainly thought so), but apparently some loads
+still end up being heavy users of buffer heads. In particular, the
+kernel test robot reported that not having this bit access optimization
+in place caused a noticeable direct IO performance regression on ext4:
+
+ fxmark.ssd_ext4_no_jnl_DWTL_54_directio.works/sec -26.5% regression
+
+although you presumably need a fast disk and a lot of cores to actually
+notice.
+
+Link: https://lore.kernel.org/all/Yw8L7HTZ%2FdE2%2Fo9C@xsang-OptiPlex-9020/
+Reported-by: kernel test robot <oliver.sang@intel.com>
+Tested-by: Fengwei Yin <fengwei.yin@intel.com>
+Cc: Mikulas Patocka <mpatocka@redhat.com>
+Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
+Cc: stable@kernel.org
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/buffer_head.h | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/include/linux/buffer_head.h
++++ b/include/linux/buffer_head.h
+@@ -137,6 +137,17 @@ BUFFER_FNS(Defer_Completion, defer_compl
+ static __always_inline void set_buffer_uptodate(struct buffer_head *bh)
+ {
+ /*
++ * If somebody else already set this uptodate, they will
++ * have done the memory barrier, and a reader will thus
++ * see *some* valid buffer state.
++ *
++ * Any other serialization (with IO errors or whatever that
++ * might clear the bit) has to come from other state (eg BH_Lock).
++ */
++ if (test_bit(BH_Uptodate, &bh->b_state))
++ return;
++
++ /*
+ * make it consistent with folio_mark_uptodate
+ * pairs with smp_load_acquire in buffer_uptodate
+ */
--- /dev/null
+From fe2c9c61f668cde28dac2b188028c5299cedcc1e Mon Sep 17 00:00:00 2001
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Date: Fri, 2 Sep 2022 15:41:11 +0200
+Subject: net: mvpp2: debugfs: fix memory leak when using debugfs_lookup()
+
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+commit fe2c9c61f668cde28dac2b188028c5299cedcc1e upstream.
+
+When calling debugfs_lookup() the result must have dput() called on it,
+otherwise the memory will leak over time. Fix this up to be much
+simpler logic and only create the root debugfs directory once when the
+driver is first accessed. That resolves the memory leak and makes
+things more obvious as to what the intent is.
+
+Cc: Marcin Wojtas <mw@semihalf.com>
+Cc: Russell King <linux@armlinux.org.uk>
+Cc: "David S. Miller" <davem@davemloft.net>
+Cc: Eric Dumazet <edumazet@google.com>
+Cc: Jakub Kicinski <kuba@kernel.org>
+Cc: Paolo Abeni <pabeni@redhat.com>
+Cc: netdev@vger.kernel.org
+Cc: stable <stable@kernel.org>
+Fixes: 21da57a23125 ("net: mvpp2: add a debugfs interface for the Header Parser")
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/marvell/mvpp2/mvpp2_debugfs.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_debugfs.c
++++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_debugfs.c
+@@ -700,10 +700,10 @@ void mvpp2_dbgfs_cleanup(struct mvpp2 *p
+
+ void mvpp2_dbgfs_init(struct mvpp2 *priv, const char *name)
+ {
+- struct dentry *mvpp2_dir, *mvpp2_root;
++ static struct dentry *mvpp2_root;
++ struct dentry *mvpp2_dir;
+ int ret, i;
+
+- mvpp2_root = debugfs_lookup(MVPP2_DRIVER_NAME, NULL);
+ if (!mvpp2_root)
+ mvpp2_root = debugfs_create_dir(MVPP2_DRIVER_NAME, NULL);
+
--- /dev/null
+From yee.lee@mediatek.com Thu Sep 8 19:05:17 2022
+From: <yee.lee@mediatek.com>
+Date: Tue, 6 Sep 2022 15:03:06 +0800
+Subject: Revert "mm: kmemleak: take a full lowmem check in kmemleak_*_phys()"
+To: <linux-kernel@vger.kernel.org>
+Cc: <patrick.wang.shcn@gmail.com>, Yee Lee <yee.lee@mediatek.com>, <stable@vger.kernel.org>, Catalin Marinas <catalin.marinas@arm.com>, "Andrew Morton" <akpm@linux-foundation.org>, Matthias Brugger <matthias.bgg@gmail.com>, "open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>, "moderated list:ARM/Mediatek SoC support" <linux-arm-kernel@lists.infradead.org>, "moderated list:ARM/Mediatek SoC support" <linux-mediatek@lists.infradead.org>
+Message-ID: <20220906070309.18809-1-yee.lee@mediatek.com>
+
+From: Yee Lee <yee.lee@mediatek.com>
+
+This reverts commit 23c2d497de21f25898fbea70aeb292ab8acc8c94.
+
+Commit 23c2d497de21 ("mm: kmemleak: take a full lowmem check in
+kmemleak_*_phys()") brought false leak alarms on some archs like arm64
+that does not init pfn boundary in early booting. The final solution
+lands on linux-6.0: commit 0c24e061196c ("mm: kmemleak: add rbtree and
+store physical address for objects allocated with PA").
+
+Revert this commit before linux-6.0. The original issue of invalid PA
+can be mitigated by additional check in devicetree.
+
+The false alarm report is as following: Kmemleak output: (Qemu/arm64)
+unreferenced object 0xffff0000c0170a00 (size 128):
+ comm "swapper/0", pid 1, jiffies 4294892404 (age 126.208s)
+ hex dump (first 32 bytes):
+ 62 61 73 65 00 00 00 00 00 00 00 00 00 00 00 00 base............
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+ backtrace:
+ [<(____ptrval____)>] __kmalloc_track_caller+0x1b0/0x2e4
+ [<(____ptrval____)>] kstrdup_const+0x8c/0xc4
+ [<(____ptrval____)>] kvasprintf_const+0xbc/0xec
+ [<(____ptrval____)>] kobject_set_name_vargs+0x58/0xe4
+ [<(____ptrval____)>] kobject_add+0x84/0x100
+ [<(____ptrval____)>] __of_attach_node_sysfs+0x78/0xec
+ [<(____ptrval____)>] of_core_init+0x68/0x104
+ [<(____ptrval____)>] driver_init+0x28/0x48
+ [<(____ptrval____)>] do_basic_setup+0x14/0x28
+ [<(____ptrval____)>] kernel_init_freeable+0x110/0x178
+ [<(____ptrval____)>] kernel_init+0x20/0x1a0
+ [<(____ptrval____)>] ret_from_fork+0x10/0x20
+
+This pacth is also applicable to linux-5.17.y/linux-5.18.y/linux-5.19.y
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Yee Lee <yee.lee@mediatek.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/kmemleak.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/mm/kmemleak.c
++++ b/mm/kmemleak.c
+@@ -1132,7 +1132,7 @@ EXPORT_SYMBOL(kmemleak_no_scan);
+ void __ref kmemleak_alloc_phys(phys_addr_t phys, size_t size, int min_count,
+ gfp_t gfp)
+ {
+- if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn)
++ if (!IS_ENABLED(CONFIG_HIGHMEM) || PHYS_PFN(phys) < max_low_pfn)
+ kmemleak_alloc(__va(phys), size, min_count, gfp);
+ }
+ EXPORT_SYMBOL(kmemleak_alloc_phys);
+@@ -1146,7 +1146,7 @@ EXPORT_SYMBOL(kmemleak_alloc_phys);
+ */
+ void __ref kmemleak_free_part_phys(phys_addr_t phys, size_t size)
+ {
+- if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn)
++ if (!IS_ENABLED(CONFIG_HIGHMEM) || PHYS_PFN(phys) < max_low_pfn)
+ kmemleak_free_part(__va(phys), size);
+ }
+ EXPORT_SYMBOL(kmemleak_free_part_phys);
+@@ -1158,7 +1158,7 @@ EXPORT_SYMBOL(kmemleak_free_part_phys);
+ */
+ void __ref kmemleak_not_leak_phys(phys_addr_t phys)
+ {
+- if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn)
++ if (!IS_ENABLED(CONFIG_HIGHMEM) || PHYS_PFN(phys) < max_low_pfn)
+ kmemleak_not_leak(__va(phys));
+ }
+ EXPORT_SYMBOL(kmemleak_not_leak_phys);
+@@ -1170,7 +1170,7 @@ EXPORT_SYMBOL(kmemleak_not_leak_phys);
+ */
+ void __ref kmemleak_ignore_phys(phys_addr_t phys)
+ {
+- if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn)
++ if (!IS_ENABLED(CONFIG_HIGHMEM) || PHYS_PFN(phys) < max_low_pfn)
+ kmemleak_ignore(__va(phys));
+ }
+ EXPORT_SYMBOL(kmemleak_ignore_phys);
--- /dev/null
+efi-libstub-disable-struct-randomization.patch
+efi-capsule-loader-fix-use-after-free-in-efi_capsule_write.patch
+wifi-mt76-mt7921e-fix-crash-in-chip-reset-fail.patch
+wifi-iwlegacy-4965-corrected-fix-for-potential-off-by-one-overflow-in-il4965_rs_fill_link_cmd.patch
+net-mvpp2-debugfs-fix-memory-leak-when-using-debugfs_lookup.patch
+fs-only-do-a-memory-barrier-for-the-first-set_buffer_uptodate.patch
+soc-fsl-select-fsl_guts-driver-for-dpio.patch
+revert-mm-kmemleak-take-a-full-lowmem-check-in-kmemleak_-_phys.patch
--- /dev/null
+From 9a472613f5bccf1b36837423495ae592a9c5182f Mon Sep 17 00:00:00 2001
+From: Mathew McBride <matt@traverse.com.au>
+Date: Thu, 1 Sep 2022 05:21:49 +0000
+Subject: soc: fsl: select FSL_GUTS driver for DPIO
+
+From: Mathew McBride <matt@traverse.com.au>
+
+commit 9a472613f5bccf1b36837423495ae592a9c5182f upstream.
+
+The soc/fsl/dpio driver will perform a soc_device_match()
+to determine the optimal cache settings for a given CPU core.
+
+If FSL_GUTS is not enabled, this search will fail and
+the driver will not configure cache stashing for the given
+DPIO, and a string of "unknown SoC" messages will appear:
+
+fsl_mc_dpio dpio.7: unknown SoC version
+fsl_mc_dpio dpio.6: unknown SoC version
+fsl_mc_dpio dpio.5: unknown SoC version
+
+Fixes: 51da14e96e9b ("soc: fsl: dpio: configure cache stashing destination")
+Signed-off-by: Mathew McBride <matt@traverse.com.au>
+Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20220901052149.23873-2-matt@traverse.com.au'
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/soc/fsl/Kconfig | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/soc/fsl/Kconfig
++++ b/drivers/soc/fsl/Kconfig
+@@ -24,6 +24,7 @@ config FSL_MC_DPIO
+ tristate "QorIQ DPAA2 DPIO driver"
+ depends on FSL_MC_BUS
+ select SOC_BUS
++ select FSL_GUTS
+ select DIMLIB
+ help
+ Driver for the DPAA2 DPIO object. A DPIO provides queue and
--- /dev/null
+From 6d0ef7241553f3553a0a2764c69b07892705924c Mon Sep 17 00:00:00 2001
+From: Stanislaw Gruszka <stf_xl@wp.pl>
+Date: Mon, 15 Aug 2022 09:37:37 +0200
+Subject: wifi: iwlegacy: 4965: corrected fix for potential off-by-one overflow in il4965_rs_fill_link_cmd()
+
+From: Stanislaw Gruszka <stf_xl@wp.pl>
+
+commit 6d0ef7241553f3553a0a2764c69b07892705924c upstream.
+
+This reverts commit a8eb8e6f7159c7c20c0ddac428bde3d110890aa7 as
+it can cause invalid link quality command sent to the firmware
+and address the off-by-one issue by fixing condition of while loop.
+
+Cc: stable@vger.kernel.org
+Fixes: a8eb8e6f7159 ("wifi: iwlegacy: 4965: fix potential off-by-one overflow in il4965_rs_fill_link_cmd()")
+Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
+Signed-off-by: Kalle Valo <kvalo@kernel.org>
+Link: https://lore.kernel.org/r/20220815073737.GA999388@wp.pl
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/intel/iwlegacy/4965-rs.c | 5 +----
+ 1 file changed, 1 insertion(+), 4 deletions(-)
+
+--- a/drivers/net/wireless/intel/iwlegacy/4965-rs.c
++++ b/drivers/net/wireless/intel/iwlegacy/4965-rs.c
+@@ -2403,7 +2403,7 @@ il4965_rs_fill_link_cmd(struct il_priv *
+ /* Repeat initial/next rate.
+ * For legacy IL_NUMBER_TRY == 1, this loop will not execute.
+ * For HT IL_HT_NUMBER_TRY == 3, this executes twice. */
+- while (repeat_rate > 0) {
++ while (repeat_rate > 0 && idx < (LINK_QUAL_MAX_RETRY_NUM - 1)) {
+ if (is_legacy(tbl_type.lq_type)) {
+ if (ant_toggle_cnt < NUM_TRY_BEFORE_ANT_TOGGLE)
+ ant_toggle_cnt++;
+@@ -2422,8 +2422,6 @@ il4965_rs_fill_link_cmd(struct il_priv *
+ cpu_to_le32(new_rate);
+ repeat_rate--;
+ idx++;
+- if (idx >= LINK_QUAL_MAX_RETRY_NUM)
+- goto out;
+ }
+
+ il4965_rs_get_tbl_info_from_mcs(new_rate, lq_sta->band,
+@@ -2468,7 +2466,6 @@ il4965_rs_fill_link_cmd(struct il_priv *
+ repeat_rate--;
+ }
+
+-out:
+ lq_cmd->agg_params.agg_frame_cnt_limit = LINK_QUAL_AGG_FRAME_LIMIT_DEF;
+ lq_cmd->agg_params.agg_dis_start_th = LINK_QUAL_AGG_DISABLE_START_DEF;
+
--- /dev/null
+From fa3fbe64037839f448dc569212bafc5a495d8219 Mon Sep 17 00:00:00 2001
+From: Deren Wu <deren.wu@mediatek.com>
+Date: Tue, 2 Aug 2022 23:15:07 +0800
+Subject: wifi: mt76: mt7921e: fix crash in chip reset fail
+
+From: Deren Wu <deren.wu@mediatek.com>
+
+commit fa3fbe64037839f448dc569212bafc5a495d8219 upstream.
+
+In case of drv own fail in reset, we may need to run mac_reset several
+times. The sequence would trigger system crash as the log below.
+
+Because we do not re-enable/schedule "tx_napi" before disable it again,
+the process would keep waiting for state change in napi_diable(). To
+avoid the problem and keep status synchronize for each run, goto final
+resource handling if drv own failed.
+
+[ 5857.353423] mt7921e 0000:3b:00.0: driver own failed
+[ 5858.433427] mt7921e 0000:3b:00.0: Timeout for driver own
+[ 5859.633430] mt7921e 0000:3b:00.0: driver own failed
+[ 5859.633444] ------------[ cut here ]------------
+[ 5859.633446] WARNING: CPU: 6 at kernel/kthread.c:659 kthread_park+0x11d
+[ 5859.633717] Workqueue: mt76 mt7921_mac_reset_work [mt7921_common]
+[ 5859.633728] RIP: 0010:kthread_park+0x11d/0x150
+[ 5859.633736] RSP: 0018:ffff8881b676fc68 EFLAGS: 00010202
+......
+[ 5859.633766] Call Trace:
+[ 5859.633768] <TASK>
+[ 5859.633771] mt7921e_mac_reset+0x176/0x6f0 [mt7921e]
+[ 5859.633778] mt7921_mac_reset_work+0x184/0x3a0 [mt7921_common]
+[ 5859.633785] ? mt7921_mac_set_timing+0x520/0x520 [mt7921_common]
+[ 5859.633794] ? __kasan_check_read+0x11/0x20
+[ 5859.633802] process_one_work+0x7ee/0x1320
+[ 5859.633810] worker_thread+0x53c/0x1240
+[ 5859.633818] kthread+0x2b8/0x370
+[ 5859.633824] ? process_one_work+0x1320/0x1320
+[ 5859.633828] ? kthread_complete_and_exit+0x30/0x30
+[ 5859.633834] ret_from_fork+0x1f/0x30
+[ 5859.633842] </TASK>
+
+Cc: stable@vger.kernel.org
+Fixes: 0efaf31dec57 ("mt76: mt7921: fix MT7921E reset failure")
+Signed-off-by: Deren Wu <deren.wu@mediatek.com>
+Link: https://lore.kernel.org/r/727eb5ffd3c7c805245e512da150ecf0a7154020.1659452909.git.deren.wu@mediatek.com
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/mediatek/mt76/mt7921/pci_mac.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/wireless/mediatek/mt76/mt7921/pci_mac.c
++++ b/drivers/net/wireless/mediatek/mt76/mt7921/pci_mac.c
+@@ -345,7 +345,7 @@ int mt7921e_mac_reset(struct mt7921_dev
+
+ err = mt7921e_driver_own(dev);
+ if (err)
+- return err;
++ goto out;
+
+ err = mt7921_run_firmware(dev);
+ if (err)
projects / thirdparty / kernel / stable-queue.git / commitdiff
