--- /dev/null
+From b9c84331556c7bd471e42ca242d2fa5e9fc3c0cc Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 8 Aug 2022 09:46:40 +0100
+Subject: arm64: cacheinfo: Fix incorrect assignment of signed error value to
+ unsigned fw_level
+
+From: Sudeep Holla <sudeep.holla@arm.com>
+
+[ Upstream commit e75d18cecbb3805895d8ed64da4f78575ec96043 ]
+
+Though acpi_find_last_cache_level() always returned signed value and the
+document states it will return any errors caused by lack of a PPTT table,
+it never returned negative values before.
+
+Commit 0c80f9e165f8 ("ACPI: PPTT: Leave the table mapped for the runtime usage")
+however changed it by returning -ENOENT if no PPTT was found. The value
+returned from acpi_find_last_cache_level() is then assigned to unsigned
+fw_level.
+
+It will result in the number of cache leaves calculated incorrectly as
+a huge value which will then cause the following warning from __alloc_pages
+as the order would be great than MAX_ORDER because of incorrect and huge
+cache leaves value.
+
+ | WARNING: CPU: 0 PID: 1 at mm/page_alloc.c:5407 __alloc_pages+0x74/0x314
+ | Modules linked in:
+ | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-10393-g7c2a8d3ac4c0 #73
+ | pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
+ | pc : __alloc_pages+0x74/0x314
+ | lr : alloc_pages+0xe8/0x318
+ | Call trace:
+ | __alloc_pages+0x74/0x314
+ | alloc_pages+0xe8/0x318
+ | kmalloc_order_trace+0x68/0x1dc
+ | __kmalloc+0x240/0x338
+ | detect_cache_attributes+0xe0/0x56c
+ | update_siblings_masks+0x38/0x284
+ | store_cpu_topology+0x78/0x84
+ | smp_prepare_cpus+0x48/0x134
+ | kernel_init_freeable+0xc4/0x14c
+ | kernel_init+0x2c/0x1b4
+ | ret_from_fork+0x10/0x20
+
+Fix the same by changing fw_level to be signed integer and return the
+error from init_cache_level() early in case of error.
+
+Reported-and-Tested-by: Bruno Goncalves <bgoncalv@redhat.com>
+Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
+Link: https://lore.kernel.org/r/20220808084640.3165368-1-sudeep.holla@arm.com
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm64/kernel/cacheinfo.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/arch/arm64/kernel/cacheinfo.c b/arch/arm64/kernel/cacheinfo.c
+index 587543c6c51cb..97c42be71338a 100644
+--- a/arch/arm64/kernel/cacheinfo.c
++++ b/arch/arm64/kernel/cacheinfo.c
+@@ -45,7 +45,8 @@ static void ci_leaf_init(struct cacheinfo *this_leaf,
+
+ int init_cache_level(unsigned int cpu)
+ {
+- unsigned int ctype, level, leaves, fw_level;
++ unsigned int ctype, level, leaves;
++ int fw_level;
+ struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
+
+ for (level = 1, leaves = 0; level <= MAX_CACHE_LEVEL; level++) {
+@@ -63,6 +64,9 @@ int init_cache_level(unsigned int cpu)
+ else
+ fw_level = acpi_find_last_cache_level(cpu);
+
++ if (fw_level < 0)
++ return fw_level;
++
+ if (level < fw_level) {
+ /*
+ * some external caches not specified in CLIDR_EL1
+--
+2.35.1
+
--- /dev/null
+From 3d1f2c313dc682145d012e801d310aac73eaa691 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 17 Aug 2022 19:23:21 +0100
+Subject: arm64/signal: Raise limit on stack frames
+
+From: Mark Brown <broonie@kernel.org>
+
+[ Upstream commit 7ddcaf78e93c9282b4d92184f511b4d5bee75355 ]
+
+The signal code has a limit of 64K on the size of a stack frame that it
+will generate, if this limit is exceeded then a process will be killed if
+it receives a signal. Unfortunately with the advent of SME this limit is
+too small - the maximum possible size of the ZA register alone is 64K. This
+is not an issue for practical systems at present but is easily seen using
+virtual platforms.
+
+Raise the limit to 256K, this is substantially more than could be used by
+any current architecture extension.
+
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Acked-by: Catalin Marinas <catalin.marinas@arm.com>
+Link: https://lore.kernel.org/r/20220817182324.638214-2-broonie@kernel.org
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm64/kernel/signal.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
+index b3e1beccf4588..8fdb89afd2b85 100644
+--- a/arch/arm64/kernel/signal.c
++++ b/arch/arm64/kernel/signal.c
+@@ -91,7 +91,7 @@ static size_t sigframe_size(struct rt_sigframe_user_layout const *user)
+ * not taken into account. This limit is not a guarantee and is
+ * NOT ABI.
+ */
+-#define SIGFRAME_MAXSZ SZ_64K
++#define SIGFRAME_MAXSZ SZ_256K
+
+ static int __sigframe_alloc(struct rt_sigframe_user_layout *user,
+ unsigned long *offset, size_t size, bool extend)
+--
+2.35.1
+
--- /dev/null
+From 47e81036da7e993e7afbcd17ae1275e9a821797d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 16 Aug 2022 13:01:57 +0100
+Subject: cpufreq: check only freq_table in __resolve_freq()
+
+From: Lukasz Luba <lukasz.luba@arm.com>
+
+[ Upstream commit 6ca7076fbfaeccce173aeab832d76b9e49e1034b ]
+
+There is no need to check if the cpufreq driver implements callback
+cpufreq_driver::target_index. The logic in the __resolve_freq uses
+the frequency table available in the policy. It doesn't matter if the
+driver provides 'target_index' or 'target' callback. It just has to
+populate the 'policy->freq_table'.
+
+Thus, check only frequency table during the frequency resolving call.
+
+Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
+Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/cpufreq/cpufreq.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
+index cddf7e13c2322..799431d287ee8 100644
+--- a/drivers/cpufreq/cpufreq.c
++++ b/drivers/cpufreq/cpufreq.c
+@@ -532,7 +532,7 @@ static unsigned int __resolve_freq(struct cpufreq_policy *policy,
+
+ target_freq = clamp_val(target_freq, policy->min, policy->max);
+
+- if (!cpufreq_driver->target_index)
++ if (!policy->freq_table)
+ return target_freq;
+
+ idx = cpufreq_frequency_table_target(policy, target_freq, relation);
+--
+2.35.1
+
--- /dev/null
+From 8c587881a9549225c4d0edc38b510235f62691f3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Aug 2022 10:47:09 +0800
+Subject: drm/amdgpu: Check num_gfx_rings for gfx v9_0 rb setup.
+
+From: Candice Li <candice.li@amd.com>
+
+[ Upstream commit c351938350ab9b5e978dede2c321da43de7eb70c ]
+
+No need to set up rb when no gfx rings.
+
+Signed-off-by: Candice Li <candice.li@amd.com>
+Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+index db27fcf87cd04..16cbae04078ad 100644
+--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
++++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+@@ -2624,7 +2624,8 @@ static void gfx_v9_0_constants_init(struct amdgpu_device *adev)
+
+ gfx_v9_0_tiling_mode_table_init(adev);
+
+- gfx_v9_0_setup_rb(adev);
++ if (adev->gfx.num_gfx_rings)
++ gfx_v9_0_setup_rb(adev);
+ gfx_v9_0_get_cu_info(adev, &adev->gfx.cu_info);
+ adev->gfx.config.db_debug2 = RREG32_SOC15(GC, 0, mmDB_DEBUG2);
+
+--
+2.35.1
+
--- /dev/null
+From 6fd9b6d4db7837235d051ab8a34ea36ccdbcd079 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 23 Aug 2022 14:44:06 +0800
+Subject: drm/amdgpu: mmVM_L2_CNTL3 register not initialized correctly
+
+From: Qu Huang <jinsdb@126.com>
+
+[ Upstream commit b8983d42524f10ac6bf35bbce6a7cc8e45f61e04 ]
+
+The mmVM_L2_CNTL3 register is not assigned an initial value
+
+Signed-off-by: Qu Huang <jinsdb@126.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c b/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c
+index b3bede1dc41da..4259f623a9d7a 100644
+--- a/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c
++++ b/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c
+@@ -176,6 +176,7 @@ static void mmhub_v1_0_init_cache_regs(struct amdgpu_device *adev)
+ tmp = REG_SET_FIELD(tmp, VM_L2_CNTL2, INVALIDATE_L2_CACHE, 1);
+ WREG32_SOC15(MMHUB, 0, mmVM_L2_CNTL2, tmp);
+
++ tmp = mmVM_L2_CNTL3_DEFAULT;
+ if (adev->gmc.translate_further) {
+ tmp = REG_SET_FIELD(tmp, VM_L2_CNTL3, BANK_SELECT, 12);
+ tmp = REG_SET_FIELD(tmp, VM_L2_CNTL3,
+--
+2.35.1
+
--- /dev/null
+From fdee6ad93007eaf9ea781145db178b9d6be2f90c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 12 Aug 2022 13:38:34 +0800
+Subject: drm/amdgpu: Move psp_xgmi_terminate call from
+ amdgpu_xgmi_remove_device to psp_hw_fini
+
+From: YiPeng Chai <YiPeng.Chai@amd.com>
+
+[ Upstream commit 9d705d7741ae70764f3d6d87e67fad3b5c30ffd0 ]
+
+V1:
+The amdgpu_xgmi_remove_device function will send unload command
+to psp through psp ring to terminate xgmi, but psp ring has been
+destroyed in psp_hw_fini.
+
+V2:
+1. Change the commit title.
+2. Restore amdgpu_xgmi_remove_device to its original calling location.
+ Move psp_xgmi_terminate call from amdgpu_xgmi_remove_device to
+ psp_hw_fini.
+
+Signed-off-by: YiPeng Chai <YiPeng.Chai@amd.com>
+Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 3 +++
+ drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 2 +-
+ 2 files changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+index 57e9932d8a04e..5b41c29f3ed50 100644
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+@@ -2729,6 +2729,9 @@ static int psp_hw_fini(void *handle)
+ psp_rap_terminate(psp);
+ psp_dtm_terminate(psp);
+ psp_hdcp_terminate(psp);
++
++ if (adev->gmc.xgmi.num_physical_nodes > 1)
++ psp_xgmi_terminate(psp);
+ }
+
+ psp_asd_unload(psp);
+diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
+index a799e0b1ff736..ce0b9cb61f582 100644
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
+@@ -723,7 +723,7 @@ int amdgpu_xgmi_remove_device(struct amdgpu_device *adev)
+ amdgpu_put_xgmi_hive(hive);
+ }
+
+- return psp_xgmi_terminate(&adev->psp);
++ return 0;
+ }
+
+ static int amdgpu_xgmi_ras_late_init(struct amdgpu_device *adev)
+--
+2.35.1
+
--- /dev/null
+From df50fe92b3326ccc532cf3d62ea02d68647053a7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 19 Aug 2022 15:28:34 +0800
+Subject: drm/gem: Fix GEM handle release errors
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Jeffy Chen <jeffy.chen@rock-chips.com>
+
+[ Upstream commit ea2aa97ca37a9044ade001aef71dbc06318e8d44 ]
+
+Currently we are assuming a one to one mapping between dmabuf and
+GEM handle when releasing GEM handles.
+
+But that is not always true, since we would create extra handles for the
+GEM obj in cases like gem_open() and getfb{,2}().
+
+A similar issue was reported at:
+https://lore.kernel.org/all/20211105083308.392156-1-jay.xu@rock-chips.com/
+
+Another problem is that the imported dmabuf might not always have
+gem_obj->dma_buf set, which would cause leaks in
+drm_gem_remove_prime_handles().
+
+Let's fix these for now by using handle to find the exact map to remove.
+
+Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Signed-off-by: Christian König <christian.koenig@amd.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20220819072834.17888-1-jeffy.chen@rock-chips.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/drm_gem.c | 17 +----------------
+ drivers/gpu/drm/drm_internal.h | 4 ++--
+ drivers/gpu/drm/drm_prime.c | 20 ++++++++++++--------
+ 3 files changed, 15 insertions(+), 26 deletions(-)
+
+diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
+index 6410563a9cb6f..dbd19a34b517b 100644
+--- a/drivers/gpu/drm/drm_gem.c
++++ b/drivers/gpu/drm/drm_gem.c
+@@ -167,21 +167,6 @@ void drm_gem_private_object_init(struct drm_device *dev,
+ }
+ EXPORT_SYMBOL(drm_gem_private_object_init);
+
+-static void
+-drm_gem_remove_prime_handles(struct drm_gem_object *obj, struct drm_file *filp)
+-{
+- /*
+- * Note: obj->dma_buf can't disappear as long as we still hold a
+- * handle reference in obj->handle_count.
+- */
+- mutex_lock(&filp->prime.lock);
+- if (obj->dma_buf) {
+- drm_prime_remove_buf_handle_locked(&filp->prime,
+- obj->dma_buf);
+- }
+- mutex_unlock(&filp->prime.lock);
+-}
+-
+ /**
+ * drm_gem_object_handle_free - release resources bound to userspace handles
+ * @obj: GEM object to clean up.
+@@ -252,7 +237,7 @@ drm_gem_object_release_handle(int id, void *ptr, void *data)
+ if (obj->funcs->close)
+ obj->funcs->close(obj, file_priv);
+
+- drm_gem_remove_prime_handles(obj, file_priv);
++ drm_prime_remove_buf_handle(&file_priv->prime, id);
+ drm_vma_node_revoke(&obj->vma_node, file_priv);
+
+ drm_gem_object_handle_put_unlocked(obj);
+diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
+index 17f3548c8ed25..d05e6a5b66873 100644
+--- a/drivers/gpu/drm/drm_internal.h
++++ b/drivers/gpu/drm/drm_internal.h
+@@ -74,8 +74,8 @@ int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data,
+
+ void drm_prime_init_file_private(struct drm_prime_file_private *prime_fpriv);
+ void drm_prime_destroy_file_private(struct drm_prime_file_private *prime_fpriv);
+-void drm_prime_remove_buf_handle_locked(struct drm_prime_file_private *prime_fpriv,
+- struct dma_buf *dma_buf);
++void drm_prime_remove_buf_handle(struct drm_prime_file_private *prime_fpriv,
++ uint32_t handle);
+
+ /* drm_drv.c */
+ struct drm_minor *drm_minor_acquire(unsigned int minor_id);
+diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
+index d6c7f4f9a7a29..a350310b65d89 100644
+--- a/drivers/gpu/drm/drm_prime.c
++++ b/drivers/gpu/drm/drm_prime.c
+@@ -187,29 +187,33 @@ static int drm_prime_lookup_buf_handle(struct drm_prime_file_private *prime_fpri
+ return -ENOENT;
+ }
+
+-void drm_prime_remove_buf_handle_locked(struct drm_prime_file_private *prime_fpriv,
+- struct dma_buf *dma_buf)
++void drm_prime_remove_buf_handle(struct drm_prime_file_private *prime_fpriv,
++ uint32_t handle)
+ {
+ struct rb_node *rb;
+
+- rb = prime_fpriv->dmabufs.rb_node;
++ mutex_lock(&prime_fpriv->lock);
++
++ rb = prime_fpriv->handles.rb_node;
+ while (rb) {
+ struct drm_prime_member *member;
+
+- member = rb_entry(rb, struct drm_prime_member, dmabuf_rb);
+- if (member->dma_buf == dma_buf) {
++ member = rb_entry(rb, struct drm_prime_member, handle_rb);
++ if (member->handle == handle) {
+ rb_erase(&member->handle_rb, &prime_fpriv->handles);
+ rb_erase(&member->dmabuf_rb, &prime_fpriv->dmabufs);
+
+- dma_buf_put(dma_buf);
++ dma_buf_put(member->dma_buf);
+ kfree(member);
+- return;
+- } else if (member->dma_buf < dma_buf) {
++ break;
++ } else if (member->handle < handle) {
+ rb = rb->rb_right;
+ } else {
+ rb = rb->rb_left;
+ }
+ }
++
++ mutex_unlock(&prime_fpriv->lock);
+ }
+
+ void drm_prime_init_file_private(struct drm_prime_file_private *prime_fpriv)
+--
+2.35.1
+
--- /dev/null
+From 8166bba34041ed99b24c958f62a4b6d96e4c17f4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 11 Aug 2022 15:25:40 +0800
+Subject: drm/radeon: add a force flush to delay work when radeon
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Zhenneng Li <lizhenneng@kylinos.cn>
+
+[ Upstream commit f461950fdc374a3ada5a63c669d997de4600dffe ]
+
+Although radeon card fence and wait for gpu to finish processing current batch rings,
+there is still a corner case that radeon lockup work queue may not be fully flushed,
+and meanwhile the radeon_suspend_kms() function has called pci_set_power_state() to
+put device in D3hot state.
+Per PCI spec rev 4.0 on 5.3.1.4.1 D3hot State.
+> Configuration and Message requests are the only TLPs accepted by a Function in
+> the D3hot state. All other received Requests must be handled as Unsupported Requests,
+> and all received Completions may optionally be handled as Unexpected Completions.
+This issue will happen in following logs:
+Unable to handle kernel paging request at virtual address 00008800e0008010
+CPU 0 kworker/0:3(131): Oops 0
+pc = [<ffffffff811bea5c>] ra = [<ffffffff81240844>] ps = 0000 Tainted: G W
+pc is at si_gpu_check_soft_reset+0x3c/0x240
+ra is at si_dma_is_lockup+0x34/0xd0
+v0 = 0000000000000000 t0 = fff08800e0008010 t1 = 0000000000010000
+t2 = 0000000000008010 t3 = fff00007e3c00000 t4 = fff00007e3c00258
+t5 = 000000000000ffff t6 = 0000000000000001 t7 = fff00007ef078000
+s0 = fff00007e3c016e8 s1 = fff00007e3c00000 s2 = fff00007e3c00018
+s3 = fff00007e3c00000 s4 = fff00007fff59d80 s5 = 0000000000000000
+s6 = fff00007ef07bd98
+a0 = fff00007e3c00000 a1 = fff00007e3c016e8 a2 = 0000000000000008
+a3 = 0000000000000001 a4 = 8f5c28f5c28f5c29 a5 = ffffffff810f4338
+t8 = 0000000000000275 t9 = ffffffff809b66f8 t10 = ff6769c5d964b800
+t11= 000000000000b886 pv = ffffffff811bea20 at = 0000000000000000
+gp = ffffffff81d89690 sp = 00000000aa814126
+Disabling lock debugging due to kernel taint
+Trace:
+[<ffffffff81240844>] si_dma_is_lockup+0x34/0xd0
+[<ffffffff81119610>] radeon_fence_check_lockup+0xd0/0x290
+[<ffffffff80977010>] process_one_work+0x280/0x550
+[<ffffffff80977350>] worker_thread+0x70/0x7c0
+[<ffffffff80977410>] worker_thread+0x130/0x7c0
+[<ffffffff80982040>] kthread+0x200/0x210
+[<ffffffff809772e0>] worker_thread+0x0/0x7c0
+[<ffffffff80981f8c>] kthread+0x14c/0x210
+[<ffffffff80911658>] ret_from_kernel_thread+0x18/0x20
+[<ffffffff80981e40>] kthread+0x0/0x210
+ Code: ad3e0008 43f0074a ad7e0018 ad9e0020 8c3001e8 40230101
+ <88210000> 4821ed21
+So force lockup work queue flush to fix this problem.
+
+Acked-by: Christian König <christian.koenig@amd.com>
+Signed-off-by: Zhenneng Li <lizhenneng@kylinos.cn>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/radeon/radeon_device.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c
+index 4f0fbf6674316..92905ebb7b459 100644
+--- a/drivers/gpu/drm/radeon/radeon_device.c
++++ b/drivers/gpu/drm/radeon/radeon_device.c
+@@ -1617,6 +1617,9 @@ int radeon_suspend_kms(struct drm_device *dev, bool suspend,
+ if (r) {
+ /* delay GPU reset to resume */
+ radeon_fence_driver_force_completion(rdev, i);
++ } else {
++ /* finish executing delayed work */
++ flush_delayed_work(&rdev->fence_drv[i].lockup_work);
+ }
+ }
+
+--
+2.35.1
+
--- /dev/null
+From 9e4a134b9bc3e7b373d8d2bb147baf489d852e37 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 19 Aug 2022 16:57:52 +0800
+Subject: fbdev: chipsfb: Add missing pci_disable_device() in
+ chipsfb_pci_init()
+
+From: Yang Yingliang <yangyingliang@huawei.com>
+
+[ Upstream commit 07c55c9803dea748d17a054000cbf1913ce06399 ]
+
+Add missing pci_disable_device() in error path in chipsfb_pci_init().
+
+Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/video/fbdev/chipsfb.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/video/fbdev/chipsfb.c b/drivers/video/fbdev/chipsfb.c
+index 393894af26f84..2b00a9d554fc0 100644
+--- a/drivers/video/fbdev/chipsfb.c
++++ b/drivers/video/fbdev/chipsfb.c
+@@ -430,6 +430,7 @@ static int chipsfb_pci_init(struct pci_dev *dp, const struct pci_device_id *ent)
+ err_release_fb:
+ framebuffer_release(p);
+ err_disable:
++ pci_disable_device(dp);
+ err_out:
+ return rc;
+ }
+--
+2.35.1
+
--- /dev/null
+From 795668c11dce351ea193459853044f97309d2c10 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 21 Aug 2022 20:17:31 +0900
+Subject: fbdev: fbcon: Destroy mutex on freeing struct fb_info
+
+From: Shigeru Yoshida <syoshida@redhat.com>
+
+[ Upstream commit 58559dfc1ebba2ae0c7627dc8f8991ae1984c6e3 ]
+
+It's needed to destroy bl_curve_mutex on freeing struct fb_info since
+the mutex is embedded in the structure and initialized when it's
+allocated.
+
+Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/video/fbdev/core/fbsysfs.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/video/fbdev/core/fbsysfs.c b/drivers/video/fbdev/core/fbsysfs.c
+index ce699396d6bad..09ee27e7fc25f 100644
+--- a/drivers/video/fbdev/core/fbsysfs.c
++++ b/drivers/video/fbdev/core/fbsysfs.c
+@@ -84,6 +84,10 @@ void framebuffer_release(struct fb_info *info)
+ if (WARN_ON(refcount_read(&info->count)))
+ return;
+
++#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
++ mutex_destroy(&info->bl_curve_mutex);
++#endif
++
+ kfree(info->apertures);
+ kfree(info);
+ }
+--
+2.35.1
+
--- /dev/null
+From 1ec5a3cd65972354f00ca547f2f5fa0e2b6b32c6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 11 Aug 2022 11:14:13 -0600
+Subject: md: Flush workqueue md_rdev_misc_wq in md_alloc()
+
+From: David Sloan <david.sloan@eideticom.com>
+
+[ Upstream commit 5e8daf906f890560df430d30617c692a794acb73 ]
+
+A race condition still exists when removing and re-creating md devices
+in test cases. However, it is only seen on some setups.
+
+The race condition was tracked down to a reference still being held
+to the kobject by the rdev in the md_rdev_misc_wq which will be released
+in rdev_delayed_delete().
+
+md_alloc() waits for previous deletions by waiting on the md_misc_wq,
+but the md_rdev_misc_wq may still be holding a reference to a recently
+removed device.
+
+To fix this, also flush the md_rdev_misc_wq in md_alloc().
+
+Signed-off-by: David Sloan <david.sloan@eideticom.com>
+[logang@deltatee.com: rewrote commit message]
+Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
+Signed-off-by: Song Liu <song@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/md/md.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/md/md.c b/drivers/md/md.c
+index c8f2e8524bfb7..04e1e294b4b1e 100644
+--- a/drivers/md/md.c
++++ b/drivers/md/md.c
+@@ -5651,6 +5651,7 @@ static int md_alloc(dev_t dev, char *name)
+ * removed (mddev_delayed_delete).
+ */
+ flush_workqueue(md_misc_wq);
++ flush_workqueue(md_rdev_misc_wq);
+
+ mutex_lock(&disks_mutex);
+ mddev = mddev_alloc(dev);
+--
+2.35.1
+
--- /dev/null
+From 10defa263de1debd6a5f51673b68903ef3c872fb Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 22 Aug 2022 22:44:11 -0700
+Subject: net/core/skbuff: Check the return value of skb_copy_bits()
+
+From: lily <floridsleeves@gmail.com>
+
+[ Upstream commit c624c58e08b15105662b9ab9be23d14a6b945a49 ]
+
+skb_copy_bits() could fail, which requires a check on the return
+value.
+
+Signed-off-by: Li Zhong <floridsleeves@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/core/skbuff.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+diff --git a/net/core/skbuff.c b/net/core/skbuff.c
+index 563848242ad33..3c193e7d4bc67 100644
+--- a/net/core/skbuff.c
++++ b/net/core/skbuff.c
+@@ -4188,9 +4188,8 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
+ SKB_GSO_CB(nskb)->csum_start =
+ skb_headroom(nskb) + doffset;
+ } else {
+- skb_copy_bits(head_skb, offset,
+- skb_put(nskb, len),
+- len);
++ if (skb_copy_bits(head_skb, offset, skb_put(nskb, len), len))
++ goto err;
+ }
+ continue;
+ }
+--
+2.35.1
+
--- /dev/null
+From a35dd61fe0e46cd14f01d6a210552b764ff8cc2a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 19 Aug 2022 00:42:31 +0200
+Subject: netfilter: conntrack: work around exceeded receive window
+
+From: Florian Westphal <fw@strlen.de>
+
+[ Upstream commit cf97769c761abfeac8931b35fe0e1a8d5fabc9d8 ]
+
+When a TCP sends more bytes than allowed by the receive window, all future
+packets can be marked as invalid.
+This can clog up the conntrack table because of 5-day default timeout.
+
+Sequence of packets:
+ 01 initiator > responder: [S], seq 171, win 5840, options [mss 1330,sackOK,TS val 63 ecr 0,nop,wscale 1]
+ 02 responder > initiator: [S.], seq 33211, ack 172, win 65535, options [mss 1460,sackOK,TS val 010 ecr 63,nop,wscale 8]
+ 03 initiator > responder: [.], ack 33212, win 2920, options [nop,nop,TS val 068 ecr 010], length 0
+ 04 initiator > responder: [P.], seq 172:240, ack 33212, win 2920, options [nop,nop,TS val 279 ecr 010], length 68
+
+Window is 5840 starting from 33212 -> 39052.
+
+ 05 responder > initiator: [.], ack 240, win 256, options [nop,nop,TS val 872 ecr 279], length 0
+ 06 responder > initiator: [.], seq 33212:34530, ack 240, win 256, options [nop,nop,TS val 892 ecr 279], length 1318
+
+This is fine, conntrack will flag the connection as having outstanding
+data (UNACKED), which lowers the conntrack timeout to 300s.
+
+ 07 responder > initiator: [.], seq 34530:35848, ack 240, win 256, options [nop,nop,TS val 892 ecr 279], length 1318
+ 08 responder > initiator: [.], seq 35848:37166, ack 240, win 256, options [nop,nop,TS val 892 ecr 279], length 1318
+ 09 responder > initiator: [.], seq 37166:38484, ack 240, win 256, options [nop,nop,TS val 892 ecr 279], length 1318
+ 10 responder > initiator: [.], seq 38484:39802, ack 240, win 256, options [nop,nop,TS val 892 ecr 279], length 1318
+
+Packet 10 is already sending more than permitted, but conntrack doesn't
+validate this (only seq is tested vs. maxend, not 'seq+len').
+
+38484 is acceptable, but only up to 39052, so this packet should
+not have been sent (or only 568 bytes, not 1318).
+
+At this point, connection is still in '300s' mode.
+
+Next packet however will get flagged:
+ 11 responder > initiator: [P.], seq 39802:40128, ack 240, win 256, options [nop,nop,TS val 892 ecr 279], length 326
+
+nf_ct_proto_6: SEQ is over the upper bound (over the window of the receiver) .. LEN=378 .. SEQ=39802 ACK=240 ACK PSH ..
+
+Now, a couple of replies/acks comes in:
+
+ 12 initiator > responder: [.], ack 34530, win 4368,
+[.. irrelevant acks removed ]
+ 16 initiator > responder: [.], ack 39802, win 8712, options [nop,nop,TS val 296201291 ecr 2982371892], length 0
+
+This ack is significant -- this acks the last packet send by the
+responder that conntrack considered valid.
+
+This means that ack == td_end. This will withdraw the
+'unacked data' flag, the connection moves back to the 5-day timeout
+of established conntracks.
+
+ 17 initiator > responder: ack 40128, win 10030, ...
+
+This packet is also flagged as invalid.
+
+Because conntrack only updates state based on packets that are
+considered valid, packet 11 'did not exist' and that gets us:
+
+nf_ct_proto_6: ACK is over upper bound 39803 (ACKed data not seen yet) .. SEQ=240 ACK=40128 WINDOW=10030 RES=0x00 ACK URG
+
+Because this received and processed by the endpoints, the conntrack entry
+remains in a bad state, no packets will ever be considered valid again:
+
+ 30 responder > initiator: [F.], seq 40432, ack 2045, win 391, ..
+ 31 initiator > responder: [.], ack 40433, win 11348, ..
+ 32 initiator > responder: [F.], seq 2045, ack 40433, win 11348 ..
+
+... all trigger 'ACK is over bound' test and we end up with
+non-early-evictable 5-day default timeout.
+
+NB: This patch triggers a bunch of checkpatch warnings because of silly
+indent. I will resend the cleanup series linked below to reduce the
+indent level once this change has propagated to net-next.
+
+I could route the cleanup via nf but that causes extra backport work for
+stable maintainers.
+
+Link: https://lore.kernel.org/netfilter-devel/20220720175228.17880-1-fw@strlen.de/T/#mb1d7147d36294573cc4f81d00f9f8dadfdd06cd8
+Signed-off-by: Florian Westphal <fw@strlen.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/netfilter/nf_conntrack_proto_tcp.c | 31 ++++++++++++++++++++++++++
+ 1 file changed, 31 insertions(+)
+
+diff --git a/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c
+index 3cee5d8ee7027..1ecfdc4f23be8 100644
+--- a/net/netfilter/nf_conntrack_proto_tcp.c
++++ b/net/netfilter/nf_conntrack_proto_tcp.c
+@@ -671,6 +671,37 @@ static bool tcp_in_window(struct nf_conn *ct,
+ tn->tcp_be_liberal)
+ res = true;
+ if (!res) {
++ bool seq_ok = before(seq, sender->td_maxend + 1);
++
++ if (!seq_ok) {
++ u32 overshot = end - sender->td_maxend + 1;
++ bool ack_ok;
++
++ ack_ok = after(sack, receiver->td_end - MAXACKWINDOW(sender) - 1);
++
++ if (in_recv_win &&
++ ack_ok &&
++ overshot <= receiver->td_maxwin &&
++ before(sack, receiver->td_end + 1)) {
++ /* Work around TCPs that send more bytes than allowed by
++ * the receive window.
++ *
++ * If the (marked as invalid) packet is allowed to pass by
++ * the ruleset and the peer acks this data, then its possible
++ * all future packets will trigger 'ACK is over upper bound' check.
++ *
++ * Thus if only the sequence check fails then do update td_end so
++ * possible ACK for this data can update internal state.
++ */
++ sender->td_end = end;
++ sender->flags |= IP_CT_TCP_FLAG_DATA_UNACKNOWLEDGED;
++
++ nf_ct_l4proto_log_invalid(skb, ct, hook_state,
++ "%u bytes more than expected", overshot);
++ return res;
++ }
++ }
++
+ nf_ct_l4proto_log_invalid(skb, ct, hook_state,
+ "%s",
+ before(seq, sender->td_maxend + 1) ?
+--
+2.35.1
+
--- /dev/null
+From 426fe2757ba6550dc4a5cc23fdd1c0dc099529b3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 21 Aug 2022 14:49:58 +0200
+Subject: parisc: Add runtime check to prevent PA2.0 kernels on PA1.x machines
+
+From: Helge Deller <deller@gmx.de>
+
+[ Upstream commit 591d2108f3abc4db9f9073cae37cf3591fd250d6 ]
+
+If a 32-bit kernel was compiled for PA2.0 CPUs, it won't be able to run
+on machines with PA1.x CPUs. Add a check and bail out early if a PA1.x
+machine is detected.
+
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/parisc/kernel/head.S | 43 ++++++++++++++++++++++++++++++++++++++-
+ 1 file changed, 42 insertions(+), 1 deletion(-)
+
+diff --git a/arch/parisc/kernel/head.S b/arch/parisc/kernel/head.S
+index aa93d775c34db..598d0938449da 100644
+--- a/arch/parisc/kernel/head.S
++++ b/arch/parisc/kernel/head.S
+@@ -22,7 +22,7 @@
+ #include <linux/init.h>
+ #include <linux/pgtable.h>
+
+- .level PA_ASM_LEVEL
++ .level 1.1
+
+ __INITDATA
+ ENTRY(boot_args)
+@@ -69,6 +69,47 @@ $bss_loop:
+ stw,ma %arg2,4(%r1)
+ stw,ma %arg3,4(%r1)
+
++#if !defined(CONFIG_64BIT) && defined(CONFIG_PA20)
++ /* This 32-bit kernel was compiled for PA2.0 CPUs. Check current CPU
++ * and halt kernel if we detect a PA1.x CPU. */
++ ldi 32,%r10
++ mtctl %r10,%cr11
++ .level 2.0
++ mfctl,w %cr11,%r10
++ .level 1.1
++ comib,<>,n 0,%r10,$cpu_ok
++
++ load32 PA(msg1),%arg0
++ ldi msg1_end-msg1,%arg1
++$iodc_panic:
++ copy %arg0, %r10
++ copy %arg1, %r11
++ load32 PA(init_stack),%sp
++#define MEM_CONS 0x3A0
++ ldw MEM_CONS+32(%r0),%arg0 // HPA
++ ldi ENTRY_IO_COUT,%arg1
++ ldw MEM_CONS+36(%r0),%arg2 // SPA
++ ldw MEM_CONS+8(%r0),%arg3 // layers
++ load32 PA(__bss_start),%r1
++ stw %r1,-52(%sp) // arg4
++ stw %r0,-56(%sp) // arg5
++ stw %r10,-60(%sp) // arg6 = ptr to text
++ stw %r11,-64(%sp) // arg7 = len
++ stw %r0,-68(%sp) // arg8
++ load32 PA(.iodc_panic_ret), %rp
++ ldw MEM_CONS+40(%r0),%r1 // ENTRY_IODC
++ bv,n (%r1)
++.iodc_panic_ret:
++ b . /* wait endless with ... */
++ or %r10,%r10,%r10 /* qemu idle sleep */
++msg1: .ascii "Can't boot kernel which was built for PA8x00 CPUs on this machine.\r\n"
++msg1_end:
++
++$cpu_ok:
++#endif
++
++ .level PA_ASM_LEVEL
++
+ /* Initialize startup VM. Just map first 16/32 MB of memory */
+ load32 PA(swapper_pg_dir),%r4
+ mtctl %r4,%cr24 /* Initialize kernel root pointer */
+--
+2.35.1
+
--- /dev/null
+From 6664d254eec1055cf8861d5f24519a2a5ad7f34a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 19 Aug 2022 12:15:10 +0800
+Subject: parisc: ccio-dma: Handle kmalloc failure in ccio_init_resources()
+
+From: Li Qiong <liqiong@nfschina.com>
+
+[ Upstream commit d46c742f827fa2326ab1f4faa1cccadb56912341 ]
+
+As the possible failure of the kmalloc(), it should be better
+to fix this error path, check and return '-ENOMEM' error code.
+
+Signed-off-by: Li Qiong <liqiong@nfschina.com>
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/parisc/ccio-dma.c | 11 ++++++++---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/parisc/ccio-dma.c b/drivers/parisc/ccio-dma.c
+index 9be007c9420f9..f69ab90b5e22d 100644
+--- a/drivers/parisc/ccio-dma.c
++++ b/drivers/parisc/ccio-dma.c
+@@ -1380,15 +1380,17 @@ ccio_init_resource(struct resource *res, char *name, void __iomem *ioaddr)
+ }
+ }
+
+-static void __init ccio_init_resources(struct ioc *ioc)
++static int __init ccio_init_resources(struct ioc *ioc)
+ {
+ struct resource *res = ioc->mmio_region;
+ char *name = kmalloc(14, GFP_KERNEL);
+-
++ if (unlikely(!name))
++ return -ENOMEM;
+ snprintf(name, 14, "GSC Bus [%d/]", ioc->hw_path);
+
+ ccio_init_resource(res, name, &ioc->ioc_regs->io_io_low);
+ ccio_init_resource(res + 1, name, &ioc->ioc_regs->io_io_low_hv);
++ return 0;
+ }
+
+ static int new_ioc_area(struct resource *res, unsigned long size,
+@@ -1543,7 +1545,10 @@ static int __init ccio_probe(struct parisc_device *dev)
+ return -ENOMEM;
+ }
+ ccio_ioc_init(ioc);
+- ccio_init_resources(ioc);
++ if (ccio_init_resources(ioc)) {
++ kfree(ioc);
++ return -ENOMEM;
++ }
+ hppa_dma_ops = &ccio_ops;
+
+ hba = kzalloc(sizeof(*hba), GFP_KERNEL);
+--
+2.35.1
+
--- /dev/null
+From 6759ca7df353e48403f5e863bf4bc3331f28b59c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 21 Aug 2022 08:12:19 +0200
+Subject: Revert "parisc: Show error if wrong 32/64-bit compiler is being used"
+
+From: Helge Deller <deller@gmx.de>
+
+[ Upstream commit b4b18f47f4f9682fbf5827682645da7c8dde8f80 ]
+
+This reverts commit b160628e9ebcdc85d0db9d7f423c26b3c7c179d0.
+
+There is no need any longer to have this sanity check, because the
+previous commit ("parisc: Make CONFIG_64BIT available for ARCH=parisc64
+only") prevents that CONFIG_64BIT is set if ARCH==parisc.
+
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/parisc/include/asm/bitops.h | 8 --------
+ 1 file changed, 8 deletions(-)
+
+diff --git a/arch/parisc/include/asm/bitops.h b/arch/parisc/include/asm/bitops.h
+index 5779d463b341f..aa4e883431c1a 100644
+--- a/arch/parisc/include/asm/bitops.h
++++ b/arch/parisc/include/asm/bitops.h
+@@ -12,14 +12,6 @@
+ #include <asm/barrier.h>
+ #include <linux/atomic.h>
+
+-/* compiler build environment sanity checks: */
+-#if !defined(CONFIG_64BIT) && defined(__LP64__)
+-#error "Please use 'ARCH=parisc' to build the 32-bit kernel."
+-#endif
+-#if defined(CONFIG_64BIT) && !defined(__LP64__)
+-#error "Please use 'ARCH=parisc64' to build the 64-bit kernel."
+-#endif
+-
+ /* See http://marc.theaimsgroup.com/?t=108826637900003 for discussion
+ * on use of volatile and __*_bit() (set/clear/change):
+ * *_bit() want use of volatile.
+--
+2.35.1
+
--- /dev/null
+From 39a6be568991a51bb2a2715b9fcc658c4b6c0657 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 2 Aug 2022 15:18:49 +0800
+Subject: scsi: megaraid_sas: Fix double kfree()
+
+From: Guixin Liu <kanie@linux.alibaba.com>
+
+[ Upstream commit 8c499e49240bd93628368c3588975cfb94169b8b ]
+
+When allocating log_to_span fails, kfree(instance->ctrl_context) is called
+twice. Remove redundant call.
+
+Link: https://lore.kernel.org/r/1659424729-46502-1-git-send-email-kanie@linux.alibaba.com
+Acked-by: Sumit Saxena <sumit.saxena@broadcom.com>
+Signed-off-by: Guixin Liu <kanie@linux.alibaba.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/megaraid/megaraid_sas_fusion.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c b/drivers/scsi/megaraid/megaraid_sas_fusion.c
+index eb5ceb75a15ec..056837849ead5 100644
+--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
++++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
+@@ -5279,7 +5279,6 @@ megasas_alloc_fusion_context(struct megasas_instance *instance)
+ if (!fusion->log_to_span) {
+ dev_err(&instance->pdev->dev, "Failed from %s %d\n",
+ __func__, __LINE__);
+- kfree(instance->ctrl_context);
+ return -ENOMEM;
+ }
+ }
+--
+2.35.1
+
--- /dev/null
+From 273c332d5834895721e5992a170373c960a368d2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 7 Jul 2022 15:08:01 -0400
+Subject: scsi: qla2xxx: Disable ATIO interrupt coalesce for quad port ISP27XX
+
+From: Tony Battersby <tonyb@cybernetics.com>
+
+[ Upstream commit 53661ded2460b414644532de6b99bd87f71987e9 ]
+
+This partially reverts commit d2b292c3f6fd ("scsi: qla2xxx: Enable ATIO
+interrupt handshake for ISP27XX")
+
+For some workloads where the host sends a batch of commands and then
+pauses, ATIO interrupt coalesce can cause some incoming ATIO entries to be
+ignored for extended periods of time, resulting in slow performance,
+timeouts, and aborted commands.
+
+Disable interrupt coalesce and re-enable the dedicated ATIO MSI-X
+interrupt.
+
+Link: https://lore.kernel.org/r/97dcf365-89ff-014d-a3e5-1404c6af511c@cybernetics.com
+Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
+Reviewed-by: Nilesh Javali <njavali@marvell.com>
+Signed-off-by: Tony Battersby <tonyb@cybernetics.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/qla2xxx/qla_target.c | 10 ++--------
+ 1 file changed, 2 insertions(+), 8 deletions(-)
+
+diff --git a/drivers/scsi/qla2xxx/qla_target.c b/drivers/scsi/qla2xxx/qla_target.c
+index 7ab3c9e4d4783..b86f6e1f21b5c 100644
+--- a/drivers/scsi/qla2xxx/qla_target.c
++++ b/drivers/scsi/qla2xxx/qla_target.c
+@@ -6961,14 +6961,8 @@ qlt_24xx_config_rings(struct scsi_qla_host *vha)
+
+ if (ha->flags.msix_enabled) {
+ if (IS_QLA83XX(ha) || IS_QLA27XX(ha) || IS_QLA28XX(ha)) {
+- if (IS_QLA2071(ha)) {
+- /* 4 ports Baker: Enable Interrupt Handshake */
+- icb->msix_atio = 0;
+- icb->firmware_options_2 |= cpu_to_le32(BIT_26);
+- } else {
+- icb->msix_atio = cpu_to_le16(msix->entry);
+- icb->firmware_options_2 &= cpu_to_le32(~BIT_26);
+- }
++ icb->msix_atio = cpu_to_le16(msix->entry);
++ icb->firmware_options_2 &= cpu_to_le32(~BIT_26);
+ ql_dbg(ql_dbg_init, vha, 0xf072,
+ "Registering ICB vector 0x%x for atio que.\n",
+ msix->entry);
+--
+2.35.1
+
--- /dev/null
+From c820024f4b194cb7c2ded5604a7abea40391d435 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 11 Aug 2022 16:43:49 -0700
+Subject: scsi: ufs: core: Reduce the power mode change timeout
+
+From: Bart Van Assche <bvanassche@acm.org>
+
+[ Upstream commit 8f2c96420c6ec3dcb18c8be923e24c6feaa5ccf6 ]
+
+The current power mode change timeout (180 s) is so large that it can cause
+a watchdog timer to fire. Reduce the power mode change timeout to 10
+seconds.
+
+Link: https://lore.kernel.org/r/20220811234401.1957911-1-bvanassche@acm.org
+Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
+Signed-off-by: Bart Van Assche <bvanassche@acm.org>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/ufs/ufshcd.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
+index 2f6468f22b489..dae1a85f1512c 100644
+--- a/drivers/scsi/ufs/ufshcd.c
++++ b/drivers/scsi/ufs/ufshcd.c
+@@ -8476,6 +8476,8 @@ static int ufshcd_set_dev_pwr_mode(struct ufs_hba *hba,
+ struct scsi_device *sdp;
+ unsigned long flags;
+ int ret, retries;
++ unsigned long deadline;
++ int32_t remaining;
+
+ spin_lock_irqsave(hba->host->host_lock, flags);
+ sdp = hba->sdev_ufs_device;
+@@ -8508,9 +8510,14 @@ static int ufshcd_set_dev_pwr_mode(struct ufs_hba *hba,
+ * callbacks hence set the RQF_PM flag so that it doesn't resume the
+ * already suspended childs.
+ */
++ deadline = jiffies + 10 * HZ;
+ for (retries = 3; retries > 0; --retries) {
++ ret = -ETIMEDOUT;
++ remaining = deadline - jiffies;
++ if (remaining <= 0)
++ break;
+ ret = scsi_execute(sdp, cmd, DMA_NONE, NULL, 0, NULL, &sshdr,
+- START_STOP_TIMEOUT, 0, 0, RQF_PM, NULL);
++ remaining / HZ, 0, 0, RQF_PM, NULL);
+ if (!scsi_status_is_check_condition(ret) ||
+ !scsi_sense_valid(&sshdr) ||
+ sshdr.sense_key != UNIT_ATTENTION)
+--
+2.35.1
+
net-mvpp2-debugfs-fix-memory-leak-when-using-debugfs_lookup.patch
fs-only-do-a-memory-barrier-for-the-first-set_buffer_uptodate.patch
revert-mm-kmemleak-take-a-full-lowmem-check-in-kmemleak_-_phys.patch
+scsi-qla2xxx-disable-atio-interrupt-coalesce-for-qua.patch
+scsi-megaraid_sas-fix-double-kfree.patch
+drm-gem-fix-gem-handle-release-errors.patch
+drm-amdgpu-move-psp_xgmi_terminate-call-from-amdgpu_.patch
+drm-amdgpu-check-num_gfx_rings-for-gfx-v9_0-rb-setup.patch
+drm-radeon-add-a-force-flush-to-delay-work-when-rade.patch
+scsi-ufs-core-reduce-the-power-mode-change-timeout.patch
+revert-parisc-show-error-if-wrong-32-64-bit-compiler.patch
+parisc-ccio-dma-handle-kmalloc-failure-in-ccio_init_.patch
+parisc-add-runtime-check-to-prevent-pa2.0-kernels-on.patch
+arm64-cacheinfo-fix-incorrect-assignment-of-signed-e.patch
+arm64-signal-raise-limit-on-stack-frames.patch
+netfilter-conntrack-work-around-exceeded-receive-win.patch
+cpufreq-check-only-freq_table-in-__resolve_freq.patch
+net-core-skbuff-check-the-return-value-of-skb_copy_b.patch
+md-flush-workqueue-md_rdev_misc_wq-in-md_alloc.patch
+fbdev-fbcon-destroy-mutex-on-freeing-struct-fb_info.patch
+fbdev-chipsfb-add-missing-pci_disable_device-in-chip.patch
+drm-amdgpu-mmvm_l2_cntl3-register-not-initialized-co.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
