--- /dev/null
+From 7455b7007b9e93bcc2bc9c1c6c73a228e3152069 Mon Sep 17 00:00:00 2001
+From: Conor Dooley <conor.dooley@microchip.com>
+Date: Thu, 13 Apr 2023 23:20:45 +0100
+Subject: clk: microchip: fix potential UAF in auxdev release callback
+
+From: Conor Dooley <conor.dooley@microchip.com>
+
+commit 7455b7007b9e93bcc2bc9c1c6c73a228e3152069 upstream.
+
+Similar to commit 1c11289b34ab ("peci: cpu: Fix use-after-free in
+adev_release()"), the auxiliary device is not torn down in the correct
+order. If auxiliary_device_add() fails, the release callback will be
+called twice, resulting in a UAF. Due to timing, the auxdev code in this
+driver "took inspiration" from the aforementioned commit, and thus its
+bugs too!
+
+Moving auxiliary_device_uninit() to the unregister callback instead
+avoids the issue.
+
+CC: stable@vger.kernel.org
+Fixes: b56bae2dd6fd ("clk: microchip: mpfs: add reset controller")
+Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
+Link: https://lore.kernel.org/r/20230413-critter-synopsis-dac070a86cb4@spud
+Signed-off-by: Stephen Boyd <sboyd@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/clk/microchip/clk-mpfs.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/drivers/clk/microchip/clk-mpfs.c
++++ b/drivers/clk/microchip/clk-mpfs.c
+@@ -374,14 +374,13 @@ static void mpfs_reset_unregister_adev(v
+ struct auxiliary_device *adev = _adev;
+
+ auxiliary_device_delete(adev);
++ auxiliary_device_uninit(adev);
+ }
+
+ static void mpfs_reset_adev_release(struct device *dev)
+ {
+ struct auxiliary_device *adev = to_auxiliary_dev(dev);
+
+- auxiliary_device_uninit(adev);
+-
+ kfree(adev);
+ }
+
--- /dev/null
+From 933bf364e152cd60902cf9585c2ba310d593e69f Mon Sep 17 00:00:00 2001
+From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
+Date: Thu, 17 Nov 2022 13:04:31 +0100
+Subject: clk: rockchip: rk3399: allow clk_cifout to force clk_cifout_src to reparent
+
+From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
+
+commit 933bf364e152cd60902cf9585c2ba310d593e69f upstream.
+
+clk_cifout is derived from clk_cifout_src through an integer divider
+limited to 32. clk_cifout_src is a child of either cpll, gpll or npll
+without any possibility of a divider of any sort. The default clock
+parent is cpll.
+
+Let's allow clk_cifout to ask its parent clk_cifout_src to reparent in
+order to find the real closest possible rate for clk_cifout and not one
+derived from cpll only.
+
+Cc: stable@vger.kernel.org # 4.10+
+Fixes: fd8bc829336a ("clk: rockchip: fix the rk3399 cifout clock")
+Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
+Link: https://lore.kernel.org/r/20221117-rk3399-cifout-set-rate-parent-v1-0-432548d04081@theobroma-systems.com
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/clk/rockchip/clk-rk3399.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/clk/rockchip/clk-rk3399.c
++++ b/drivers/clk/rockchip/clk-rk3399.c
+@@ -1263,7 +1263,7 @@ static struct rockchip_clk_branch rk3399
+ RK3399_CLKSEL_CON(56), 6, 2, MFLAGS,
+ RK3399_CLKGATE_CON(10), 7, GFLAGS),
+
+- COMPOSITE_NOGATE(SCLK_CIF_OUT, "clk_cifout", mux_clk_cif_p, 0,
++ COMPOSITE_NOGATE(SCLK_CIF_OUT, "clk_cifout", mux_clk_cif_p, CLK_SET_RATE_PARENT,
+ RK3399_CLKSEL_CON(56), 5, 1, MFLAGS, 0, 5, DFLAGS),
+
+ /* gic */
--- /dev/null
+From 81c18e08a609706c5c2887f267135fa0dece4119 Mon Sep 17 00:00:00 2001
+From: Tanmay Shah <tanmay.shah@amd.com>
+Date: Fri, 10 Mar 2023 17:24:07 -0800
+Subject: drivers: remoteproc: xilinx: Fix carveout names
+
+From: Tanmay Shah <tanmay.shah@amd.com>
+
+commit 81c18e08a609706c5c2887f267135fa0dece4119 upstream.
+
+If the unit address is appended to node name of memory-region,
+then adding rproc carveouts fails as node name and unit-address
+both are passed as carveout name (i.e. vdev0vring0@xxxxxxxx). However,
+only node name is expected by remoteproc framework. This patch moves
+memory-region node parsing from driver probe to prepare and
+only passes node-name and not unit-address
+
+Fixes: 6b291e8020a8 ("drivers: remoteproc: Add Xilinx r5 remoteproc driver")
+Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20230311012407.1292118-5-tanmay.shah@amd.com
+Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/remoteproc/xlnx_r5_remoteproc.c | 90 +++++++-------------------------
+ 1 file changed, 20 insertions(+), 70 deletions(-)
+
+--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
++++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
+@@ -61,8 +61,6 @@ static const struct mem_bank_data zynqmp
+ * @np: device node of RPU instance
+ * @tcm_bank_count: number TCM banks accessible to this RPU
+ * @tcm_banks: array of each TCM bank data
+- * @rmem_count: Number of reserved mem regions
+- * @rmem: reserved memory region nodes from device tree
+ * @rproc: rproc handle
+ * @pm_domain_id: RPU CPU power domain id
+ */
+@@ -71,8 +69,6 @@ struct zynqmp_r5_core {
+ struct device_node *np;
+ int tcm_bank_count;
+ struct mem_bank_data **tcm_banks;
+- int rmem_count;
+- struct reserved_mem **rmem;
+ struct rproc *rproc;
+ u32 pm_domain_id;
+ };
+@@ -239,21 +235,29 @@ static int add_mem_regions_carveout(stru
+ {
+ struct rproc_mem_entry *rproc_mem;
+ struct zynqmp_r5_core *r5_core;
++ struct of_phandle_iterator it;
+ struct reserved_mem *rmem;
+- int i, num_mem_regions;
++ int i = 0;
+
+ r5_core = (struct zynqmp_r5_core *)rproc->priv;
+- num_mem_regions = r5_core->rmem_count;
+
+- for (i = 0; i < num_mem_regions; i++) {
+- rmem = r5_core->rmem[i];
++ /* Register associated reserved memory regions */
++ of_phandle_iterator_init(&it, r5_core->np, "memory-region", NULL, 0);
+
+- if (!strncmp(rmem->name, "vdev0buffer", strlen("vdev0buffer"))) {
++ while (of_phandle_iterator_next(&it) == 0) {
++ rmem = of_reserved_mem_lookup(it.node);
++ if (!rmem) {
++ of_node_put(it.node);
++ dev_err(&rproc->dev, "unable to acquire memory-region\n");
++ return -EINVAL;
++ }
++
++ if (!strcmp(it.node->name, "vdev0buffer")) {
+ /* Init reserved memory for vdev buffer */
+ rproc_mem = rproc_of_resm_mem_entry_init(&rproc->dev, i,
+ rmem->size,
+ rmem->base,
+- rmem->name);
++ it.node->name);
+ } else {
+ /* Register associated reserved memory regions */
+ rproc_mem = rproc_mem_entry_init(&rproc->dev, NULL,
+@@ -261,16 +265,19 @@ static int add_mem_regions_carveout(stru
+ rmem->size, rmem->base,
+ zynqmp_r5_mem_region_map,
+ zynqmp_r5_mem_region_unmap,
+- rmem->name);
++ it.node->name);
+ }
+
+- if (!rproc_mem)
++ if (!rproc_mem) {
++ of_node_put(it.node);
+ return -ENOMEM;
++ }
+
+ rproc_add_carveout(rproc, rproc_mem);
+
+ dev_dbg(&rproc->dev, "reserved mem carveout %s addr=%llx, size=0x%llx",
+- rmem->name, rmem->base, rmem->size);
++ it.node->name, rmem->base, rmem->size);
++ i++;
+ }
+
+ return 0;
+@@ -726,59 +733,6 @@ static int zynqmp_r5_get_tcm_node(struct
+ return 0;
+ }
+
+-/**
+- * zynqmp_r5_get_mem_region_node()
+- * parse memory-region property and get reserved mem regions
+- *
+- * @r5_core: pointer to zynqmp_r5_core type object
+- *
+- * Return: 0 for success and error code for failure.
+- */
+-static int zynqmp_r5_get_mem_region_node(struct zynqmp_r5_core *r5_core)
+-{
+- struct device_node *np, *rmem_np;
+- struct reserved_mem **rmem;
+- int res_mem_count, i;
+- struct device *dev;
+-
+- dev = r5_core->dev;
+- np = r5_core->np;
+-
+- res_mem_count = of_property_count_elems_of_size(np, "memory-region",
+- sizeof(phandle));
+- if (res_mem_count <= 0) {
+- dev_warn(dev, "failed to get memory-region property %d\n",
+- res_mem_count);
+- return 0;
+- }
+-
+- rmem = devm_kcalloc(dev, res_mem_count,
+- sizeof(struct reserved_mem *), GFP_KERNEL);
+- if (!rmem)
+- return -ENOMEM;
+-
+- for (i = 0; i < res_mem_count; i++) {
+- rmem_np = of_parse_phandle(np, "memory-region", i);
+- if (!rmem_np)
+- goto release_rmem;
+-
+- rmem[i] = of_reserved_mem_lookup(rmem_np);
+- if (!rmem[i]) {
+- of_node_put(rmem_np);
+- goto release_rmem;
+- }
+-
+- of_node_put(rmem_np);
+- }
+-
+- r5_core->rmem_count = res_mem_count;
+- r5_core->rmem = rmem;
+- return 0;
+-
+-release_rmem:
+- return -EINVAL;
+-}
+-
+ /*
+ * zynqmp_r5_core_init()
+ * Create and initialize zynqmp_r5_core type object
+@@ -806,10 +760,6 @@ static int zynqmp_r5_core_init(struct zy
+ for (i = 0; i < cluster->core_count; i++) {
+ r5_core = cluster->r5_cores[i];
+
+- ret = zynqmp_r5_get_mem_region_node(r5_core);
+- if (ret)
+- dev_warn(dev, "memory-region prop failed %d\n", ret);
+-
+ /* Initialize r5 cores with power-domains parsed from dts */
+ ret = of_property_read_u32_index(r5_core->np, "power-domains",
+ 1, &r5_core->pm_domain_id);
--- /dev/null
+From 29083fd84da576bfb3563d044f98d38e6b338f00 Mon Sep 17 00:00:00 2001
+From: Mark Rutland <mark.rutland@arm.com>
+Date: Tue, 18 Apr 2023 17:42:12 +0100
+Subject: kasan: hw_tags: avoid invalid virt_to_page()
+
+From: Mark Rutland <mark.rutland@arm.com>
+
+commit 29083fd84da576bfb3563d044f98d38e6b338f00 upstream.
+
+When booting with 'kasan.vmalloc=off', a kernel configured with support
+for KASAN_HW_TAGS will explode at boot time due to bogus use of
+virt_to_page() on a vmalloc adddress. With CONFIG_DEBUG_VIRTUAL selected
+this will be reported explicitly, and with or without CONFIG_DEBUG_VIRTUAL
+the kernel will dereference a bogus address:
+
+| ------------[ cut here ]------------
+| virt_to_phys used for non-linear address: (____ptrval____) (0xffff800008000000)
+| WARNING: CPU: 0 PID: 0 at arch/arm64/mm/physaddr.c:15 __virt_to_phys+0x78/0x80
+| Modules linked in:
+| CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.3.0-rc3-00073-g83865133300d-dirty #4
+| Hardware name: linux,dummy-virt (DT)
+| pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
+| pc : __virt_to_phys+0x78/0x80
+| lr : __virt_to_phys+0x78/0x80
+| sp : ffffcd076afd3c80
+| x29: ffffcd076afd3c80 x28: 0068000000000f07 x27: ffff800008000000
+| x26: fffffbfff0000000 x25: fffffbffff000000 x24: ff00000000000000
+| x23: ffffcd076ad3c000 x22: fffffc0000000000 x21: ffff800008000000
+| x20: ffff800008004000 x19: ffff800008000000 x18: ffff800008004000
+| x17: 666678302820295f x16: ffffffffffffffff x15: 0000000000000004
+| x14: ffffcd076b009e88 x13: 0000000000000fff x12: 0000000000000003
+| x11: 00000000ffffefff x10: c0000000ffffefff x9 : 0000000000000000
+| x8 : 0000000000000000 x7 : 205d303030303030 x6 : 302e30202020205b
+| x5 : ffffcd076b41d63f x4 : ffffcd076afd3827 x3 : 0000000000000000
+| x2 : 0000000000000000 x1 : ffffcd076afd3a30 x0 : 000000000000004f
+| Call trace:
+| __virt_to_phys+0x78/0x80
+| __kasan_unpoison_vmalloc+0xd4/0x478
+| __vmalloc_node_range+0x77c/0x7b8
+| __vmalloc_node+0x54/0x64
+| init_IRQ+0x94/0xc8
+| start_kernel+0x194/0x420
+| __primary_switched+0xbc/0xc4
+| ---[ end trace 0000000000000000 ]---
+| Unable to handle kernel paging request at virtual address 03fffacbe27b8000
+| Mem abort info:
+| ESR = 0x0000000096000004
+| EC = 0x25: DABT (current EL), IL = 32 bits
+| SET = 0, FnV = 0
+| EA = 0, S1PTW = 0
+| FSC = 0x04: level 0 translation fault
+| Data abort info:
+| ISV = 0, ISS = 0x00000004
+| CM = 0, WnR = 0
+| swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000041bc5000
+| [03fffacbe27b8000] pgd=0000000000000000, p4d=0000000000000000
+| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
+| Modules linked in:
+| CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 6.3.0-rc3-00073-g83865133300d-dirty #4
+| Hardware name: linux,dummy-virt (DT)
+| pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
+| pc : __kasan_unpoison_vmalloc+0xe4/0x478
+| lr : __kasan_unpoison_vmalloc+0xd4/0x478
+| sp : ffffcd076afd3ca0
+| x29: ffffcd076afd3ca0 x28: 0068000000000f07 x27: ffff800008000000
+| x26: 0000000000000000 x25: 03fffacbe27b8000 x24: ff00000000000000
+| x23: ffffcd076ad3c000 x22: fffffc0000000000 x21: ffff800008000000
+| x20: ffff800008004000 x19: ffff800008000000 x18: ffff800008004000
+| x17: 666678302820295f x16: ffffffffffffffff x15: 0000000000000004
+| x14: ffffcd076b009e88 x13: 0000000000000fff x12: 0000000000000001
+| x11: 0000800008000000 x10: ffff800008000000 x9 : ffffb2f8dee00000
+| x8 : 000ffffb2f8dee00 x7 : 205d303030303030 x6 : 302e30202020205b
+| x5 : ffffcd076b41d63f x4 : ffffcd076afd3827 x3 : 0000000000000000
+| x2 : 0000000000000000 x1 : ffffcd076afd3a30 x0 : ffffb2f8dee00000
+| Call trace:
+| __kasan_unpoison_vmalloc+0xe4/0x478
+| __vmalloc_node_range+0x77c/0x7b8
+| __vmalloc_node+0x54/0x64
+| init_IRQ+0x94/0xc8
+| start_kernel+0x194/0x420
+| __primary_switched+0xbc/0xc4
+| Code: d34cfc08 aa1f03fa 8b081b39 d503201f (f9400328)
+| ---[ end trace 0000000000000000 ]---
+| Kernel panic - not syncing: Attempted to kill the idle task!
+
+This is because init_vmalloc_pages() erroneously calls virt_to_page() on
+a vmalloc address, while virt_to_page() is only valid for addresses in
+the linear/direct map. Since init_vmalloc_pages() expects virtual
+addresses in the vmalloc range, it must use vmalloc_to_page() rather
+than virt_to_page().
+
+We call init_vmalloc_pages() from __kasan_unpoison_vmalloc(), where we
+check !is_vmalloc_or_module_addr(), suggesting that we might encounter a
+non-vmalloc address. Luckily, this never happens. By design, we only
+call __kasan_unpoison_vmalloc() on pointers in the vmalloc area, and I
+have verified that we don't violate that expectation. Given that,
+is_vmalloc_or_module_addr() must always be true for any legitimate
+argument to __kasan_unpoison_vmalloc().
+
+Correct init_vmalloc_pages() to use vmalloc_to_page(), and remove the
+redundant and misleading use of is_vmalloc_or_module_addr() in
+__kasan_unpoison_vmalloc().
+
+Link: https://lkml.kernel.org/r/20230418164212.1775741-1-mark.rutland@arm.com
+Fixes: 6c2f761dad7851d8 ("kasan: fix zeroing vmalloc memory with HW_TAGS")
+Signed-off-by: Mark Rutland <mark.rutland@arm.com>
+Cc: Alexander Potapenko <glider@google.com>
+Cc: Andrey Konovalov <andreyknvl@google.com>
+Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
+Cc: Dmitry Vyukov <dvyukov@google.com>
+Cc: Marco Elver <elver@google.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/kasan/hw_tags.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/mm/kasan/hw_tags.c
++++ b/mm/kasan/hw_tags.c
+@@ -225,7 +225,7 @@ static void init_vmalloc_pages(const voi
+ const void *addr;
+
+ for (addr = start; addr < start + size; addr += PAGE_SIZE) {
+- struct page *page = virt_to_page(addr);
++ struct page *page = vmalloc_to_page(addr);
+
+ clear_highpage_kasan_tagged(page);
+ }
+@@ -237,7 +237,7 @@ void *__kasan_unpoison_vmalloc(const voi
+ u8 tag;
+ unsigned long redzone_start, redzone_size;
+
+- if (!kasan_vmalloc_enabled() || !is_vmalloc_or_module_addr(start)) {
++ if (!kasan_vmalloc_enabled()) {
+ if (flags & KASAN_VMALLOC_INIT)
+ init_vmalloc_pages(start, size);
+ return (void *)start;
--- /dev/null
+From 8dec88070d964bfeb4198f34cb5956d89dd1f557 Mon Sep 17 00:00:00 2001
+From: Marco Elver <elver@google.com>
+Date: Thu, 9 Mar 2023 11:17:52 +0100
+Subject: kcsan: Avoid READ_ONCE() in read_instrumented_memory()
+
+From: Marco Elver <elver@google.com>
+
+commit 8dec88070d964bfeb4198f34cb5956d89dd1f557 upstream.
+
+Haibo Li reported:
+
+ | Unable to handle kernel paging request at virtual address
+ | ffffff802a0d8d7171
+ | Mem abort info:o:
+ | ESR = 0x9600002121
+ | EC = 0x25: DABT (current EL), IL = 32 bitsts
+ | SET = 0, FnV = 0 0
+ | EA = 0, S1PTW = 0 0
+ | FSC = 0x21: alignment fault
+ | Data abort info:o:
+ | ISV = 0, ISS = 0x0000002121
+ | CM = 0, WnR = 0 0
+ | swapper pgtable: 4k pages, 39-bit VAs, pgdp=000000002835200000
+ | [ffffff802a0d8d71] pgd=180000005fbf9003, p4d=180000005fbf9003,
+ | pud=180000005fbf9003, pmd=180000005fbe8003, pte=006800002a0d8707
+ | Internal error: Oops: 96000021 [#1] PREEMPT SMP
+ | Modules linked in:
+ | CPU: 2 PID: 45 Comm: kworker/u8:2 Not tainted
+ | 5.15.78-android13-8-g63561175bbda-dirty #1
+ | ...
+ | pc : kcsan_setup_watchpoint+0x26c/0x6bc
+ | lr : kcsan_setup_watchpoint+0x88/0x6bc
+ | sp : ffffffc00ab4b7f0
+ | x29: ffffffc00ab4b800 x28: ffffff80294fe588 x27: 0000000000000001
+ | x26: 0000000000000019 x25: 0000000000000001 x24: ffffff80294fdb80
+ | x23: 0000000000000000 x22: ffffffc00a70fb68 x21: ffffff802a0d8d71
+ | x20: 0000000000000002 x19: 0000000000000000 x18: ffffffc00a9bd060
+ | x17: 0000000000000001 x16: 0000000000000000 x15: ffffffc00a59f000
+ | x14: 0000000000000001 x13: 0000000000000000 x12: ffffffc00a70faa0
+ | x11: 00000000aaaaaaab x10: 0000000000000054 x9 : ffffffc00839adf8
+ | x8 : ffffffc009b4cf00 x7 : 0000000000000000 x6 : 0000000000000007
+ | x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffffffc00a70fb70
+ | x2 : 0005ff802a0d8d71 x1 : 0000000000000000 x0 : 0000000000000000
+ | Call trace:
+ | kcsan_setup_watchpoint+0x26c/0x6bc
+ | __tsan_read2+0x1f0/0x234
+ | inflate_fast+0x498/0x750
+ | zlib_inflate+0x1304/0x2384
+ | __gunzip+0x3a0/0x45c
+ | gunzip+0x20/0x30
+ | unpack_to_rootfs+0x2a8/0x3fc
+ | do_populate_rootfs+0xe8/0x11c
+ | async_run_entry_fn+0x58/0x1bc
+ | process_one_work+0x3ec/0x738
+ | worker_thread+0x4c4/0x838
+ | kthread+0x20c/0x258
+ | ret_from_fork+0x10/0x20
+ | Code: b8bfc2a8 2a0803f7 14000007 d503249f (78bfc2a8) )
+ | ---[ end trace 613a943cb0a572b6 ]-----
+
+The reason for this is that on certain arm64 configuration since
+e35123d83ee3 ("arm64: lto: Strengthen READ_ONCE() to acquire when
+CONFIG_LTO=y"), READ_ONCE() may be promoted to a full atomic acquire
+instruction which cannot be used on unaligned addresses.
+
+Fix it by avoiding READ_ONCE() in read_instrumented_memory(), and simply
+forcing the compiler to do the required access by casting to the
+appropriate volatile type. In terms of generated code this currently
+only affects architectures that do not use the default READ_ONCE()
+implementation.
+
+The only downside is that we are not guaranteed atomicity of the access
+itself, although on most architectures a plain load up to machine word
+size should still be atomic (a fact the default READ_ONCE() still relies
+on itself).
+
+Reported-by: Haibo Li <haibo.li@mediatek.com>
+Tested-by: Haibo Li <haibo.li@mediatek.com>
+Cc: <stable@vger.kernel.org> # 5.17+
+Signed-off-by: Marco Elver <elver@google.com>
+Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/kcsan/core.c | 17 +++++++++++++----
+ 1 file changed, 13 insertions(+), 4 deletions(-)
+
+--- a/kernel/kcsan/core.c
++++ b/kernel/kcsan/core.c
+@@ -337,11 +337,20 @@ static void delay_access(int type)
+ */
+ static __always_inline u64 read_instrumented_memory(const volatile void *ptr, size_t size)
+ {
++ /*
++ * In the below we don't necessarily need the read of the location to
++ * be atomic, and we don't use READ_ONCE(), since all we need for race
++ * detection is to observe 2 different values.
++ *
++ * Furthermore, on certain architectures (such as arm64), READ_ONCE()
++ * may turn into more complex instructions than a plain load that cannot
++ * do unaligned accesses.
++ */
+ switch (size) {
+- case 1: return READ_ONCE(*(const u8 *)ptr);
+- case 2: return READ_ONCE(*(const u16 *)ptr);
+- case 4: return READ_ONCE(*(const u32 *)ptr);
+- case 8: return READ_ONCE(*(const u64 *)ptr);
++ case 1: return *(const volatile u8 *)ptr;
++ case 2: return *(const volatile u16 *)ptr;
++ case 4: return *(const volatile u32 *)ptr;
++ case 8: return *(const volatile u64 *)ptr;
+ default: return 0; /* Ignore; we do not diff the values. */
+ }
+ }
--- /dev/null
+From 74ad37a30ffee3643bc34f9ca7225b20a66abaaf Mon Sep 17 00:00:00 2001
+From: Tanmay Shah <tanmay.shah@amd.com>
+Date: Fri, 10 Mar 2023 17:24:05 -0800
+Subject: mailbox: zynqmp: Fix IPI isr handling
+
+From: Tanmay Shah <tanmay.shah@amd.com>
+
+commit 74ad37a30ffee3643bc34f9ca7225b20a66abaaf upstream.
+
+Multiple IPI channels are mapped to same interrupt handler.
+Current isr implementation handles only one channel per isr.
+Fix this behavior by checking isr status bit of all child
+mailbox nodes.
+
+Fixes: 4981b82ba2ff ("mailbox: ZynqMP IPI mailbox controller")
+Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
+Acked-by: Michal Simek <michal.simek@amd.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20230311012407.1292118-3-tanmay.shah@amd.com
+Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mailbox/zynqmp-ipi-mailbox.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/mailbox/zynqmp-ipi-mailbox.c
++++ b/drivers/mailbox/zynqmp-ipi-mailbox.c
+@@ -152,7 +152,7 @@ static irqreturn_t zynqmp_ipi_interrupt(
+ struct zynqmp_ipi_message *msg;
+ u64 arg0, arg3;
+ struct arm_smccc_res res;
+- int ret, i;
++ int ret, i, status = IRQ_NONE;
+
+ (void)irq;
+ arg0 = SMC_IPI_MAILBOX_STATUS_ENQUIRY;
+@@ -170,11 +170,11 @@ static irqreturn_t zynqmp_ipi_interrupt(
+ memcpy_fromio(msg->data, mchan->req_buf,
+ msg->len);
+ mbox_chan_received_data(chan, (void *)msg);
+- return IRQ_HANDLED;
++ status = IRQ_HANDLED;
+ }
+ }
+ }
+- return IRQ_NONE;
++ return status;
+ }
+
+ /**
--- /dev/null
+From 79963fbfc233759bd8a43462f120d15a1bd4f4fa Mon Sep 17 00:00:00 2001
+From: Tanmay Shah <tanmay.shah@amd.com>
+Date: Fri, 10 Mar 2023 17:24:06 -0800
+Subject: mailbox: zynqmp: Fix typo in IPI documentation
+
+From: Tanmay Shah <tanmay.shah@amd.com>
+
+commit 79963fbfc233759bd8a43462f120d15a1bd4f4fa upstream.
+
+Xilinx IPI message buffers allows 32-byte data transfer.
+Fix documentation that says 12 bytes
+
+Fixes: 4981b82ba2ff ("mailbox: ZynqMP IPI mailbox controller")
+Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
+Acked-by: Michal Simek <michal.simek@amd.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20230311012407.1292118-4-tanmay.shah@amd.com
+Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/mailbox/zynqmp-ipi-message.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/include/linux/mailbox/zynqmp-ipi-message.h
++++ b/include/linux/mailbox/zynqmp-ipi-message.h
+@@ -9,7 +9,7 @@
+ * @data: message payload
+ *
+ * This is the structure for data used in mbox_send_message
+- * the maximum length of data buffer is fixed to 12 bytes.
++ * the maximum length of data buffer is fixed to 32 bytes.
+ * Client is supposed to be aware of this.
+ */
+ struct zynqmp_ipi_message {
--- /dev/null
+From a405c6f0229526160aa3f177f65e20c86fce84c5 Mon Sep 17 00:00:00 2001
+From: Li Nan <linan122@huawei.com>
+Date: Wed, 22 Feb 2023 12:10:00 +0800
+Subject: md/raid10: fix null-ptr-deref in raid10_sync_request
+
+From: Li Nan <linan122@huawei.com>
+
+commit a405c6f0229526160aa3f177f65e20c86fce84c5 upstream.
+
+init_resync() inits mempool and sets conf->have_replacemnt at the beginning
+of sync, close_sync() frees the mempool when sync is completed.
+
+After [1] recovery might be skipped and init_resync() is called but
+close_sync() is not. null-ptr-deref occurs with r10bio->dev[i].repl_bio.
+
+The following is one way to reproduce the issue.
+
+ 1) create a array, wait for resync to complete, mddev->recovery_cp is set
+ to MaxSector.
+ 2) recovery is woken and it is skipped. conf->have_replacement is set to
+ 0 in init_resync(). close_sync() not called.
+ 3) some io errors and rdev A is set to WantReplacement.
+ 4) a new device is added and set to A's replacement.
+ 5) recovery is woken, A have replacement, but conf->have_replacemnt is
+ 0. r10bio->dev[i].repl_bio will not be alloced and null-ptr-deref
+ occurs.
+
+Fix it by not calling init_resync() if recovery skipped.
+
+[1] commit 7e83ccbecd60 ("md/raid10: Allow skipping recovery when clean arrays are assembled")
+Fixes: 7e83ccbecd60 ("md/raid10: Allow skipping recovery when clean arrays are assembled")
+Cc: stable@vger.kernel.org
+Signed-off-by: Li Nan <linan122@huawei.com>
+Signed-off-by: Song Liu <song@kernel.org>
+Link: https://lore.kernel.org/r/20230222041000.3341651-3-linan666@huaweicloud.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/raid10.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/md/raid10.c
++++ b/drivers/md/raid10.c
+@@ -3302,10 +3302,6 @@ static sector_t raid10_sync_request(stru
+ sector_t chunk_mask = conf->geo.chunk_mask;
+ int page_idx = 0;
+
+- if (!mempool_initialized(&conf->r10buf_pool))
+- if (init_resync(conf))
+- return 0;
+-
+ /*
+ * Allow skipping a full rebuild for incremental assembly
+ * of a clean array, like RAID1 does.
+@@ -3321,6 +3317,10 @@ static sector_t raid10_sync_request(stru
+ return mddev->dev_sectors - sector_nr;
+ }
+
++ if (!mempool_initialized(&conf->r10buf_pool))
++ if (init_resync(conf))
++ return 0;
++
+ skipped:
+ max_sector = mddev->dev_sectors;
+ if (test_bit(MD_RECOVERY_SYNC, &mddev->recovery) ||
--- /dev/null
+From fc05e06e6098ca2c28f7a10da0e00aeea20fa59e Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Mon, 17 Apr 2023 19:15:37 +0200
+Subject: md/raid5: Improve performance for sequential IO
+
+From: Jan Kara <jack@suse.cz>
+
+commit fc05e06e6098ca2c28f7a10da0e00aeea20fa59e upstream.
+
+Commit 7e55c60acfbb ("md/raid5: Pivot raid5_make_request()") changed the
+order in which requests for underlying disks are created. Since for
+large sequential IO adding of requests frequently races with md_raid5
+thread submitting bios to underlying disks, this results in a change in
+IO pattern because intermediate states of new order of request creation
+result in more smaller discontiguous requests. For RAID5 on top of three
+rotational disks our performance testing revealed this results in
+regression in write throughput:
+
+iozone -a -s 131072000 -y 4 -q 8 -i 0 -i 1 -R
+
+before 7e55c60acfbb:
+ KB reclen write rewrite read reread
+ 131072000 4 493670 525964 524575 513384
+ 131072000 8 540467 532880 512028 513703
+
+after 7e55c60acfbb:
+ KB reclen write rewrite read reread
+ 131072000 4 421785 456184 531278 509248
+ 131072000 8 459283 456354 528449 543834
+
+To reduce the amount of discontiguous requests we can start generating
+requests with the stripe with the lowest chunk offset as that has the
+best chance of being adjacent to IO queued previously. This improves the
+performance to:
+ KB reclen write rewrite read reread
+ 131072000 4 497682 506317 518043 514559
+ 131072000 8 514048 501886 506453 504319
+
+restoring big part of the regression.
+
+Fixes: 7e55c60acfbb ("md/raid5: Pivot raid5_make_request()")
+Cc: stable@vger.kernel.org # v6.0+
+Signed-off-by: Jan Kara <jack@suse.cz>
+Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
+Signed-off-by: Song Liu <song@kernel.org>
+Link: https://lore.kernel.org/r/20230417171537.17899-1-jack@suse.cz
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/raid5.c | 45 ++++++++++++++++++++++++++++++++++++++++++++-
+ 1 file changed, 44 insertions(+), 1 deletion(-)
+
+--- a/drivers/md/raid5.c
++++ b/drivers/md/raid5.c
+@@ -6079,6 +6079,38 @@ out_release:
+ return ret;
+ }
+
++/*
++ * If the bio covers multiple data disks, find sector within the bio that has
++ * the lowest chunk offset in the first chunk.
++ */
++static sector_t raid5_bio_lowest_chunk_sector(struct r5conf *conf,
++ struct bio *bi)
++{
++ int sectors_per_chunk = conf->chunk_sectors;
++ int raid_disks = conf->raid_disks;
++ int dd_idx;
++ struct stripe_head sh;
++ unsigned int chunk_offset;
++ sector_t r_sector = bi->bi_iter.bi_sector & ~((sector_t)RAID5_STRIPE_SECTORS(conf)-1);
++ sector_t sector;
++
++ /* We pass in fake stripe_head to get back parity disk numbers */
++ sector = raid5_compute_sector(conf, r_sector, 0, &dd_idx, &sh);
++ chunk_offset = sector_div(sector, sectors_per_chunk);
++ if (sectors_per_chunk - chunk_offset >= bio_sectors(bi))
++ return r_sector;
++ /*
++ * Bio crosses to the next data disk. Check whether it's in the same
++ * chunk.
++ */
++ dd_idx++;
++ while (dd_idx == sh.pd_idx || dd_idx == sh.qd_idx)
++ dd_idx++;
++ if (dd_idx >= raid_disks)
++ return r_sector;
++ return r_sector + sectors_per_chunk - chunk_offset;
++}
++
+ static bool raid5_make_request(struct mddev *mddev, struct bio * bi)
+ {
+ DEFINE_WAIT_FUNC(wait, woken_wake_function);
+@@ -6150,6 +6182,17 @@ static bool raid5_make_request(struct md
+ }
+ md_account_bio(mddev, &bi);
+
++ /*
++ * Lets start with the stripe with the lowest chunk offset in the first
++ * chunk. That has the best chances of creating IOs adjacent to
++ * previous IOs in case of sequential IO and thus creates the most
++ * sequential IO pattern. We don't bother with the optimization when
++ * reshaping as the performance benefit is not worth the complexity.
++ */
++ if (likely(conf->reshape_progress == MaxSector))
++ logical_sector = raid5_bio_lowest_chunk_sector(conf, bi);
++ s = (logical_sector - ctx.first_sector) >> RAID5_STRIPE_SHIFT(conf);
++
+ add_wait_queue(&conf->wait_for_overlap, &wait);
+ while (1) {
+ res = make_stripe_request(mddev, conf, &ctx, logical_sector,
+@@ -6178,7 +6221,7 @@ static bool raid5_make_request(struct md
+ continue;
+ }
+
+- s = find_first_bit(ctx.sectors_to_do, stripe_cnt);
++ s = find_next_bit_wrap(ctx.sectors_to_do, stripe_cnt, s);
+ if (s == stripe_cnt)
+ break;
+
--- /dev/null
+From e0489f6e221f5ddee6cb3bd51b992b790c5fa4b9 Mon Sep 17 00:00:00 2001
+From: Michael Walle <michael@walle.cc>
+Date: Wed, 8 Mar 2023 09:20:20 +0100
+Subject: mtd: core: fix error path for nvmem provider
+
+From: Michael Walle <michael@walle.cc>
+
+commit e0489f6e221f5ddee6cb3bd51b992b790c5fa4b9 upstream.
+
+If mtd_otp_nvmem_add() fails, the partitions won't be removed
+because there is simply no call to del_mtd_partitions().
+Unfortunately, add_mtd_partitions() will print all partitions to
+the kernel console. If mtd_otp_nvmem_add() returns -EPROBE_DEFER
+this would print the partitions multiple times to the kernel
+console. Instead move mtd_otp_nvmem_add() to the beginning of the
+function.
+
+Fixes: 4b361cfa8624 ("mtd: core: add OTP nvmem provider support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Michael Walle <michael@walle.cc>
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Link: https://lore.kernel.org/linux-mtd/20230308082021.870459-3-michael@walle.cc
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/mtdcore.c | 13 ++++++++++---
+ 1 file changed, 10 insertions(+), 3 deletions(-)
+
+--- a/drivers/mtd/mtdcore.c
++++ b/drivers/mtd/mtdcore.c
+@@ -1023,10 +1023,14 @@ int mtd_device_parse_register(struct mtd
+
+ mtd_set_dev_defaults(mtd);
+
++ ret = mtd_otp_nvmem_add(mtd);
++ if (ret)
++ goto out;
++
+ if (IS_ENABLED(CONFIG_MTD_PARTITIONED_MASTER)) {
+ ret = add_mtd_device(mtd);
+ if (ret)
+- return ret;
++ goto out;
+ }
+
+ /* Prefer parsed partitions over driver-provided fallback */
+@@ -1061,9 +1065,12 @@ int mtd_device_parse_register(struct mtd
+ register_reboot_notifier(&mtd->reboot_notifier);
+ }
+
+- ret = mtd_otp_nvmem_add(mtd);
+-
+ out:
++ if (ret) {
++ nvmem_unregister(mtd->otp_user_nvmem);
++ nvmem_unregister(mtd->otp_factory_nvmem);
++ }
++
+ if (ret && device_is_registered(&mtd->dev))
+ del_mtd_device(mtd);
+
--- /dev/null
+From 8bd1d24e6ca3c599dd455b0e1b22f77bab8290eb Mon Sep 17 00:00:00 2001
+From: Michael Walle <michael@walle.cc>
+Date: Wed, 8 Mar 2023 09:20:19 +0100
+Subject: mtd: core: fix nvmem error reporting
+
+From: Michael Walle <michael@walle.cc>
+
+commit 8bd1d24e6ca3c599dd455b0e1b22f77bab8290eb upstream.
+
+The master MTD will only have an associated device if
+CONFIG_MTD_PARTITIONED_MASTER is set, thus we cannot use dev_err() on
+mtd->dev. Instead use the parent device which is the physical flash
+memory.
+
+Fixes: 4b361cfa8624 ("mtd: core: add OTP nvmem provider support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Michael Walle <michael@walle.cc>
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Link: https://lore.kernel.org/linux-mtd/20230308082021.870459-2-michael@walle.cc
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/mtdcore.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/mtd/mtdcore.c
++++ b/drivers/mtd/mtdcore.c
+@@ -939,6 +939,7 @@ static int mtd_nvmem_fact_otp_reg_read(v
+
+ static int mtd_otp_nvmem_add(struct mtd_info *mtd)
+ {
++ struct device *dev = mtd->dev.parent;
+ struct nvmem_device *nvmem;
+ ssize_t size;
+ int err;
+@@ -952,7 +953,7 @@ static int mtd_otp_nvmem_add(struct mtd_
+ nvmem = mtd_otp_nvmem_register(mtd, "user-otp", size,
+ mtd_nvmem_user_otp_reg_read);
+ if (IS_ERR(nvmem)) {
+- dev_err(&mtd->dev, "Failed to register OTP NVMEM device\n");
++ dev_err(dev, "Failed to register OTP NVMEM device\n");
+ return PTR_ERR(nvmem);
+ }
+ mtd->otp_user_nvmem = nvmem;
+@@ -970,7 +971,7 @@ static int mtd_otp_nvmem_add(struct mtd_
+ nvmem = mtd_otp_nvmem_register(mtd, "factory-otp", size,
+ mtd_nvmem_fact_otp_reg_read);
+ if (IS_ERR(nvmem)) {
+- dev_err(&mtd->dev, "Failed to register OTP NVMEM device\n");
++ dev_err(dev, "Failed to register OTP NVMEM device\n");
+ err = PTR_ERR(nvmem);
+ goto err;
+ }
--- /dev/null
+From 1cd9ceaa5282ff10ea20a7fbadde5a476a1cc99e Mon Sep 17 00:00:00 2001
+From: Michael Walle <michael@walle.cc>
+Date: Wed, 8 Mar 2023 09:20:18 +0100
+Subject: mtd: core: provide unique name for nvmem device, take two
+
+From: Michael Walle <michael@walle.cc>
+
+commit 1cd9ceaa5282ff10ea20a7fbadde5a476a1cc99e upstream.
+
+Commit c048b60d39e1 ("mtd: core: provide unique name for nvmem device")
+tries to give the nvmem device a unique name, but fails badly if the mtd
+device doesn't have a "struct device" associated with it, i.e. if
+CONFIG_MTD_PARTITIONED_MASTER is not set. This will result in the name
+"(null)-user-otp", which is not unique. It seems the best we can do is
+to use the compatible name together with a unique identifier added by
+the nvmem subsystem by using NVMEM_DEVID_AUTO.
+
+Fixes: c048b60d39e1 ("mtd: core: provide unique name for nvmem device")
+Cc: stable@vger.kernel.org
+Signed-off-by: Michael Walle <michael@walle.cc>
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Link: https://lore.kernel.org/linux-mtd/20230308082021.870459-1-michael@walle.cc
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/mtdcore.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/drivers/mtd/mtdcore.c
++++ b/drivers/mtd/mtdcore.c
+@@ -888,8 +888,8 @@ static struct nvmem_device *mtd_otp_nvme
+
+ /* OTP nvmem will be registered on the physical device */
+ config.dev = mtd->dev.parent;
+- config.name = kasprintf(GFP_KERNEL, "%s-%s", dev_name(&mtd->dev), compatible);
+- config.id = NVMEM_DEVID_NONE;
++ config.name = compatible;
++ config.id = NVMEM_DEVID_AUTO;
+ config.owner = THIS_MODULE;
+ config.type = NVMEM_TYPE_OTP;
+ config.root_only = true;
+@@ -905,7 +905,6 @@ static struct nvmem_device *mtd_otp_nvme
+ nvmem = NULL;
+
+ of_node_put(np);
+- kfree(config.name);
+
+ return nvmem;
+ }
--- /dev/null
+From 37513c56139b79dd43c1774513c28f8ab2b05224 Mon Sep 17 00:00:00 2001
+From: Tudor Ambarus <tudor.ambarus@linaro.org>
+Date: Fri, 31 Mar 2023 07:46:04 +0000
+Subject: mtd: spi-nor: core: Update flash's current address mode when changing address mode
+
+From: Tudor Ambarus <tudor.ambarus@linaro.org>
+
+commit 37513c56139b79dd43c1774513c28f8ab2b05224 upstream.
+
+The bug was obswerved while reading code. There are not many users of
+addr_mode_nbytes. Anyway, we should update the flash's current address
+mode when changing the address mode, fix it. We don't care for now about
+the set_4byte_addr_mode(nor, false) from spi_nor_restore(), as it is
+used at driver remove and shutdown.
+
+Fixes: d7931a215063 ("mtd: spi-nor: core: Track flash's internal address mode")
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20230331074606.3559258-9-tudor.ambarus@linaro.org
+Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/spi-nor/core.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/mtd/spi-nor/core.c
++++ b/drivers/mtd/spi-nor/core.c
+@@ -2733,6 +2733,7 @@ static int spi_nor_quad_enable(struct sp
+
+ static int spi_nor_init(struct spi_nor *nor)
+ {
++ struct spi_nor_flash_parameter *params = nor->params;
+ int err;
+
+ err = spi_nor_octal_dtr_enable(nor, true);
+@@ -2774,9 +2775,10 @@ static int spi_nor_init(struct spi_nor *
+ */
+ WARN_ONCE(nor->flags & SNOR_F_BROKEN_RESET,
+ "enabling reset hack; may not recover from unexpected reboots\n");
+- err = nor->params->set_4byte_addr_mode(nor, true);
++ err = params->set_4byte_addr_mode(nor, true);
+ if (err && err != -ENOTSUPP)
+ return err;
++ params->addr_mode_nbytes = 4;
+ }
+
+ return 0;
--- /dev/null
+From 4199c1719e24e73be0acc8b0146fc31ad8af9771 Mon Sep 17 00:00:00 2001
+From: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
+Date: Thu, 6 Apr 2023 15:17:45 +0900
+Subject: mtd: spi-nor: spansion: Enable JFFS2 write buffer for Infineon s25hx SEMPER flash
+
+From: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
+
+commit 4199c1719e24e73be0acc8b0146fc31ad8af9771 upstream.
+
+Infineon(Cypress) SEMPER NOR flash family has on-die ECC and its program
+granularity is 16-byte ECC data unit size. JFFS2 supports write buffer
+mode for ECC'd NOR flash. Provide a way to clear the MTD_BIT_WRITEABLE
+flag in order to enable JFFS2 write buffer mode support.
+
+Fixes: b6b23833fc42 ("mtd: spi-nor: spansion: Add s25hl-t/s25hs-t IDs and fixups")
+Suggested-by: Tudor Ambarus <tudor.ambarus@linaro.org>
+Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/a1cc128e094db4ec141f85bd380127598dfef17e.1680760742.git.Takahiro.Kuwano@infineon.com
+Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/spi-nor/spansion.c | 7 ++-----
+ 1 file changed, 2 insertions(+), 5 deletions(-)
+
+--- a/drivers/mtd/spi-nor/spansion.c
++++ b/drivers/mtd/spi-nor/spansion.c
+@@ -255,13 +255,10 @@ static void s25hx_t_post_sfdp_fixup(stru
+
+ static void s25hx_t_late_init(struct spi_nor *nor)
+ {
+- struct spi_nor_flash_parameter *params = nor->params;
+-
+ /* Fast Read 4B requires mode cycles */
+- params->reads[SNOR_CMD_READ_FAST].num_mode_clocks = 8;
++ nor->params->reads[SNOR_CMD_READ_FAST].num_mode_clocks = 8;
+
+- /* The writesize should be ECC data unit size */
+- params->writesize = 16;
++ cypress_nor_ecc_init(nor);
+ }
+
+ static struct spi_nor_fixups s25hx_t_fixups = {
--- /dev/null
+From 63cfd210034c772fad047afa13dd5a4664b0a72e Mon Sep 17 00:00:00 2001
+From: Huanhuan Wang <huanhuan.wang@corigine.com>
+Date: Thu, 20 Apr 2023 16:01:25 +0200
+Subject: nfp: fix incorrect pointer deference when offloading IPsec with bonding
+
+From: Huanhuan Wang <huanhuan.wang@corigine.com>
+
+commit 63cfd210034c772fad047afa13dd5a4664b0a72e upstream.
+
+There are two pointers in struct xfrm_dev_offload, *dev, *real_dev.
+The *dev points whether bonding interface or real interface, if
+bonding IPsec offload is used, it points bonding interface; if not,
+it points real interface. And *real_dev always points real interface.
+So nfp should always use real_dev instead of dev.
+
+Prior to this change the system becomes unresponsive when offloading
+IPsec for a device which is a lower device to a bonding device.
+
+Fixes: 859a497fe80c ("nfp: implement xfrm callbacks and expose ipsec offload feature to upper layer")
+CC: stable@vger.kernel.org
+Signed-off-by: Huanhuan Wang <huanhuan.wang@corigine.com>
+Acked-by: Simon Horman <simon.horman@corigine.com>
+Signed-off-by: Louis Peens <louis.peens@corigine.com>
+Link: https://lore.kernel.org/r/20230420140125.38521-1-louis.peens@corigine.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/netronome/nfp/crypto/ipsec.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/ethernet/netronome/nfp/crypto/ipsec.c
++++ b/drivers/net/ethernet/netronome/nfp/crypto/ipsec.c
+@@ -267,7 +267,7 @@ static void set_sha2_512hmac(struct nfp_
+
+ static int nfp_net_xfrm_add_state(struct xfrm_state *x)
+ {
+- struct net_device *netdev = x->xso.dev;
++ struct net_device *netdev = x->xso.real_dev;
+ struct nfp_ipsec_cfg_mssg msg = {};
+ int i, key_len, trunc_len, err = 0;
+ struct nfp_ipsec_cfg_add_sa *cfg;
+@@ -503,7 +503,7 @@ static void nfp_net_xfrm_del_state(struc
+ .cmd = NFP_IPSEC_CFG_MSSG_INV_SA,
+ .sa_idx = x->xso.offload_handle - 1,
+ };
+- struct net_device *netdev = x->xso.dev;
++ struct net_device *netdev = x->xso.real_dev;
+ struct nfp_net *nn;
+ int err;
+
nilfs2-fix-infinite-loop-in-nilfs_mdt_get_block.patch
mm-do-not-reclaim-private-data-from-pinned-page.patch
drbd-correctly-submit-flush-bio-on-barrier.patch
+md-raid10-fix-null-ptr-deref-in-raid10_sync_request.patch
+md-raid5-improve-performance-for-sequential-io.patch
+kasan-hw_tags-avoid-invalid-virt_to_page.patch
+mtd-core-provide-unique-name-for-nvmem-device-take-two.patch
+mtd-core-fix-nvmem-error-reporting.patch
+mtd-core-fix-error-path-for-nvmem-provider.patch
+mtd-spi-nor-core-update-flash-s-current-address-mode-when-changing-address-mode.patch
+mtd-spi-nor-spansion-enable-jffs2-write-buffer-for-infineon-s25hx-semper-flash.patch
+drivers-remoteproc-xilinx-fix-carveout-names.patch
+mailbox-zynqmp-fix-ipi-isr-handling.patch
+kcsan-avoid-read_once-in-read_instrumented_memory.patch
+mailbox-zynqmp-fix-typo-in-ipi-documentation.patch
+nfp-fix-incorrect-pointer-deference-when-offloading-ipsec-with-bonding.patch
+wifi-rtl8xxxu-rtl8192eu-always-needs-full-init.patch
+wifi-rtw88-rtw8821c-fix-rfe_option-field-width.patch
+wifi-rtw89-fix-potential-race-condition-between-napi_init-and-napi_enable.patch
+clk-microchip-fix-potential-uaf-in-auxdev-release-callback.patch
+clk-rockchip-rk3399-allow-clk_cifout-to-force-clk_cifout_src-to-reparent.patch
--- /dev/null
+From d46e04ccd40457a0119b76e11ab64a2ad403e138 Mon Sep 17 00:00:00 2001
+From: Bitterblue Smith <rtl8821cerfe2@gmail.com>
+Date: Mon, 13 Mar 2023 15:42:59 +0200
+Subject: wifi: rtl8xxxu: RTL8192EU always needs full init
+
+From: Bitterblue Smith <rtl8821cerfe2@gmail.com>
+
+commit d46e04ccd40457a0119b76e11ab64a2ad403e138 upstream.
+
+Always run the entire init sequence (rtl8xxxu_init_device()) for
+RTL8192EU. It's what the vendor driver does too.
+
+This fixes a bug where the device is unable to connect after
+rebooting:
+
+wlp3s0f3u2: send auth to ... (try 1/3)
+wlp3s0f3u2: send auth to ... (try 2/3)
+wlp3s0f3u2: send auth to ... (try 3/3)
+wlp3s0f3u2: authentication with ... timed out
+
+Rebooting leaves the device powered on (partially? at least the
+firmware is still running), but not really in a working state.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
+Acked-by: Jes Sorensen <jes@trained-monkey.org>
+Signed-off-by: Kalle Valo <kvalo@kernel.org>
+Link: https://lore.kernel.org/r/4eb111a9-d4c4-37d0-b376-4e202de7153c@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
++++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
+@@ -1801,6 +1801,7 @@ struct rtl8xxxu_fileops rtl8192eu_fops =
+ .rx_desc_size = sizeof(struct rtl8xxxu_rxdesc24),
+ .has_s0s1 = 0,
+ .gen2_thermal_meter = 1,
++ .needs_full_init = 1,
+ .adda_1t_init = 0x0fc01616,
+ .adda_1t_path_on = 0x0fc01616,
+ .adda_2t_path_on_a = 0x0fc01616,
--- /dev/null
+From 14705f969d98187a1cc2682e0c9bd2e230b8098f Mon Sep 17 00:00:00 2001
+From: Sascha Hauer <s.hauer@pengutronix.de>
+Date: Mon, 17 Apr 2023 16:03:56 +0200
+Subject: wifi: rtw88: rtw8821c: Fix rfe_option field width
+
+From: Sascha Hauer <s.hauer@pengutronix.de>
+
+commit 14705f969d98187a1cc2682e0c9bd2e230b8098f upstream.
+
+On my RTW8821CU chipset rfe_option reads as 0x22. Looking at the
+vendor driver suggests that the field width of rfe_option is 5 bit,
+so rfe_option should be masked with 0x1f.
+
+Without this the rfe_option comparisons with 2 further down the
+driver evaluate as false when they should really evaluate as true.
+The effect is that 2G channels do not work.
+
+rfe_option is also used as an array index into rtw8821c_rfe_defs[].
+rtw8821c_rfe_defs[34] (0x22) was added as part of adding USB support,
+likely because rfe_option reads as 0x22. As this now becomes 0x2,
+rtw8821c_rfe_defs[34] is no longer used and can be removed.
+
+Note that this might not be the whole truth. In the vendor driver
+there are indeed places where the unmasked rfe_option value is used.
+However, the driver has several places where rfe_option is tested
+with the pattern if (rfe_option == 2 || rfe_option == 0x22) or
+if (rfe_option == 4 || rfe_option == 0x24), so that rfe_option BIT(5)
+has no influence on the code path taken. We therefore mask BIT(5)
+out from rfe_option entirely until this assumption is proved wrong
+by some chip variant we do not know yet.
+
+Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
+Tested-by: Alexandru gagniuc <mr.nuke.me@gmail.com>
+Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
+Tested-by: ValdikSS <iam@valdikss.org.ru>
+Cc: stable@vger.kernel.org
+Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
+Signed-off-by: Kalle Valo <kvalo@kernel.org>
+Link: https://lore.kernel.org/r/20230417140358.2240429-3-s.hauer@pengutronix.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/realtek/rtw88/rtw8821c.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/drivers/net/wireless/realtek/rtw88/rtw8821c.c
++++ b/drivers/net/wireless/realtek/rtw88/rtw8821c.c
+@@ -47,7 +47,7 @@ static int rtw8821c_read_efuse(struct rt
+
+ map = (struct rtw8821c_efuse *)log_map;
+
+- efuse->rfe_option = map->rfe_option;
++ efuse->rfe_option = map->rfe_option & 0x1f;
+ efuse->rf_board_option = map->rf_board_option;
+ efuse->crystal_cap = map->xtal_k;
+ efuse->pa_type_2g = map->pa_type;
+@@ -1537,7 +1537,6 @@ static const struct rtw_rfe_def rtw8821c
+ [2] = RTW_DEF_RFE_EXT(8821c, 0, 0, 2),
+ [4] = RTW_DEF_RFE_EXT(8821c, 0, 0, 2),
+ [6] = RTW_DEF_RFE(8821c, 0, 0),
+- [34] = RTW_DEF_RFE(8821c, 0, 0),
+ };
+
+ static struct rtw_hw_reg rtw8821c_dig[] = {
--- /dev/null
+From 47515664ecfbde11425dff121f298ae4499425c9 Mon Sep 17 00:00:00 2001
+From: Ping-Ke Shih <pkshih@realtek.com>
+Date: Thu, 23 Mar 2023 16:28:39 +0800
+Subject: wifi: rtw89: fix potential race condition between napi_init and napi_enable
+
+From: Ping-Ke Shih <pkshih@realtek.com>
+
+commit 47515664ecfbde11425dff121f298ae4499425c9 upstream.
+
+A race condition can happen if netdev is registered, but NAPI isn't
+initialized yet, and meanwhile user space starts the netdev that will
+enable NAPI. Then, it hits BUG_ON():
+
+ kernel BUG at net/core/dev.c:6423!
+ invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
+ CPU: 0 PID: 417 Comm: iwd Not tainted 6.2.7-slab-dirty #3 eb0f5a8a9d91
+ Hardware name: LENOVO 21DL/LNVNB161216, BIOS JPCN20WW(V1.06) 09/20/2022
+ RIP: 0010:napi_enable+0x3f/0x50
+ Code: 48 89 c2 48 83 e2 f6 f6 81 89 08 00 00 02 74 0d 48 83 ...
+ RSP: 0018:ffffada1414f3548 EFLAGS: 00010246
+ RAX: 0000000000000000 RBX: ffffa01425802080 RCX: 0000000000000000
+ RDX: 00000000000002ff RSI: ffffada14e50c614 RDI: ffffa01425808dc0
+ RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
+ R10: 0000000000000001 R11: 0000000000000100 R12: ffffa01425808f58
+ R13: 0000000000000000 R14: ffffa01423498940 R15: 0000000000000001
+ FS: 00007f5577c0a740(0000) GS:ffffa0169fc00000(0000) knlGS:0000000000000000
+ CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ CR2: 00007f5577a19972 CR3: 0000000125a7a000 CR4: 0000000000750ef0
+ PKRU: 55555554
+ Call Trace:
+ <TASK>
+ rtw89_pci_ops_start+0x1c/0x70 [rtw89_pci 6cbc75429515c181cbc386478d5cfb32ffc5a0f8]
+ rtw89_core_start+0xbe/0x160 [rtw89_core fe07ecb874820b6d778370d4acb6ef8a37847f22]
+ rtw89_ops_start+0x26/0x40 [rtw89_core fe07ecb874820b6d778370d4acb6ef8a37847f22]
+ drv_start+0x42/0x100 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2]
+ ieee80211_do_open+0x311/0x7d0 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2]
+ ieee80211_open+0x6a/0x90 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2]
+ __dev_open+0xe0/0x180
+ __dev_change_flags+0x1da/0x250
+ dev_change_flags+0x26/0x70
+ do_setlink+0x37c/0x12c0
+ ? ep_poll_callback+0x246/0x290
+ ? __nla_validate_parse+0x61/0xd00
+ ? __wake_up_common_lock+0x8f/0xd0
+
+To fix this, follow Jonas' suggestion to switch the order of these
+functions and move register netdev to be the last step of PCI probe.
+Also, correct the error handling of rtw89_core_register_hw().
+
+Fixes: e3ec7017f6a2 ("rtw89: add Realtek 802.11ax driver")
+Cc: stable@vger.kernel.org
+Reported-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>
+Link: https://lore.kernel.org/linux-wireless/CAOiHx=n7EwK2B9CnBR07FVA=sEzFagb8TkS4XC_qBNq8OwcYUg@mail.gmail.com/T/#t
+Suggested-by: Jonas Gorski <jonas.gorski@gmail.com>
+Tested-by: Larry Finger<Larry.Finger@lwfinger.net>
+Reviewed-by: Larry Finger<Larry.Finger@lwfinger.net>
+Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
+Signed-off-by: Kalle Valo <kvalo@kernel.org>
+Link: https://lore.kernel.org/r/20230323082839.20474-1-pkshih@realtek.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/realtek/rtw89/core.c | 10 +++++++---
+ drivers/net/wireless/realtek/rtw89/pci.c | 19 ++++++++++---------
+ 2 files changed, 17 insertions(+), 12 deletions(-)
+
+--- a/drivers/net/wireless/realtek/rtw89/core.c
++++ b/drivers/net/wireless/realtek/rtw89/core.c
+@@ -3374,18 +3374,22 @@ static int rtw89_core_register_hw(struct
+ ret = ieee80211_register_hw(hw);
+ if (ret) {
+ rtw89_err(rtwdev, "failed to register hw\n");
+- goto err;
++ goto err_free_supported_band;
+ }
+
+ ret = rtw89_regd_init(rtwdev, rtw89_regd_notifier);
+ if (ret) {
+ rtw89_err(rtwdev, "failed to init regd\n");
+- goto err;
++ goto err_unregister_hw;
+ }
+
+ return 0;
+
+-err:
++err_unregister_hw:
++ ieee80211_unregister_hw(hw);
++err_free_supported_band:
++ rtw89_core_clr_supported_band(rtwdev);
++
+ return ret;
+ }
+
+--- a/drivers/net/wireless/realtek/rtw89/pci.c
++++ b/drivers/net/wireless/realtek/rtw89/pci.c
+@@ -3874,25 +3874,26 @@ int rtw89_pci_probe(struct pci_dev *pdev
+ rtw89_pci_link_cfg(rtwdev);
+ rtw89_pci_l1ss_cfg(rtwdev);
+
+- ret = rtw89_core_register(rtwdev);
+- if (ret) {
+- rtw89_err(rtwdev, "failed to register core\n");
+- goto err_clear_resource;
+- }
+-
+ rtw89_core_napi_init(rtwdev);
+
+ ret = rtw89_pci_request_irq(rtwdev, pdev);
+ if (ret) {
+ rtw89_err(rtwdev, "failed to request pci irq\n");
+- goto err_unregister;
++ goto err_deinit_napi;
++ }
++
++ ret = rtw89_core_register(rtwdev);
++ if (ret) {
++ rtw89_err(rtwdev, "failed to register core\n");
++ goto err_free_irq;
+ }
+
+ return 0;
+
+-err_unregister:
++err_free_irq:
++ rtw89_pci_free_irq(rtwdev, pdev);
++err_deinit_napi:
+ rtw89_core_napi_deinit(rtwdev);
+- rtw89_core_unregister(rtwdev);
+ err_clear_resource:
+ rtw89_pci_clear_resource(rtwdev, pdev);
+ err_declaim_pci:
projects / thirdparty / kernel / stable-queue.git / commitdiff
