]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
5.10-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sat, 13 Aug 2022 12:57:05 +0000 (14:57 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sat, 13 Aug 2022 12:57:05 +0000 (14:57 +0200)
added patches:
drm-amdgpu-check-bo-s-requested-pinning-domains-against-its-preferred_domains.patch
drm-gem-properly-annotate-ww-context-on-drm_gem_lock_reservations-error.patch
drm-nouveau-acpi-don-t-print-error-when-we-get-einprogress-from-pm_runtime.patch
drm-nouveau-don-t-pm_runtime_put_sync-only-pm_runtime_put_autosuspend.patch
drm-nouveau-fix-another-off-by-one-in-nvbios_addr.patch
drm-vc4-hdmi-disable-audio-if-dmas-property-is-present-but-empty.patch
parisc-check-the-return-value-of-ioremap-in-lba_driver_probe.patch
parisc-fix-device-names-in-proc-iomem.patch
parisc-io_pgetevents_time64-needs-compat-syscall-in-32-bit-compat-mode.patch

queue-5.10/drm-amdgpu-check-bo-s-requested-pinning-domains-against-its-preferred_domains.patch [new file with mode: 0644]
queue-5.10/drm-gem-properly-annotate-ww-context-on-drm_gem_lock_reservations-error.patch [new file with mode: 0644]
queue-5.10/drm-nouveau-acpi-don-t-print-error-when-we-get-einprogress-from-pm_runtime.patch [new file with mode: 0644]
queue-5.10/drm-nouveau-don-t-pm_runtime_put_sync-only-pm_runtime_put_autosuspend.patch [new file with mode: 0644]
queue-5.10/drm-nouveau-fix-another-off-by-one-in-nvbios_addr.patch [new file with mode: 0644]
queue-5.10/drm-vc4-hdmi-disable-audio-if-dmas-property-is-present-but-empty.patch [new file with mode: 0644]
queue-5.10/parisc-check-the-return-value-of-ioremap-in-lba_driver_probe.patch [new file with mode: 0644]
queue-5.10/parisc-fix-device-names-in-proc-iomem.patch [new file with mode: 0644]
queue-5.10/parisc-io_pgetevents_time64-needs-compat-syscall-in-32-bit-compat-mode.patch [new file with mode: 0644]
queue-5.10/series

diff --git a/queue-5.10/drm-amdgpu-check-bo-s-requested-pinning-domains-against-its-preferred_domains.patch b/queue-5.10/drm-amdgpu-check-bo-s-requested-pinning-domains-against-its-preferred_domains.patch
new file mode 100644 (file)
index 0000000..47e2e77
--- /dev/null
@@ -0,0 +1,49 @@
+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
+@@ -905,6 +905,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->prime_shared_count) {
+               if (domain & AMDGPU_GEM_DOMAIN_GTT)
diff --git a/queue-5.10/drm-gem-properly-annotate-ww-context-on-drm_gem_lock_reservations-error.patch b/queue-5.10/drm-gem-properly-annotate-ww-context-on-drm_gem_lock_reservations-error.patch
new file mode 100644 (file)
index 0000000..53b18bd
--- /dev/null
@@ -0,0 +1,50 @@
+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
+@@ -1277,7 +1277,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;
+               }
+       }
+@@ -1302,7 +1302,7 @@ retry:
+                               goto retry;
+                       }
+-                      ww_acquire_done(acquire_ctx);
++                      ww_acquire_fini(acquire_ctx);
+                       return ret;
+               }
+       }
diff --git a/queue-5.10/drm-nouveau-acpi-don-t-print-error-when-we-get-einprogress-from-pm_runtime.patch b/queue-5.10/drm-nouveau-acpi-don-t-print-error-when-we-get-einprogress-from-pm_runtime.patch
new file mode 100644 (file)
index 0000000..6f41613
--- /dev/null
@@ -0,0 +1,32 @@
+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
+@@ -543,7 +543,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
diff --git a/queue-5.10/drm-nouveau-don-t-pm_runtime_put_sync-only-pm_runtime_put_autosuspend.patch b/queue-5.10/drm-nouveau-don-t-pm_runtime_put_sync-only-pm_runtime_put_autosuspend.patch
new file mode 100644 (file)
index 0000000..b09c7a1
--- /dev/null
@@ -0,0 +1,54 @@
+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
+@@ -521,7 +521,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
+@@ -464,7 +464,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);
+       }
+ }
diff --git a/queue-5.10/drm-nouveau-fix-another-off-by-one-in-nvbios_addr.patch b/queue-5.10/drm-nouveau-fix-another-off-by-one-in-nvbios_addr.patch
new file mode 100644 (file)
index 0000000..a3edec8
--- /dev/null
@@ -0,0 +1,35 @@
+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;
+       }
diff --git a/queue-5.10/drm-vc4-hdmi-disable-audio-if-dmas-property-is-present-but-empty.patch b/queue-5.10/drm-vc4-hdmi-disable-audio-if-dmas-property-is-present-but-empty.patch
new file mode 100644 (file)
index 0000000..7a452c5
--- /dev/null
@@ -0,0 +1,46 @@
+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
+@@ -1231,12 +1231,12 @@ static int vc4_hdmi_audio_init(struct vc
+       struct snd_soc_card *card = &vc4_hdmi->audio.card;
+       struct device *dev = &vc4_hdmi->pdev->dev;
+       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;
+       }
diff --git a/queue-5.10/parisc-check-the-return-value-of-ioremap-in-lba_driver_probe.patch b/queue-5.10/parisc-check-the-return-value-of-ioremap-in-lba_driver_probe.patch
new file mode 100644 (file)
index 0000000..38a8105
--- /dev/null
@@ -0,0 +1,39 @@
+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);
diff --git a/queue-5.10/parisc-fix-device-names-in-proc-iomem.patch b/queue-5.10/parisc-fix-device-names-in-proc-iomem.patch
new file mode 100644 (file)
index 0000000..fba1ddb
--- /dev/null
@@ -0,0 +1,45 @@
+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
+@@ -521,7 +521,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
+@@ -535,10 +534,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
diff --git a/queue-5.10/parisc-io_pgetevents_time64-needs-compat-syscall-in-32-bit-compat-mode.patch b/queue-5.10/parisc-io_pgetevents_time64-needs-compat-syscall-in-32-bit-compat-mode.patch
new file mode 100644 (file)
index 0000000..81785be
--- /dev/null
@@ -0,0 +1,36 @@
+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
index 161a697cea84f08f6967c01285e1e4b621cb87e9..66cbcf779c16043ba4c707654815f345b47e0a29 100644 (file)
@@ -36,3 +36,12 @@ fbcon-fix-boundary-checks-for-fbcon-vc-n1-n2-parameters.patch
 fbcon-fix-accelerated-fbdev-scrolling-while-logo-is-still-shown.patch
 usbnet-fix-linkwatch-use-after-free-on-disconnect.patch
 ovl-drop-warn_on-dentry-is-null-in-ovl_encode_fh.patch
+parisc-fix-device-names-in-proc-iomem.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
+drm-gem-properly-annotate-ww-context-on-drm_gem_lock_reservations-error.patch
+drm-vc4-hdmi-disable-audio-if-dmas-property-is-present-but-empty.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-amdgpu-check-bo-s-requested-pinning-domains-against-its-preferred_domains.patch