From: Greg Kroah-Hartman Date: Sat, 13 Aug 2022 12:57:05 +0000 (+0200) Subject: 5.10-stable patches X-Git-Tag: v5.15.61~182 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=47c28669f207638272760802f2eaa6d2a3397b0a;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches 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 --- 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 index 00000000000..47e2e778be5 --- /dev/null +++ b/queue-5.10/drm-amdgpu-check-bo-s-requested-pinning-domains-against-its-preferred_domains.patch @@ -0,0 +1,49 @@ +From f5ba14043621f4afdf3ad5f92ee2d8dbebbe4340 Mon Sep 17 00:00:00 2001 +From: Leo Li +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 + +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 +Reviewed-by: Alex Deucher +Reviewed-by: Christian König +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + 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 index 00000000000..53b18bdf194 --- /dev/null +++ b/queue-5.10/drm-gem-properly-annotate-ww-context-on-drm_gem_lock_reservations-error.patch @@ -0,0 +1,50 @@ +From 2939deac1fa220bc82b89235f146df1d9b52e876 Mon Sep 17 00:00:00 2001 +From: Dmitry Osipenko +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 + +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 +Reviewed-by: Christian König +Signed-off-by: Dmitry Osipenko +Signed-off-by: Daniel Vetter +Link: https://patchwork.freedesktop.org/patch/msgid/20220630200405.1883897-2-dmitry.osipenko@collabora.com +Signed-off-by: Greg Kroah-Hartman +--- + 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 index 00000000000..6f4161351be --- /dev/null +++ b/queue-5.10/drm-nouveau-acpi-don-t-print-error-when-we-get-einprogress-from-pm_runtime.patch @@ -0,0 +1,32 @@ +From 53c26181950ddc3c8ace3c0939c89e9c4d8deeb9 Mon Sep 17 00:00:00 2001 +From: Lyude Paul +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 + +commit 53c26181950ddc3c8ace3c0939c89e9c4d8deeb9 upstream. + +Since this isn't actually a failure. + +Signed-off-by: Lyude Paul +Reviewed-by: David Airlie +Fixes: 79e765ad665d ("drm/nouveau/drm/nouveau: Prevent handling ACPI HPD events too early") +Cc: # v4.19+ +Link: https://patchwork.freedesktop.org/patch/msgid/20220714174234.949259-2-lyude@redhat.com +Signed-off-by: Greg Kroah-Hartman +--- + 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 index 00000000000..b09c7a11223 --- /dev/null +++ b/queue-5.10/drm-nouveau-don-t-pm_runtime_put_sync-only-pm_runtime_put_autosuspend.patch @@ -0,0 +1,54 @@ +From c96cfaf8fc02d4bb70727dfa7ce7841a3cff9be2 Mon Sep 17 00:00:00 2001 +From: Lyude Paul +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 + +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 +Reviewed-by: David Airlie +Fixes: 3a6536c51d5d ("drm/nouveau: Intercept ACPI_VIDEO_NOTIFY_PROBE") +Cc: Hans de Goede +Cc: # v4.10+ +Link: https://patchwork.freedesktop.org/patch/msgid/20220714174234.949259-3-lyude@redhat.com +Signed-off-by: Greg Kroah-Hartman +--- + 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 index 00000000000..a3edec84b86 --- /dev/null +++ b/queue-5.10/drm-nouveau-fix-another-off-by-one-in-nvbios_addr.patch @@ -0,0 +1,35 @@ +From c441d28945fb113220d48d6c86ebc0b090a2b677 Mon Sep 17 00:00:00 2001 +From: Timur Tabi +Date: Wed, 11 May 2022 11:37:16 -0500 +Subject: drm/nouveau: fix another off-by-one in nvbios_addr + +From: Timur Tabi + +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: # v4.8+ +Signed-off-by: Timur Tabi +Reviewed-by: Karol Herbst +Signed-off-by: Lyude Paul +Link: https://patchwork.freedesktop.org/patch/msgid/20220511163716.3520591-1-ttabi@nvidia.com +Signed-off-by: Greg Kroah-Hartman +--- + 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 index 00000000000..7a452c56076 --- /dev/null +++ b/queue-5.10/drm-vc4-hdmi-disable-audio-if-dmas-property-is-present-but-empty.patch @@ -0,0 +1,46 @@ +From db2b927f8668adf3ac765e0921cd2720f5c04172 Mon Sep 17 00:00:00 2001 +From: Phil Elwell +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 + +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: +Signed-off-by: Phil Elwell +Link: https://lore.kernel.org/r/20220613144800.326124-18-maxime@cerno.tech +Signed-off-by: Maxime Ripard +Signed-off-by: Greg Kroah-Hartman +--- + 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 index 00000000000..38a8105c436 --- /dev/null +++ b/queue-5.10/parisc-check-the-return-value-of-ioremap-in-lba_driver_probe.patch @@ -0,0 +1,39 @@ +From cf59f34d7f978d14d6520fd80a78a5ad5cb8abf8 Mon Sep 17 00:00:00 2001 +From: William Dean +Date: Fri, 22 Jul 2022 10:57:09 +0800 +Subject: parisc: Check the return value of ioremap() in lba_driver_probe() + +From: William Dean + +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 +Signed-off-by: William Dean +Signed-off-by: Helge Deller +Cc: # v5.6+ +Signed-off-by: Greg Kroah-Hartman +--- + 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 index 00000000000..fba1ddb4b34 --- /dev/null +++ b/queue-5.10/parisc-fix-device-names-in-proc-iomem.patch @@ -0,0 +1,45 @@ +From cab56b51ec0e69128909cef4650e1907248d821b Mon Sep 17 00:00:00 2001 +From: Helge Deller +Date: Mon, 18 Jul 2022 17:06:47 +0200 +Subject: parisc: Fix device names in /proc/iomem + +From: Helge Deller + +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 +Cc: # v4.9+ +Signed-off-by: Greg Kroah-Hartman +--- + 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 index 00000000000..81785bec4cd --- /dev/null +++ b/queue-5.10/parisc-io_pgetevents_time64-needs-compat-syscall-in-32-bit-compat-mode.patch @@ -0,0 +1,36 @@ +From 6431e92fc827bdd2d28f79150d90415ba9ce0d21 Mon Sep 17 00:00:00 2001 +From: Helge Deller +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 + +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: # v5.1+ +Signed-off-by: Helge Deller +Signed-off-by: Greg Kroah-Hartman +--- + 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 diff --git a/queue-5.10/series b/queue-5.10/series index 161a697cea8..66cbcf779c1 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -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