--- /dev/null
+From f5ba14043621f4afdf3ad5f92ee2d8dbebbe4340 Mon Sep 17 00:00:00 2001
+From: Leo Li <sunpeng.li@amd.com>
+Date: Tue, 12 Jul 2022 12:30:29 -0400
+Subject: drm/amdgpu: Check BO's requested pinning domains against its preferred_domains
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Leo Li <sunpeng.li@amd.com>
+
+commit f5ba14043621f4afdf3ad5f92ee2d8dbebbe4340 upstream.
+
+When pinning a buffer, we should check to see if there are any
+additional restrictions imposed by bo->preferred_domains. This will
+prevent the BO from being moved to an invalid domain when pinning.
+
+For example, this can happen if the user requests to create a BO in GTT
+domain for display scanout. amdgpu_dm will allow pinning to either VRAM
+or GTT domains, since DCN can scanout from either or. However, in
+amdgpu_bo_pin_restricted(), pinning to VRAM is preferred if there is
+adequate carveout. This can lead to pinning to VRAM despite the user
+requesting GTT placement for the BO.
+
+v2: Allow the kernel to override the domain, which can happen when
+ exporting a BO to a V4L camera (for example).
+
+Signed-off-by: Leo Li <sunpeng.li@amd.com>
+Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+@@ -912,6 +912,10 @@ int amdgpu_bo_pin_restricted(struct amdg
+ if (WARN_ON_ONCE(min_offset > max_offset))
+ return -EINVAL;
+
++ /* Check domain to be pinned to against preferred domains */
++ if (bo->preferred_domains & domain)
++ domain = bo->preferred_domains & domain;
++
+ /* A shared bo cannot be migrated to VRAM */
+ if (bo->tbo.base.import_attach) {
+ if (domain & AMDGPU_GEM_DOMAIN_GTT)
--- /dev/null
+From git@z Thu Jan 1 00:00:00 1970
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Tue, 19 Jul 2022 14:56:59 -0400
+Subject: drm/amdgpu: fix check in fbdev init
+To: <stable@vger.kernel.org>
+Cc: <amd-gfx@lists.freedesktop.org>, Alex Deucher <alexander.deucher@amd.com>, <hgoffin@amazon.com>
+Message-ID: <20220719185659.2068735-1-alexander.deucher@amd.com>
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+The new vkms virtual display code is atomic so there is
+no need to call drm_helper_disable_unused_functions()
+when it is enabled. Doing so can result in a segfault.
+When the driver switched from the old virtual display code
+to the new atomic virtual display code, it was missed that
+we enable virtual display unconditionally under SR-IOV
+so the checks here missed that case. Add the missing
+check for SR-IOV.
+
+There is no equivalent of this patch for Linus' tree
+because the relevant code no longer exists. This patch
+is only relevant to kernels 5.15 and 5.16.
+
+Fixes: 84ec374bd580 ("drm/amdgpu: create amdgpu_vkms (v4)")
+Cc: stable@vger.kernel.org # 5.15.x
+Cc: hgoffin@amazon.com
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+@@ -341,7 +341,8 @@ int amdgpu_fbdev_init(struct amdgpu_devi
+ }
+
+ /* disable all the possible outputs/crtcs before entering KMS mode */
+- if (!amdgpu_device_has_dc_support(adev) && !amdgpu_virtual_display)
++ if (!amdgpu_device_has_dc_support(adev) && !amdgpu_virtual_display &&
++ !amdgpu_sriov_vf(adev))
+ drm_helper_disable_unused_functions(adev_to_drm(adev));
+
+ drm_fb_helper_initial_config(&rfbdev->helper, bpp_sel);
--- /dev/null
+From 2939deac1fa220bc82b89235f146df1d9b52e876 Mon Sep 17 00:00:00 2001
+From: Dmitry Osipenko <dmitry.osipenko@collabora.com>
+Date: Thu, 30 Jun 2022 23:04:04 +0300
+Subject: drm/gem: Properly annotate WW context on drm_gem_lock_reservations() error
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Dmitry Osipenko <dmitry.osipenko@collabora.com>
+
+commit 2939deac1fa220bc82b89235f146df1d9b52e876 upstream.
+
+Use ww_acquire_fini() in the error code paths. Otherwise lockdep
+thinks that lock is held when lock's memory is freed after the
+drm_gem_lock_reservations() error. The ww_acquire_context needs to be
+annotated as "released", which fixes the noisy "WARNING: held lock freed!"
+splat of VirtIO-GPU driver with CONFIG_DEBUG_MUTEXES=y and enabled lockdep.
+
+Cc: stable@vger.kernel.org
+Fixes: 7edc3e3b975b5 ("drm: Add helpers for locking an array of BO reservations.")
+Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Link: https://patchwork.freedesktop.org/patch/msgid/20220630200405.1883897-2-dmitry.osipenko@collabora.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/drm_gem.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/drm_gem.c
++++ b/drivers/gpu/drm/drm_gem.c
+@@ -1224,7 +1224,7 @@ retry:
+ ret = dma_resv_lock_slow_interruptible(obj->resv,
+ acquire_ctx);
+ if (ret) {
+- ww_acquire_done(acquire_ctx);
++ ww_acquire_fini(acquire_ctx);
+ return ret;
+ }
+ }
+@@ -1249,7 +1249,7 @@ retry:
+ goto retry;
+ }
+
+- ww_acquire_done(acquire_ctx);
++ ww_acquire_fini(acquire_ctx);
+ return ret;
+ }
+ }
--- /dev/null
+From 009a3a52791f31c57d755a73f6bc66fbdd8bd76c Mon Sep 17 00:00:00 2001
+From: Thomas Zimmermann <tzimmermann@suse.de>
+Date: Wed, 22 Jun 2022 10:34:13 +0200
+Subject: drm/hyperv-drm: Include framebuffer and EDID headers
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Thomas Zimmermann <tzimmermann@suse.de>
+
+commit 009a3a52791f31c57d755a73f6bc66fbdd8bd76c upstream.
+
+Fix a number of compile errors by including the correct header
+files. Examples are shown below.
+
+ ../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c: In function 'hyperv_blit_to_vram_rect':
+ ../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c:25:48: error: invalid use of undefined type 'struct drm_framebuffer'
+ 25 | struct hyperv_drm_device *hv = to_hv(fb->dev);
+ | ^~
+
+ ../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c: In function 'hyperv_connector_get_modes':
+ ../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c:59:17: error: implicit declaration of function 'drm_add_modes_noedid' [-Werror=implicit-function-declaration]
+ 59 | count = drm_add_modes_noedid(connector,
+ | ^~~~~~~~~~~~~~~~~~~~
+
+ ../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c:62:9: error: implicit declaration of function 'drm_set_preferred_mode'; did you mean 'drm_mm_reserve_node'? [-Werror=implicit-function-declaration]
+ 62 | drm_set_preferred_mode(connector, hv->preferred_width,
+ | ^~~~~~~~~~~~~~~~~~~~~~
+
+Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
+Fixes: 76c56a5affeb ("drm/hyperv: Add DRM driver for hyperv synthetic video device")
+Fixes: 720cf96d8fec ("drm: Drop drm_framebuffer.h from drm_crtc.h")
+Fixes: 255490f9150d ("drm: Drop drm_edid.h from drm_crtc.h")
+Cc: Deepak Rawat <drawat.floss@gmail.com>
+Cc: Thomas Zimmermann <tzimmermann@suse.de>
+Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
+Cc: Maxime Ripard <mripard@kernel.org>
+Cc: linux-hyperv@vger.kernel.org
+Cc: dri-devel@lists.freedesktop.org
+Cc: <stable@vger.kernel.org> # v5.14+
+Acked-by: Maxime Ripard <maxime@cerno.tech>
+Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20220622083413.12573-1-tzimmermann@suse.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c
++++ b/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c
+@@ -7,9 +7,11 @@
+
+ #include <drm/drm_damage_helper.h>
+ #include <drm/drm_drv.h>
++#include <drm/drm_edid.h>
+ #include <drm/drm_fb_helper.h>
+ #include <drm/drm_format_helper.h>
+ #include <drm/drm_fourcc.h>
++#include <drm/drm_framebuffer.h>
+ #include <drm/drm_gem_atomic_helper.h>
+ #include <drm/drm_gem_framebuffer_helper.h>
+ #include <drm/drm_gem_shmem_helper.h>
--- /dev/null
+From 53c26181950ddc3c8ace3c0939c89e9c4d8deeb9 Mon Sep 17 00:00:00 2001
+From: Lyude Paul <lyude@redhat.com>
+Date: Thu, 14 Jul 2022 13:42:33 -0400
+Subject: drm/nouveau/acpi: Don't print error when we get -EINPROGRESS from pm_runtime
+
+From: Lyude Paul <lyude@redhat.com>
+
+commit 53c26181950ddc3c8ace3c0939c89e9c4d8deeb9 upstream.
+
+Since this isn't actually a failure.
+
+Signed-off-by: Lyude Paul <lyude@redhat.com>
+Reviewed-by: David Airlie <airlied@linux.ie>
+Fixes: 79e765ad665d ("drm/nouveau/drm/nouveau: Prevent handling ACPI HPD events too early")
+Cc: <stable@vger.kernel.org> # v4.19+
+Link: https://patchwork.freedesktop.org/patch/msgid/20220714174234.949259-2-lyude@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/nouveau/nouveau_display.c
++++ b/drivers/gpu/drm/nouveau/nouveau_display.c
+@@ -540,7 +540,7 @@ nouveau_display_acpi_ntfy(struct notifie
+ * it's own hotplug events.
+ */
+ pm_runtime_put_autosuspend(drm->dev->dev);
+- } else if (ret == 0) {
++ } else if (ret == 0 || ret == -EINPROGRESS) {
+ /* We've started resuming the GPU already, so
+ * it will handle scheduling a full reprobe
+ * itself
--- /dev/null
+From c96cfaf8fc02d4bb70727dfa7ce7841a3cff9be2 Mon Sep 17 00:00:00 2001
+From: Lyude Paul <lyude@redhat.com>
+Date: Thu, 14 Jul 2022 13:42:34 -0400
+Subject: drm/nouveau: Don't pm_runtime_put_sync(), only pm_runtime_put_autosuspend()
+
+From: Lyude Paul <lyude@redhat.com>
+
+commit c96cfaf8fc02d4bb70727dfa7ce7841a3cff9be2 upstream.
+
+While trying to fix another issue, it occurred to me that I don't actually
+think there is any situation where we want pm_runtime_put() in nouveau to
+be synchronous. In fact, this kind of just seems like it would cause
+issues where we may unexpectedly block a thread we don't expect to be
+blocked.
+
+So, let's only use pm_runtime_put_autosuspend().
+
+Changes since v1:
+* Use pm_runtime_put_autosuspend(), not pm_runtime_put()
+
+Signed-off-by: Lyude Paul <lyude@redhat.com>
+Reviewed-by: David Airlie <airlied@linux.ie>
+Fixes: 3a6536c51d5d ("drm/nouveau: Intercept ACPI_VIDEO_NOTIFY_PROBE")
+Cc: Hans de Goede <hdegoede@redhat.com>
+Cc: <stable@vger.kernel.org> # v4.10+
+Link: https://patchwork.freedesktop.org/patch/msgid/20220714174234.949259-3-lyude@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
+ drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/nouveau/nouveau_display.c
++++ b/drivers/gpu/drm/nouveau/nouveau_display.c
+@@ -518,7 +518,7 @@ nouveau_display_hpd_work(struct work_str
+
+ pm_runtime_mark_last_busy(drm->dev->dev);
+ noop:
+- pm_runtime_put_sync(drm->dev->dev);
++ pm_runtime_put_autosuspend(dev->dev);
+ }
+
+ #ifdef CONFIG_ACPI
+--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
++++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+@@ -466,7 +466,7 @@ nouveau_fbcon_set_suspend_work(struct wo
+ if (state == FBINFO_STATE_RUNNING) {
+ nouveau_fbcon_hotplug_resume(drm->fbcon);
+ pm_runtime_mark_last_busy(drm->dev->dev);
+- pm_runtime_put_sync(drm->dev->dev);
++ pm_runtime_put_autosuspend(drm->dev->dev);
+ }
+ }
+
--- /dev/null
+From c441d28945fb113220d48d6c86ebc0b090a2b677 Mon Sep 17 00:00:00 2001
+From: Timur Tabi <ttabi@nvidia.com>
+Date: Wed, 11 May 2022 11:37:16 -0500
+Subject: drm/nouveau: fix another off-by-one in nvbios_addr
+
+From: Timur Tabi <ttabi@nvidia.com>
+
+commit c441d28945fb113220d48d6c86ebc0b090a2b677 upstream.
+
+This check determines whether a given address is part of
+image 0 or image 1. Image 1 starts at offset image0_size,
+so that address should be included.
+
+Fixes: 4d4e9907ff572 ("drm/nouveau/bios: guard against out-of-bounds accesses to image")
+Cc: <stable@vger.kernel.org> # v4.8+
+Signed-off-by: Timur Tabi <ttabi@nvidia.com>
+Reviewed-by: Karol Herbst <kherbst@redhat.com>
+Signed-off-by: Lyude Paul <lyude@redhat.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20220511163716.3520591-1-ttabi@nvidia.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/nouveau/nvkm/subdev/bios/base.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/base.c
++++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/base.c
+@@ -33,7 +33,7 @@ nvbios_addr(struct nvkm_bios *bios, u32
+ {
+ u32 p = *addr;
+
+- if (*addr > bios->image0_size && bios->imaged_addr) {
++ if (*addr >= bios->image0_size && bios->imaged_addr) {
+ *addr -= bios->image0_size;
+ *addr += bios->imaged_addr;
+ }
--- /dev/null
+From ca0367ca5d9216644b41f86348d6661f8d9e32d8 Mon Sep 17 00:00:00 2001
+From: Lyude Paul <lyude@redhat.com>
+Date: Thu, 26 May 2022 16:43:13 -0400
+Subject: drm/nouveau/kms: Fix failure path for creating DP connectors
+
+From: Lyude Paul <lyude@redhat.com>
+
+commit ca0367ca5d9216644b41f86348d6661f8d9e32d8 upstream.
+
+It looks like that when we moved nouveau over to using drm_dp_aux_init()
+and registering it's aux bus during late connector registration, we totally
+forgot to fix the failure codepath in nouveau_connector_create() - as it
+still seems to assume that drm_dp_aux_init() can fail (it can't).
+
+So, let's fix that and also add a missing check to ensure that we've
+properly allocated nv_connector->aux.name while we're at it.
+
+Signed-off-by: Lyude Paul <lyude@redhat.com>
+Reviewed-by: David Airlie <airlied@linux.ie>
+Fixes: fd43ad9d47e7 ("drm/nouveau/kms/nv50-: Move AUX adapter reg to connector late register/early unregister")
+Cc: <stable@vger.kernel.org> # v5.14+
+Link: https://patchwork.freedesktop.org/patch/msgid/20220526204313.656473-1-lyude@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/nouveau/nouveau_connector.c | 8 +++-----
+ 1 file changed, 3 insertions(+), 5 deletions(-)
+
+--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
++++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
+@@ -1361,13 +1361,11 @@ nouveau_connector_create(struct drm_devi
+ snprintf(aux_name, sizeof(aux_name), "sor-%04x-%04x",
+ dcbe->hasht, dcbe->hashm);
+ nv_connector->aux.name = kstrdup(aux_name, GFP_KERNEL);
+- drm_dp_aux_init(&nv_connector->aux);
+- if (ret) {
+- NV_ERROR(drm, "Failed to init AUX adapter for sor-%04x-%04x: %d\n",
+- dcbe->hasht, dcbe->hashm, ret);
++ if (!nv_connector->aux.name) {
+ kfree(nv_connector);
+- return ERR_PTR(ret);
++ return ERR_PTR(-ENOMEM);
+ }
++ drm_dp_aux_init(&nv_connector->aux);
+ fallthrough;
+ default:
+ funcs = &nouveau_connector_funcs;
--- /dev/null
+From df4aaf015775221dde8a51ee09edb919981f091e Mon Sep 17 00:00:00 2001
+From: Dmitry Osipenko <dmitry.osipenko@collabora.com>
+Date: Thu, 30 Jun 2022 23:00:57 +0300
+Subject: drm/shmem-helper: Add missing vunmap on error
+
+From: Dmitry Osipenko <dmitry.osipenko@collabora.com>
+
+commit df4aaf015775221dde8a51ee09edb919981f091e upstream.
+
+The vmapping of dma-buf may succeed, but DRM SHMEM rejects the IOMEM
+mapping, and thus, drm_gem_shmem_vmap_locked() should unvmap the IOMEM
+before erroring out.
+
+Cc: stable@vger.kernel.org
+Fixes: 49a3f51dfeee ("drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM backends")
+Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Link: https://patchwork.freedesktop.org/patch/msgid/20220630200058.1883506-2-dmitry.osipenko@collabora.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/drm_gem_shmem_helper.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
++++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
+@@ -275,6 +275,7 @@ static int drm_gem_shmem_vmap_locked(str
+ ret = dma_buf_vmap(obj->import_attach->dmabuf, map);
+ if (!ret) {
+ if (WARN_ON(map->is_iomem)) {
++ dma_buf_vunmap(obj->import_attach->dmabuf, map);
+ ret = -EIO;
+ goto err_put_pages;
+ }
--- /dev/null
+From db2b927f8668adf3ac765e0921cd2720f5c04172 Mon Sep 17 00:00:00 2001
+From: Phil Elwell <phil@raspberrypi.org>
+Date: Mon, 13 Jun 2022 16:47:44 +0200
+Subject: drm/vc4: hdmi: Disable audio if dmas property is present but empty
+
+From: Phil Elwell <phil@raspberrypi.org>
+
+commit db2b927f8668adf3ac765e0921cd2720f5c04172 upstream.
+
+The dmas property is used to hold the dmaengine channel used for audio
+output.
+
+Older device trees were missing that property, so if it's not there we
+disable the audio output entirely.
+
+However, some overlays have set an empty value to that property, mostly
+to workaround the fact that overlays cannot remove a property. Let's add
+a test for that case and if it's empty, let's disable it as well.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Phil Elwell <phil@raspberrypi.org>
+Link: https://lore.kernel.org/r/20220613144800.326124-18-maxime@cerno.tech
+Signed-off-by: Maxime Ripard <maxime@cerno.tech>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/vc4/vc4_hdmi.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
++++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
+@@ -1470,12 +1470,12 @@ static int vc4_hdmi_audio_init(struct vc
+ struct device *dev = &vc4_hdmi->pdev->dev;
+ struct platform_device *codec_pdev;
+ const __be32 *addr;
+- int index;
++ int index, len;
+ int ret;
+
+- if (!of_find_property(dev->of_node, "dmas", NULL)) {
++ if (!of_find_property(dev->of_node, "dmas", &len) || !len) {
+ dev_warn(dev,
+- "'dmas' DT property is missing, no HDMI audio\n");
++ "'dmas' DT property is missing or empty, no HDMI audio\n");
+ return 0;
+ }
+
--- /dev/null
+From b60cf8e59e61133b6c9514ff8d8c8d7049d040ef Mon Sep 17 00:00:00 2001
+From: Conor Dooley <conor.dooley@microchip.com>
+Date: Wed, 3 Aug 2022 19:54:00 +0100
+Subject: dt-bindings: riscv: fix SiFive l2-cache's cache-sets
+
+From: Conor Dooley <conor.dooley@microchip.com>
+
+commit b60cf8e59e61133b6c9514ff8d8c8d7049d040ef upstream.
+
+Fix device tree schema validation error messages for the SiFive
+Unmatched: ' cache-sets:0:0: 1024 was expected'.
+
+The existing bindings allow for just 1024 cache-sets but the fu740 on
+Unmatched the has 2048 cache-sets. The ISA itself permits any arbitrary
+power of two, however this is not supported by dt-schema. The RTL for
+the IP, to which the number of cache-sets is a tunable parameter, has
+been released publicly so speculatively adding a small number of
+"reasonable" values seems unwise also.
+
+Instead, as the binding only supports two distinct controllers: add 2048
+and explicitly lock it to the fu740's l2 cache while limiting 1024 to
+the l2 cache on the fu540.
+
+Fixes: af951c3a113b ("dt-bindings: riscv: Update l2 cache DT documentation to add support for SiFive FU740")
+Reported-by: Atul Khare <atulkhare@rivosinc.com>
+Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
+Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20220803185359.942928-1-mail@conchuod.ie
+Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
++++ b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
+@@ -47,7 +47,7 @@ properties:
+ const: 2
+
+ cache-sets:
+- const: 1024
++ enum: [1024, 2048]
+
+ cache-size:
+ const: 2097152
+@@ -85,6 +85,8 @@ then:
+ description: |
+ Must contain entries for DirError, DataError and DataFail signals.
+ maxItems: 3
++ cache-sets:
++ const: 1024
+
+ else:
+ properties:
+@@ -92,6 +94,8 @@ else:
+ description: |
+ Must contain entries for DirError, DataError, DataFail, DirFail signals.
+ minItems: 4
++ cache-sets:
++ const: 2048
+
+ additionalProperties: false
+
--- /dev/null
+From cf59f34d7f978d14d6520fd80a78a5ad5cb8abf8 Mon Sep 17 00:00:00 2001
+From: William Dean <williamsukatube@gmail.com>
+Date: Fri, 22 Jul 2022 10:57:09 +0800
+Subject: parisc: Check the return value of ioremap() in lba_driver_probe()
+
+From: William Dean <williamsukatube@gmail.com>
+
+commit cf59f34d7f978d14d6520fd80a78a5ad5cb8abf8 upstream.
+
+The function ioremap() in lba_driver_probe() can fail, so
+its return value should be checked.
+
+Fixes: 4bdc0d676a643 ("remove ioremap_nocache and devm_ioremap_nocache")
+Reported-by: Hacash Robot <hacashRobot@santino.com>
+Signed-off-by: William Dean <williamsukatube@gmail.com>
+Signed-off-by: Helge Deller <deller@gmx.de>
+Cc: <stable@vger.kernel.org> # v5.6+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/parisc/lba_pci.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/drivers/parisc/lba_pci.c
++++ b/drivers/parisc/lba_pci.c
+@@ -1476,9 +1476,13 @@ lba_driver_probe(struct parisc_device *d
+ u32 func_class;
+ void *tmp_obj;
+ char *version;
+- void __iomem *addr = ioremap(dev->hpa.start, 4096);
++ void __iomem *addr;
+ int max;
+
++ addr = ioremap(dev->hpa.start, 4096);
++ if (addr == NULL)
++ return -ENOMEM;
++
+ /* Read HW Rev First */
+ func_class = READ_REG32(addr + LBA_FCLASS);
+
--- /dev/null
+From 3fbc9a7de0564c55d8a9584c9cd2c9dfe6bd6d43 Mon Sep 17 00:00:00 2001
+From: Helge Deller <deller@gmx.de>
+Date: Tue, 19 Jul 2022 06:19:41 +0200
+Subject: parisc: Drop pa_swapper_pg_lock spinlock
+
+From: Helge Deller <deller@gmx.de>
+
+commit 3fbc9a7de0564c55d8a9584c9cd2c9dfe6bd6d43 upstream.
+
+This spinlock was dropped with commit b7795074a046 ("parisc: Optimize
+per-pagetable spinlocks") in kernel v5.12.
+
+Remove it to silence a sparse warning.
+
+Signed-off-by: Helge Deller <deller@gmx.de>
+Reported-by: kernel test robot <lkp@intel.com>
+Cc: <stable@vger.kernel.org> # v5.12+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/parisc/kernel/cache.c | 3 ---
+ 1 file changed, 3 deletions(-)
+
+--- a/arch/parisc/kernel/cache.c
++++ b/arch/parisc/kernel/cache.c
+@@ -46,9 +46,6 @@ void flush_icache_page_asm(unsigned long
+ */
+ DEFINE_SPINLOCK(pa_tlb_flush_lock);
+
+-/* Swapper page setup lock. */
+-DEFINE_SPINLOCK(pa_swapper_pg_lock);
+-
+ #if defined(CONFIG_64BIT) && defined(CONFIG_SMP)
+ int pa_serialize_tlb_flushes __ro_after_init;
+ #endif
--- /dev/null
+From cab56b51ec0e69128909cef4650e1907248d821b Mon Sep 17 00:00:00 2001
+From: Helge Deller <deller@gmx.de>
+Date: Mon, 18 Jul 2022 17:06:47 +0200
+Subject: parisc: Fix device names in /proc/iomem
+
+From: Helge Deller <deller@gmx.de>
+
+commit cab56b51ec0e69128909cef4650e1907248d821b upstream.
+
+Fix the output of /proc/iomem to show the real hardware device name
+including the pa_pathname, e.g. "Merlin 160 Core Centronics [8:16:0]".
+Up to now only the pa_pathname ("[8:16.0]") was shown.
+
+Signed-off-by: Helge Deller <deller@gmx.de>
+Cc: <stable@vger.kernel.org> # v4.9+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/parisc/kernel/drivers.c | 9 ++++-----
+ 1 file changed, 4 insertions(+), 5 deletions(-)
+
+--- a/arch/parisc/kernel/drivers.c
++++ b/arch/parisc/kernel/drivers.c
+@@ -520,7 +520,6 @@ alloc_pa_dev(unsigned long hpa, struct h
+ dev->id.hversion_rev = iodc_data[1] & 0x0f;
+ dev->id.sversion = ((iodc_data[4] & 0x0f) << 16) |
+ (iodc_data[5] << 8) | iodc_data[6];
+- dev->hpa.name = parisc_pathname(dev);
+ dev->hpa.start = hpa;
+ /* This is awkward. The STI spec says that gfx devices may occupy
+ * 32MB or 64MB. Unfortunately, we don't know how to tell whether
+@@ -534,10 +533,10 @@ alloc_pa_dev(unsigned long hpa, struct h
+ dev->hpa.end = hpa + 0xfff;
+ }
+ dev->hpa.flags = IORESOURCE_MEM;
+- name = parisc_hardware_description(&dev->id);
+- if (name) {
+- strlcpy(dev->name, name, sizeof(dev->name));
+- }
++ dev->hpa.name = dev->name;
++ name = parisc_hardware_description(&dev->id) ? : "unknown";
++ snprintf(dev->name, sizeof(dev->name), "%s [%s]",
++ name, parisc_pathname(dev));
+
+ /* Silently fail things like mouse ports which are subsumed within
+ * the keyboard controller
--- /dev/null
+From 6431e92fc827bdd2d28f79150d90415ba9ce0d21 Mon Sep 17 00:00:00 2001
+From: Helge Deller <deller@gmx.de>
+Date: Mon, 1 Aug 2022 17:36:15 +0200
+Subject: parisc: io_pgetevents_time64() needs compat syscall in 32-bit compat mode
+
+From: Helge Deller <deller@gmx.de>
+
+commit 6431e92fc827bdd2d28f79150d90415ba9ce0d21 upstream.
+
+For all syscalls in 32-bit compat mode on 64-bit kernels the upper
+32-bits of the 64-bit registers are zeroed out, so a negative 32-bit
+signed value will show up as positive 64-bit signed value.
+
+This behaviour breaks the io_pgetevents_time64() syscall which expects
+signed 64-bit values for the "min_nr" and "nr" parameters.
+Fix this by switching to the compat_sys_io_pgetevents_time64() syscall,
+which uses "compat_long_t" types for those parameters.
+
+Cc: <stable@vger.kernel.org> # v5.1+
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/parisc/kernel/syscalls/syscall.tbl | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/parisc/kernel/syscalls/syscall.tbl
++++ b/arch/parisc/kernel/syscalls/syscall.tbl
+@@ -413,7 +413,7 @@
+ 412 32 utimensat_time64 sys_utimensat sys_utimensat
+ 413 32 pselect6_time64 sys_pselect6 compat_sys_pselect6_time64
+ 414 32 ppoll_time64 sys_ppoll compat_sys_ppoll_time64
+-416 32 io_pgetevents_time64 sys_io_pgetevents sys_io_pgetevents
++416 32 io_pgetevents_time64 sys_io_pgetevents compat_sys_io_pgetevents_time64
+ 417 32 recvmmsg_time64 sys_recvmmsg compat_sys_recvmmsg_time64
+ 418 32 mq_timedsend_time64 sys_mq_timedsend sys_mq_timedsend
+ 419 32 mq_timedreceive_time64 sys_mq_timedreceive sys_mq_timedreceive
--- /dev/null
+From f9293ad46d8ba9909187a37b7215324420ad4596 Mon Sep 17 00:00:00 2001
+From: Xianting Tian <xianting.tian@linux.alibaba.com>
+Date: Thu, 11 Aug 2022 15:41:48 +0800
+Subject: RISC-V: Add modules to virtual kernel memory layout dump
+
+From: Xianting Tian <xianting.tian@linux.alibaba.com>
+
+commit f9293ad46d8ba9909187a37b7215324420ad4596 upstream.
+
+Modules always live before the kernel, MODULES_END is fixed but
+MODULES_VADDR isn't fixed, it depends on the kernel size.
+Let's add it to virtual kernel memory layout dump.
+
+As MODULES is only defined for CONFIG_64BIT, so we dump it when
+CONFIG_64BIT=y.
+
+eg,
+MODULES_VADDR - MODULES_END
+0xffffffff01133000 - 0xffffffff80000000
+
+Reviewed-by: Guo Ren <guoren@kernel.org>
+Reviewed-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
+Link: https://lore.kernel.org/r/20220811074150.3020189-5-xianting.tian@linux.alibaba.com
+Cc: stable@vger.kernel.org
+Fixes: 2bfc6cd81bd1 ("riscv: Move kernel mapping outside of linear mapping")
+Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/riscv/mm/init.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/arch/riscv/mm/init.c
++++ b/arch/riscv/mm/init.c
+@@ -100,6 +100,10 @@ static void __init print_vm_layout(void)
+ (unsigned long)VMEMMAP_END);
+ print_mlm("vmalloc", (unsigned long)VMALLOC_START,
+ (unsigned long)VMALLOC_END);
++#ifdef CONFIG_64BIT
++ print_mlm("modules", (unsigned long)MODULES_VADDR,
++ (unsigned long)MODULES_END);
++#endif
+ print_mlm("lowmem", (unsigned long)PAGE_OFFSET,
+ (unsigned long)high_memory);
+ #ifdef CONFIG_64BIT
--- /dev/null
+From 59c026c359c30f116fef6ee958e24d04983efbb0 Mon Sep 17 00:00:00 2001
+From: Xianting Tian <xianting.tian@linux.alibaba.com>
+Date: Thu, 11 Aug 2022 15:41:46 +0800
+Subject: RISC-V: Fixup get incorrect user mode PC for kernel mode regs
+
+From: Xianting Tian <xianting.tian@linux.alibaba.com>
+
+commit 59c026c359c30f116fef6ee958e24d04983efbb0 upstream.
+
+When use 'echo c > /proc/sysrq-trigger' to trigger kdump, riscv_crash_save_regs()
+will be called to save regs for vmcore, we found "epc" value 00ffffffa5537400
+is not a valid kernel virtual address, but is a user virtual address. Other
+regs(eg, ra, sp, gp...) are correct kernel virtual address.
+Actually 0x00ffffffb0dd9400 is the user mode PC of 'PID: 113 Comm: sh', which
+is saved in the task's stack.
+
+[ 21.201701] CPU: 0 PID: 113 Comm: sh Kdump: loaded Not tainted 5.18.9 #45
+[ 21.201979] Hardware name: riscv-virtio,qemu (DT)
+[ 21.202160] epc : 00ffffffa5537400 ra : ffffffff80088640 sp : ff20000010333b90
+[ 21.202435] gp : ffffffff810dde38 tp : ff6000000226c200 t0 : ffffffff8032be7c
+[ 21.202707] t1 : 0720072007200720 t2 : 30203a7375746174 s0 : ff20000010333cf0
+[ 21.202973] s1 : 0000000000000000 a0 : ff20000010333b98 a1 : 0000000000000001
+[ 21.203243] a2 : 0000000000000010 a3 : 0000000000000000 a4 : 28c8f0aeffea4e00
+[ 21.203519] a5 : 28c8f0aeffea4e00 a6 : 0000000000000009 a7 : ffffffff8035c9b8
+[ 21.203794] s2 : ffffffff810df0a8 s3 : ffffffff810df718 s4 : ff20000010333b98
+[ 21.204062] s5 : 0000000000000000 s6 : 0000000000000007 s7 : ffffffff80c4a468
+[ 21.204331] s8 : 00ffffffef451410 s9 : 0000000000000007 s10: 00aaaaaac0510700
+[ 21.204606] s11: 0000000000000001 t3 : ff60000001218f00 t4 : ff60000001218f00
+[ 21.204876] t5 : ff60000001218000 t6 : ff200000103338b8
+[ 21.205079] status: 0000000200000020 badaddr: 0000000000000000 cause: 0000000000000008
+
+With the incorrect PC, the backtrace showed by crash tool as below, the first
+stack frame is abnormal,
+
+crash> bt
+PID: 113 TASK: ff60000002269600 CPU: 0 COMMAND: "sh"
+ #0 [ff2000001039bb90] __efistub_.Ldebug_info0 at 00ffffffa5537400 <-- Abnormal
+ #1 [ff2000001039bcf0] panic at ffffffff806578ba
+ #2 [ff2000001039bd50] sysrq_reset_seq_param_set at ffffffff8038c030
+ #3 [ff2000001039bda0] __handle_sysrq at ffffffff8038c5f8
+ #4 [ff2000001039be00] write_sysrq_trigger at ffffffff8038cad8
+ #5 [ff2000001039be20] proc_reg_write at ffffffff801b7edc
+ #6 [ff2000001039be40] vfs_write at ffffffff80152ba6
+ #7 [ff2000001039be80] ksys_write at ffffffff80152ece
+ #8 [ff2000001039bed0] sys_write at ffffffff80152f46
+
+With the patch, we can get current kernel mode PC, the output as below,
+
+[ 17.607658] CPU: 0 PID: 113 Comm: sh Kdump: loaded Not tainted 5.18.9 #42
+[ 17.607937] Hardware name: riscv-virtio,qemu (DT)
+[ 17.608150] epc : ffffffff800078f8 ra : ffffffff8008862c sp : ff20000010333b90
+[ 17.608441] gp : ffffffff810dde38 tp : ff6000000226c200 t0 : ffffffff8032be68
+[ 17.608741] t1 : 0720072007200720 t2 : 666666666666663c s0 : ff20000010333cf0
+[ 17.609025] s1 : 0000000000000000 a0 : ff20000010333b98 a1 : 0000000000000001
+[ 17.609320] a2 : 0000000000000010 a3 : 0000000000000000 a4 : 0000000000000000
+[ 17.609601] a5 : ff60000001c78000 a6 : 000000000000003c a7 : ffffffff8035c9a4
+[ 17.609894] s2 : ffffffff810df0a8 s3 : ffffffff810df718 s4 : ff20000010333b98
+[ 17.610186] s5 : 0000000000000000 s6 : 0000000000000007 s7 : ffffffff80c4a468
+[ 17.610469] s8 : 00ffffffca281410 s9 : 0000000000000007 s10: 00aaaaaab5bb6700
+[ 17.610755] s11: 0000000000000001 t3 : ff60000001218f00 t4 : ff60000001218f00
+[ 17.611041] t5 : ff60000001218000 t6 : ff20000010333988
+[ 17.611255] status: 0000000200000020 badaddr: 0000000000000000 cause: 0000000000000008
+
+With the correct PC, the backtrace showed by crash tool as below,
+
+crash> bt
+PID: 113 TASK: ff6000000226c200 CPU: 0 COMMAND: "sh"
+ #0 [ff20000010333b90] riscv_crash_save_regs at ffffffff800078f8 <--- Normal
+ #1 [ff20000010333cf0] panic at ffffffff806578c6
+ #2 [ff20000010333d50] sysrq_reset_seq_param_set at ffffffff8038c03c
+ #3 [ff20000010333da0] __handle_sysrq at ffffffff8038c604
+ #4 [ff20000010333e00] write_sysrq_trigger at ffffffff8038cae4
+ #5 [ff20000010333e20] proc_reg_write at ffffffff801b7ee8
+ #6 [ff20000010333e40] vfs_write at ffffffff80152bb2
+ #7 [ff20000010333e80] ksys_write at ffffffff80152eda
+ #8 [ff20000010333ed0] sys_write at ffffffff80152f52
+
+Fixes: e53d28180d4d ("RISC-V: Add kdump support")
+Co-developed-by: Guo Ren <guoren@kernel.org>
+Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
+Link: https://lore.kernel.org/r/20220811074150.3020189-3-xianting.tian@linux.alibaba.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/riscv/kernel/crash_save_regs.S | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/riscv/kernel/crash_save_regs.S b/arch/riscv/kernel/crash_save_regs.S
+index 7832fb763aba..b2a1908c0463 100644
+--- a/arch/riscv/kernel/crash_save_regs.S
++++ b/arch/riscv/kernel/crash_save_regs.S
+@@ -44,7 +44,7 @@ SYM_CODE_START(riscv_crash_save_regs)
+ REG_S t6, PT_T6(a0) /* x31 */
+
+ csrr t1, CSR_STATUS
+- csrr t2, CSR_EPC
++ auipc t2, 0x0
+ csrr t3, CSR_TVAL
+ csrr t4, CSR_CAUSE
+
+--
+2.37.1
+
--- /dev/null
+From ad943893d5f1d0aeea892bf7b781cf8062b36d58 Mon Sep 17 00:00:00 2001
+From: Xianting Tian <xianting.tian@linux.alibaba.com>
+Date: Thu, 11 Aug 2022 15:41:47 +0800
+Subject: RISC-V: Fixup schedule out issue in machine_crash_shutdown()
+
+From: Xianting Tian <xianting.tian@linux.alibaba.com>
+
+commit ad943893d5f1d0aeea892bf7b781cf8062b36d58 upstream.
+
+Current task of executing crash kexec will be schedule out when panic is
+triggered by RCU Stall, as it needs to wait rcu completion. It lead to
+inability to enter the crash system.
+
+The implementation of machine_crash_shutdown() is non-standard for RISC-V
+according to other Arch's implementation(eg, x86, arm64), we need to send
+IPI to stop secondary harts.
+
+[224521.877268] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
+[224521.883471] rcu: 0-...0: (3 GPs behind) idle=cfa/0/0x1 softirq=3968793/3968793 fqs=2495
+[224521.891742] (detected by 2, t=5255 jiffies, g=60855593, q=328)
+[224521.897754] Task dump for CPU 0:
+[224521.901074] task:swapper/0 state:R running task stack: 0 pid: 0 ppid: 0 flags:0x00000008
+[224521.911090] Call Trace:
+[224521.913638] [<ffffffe000c432de>] __schedule+0x208/0x5ea
+[224521.918957] Kernel panic - not syncing: RCU Stall
+[224521.923773] bad: scheduling from the idle thread!
+[224521.928571] CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Tainted: G O 5.10.113-yocto-standard #1
+[224521.938658] Call Trace:
+[224521.941200] [<ffffffe00020395c>] walk_stackframe+0x0/0xaa
+[224521.946689] [<ffffffe000c34f8e>] show_stack+0x32/0x3e
+[224521.951830] [<ffffffe000c39020>] dump_stack_lvl+0x7e/0xa2
+[224521.957317] [<ffffffe000c39058>] dump_stack+0x14/0x1c
+[224521.962459] [<ffffffe000243884>] dequeue_task_idle+0x2c/0x40
+[224521.968207] [<ffffffe000c434f4>] __schedule+0x41e/0x5ea
+[224521.973520] [<ffffffe000c43826>] schedule+0x34/0xe4
+[224521.978487] [<ffffffe000c46cae>] schedule_timeout+0xc6/0x170
+[224521.984234] [<ffffffe000c4491e>] wait_for_completion+0x98/0xf2
+[224521.990157] [<ffffffe00026d9e2>] __wait_rcu_gp+0x148/0x14a
+[224521.995733] [<ffffffe0002761c4>] synchronize_rcu+0x5c/0x66
+[224522.001307] [<ffffffe00026f1a6>] rcu_sync_enter+0x54/0xe6
+[224522.006795] [<ffffffe00025a436>] percpu_down_write+0x32/0x11c
+[224522.012629] [<ffffffe000c4266a>] _cpu_down+0x92/0x21a
+[224522.017771] [<ffffffe000219a0a>] smp_shutdown_nonboot_cpus+0x90/0x118
+[224522.024299] [<ffffffe00020701e>] machine_crash_shutdown+0x30/0x4a
+[224522.030483] [<ffffffe00029a3f8>] __crash_kexec+0x62/0xa6
+[224522.035884] [<ffffffe000c3515e>] panic+0xfa/0x2b6
+[224522.040678] [<ffffffe0002772be>] rcu_sched_clock_irq+0xc26/0xcb8
+[224522.046774] [<ffffffe00027fc7a>] update_process_times+0x62/0x8a
+[224522.052785] [<ffffffe00028d522>] tick_sched_timer+0x9e/0x102
+[224522.058533] [<ffffffe000280c3a>] __hrtimer_run_queues+0x16a/0x318
+[224522.064716] [<ffffffe0002812ec>] hrtimer_interrupt+0xd4/0x228
+[224522.070551] [<ffffffe0009a69b6>] riscv_timer_interrupt+0x3c/0x48
+[224522.076646] [<ffffffe000268f8c>] handle_percpu_devid_irq+0xb0/0x24c
+[224522.083004] [<ffffffe00026428e>] __handle_domain_irq+0xa8/0x122
+[224522.089014] [<ffffffe00062f954>] riscv_intc_irq+0x38/0x60
+[224522.094501] [<ffffffe000201bd4>] ret_from_exception+0x0/0xc
+[224522.100161] [<ffffffe000c42146>] rcu_eqs_enter.constprop.0+0x8c/0xb8
+
+With the patch, it can enter crash system when RCU Stall occur.
+
+Fixes: e53d28180d4d ("RISC-V: Add kdump support")
+Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
+Link: https://lore.kernel.org/r/20220811074150.3020189-4-xianting.tian@linux.alibaba.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/riscv/kernel/machine_kexec.c | 26 ++++++++++++++++++++++----
+ 1 file changed, 22 insertions(+), 4 deletions(-)
+
+diff --git a/arch/riscv/kernel/machine_kexec.c b/arch/riscv/kernel/machine_kexec.c
+index 86d1b5f9dfb5..ee79e6839b86 100644
+--- a/arch/riscv/kernel/machine_kexec.c
++++ b/arch/riscv/kernel/machine_kexec.c
+@@ -138,19 +138,37 @@ void machine_shutdown(void)
+ #endif
+ }
+
++/* Override the weak function in kernel/panic.c */
++void crash_smp_send_stop(void)
++{
++ static int cpus_stopped;
++
++ /*
++ * This function can be called twice in panic path, but obviously
++ * we execute this only once.
++ */
++ if (cpus_stopped)
++ return;
++
++ smp_send_stop();
++ cpus_stopped = 1;
++}
++
+ /*
+ * machine_crash_shutdown - Prepare to kexec after a kernel crash
+ *
+ * This function is called by crash_kexec just before machine_kexec
+- * below and its goal is similar to machine_shutdown, but in case of
+- * a kernel crash. Since we don't handle such cases yet, this function
+- * is empty.
++ * and its goal is to shutdown non-crashing cpus and save registers.
+ */
+ void
+ machine_crash_shutdown(struct pt_regs *regs)
+ {
++ local_irq_disable();
++
++ /* shutdown non-crashing cpus */
++ crash_smp_send_stop();
++
+ crash_save_cpu(regs, smp_processor_id());
+- machine_shutdown();
+ pr_info("Starting crashdump kernel...\n");
+ }
+
+--
+2.37.1
+
--- /dev/null
+From 357628e68f5c08ad578a718dc62a0031e06dbe91 Mon Sep 17 00:00:00 2001
+From: Xianting Tian <xianting.tian@linux.alibaba.com>
+Date: Thu, 11 Aug 2022 15:41:45 +0800
+Subject: RISC-V: kexec: Fixup use of smp_processor_id() in preemptible context
+
+From: Xianting Tian <xianting.tian@linux.alibaba.com>
+
+commit 357628e68f5c08ad578a718dc62a0031e06dbe91 upstream.
+
+Use __smp_processor_id() to avoid check the preemption context when
+CONFIG_DEBUG_PREEMPT enabled, as we will enter crash kernel and no
+return.
+
+Without the patch,
+[ 103.781044] sysrq: Trigger a crash
+[ 103.784625] Kernel panic - not syncing: sysrq triggered crash
+[ 103.837634] CPU1: off
+[ 103.889668] CPU2: off
+[ 103.933479] CPU3: off
+[ 103.939424] Starting crashdump kernel...
+[ 103.943442] BUG: using smp_processor_id() in preemptible [00000000] code: sh/346
+[ 103.950884] caller is debug_smp_processor_id+0x1c/0x26
+[ 103.956051] CPU: 0 PID: 346 Comm: sh Kdump: loaded Not tainted 5.10.113-00002-gce03f03bf4ec-dirty #149
+[ 103.965355] Call Trace:
+[ 103.967805] [<ffffffe00020372a>] walk_stackframe+0x0/0xa2
+[ 103.973206] [<ffffffe000bcf1f4>] show_stack+0x32/0x3e
+[ 103.978258] [<ffffffe000bd382a>] dump_stack_lvl+0x72/0x8e
+[ 103.983655] [<ffffffe000bd385a>] dump_stack+0x14/0x1c
+[ 103.988705] [<ffffffe000bdc8fe>] check_preemption_disabled+0x9e/0xaa
+[ 103.995057] [<ffffffe000bdc926>] debug_smp_processor_id+0x1c/0x26
+[ 104.001150] [<ffffffe000206c64>] machine_kexec+0x22/0xd0
+[ 104.006463] [<ffffffe000291a7e>] __crash_kexec+0x6a/0xa4
+[ 104.011774] [<ffffffe000bcf3fa>] panic+0xfc/0x2b0
+[ 104.016480] [<ffffffe000656ca4>] sysrq_reset_seq_param_set+0x0/0x70
+[ 104.022745] [<ffffffe000657310>] __handle_sysrq+0x8c/0x154
+[ 104.028229] [<ffffffe0006577e8>] write_sysrq_trigger+0x5a/0x6a
+[ 104.034061] [<ffffffe0003d90e0>] proc_reg_write+0x58/0xd4
+[ 104.039459] [<ffffffe00036cff4>] vfs_write+0x7e/0x254
+[ 104.044509] [<ffffffe00036d2f6>] ksys_write+0x58/0xbe
+[ 104.049558] [<ffffffe00036d36a>] sys_write+0xe/0x16
+[ 104.054434] [<ffffffe000201b9a>] ret_from_syscall+0x0/0x2
+[ 104.067863] Will call new kernel at ecc00000 from hart id 0
+[ 104.074939] FDT image at fc5ee000
+[ 104.079523] Bye...
+
+With the patch we can got clear output,
+[ 67.740553] sysrq: Trigger a crash
+[ 67.744166] Kernel panic - not syncing: sysrq triggered crash
+[ 67.809123] CPU1: off
+[ 67.865210] CPU2: off
+[ 67.909075] CPU3: off
+[ 67.919123] Starting crashdump kernel...
+[ 67.924900] Will call new kernel at ecc00000 from hart id 0
+[ 67.932045] FDT image at fc5ee000
+[ 67.935560] Bye...
+
+Fixes: 0e105f1d0037 ("riscv: use hart id instead of cpu id on machine_kexec")
+Reviewed-by: Guo Ren <guoren@kernel.org>
+Reviewed-by: Heiko Stuebner <heiko@sntech.de>
+Reviewed-by: Atish Patra <atishp@rivosinc.com>
+Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
+Link: https://lore.kernel.org/r/20220811074150.3020189-2-xianting.tian@linux.alibaba.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/riscv/kernel/machine_kexec.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/riscv/kernel/machine_kexec.c b/arch/riscv/kernel/machine_kexec.c
+index df8e24559035..86d1b5f9dfb5 100644
+--- a/arch/riscv/kernel/machine_kexec.c
++++ b/arch/riscv/kernel/machine_kexec.c
+@@ -171,7 +171,7 @@ machine_kexec(struct kimage *image)
+ struct kimage_arch *internal = &image->arch;
+ unsigned long jump_addr = (unsigned long) image->start;
+ unsigned long first_ind_entry = (unsigned long) &image->head;
+- unsigned long this_cpu_id = smp_processor_id();
++ unsigned long this_cpu_id = __smp_processor_id();
+ unsigned long this_hart_id = cpuid_to_hartid_map(this_cpu_id);
+ unsigned long fdt_addr = internal->fdt_addr;
+ void *control_code_buffer = page_address(image->control_code_page);
+--
+2.37.1
+
--- /dev/null
+From 3dbe5829408bc1586f75b4667ef60e5aab0209c7 Mon Sep 17 00:00:00 2001
+From: Yipeng Zou <zouyipeng@huawei.com>
+Date: Thu, 21 Jul 2022 14:58:20 +0800
+Subject: riscv:uprobe fix SR_SPIE set/clear handling
+
+From: Yipeng Zou <zouyipeng@huawei.com>
+
+commit 3dbe5829408bc1586f75b4667ef60e5aab0209c7 upstream.
+
+In riscv the process of uprobe going to clear spie before exec
+the origin insn,and set spie after that.But When access the page
+which origin insn has been placed a page fault may happen and
+irq was disabled in arch_uprobe_pre_xol function,It cause a WARN
+as follows.
+There is no need to clear/set spie in arch_uprobe_pre/post/abort_xol.
+We can just remove it.
+
+[ 31.684157] BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1488
+[ 31.684677] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 76, name: work
+[ 31.684929] preempt_count: 0, expected: 0
+[ 31.685969] CPU: 2 PID: 76 Comm: work Tainted: G
+[ 31.686542] Hardware name: riscv-virtio,qemu (DT)
+[ 31.686797] Call Trace:
+[ 31.687053] [<ffffffff80006442>] dump_backtrace+0x30/0x38
+[ 31.687699] [<ffffffff80812118>] show_stack+0x40/0x4c
+[ 31.688141] [<ffffffff8081817a>] dump_stack_lvl+0x44/0x5c
+[ 31.688396] [<ffffffff808181aa>] dump_stack+0x18/0x20
+[ 31.688653] [<ffffffff8003e454>] __might_resched+0x114/0x122
+[ 31.688948] [<ffffffff8003e4b2>] __might_sleep+0x50/0x7a
+[ 31.689435] [<ffffffff80822676>] down_read+0x30/0x130
+[ 31.689728] [<ffffffff8000b650>] do_page_fault+0x166/x446
+[ 31.689997] [<ffffffff80003c0c>] ret_from_exception+0x0/0xc
+
+Fixes: 74784081aac8 ("riscv: Add uprobes supported")
+Signed-off-by: Yipeng Zou <zouyipeng@huawei.com>
+Reviewed-by: Guo Ren <guoren@kernel.org>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20220721065820.245755-1-zouyipeng@huawei.com
+Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/riscv/kernel/probes/uprobes.c | 6 ------
+ 1 file changed, 6 deletions(-)
+
+--- a/arch/riscv/kernel/probes/uprobes.c
++++ b/arch/riscv/kernel/probes/uprobes.c
+@@ -59,8 +59,6 @@ int arch_uprobe_pre_xol(struct arch_upro
+
+ instruction_pointer_set(regs, utask->xol_vaddr);
+
+- regs->status &= ~SR_SPIE;
+-
+ return 0;
+ }
+
+@@ -72,8 +70,6 @@ int arch_uprobe_post_xol(struct arch_upr
+
+ instruction_pointer_set(regs, utask->vaddr + auprobe->insn_size);
+
+- regs->status |= SR_SPIE;
+-
+ return 0;
+ }
+
+@@ -111,8 +107,6 @@ void arch_uprobe_abort_xol(struct arch_u
+ * address.
+ */
+ instruction_pointer_set(regs, utask->vaddr);
+-
+- regs->status &= ~SR_SPIE;
+ }
+
+ bool arch_uretprobe_is_alive(struct return_instance *ret, enum rp_check ctx,
--- /dev/null
+From 71af91565052214ad86f288e0d8ffb165f790995 Mon Sep 17 00:00:00 2001
+From: Mathew McBride <matt@traverse.com.au>
+Date: Wed, 6 Jul 2022 07:42:36 +0000
+Subject: rtc: rx8025: fix 12/24 hour mode detection on RX-8035
+
+From: Mathew McBride <matt@traverse.com.au>
+
+commit 71af91565052214ad86f288e0d8ffb165f790995 upstream.
+
+The 12/24hr flag in the RX-8035 can be found in the hour register,
+instead of the CTRL1 on the RX-8025. This was overlooked when
+support for the RX-8035 was added, and was causing read errors when
+the hour register 'overflowed'.
+
+To deal with the relevant register not always being visible in
+the relevant functions, determine the 12/24 mode at startup and
+store it in the driver state.
+
+Signed-off-by: Mathew McBride <matt@traverse.com.au>
+Fixes: f120e2e33ac8 ("rtc: rx8025: implement RX-8035 support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
+Link: https://lore.kernel.org/r/20220706074236.24011-1-matt@traverse.com.au
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/rtc/rtc-rx8025.c | 22 ++++++++++++++++++----
+ 1 file changed, 18 insertions(+), 4 deletions(-)
+
+--- a/drivers/rtc/rtc-rx8025.c
++++ b/drivers/rtc/rtc-rx8025.c
+@@ -55,6 +55,8 @@
+ #define RX8025_BIT_CTRL2_XST BIT(5)
+ #define RX8025_BIT_CTRL2_VDET BIT(6)
+
++#define RX8035_BIT_HOUR_1224 BIT(7)
++
+ /* Clock precision adjustment */
+ #define RX8025_ADJ_RESOLUTION 3050 /* in ppb */
+ #define RX8025_ADJ_DATA_MAX 62
+@@ -78,6 +80,7 @@ struct rx8025_data {
+ struct rtc_device *rtc;
+ enum rx_model model;
+ u8 ctrl1;
++ int is_24;
+ };
+
+ static s32 rx8025_read_reg(const struct i2c_client *client, u8 number)
+@@ -226,7 +229,7 @@ static int rx8025_get_time(struct device
+
+ dt->tm_sec = bcd2bin(date[RX8025_REG_SEC] & 0x7f);
+ dt->tm_min = bcd2bin(date[RX8025_REG_MIN] & 0x7f);
+- if (rx8025->ctrl1 & RX8025_BIT_CTRL1_1224)
++ if (rx8025->is_24)
+ dt->tm_hour = bcd2bin(date[RX8025_REG_HOUR] & 0x3f);
+ else
+ dt->tm_hour = bcd2bin(date[RX8025_REG_HOUR] & 0x1f) % 12
+@@ -257,7 +260,7 @@ static int rx8025_set_time(struct device
+ */
+ date[RX8025_REG_SEC] = bin2bcd(dt->tm_sec);
+ date[RX8025_REG_MIN] = bin2bcd(dt->tm_min);
+- if (rx8025->ctrl1 & RX8025_BIT_CTRL1_1224)
++ if (rx8025->is_24)
+ date[RX8025_REG_HOUR] = bin2bcd(dt->tm_hour);
+ else
+ date[RX8025_REG_HOUR] = (dt->tm_hour >= 12 ? 0x20 : 0)
+@@ -282,6 +285,7 @@ static int rx8025_init_client(struct i2c
+ struct rx8025_data *rx8025 = i2c_get_clientdata(client);
+ u8 ctrl[2], ctrl2;
+ int need_clear = 0;
++ int hour_reg;
+ int err;
+
+ err = rx8025_read_regs(client, RX8025_REG_CTRL1, 2, ctrl);
+@@ -306,6 +310,16 @@ static int rx8025_init_client(struct i2c
+
+ err = rx8025_write_reg(client, RX8025_REG_CTRL2, ctrl2);
+ }
++
++ if (rx8025->model == model_rx_8035) {
++ /* In RX-8035, 12/24 flag is in the hour register */
++ hour_reg = rx8025_read_reg(client, RX8025_REG_HOUR);
++ if (hour_reg < 0)
++ return hour_reg;
++ rx8025->is_24 = (hour_reg & RX8035_BIT_HOUR_1224);
++ } else {
++ rx8025->is_24 = (ctrl[1] & RX8025_BIT_CTRL1_1224);
++ }
+ out:
+ return err;
+ }
+@@ -335,7 +349,7 @@ static int rx8025_read_alarm(struct devi
+ /* Hardware alarms precision is 1 minute! */
+ t->time.tm_sec = 0;
+ t->time.tm_min = bcd2bin(ald[0] & 0x7f);
+- if (rx8025->ctrl1 & RX8025_BIT_CTRL1_1224)
++ if (rx8025->is_24)
+ t->time.tm_hour = bcd2bin(ald[1] & 0x3f);
+ else
+ t->time.tm_hour = bcd2bin(ald[1] & 0x1f) % 12
+@@ -370,7 +384,7 @@ static int rx8025_set_alarm(struct devic
+ }
+
+ ald[0] = bin2bcd(t->time.tm_min);
+- if (rx8025->ctrl1 & RX8025_BIT_CTRL1_1224)
++ if (rx8025->is_24)
+ ald[1] = bin2bcd(t->time.tm_hour);
+ else
+ ald[1] = (t->time.tm_hour >= 12 ? 0x20 : 0)
fix-short-copy-handling-in-copy_mc_pipe_to_iter.patch
crypto-ccp-use-kzalloc-for-sev-ioctl-interfaces-to-prevent-kernel-memory-leak.patch
ovl-drop-warn_on-dentry-is-null-in-ovl_encode_fh.patch
+parisc-fix-device-names-in-proc-iomem.patch
+parisc-drop-pa_swapper_pg_lock-spinlock.patch
+parisc-check-the-return-value-of-ioremap-in-lba_driver_probe.patch
+parisc-io_pgetevents_time64-needs-compat-syscall-in-32-bit-compat-mode.patch
+riscv-uprobe-fix-sr_spie-set-clear-handling.patch
+dt-bindings-riscv-fix-sifive-l2-cache-s-cache-sets.patch
+risc-v-kexec-fixup-use-of-smp_processor_id-in-preemptible-context.patch
+risc-v-fixup-get-incorrect-user-mode-pc-for-kernel-mode-regs.patch
+risc-v-fixup-schedule-out-issue-in-machine_crash_shutdown.patch
+risc-v-add-modules-to-virtual-kernel-memory-layout-dump.patch
+rtc-rx8025-fix-12-24-hour-mode-detection-on-rx-8035.patch
+drm-gem-properly-annotate-ww-context-on-drm_gem_lock_reservations-error.patch
+drm-shmem-helper-add-missing-vunmap-on-error.patch
+drm-vc4-hdmi-disable-audio-if-dmas-property-is-present-but-empty.patch
+drm-hyperv-drm-include-framebuffer-and-edid-headers.patch
+drm-nouveau-fix-another-off-by-one-in-nvbios_addr.patch
+drm-nouveau-don-t-pm_runtime_put_sync-only-pm_runtime_put_autosuspend.patch
+drm-nouveau-acpi-don-t-print-error-when-we-get-einprogress-from-pm_runtime.patch
+drm-nouveau-kms-fix-failure-path-for-creating-dp-connectors.patch
+drm-amdgpu-check-bo-s-requested-pinning-domains-against-its-preferred_domains.patch
+drm-amdgpu-fix-check-in-fbdev-init.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
