From: Greg Kroah-Hartman Date: Mon, 20 Mar 2023 13:38:21 +0000 (+0100) Subject: 5.15-stable patches X-Git-Tag: v4.14.311~17 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=cd81d8207d6f8b71e240b66264c59a59daa8cfd7;p=thirdparty%2Fkernel%2Fstable-queue.git 5.15-stable patches added patches: drm-i915-active-fix-misuse-of-non-idle-barriers-as-fence-trackers.patch drm-i915-don-t-use-stolen-memory-for-ring-buffers-with-llc.patch io_uring-avoid-null-ptr-deref-in-io_arm_poll_handler.patch pci-dpc-await-readiness-of-secondary-bus-after-reset.patch pci-unify-delay-handling-for-reset-and-resume.patch --- diff --git a/queue-5.15/drm-i915-active-fix-misuse-of-non-idle-barriers-as-fence-trackers.patch b/queue-5.15/drm-i915-active-fix-misuse-of-non-idle-barriers-as-fence-trackers.patch new file mode 100644 index 00000000000..a5ae3de2742 --- /dev/null +++ b/queue-5.15/drm-i915-active-fix-misuse-of-non-idle-barriers-as-fence-trackers.patch @@ -0,0 +1,117 @@ +From e0e6b416b25ee14716f3549e0cbec1011b193809 Mon Sep 17 00:00:00 2001 +From: Janusz Krzysztofik +Date: Thu, 2 Mar 2023 13:08:20 +0100 +Subject: drm/i915/active: Fix misuse of non-idle barriers as fence trackers + +From: Janusz Krzysztofik + +commit e0e6b416b25ee14716f3549e0cbec1011b193809 upstream. + +Users reported oopses on list corruptions when using i915 perf with a +number of concurrently running graphics applications. Root cause analysis +pointed at an issue in barrier processing code -- a race among perf open / +close replacing active barriers with perf requests on kernel context and +concurrent barrier preallocate / acquire operations performed during user +context first pin / last unpin. + +When adding a request to a composite tracker, we try to reuse an existing +fence tracker, already allocated and registered with that composite. The +tracker we obtain may already track another fence, may be an idle barrier, +or an active barrier. + +If the tracker we get occurs a non-idle barrier then we try to delete that +barrier from a list of barrier tasks it belongs to. However, while doing +that we don't respect return value from a function that performs the +barrier deletion. Should the deletion ever fail, we would end up reusing +the tracker still registered as a barrier task. Since the same structure +field is reused with both fence callback lists and barrier tasks list, +list corruptions would likely occur. + +Barriers are now deleted from a barrier tasks list by temporarily removing +the list content, traversing that content with skip over the node to be +deleted, then populating the list back with the modified content. Should +that intentionally racy concurrent deletion attempts be not serialized, +one or more of those may fail because of the list being temporary empty. + +Related code that ignores the results of barrier deletion was initially +introduced in v5.4 by commit d8af05ff38ae ("drm/i915: Allow sharing the +idle-barrier from other kernel requests"). However, all users of the +barrier deletion routine were apparently serialized at that time, then the +issue didn't exhibit itself. Results of git bisect with help of a newly +developed igt@gem_barrier_race@remote-request IGT test indicate that list +corruptions might start to appear after commit 311770173fac ("drm/i915/gt: +Schedule request retirement when timeline idles"), introduced in v5.5. + +Respect results of barrier deletion attempts -- mark the barrier as idle +only if successfully deleted from the list. Then, before proceeding with +setting our fence as the one currently tracked, make sure that the tracker +we've got is not a non-idle barrier. If that check fails then don't use +that tracker but go back and try to acquire a new, usable one. + +v3: use unlikely() to document what outcome we expect (Andi), + - fix bad grammar in commit description. +v2: no code changes, + - blame commit 311770173fac ("drm/i915/gt: Schedule request retirement + when timeline idles"), v5.5, not commit d8af05ff38ae ("drm/i915: Allow + sharing the idle-barrier from other kernel requests"), v5.4, + - reword commit description. + +Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6333 +Fixes: 311770173fac ("drm/i915/gt: Schedule request retirement when timeline idles") +Cc: Chris Wilson +Cc: stable@vger.kernel.org # v5.5 +Cc: Andi Shyti +Signed-off-by: Janusz Krzysztofik +Reviewed-by: Andi Shyti +Signed-off-by: Andi Shyti +Link: https://patchwork.freedesktop.org/patch/msgid/20230302120820.48740-1-janusz.krzysztofik@linux.intel.com +(cherry picked from commit 506006055769b10d1b2b4e22f636f3b45e0e9fc7) +Signed-off-by: Jani Nikula +Signed-off-by: Janusz Krzysztofik +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/i915/i915_active.c | 26 ++++++++++++++------------ + 1 file changed, 14 insertions(+), 12 deletions(-) + +--- a/drivers/gpu/drm/i915/i915_active.c ++++ b/drivers/gpu/drm/i915/i915_active.c +@@ -422,8 +422,7 @@ replace_barrier(struct i915_active *ref, + * we can use it to substitute for the pending idle-barrer + * request that we want to emit on the kernel_context. + */ +- __active_del_barrier(ref, node_from_active(active)); +- return true; ++ return __active_del_barrier(ref, node_from_active(active)); + } + + int i915_active_ref(struct i915_active *ref, u64 idx, struct dma_fence *fence) +@@ -436,16 +435,19 @@ int i915_active_ref(struct i915_active * + if (err) + return err; + +- active = active_instance(ref, idx); +- if (!active) { +- err = -ENOMEM; +- goto out; +- } +- +- if (replace_barrier(ref, active)) { +- RCU_INIT_POINTER(active->fence, NULL); +- atomic_dec(&ref->count); +- } ++ do { ++ active = active_instance(ref, idx); ++ if (!active) { ++ err = -ENOMEM; ++ goto out; ++ } ++ ++ if (replace_barrier(ref, active)) { ++ RCU_INIT_POINTER(active->fence, NULL); ++ atomic_dec(&ref->count); ++ } ++ } while (unlikely(is_barrier(active))); ++ + if (!__i915_active_fence_set(active, fence)) + __i915_active_acquire(ref); + diff --git a/queue-5.15/drm-i915-don-t-use-stolen-memory-for-ring-buffers-with-llc.patch b/queue-5.15/drm-i915-don-t-use-stolen-memory-for-ring-buffers-with-llc.patch new file mode 100644 index 00000000000..203bdc99603 --- /dev/null +++ b/queue-5.15/drm-i915-don-t-use-stolen-memory-for-ring-buffers-with-llc.patch @@ -0,0 +1,48 @@ +From 690e0ec8e63da9a29b39fedc6ed5da09c7c82651 Mon Sep 17 00:00:00 2001 +From: John Harrison +Date: Wed, 15 Feb 2023 17:11:00 -0800 +Subject: drm/i915: Don't use stolen memory for ring buffers with LLC +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: John Harrison + +commit 690e0ec8e63da9a29b39fedc6ed5da09c7c82651 upstream. + +Direction from hardware is that stolen memory should never be used for +ring buffer allocations on platforms with LLC. There are too many +caching pitfalls due to the way stolen memory accesses are routed. So +it is safest to just not use it. + +Signed-off-by: John Harrison +Fixes: c58b735fc762 ("drm/i915: Allocate rings from stolen") +Cc: Chris Wilson +Cc: Joonas Lahtinen +Cc: Jani Nikula +Cc: Rodrigo Vivi +Cc: Tvrtko Ursulin +Cc: intel-gfx@lists.freedesktop.org +Cc: # v4.9+ +Tested-by: Jouni Högander +Reviewed-by: Daniele Ceraolo Spurio +Link: https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-2-John.C.Harrison@Intel.com +(cherry picked from commit f54c1f6c697c4297f7ed94283c184acc338a5cf8) +Signed-off-by: Jani Nikula +Signed-off-by: John Harrison +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/i915/gt/intel_ring.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/i915/gt/intel_ring.c ++++ b/drivers/gpu/drm/i915/gt/intel_ring.c +@@ -113,7 +113,7 @@ static struct i915_vma *create_ring_vma( + struct i915_vma *vma; + + obj = i915_gem_object_create_lmem(i915, size, I915_BO_ALLOC_VOLATILE); +- if (IS_ERR(obj) && i915_ggtt_has_aperture(ggtt)) ++ if (IS_ERR(obj) && i915_ggtt_has_aperture(ggtt) && !HAS_LLC(i915)) + obj = i915_gem_object_create_stolen(i915, size); + if (IS_ERR(obj)) + obj = i915_gem_object_create_internal(i915, size); diff --git a/queue-5.15/io_uring-avoid-null-ptr-deref-in-io_arm_poll_handler.patch b/queue-5.15/io_uring-avoid-null-ptr-deref-in-io_arm_poll_handler.patch new file mode 100644 index 00000000000..7f4aacdf167 --- /dev/null +++ b/queue-5.15/io_uring-avoid-null-ptr-deref-in-io_arm_poll_handler.patch @@ -0,0 +1,45 @@ +From pchelkin@ispras.ru Mon Mar 20 14:30:30 2023 +From: Fedor Pchelkin +Date: Thu, 16 Mar 2023 21:56:16 +0300 +Subject: io_uring: avoid null-ptr-deref in io_arm_poll_handler +To: Jens Axboe , Greg Kroah-Hartman , stable@vger.kernel.org +Cc: Fedor Pchelkin , linux-kernel@vger.kernel.org, Alexey Khoroshilov , lvc-project@linuxtesting.org +Message-ID: <20230316185616.271024-1-pchelkin@ispras.ru> + +From: Fedor Pchelkin + +No upstream commit exists for this commit. + +The issue was introduced with backporting upstream commit c16bda37594f +("io_uring/poll: allow some retries for poll triggering spuriously"). + +Memory allocation can possibly fail causing invalid pointer be +dereferenced just before comparing it to NULL value. + +Move the pointer check in proper place (upstream has the similar location +of the check). In case the request has REQ_F_POLLED flag up, apoll can't +be NULL so no need to check there. + +Found by Linux Verification Center (linuxtesting.org) with Syzkaller. + +Signed-off-by: Fedor Pchelkin +Signed-off-by: Greg Kroah-Hartman +--- + io_uring/io_uring.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/io_uring/io_uring.c ++++ b/io_uring/io_uring.c +@@ -5937,10 +5937,10 @@ static int io_arm_poll_handler(struct io + } + } else { + apoll = kmalloc(sizeof(*apoll), GFP_ATOMIC); ++ if (unlikely(!apoll)) ++ return IO_APOLL_ABORTED; + apoll->poll.retries = APOLL_MAX_RETRY; + } +- if (unlikely(!apoll)) +- return IO_APOLL_ABORTED; + apoll->double_poll = NULL; + req->apoll = apoll; + req->flags |= REQ_F_POLLED; diff --git a/queue-5.15/pci-dpc-await-readiness-of-secondary-bus-after-reset.patch b/queue-5.15/pci-dpc-await-readiness-of-secondary-bus-after-reset.patch new file mode 100644 index 00000000000..1d7ba6c1254 --- /dev/null +++ b/queue-5.15/pci-dpc-await-readiness-of-secondary-bus-after-reset.patch @@ -0,0 +1,81 @@ +From 53b54ad074de1896f8b021615f65b27f557ce874 Mon Sep 17 00:00:00 2001 +From: Lukas Wunner +Date: Sun, 15 Jan 2023 09:20:33 +0100 +Subject: PCI/DPC: Await readiness of secondary bus after reset + +From: Lukas Wunner + +commit 53b54ad074de1896f8b021615f65b27f557ce874 upstream. + +pci_bridge_wait_for_secondary_bus() is called after a Secondary Bus +Reset, but not after a DPC-induced Hot Reset. + +As a result, the delays prescribed by PCIe r6.0 sec 6.6.1 are not +observed and devices on the secondary bus may be accessed before +they're ready. + +One affected device is Intel's Ponte Vecchio HPC GPU. It comprises a +PCIe switch whose upstream port is not immediately ready after reset. +Because its config space is restored too early, it remains in +D0uninitialized, its subordinate devices remain inaccessible and DPC +recovery fails with messages such as: + + i915 0000:8c:00.0: can't change power state from D3cold to D0 (config space inaccessible) + intel_vsec 0000:8e:00.1: can't change power state from D3cold to D0 (config space inaccessible) + pcieport 0000:89:02.0: AER: device recovery failed + +Fix it. + +Link: https://lore.kernel.org/r/9f5ff00e1593d8d9a4b452398b98aa14d23fca11.1673769517.git.lukas@wunner.de +Tested-by: Ravi Kishore Koppuravuri +Signed-off-by: Lukas Wunner +Signed-off-by: Bjorn Helgaas +Reviewed-by: Mika Westerberg +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/pci.c | 3 --- + drivers/pci/pci.h | 6 ++++++ + drivers/pci/pcie/dpc.c | 4 ++-- + 3 files changed, 8 insertions(+), 5 deletions(-) + +--- a/drivers/pci/pci.c ++++ b/drivers/pci/pci.c +@@ -163,9 +163,6 @@ static int __init pcie_port_pm_setup(cha + } + __setup("pcie_port_pm=", pcie_port_pm_setup); + +-/* Time to wait after a reset for device to become responsive */ +-#define PCIE_RESET_READY_POLL_MS 60000 +- + /** + * pci_bus_max_busnr - returns maximum PCI bus number of given bus' children + * @bus: pointer to PCI bus structure to search +--- a/drivers/pci/pci.h ++++ b/drivers/pci/pci.h +@@ -69,6 +69,12 @@ struct pci_cap_saved_state *pci_find_sav + * Reset (PCIe r6.0 sec 5.8). + */ + #define PCI_RESET_WAIT 1000 /* msec */ ++/* ++ * Devices may extend the 1 sec period through Request Retry Status completions ++ * (PCIe r6.0 sec 2.3.1). The spec does not provide an upper limit, but 60 sec ++ * ought to be enough for any device to become responsive. ++ */ ++#define PCIE_RESET_READY_POLL_MS 60000 /* msec */ + + /** + * struct pci_platform_pm_ops - Firmware PM callbacks +--- a/drivers/pci/pcie/dpc.c ++++ b/drivers/pci/pcie/dpc.c +@@ -170,8 +170,8 @@ pci_ers_result_t dpc_reset_link(struct p + pci_write_config_word(pdev, cap + PCI_EXP_DPC_STATUS, + PCI_EXP_DPC_STATUS_TRIGGER); + +- if (!pcie_wait_for_link(pdev, true)) { +- pci_info(pdev, "Data Link Layer Link Active not set in 1000 msec\n"); ++ if (pci_bridge_wait_for_secondary_bus(pdev, "DPC", ++ PCIE_RESET_READY_POLL_MS)) { + clear_bit(PCI_DPC_RECOVERED, &pdev->priv_flags); + ret = PCI_ERS_RESULT_DISCONNECT; + } else { diff --git a/queue-5.15/pci-unify-delay-handling-for-reset-and-resume.patch b/queue-5.15/pci-unify-delay-handling-for-reset-and-resume.patch new file mode 100644 index 00000000000..f07555aaaa8 --- /dev/null +++ b/queue-5.15/pci-unify-delay-handling-for-reset-and-resume.patch @@ -0,0 +1,257 @@ +From ac91e6980563ed53afadd925fa6585ffd2bc4a2c Mon Sep 17 00:00:00 2001 +From: Lukas Wunner +Date: Sun, 15 Jan 2023 09:20:32 +0100 +Subject: PCI: Unify delay handling for reset and resume + +From: Lukas Wunner + +commit ac91e6980563ed53afadd925fa6585ffd2bc4a2c upstream. + +Sheng Bi reports that pci_bridge_secondary_bus_reset() may fail to wait +for devices on the secondary bus to become accessible after reset: + +Although it does call pci_dev_wait(), it erroneously passes the bridge's +pci_dev rather than that of a child. The bridge of course is always +accessible while its secondary bus is reset, so pci_dev_wait() returns +immediately. + +Sheng Bi proposes introducing a new pci_bridge_secondary_bus_wait() +function which is called from pci_bridge_secondary_bus_reset(): + +https://lore.kernel.org/linux-pci/20220523171517.32407-1-windy.bi.enflame@gmail.com/ + +However we already have pci_bridge_wait_for_secondary_bus() which does +almost exactly what we need. So far it's only called on resume from +D3cold (which implies a Fundamental Reset per PCIe r6.0 sec 5.8). +Re-using it for Secondary Bus Resets is a leaner and more rational +approach than introducing a new function. + +That only requires a few minor tweaks: + +- Amend pci_bridge_wait_for_secondary_bus() to await accessibility of + the first device on the secondary bus by calling pci_dev_wait() after + performing the prescribed delays. pci_dev_wait() needs two parameters, + a reset reason and a timeout, which callers must now pass to + pci_bridge_wait_for_secondary_bus(). The timeout is 1 sec for resume + (PCIe r6.0 sec 6.6.1) and 60 sec for reset (commit 821cdad5c46c ("PCI: + Wait up to 60 seconds for device to become ready after FLR")). + Introduce a PCI_RESET_WAIT macro for the 1 sec timeout. + +- Amend pci_bridge_wait_for_secondary_bus() to return 0 on success or + -ENOTTY on error for consumption by pci_bridge_secondary_bus_reset(). + +- Drop an unnecessary 1 sec delay from pci_reset_secondary_bus() which + is now performed by pci_bridge_wait_for_secondary_bus(). A static + delay this long is only necessary for Conventional PCI, so modern + PCIe systems benefit from shorter reset times as a side effect. + +Fixes: 6b2f1351af56 ("PCI: Wait for device to become ready after secondary bus reset") +Link: https://lore.kernel.org/r/da77c92796b99ec568bd070cbe4725074a117038.1673769517.git.lukas@wunner.de +Reported-by: Sheng Bi +Tested-by: Ravi Kishore Koppuravuri +Signed-off-by: Lukas Wunner +Signed-off-by: Bjorn Helgaas +Reviewed-by: Mika Westerberg +Reviewed-by: Kuppuswamy Sathyanarayanan +Cc: stable@vger.kernel.org # v4.17+ +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/pci-driver.c | 4 +-- + drivers/pci/pci.c | 54 ++++++++++++++++++++--------------------------- + drivers/pci/pci.h | 10 +++++++- + 3 files changed, 35 insertions(+), 33 deletions(-) + +--- a/drivers/pci/pci-driver.c ++++ b/drivers/pci/pci-driver.c +@@ -925,7 +925,7 @@ static int pci_pm_resume_noirq(struct de + pcie_pme_root_status_cleanup(pci_dev); + + if (!skip_bus_pm && prev_state == PCI_D3cold) +- pci_bridge_wait_for_secondary_bus(pci_dev); ++ pci_bridge_wait_for_secondary_bus(pci_dev, "resume", PCI_RESET_WAIT); + + if (pci_has_legacy_pm_support(pci_dev)) + return 0; +@@ -1312,7 +1312,7 @@ static int pci_pm_runtime_resume(struct + pci_pm_default_resume(pci_dev); + + if (prev_state == PCI_D3cold) +- pci_bridge_wait_for_secondary_bus(pci_dev); ++ pci_bridge_wait_for_secondary_bus(pci_dev, "resume", PCI_RESET_WAIT); + + if (pm && pm->runtime_resume) + error = pm->runtime_resume(dev); +--- a/drivers/pci/pci.c ++++ b/drivers/pci/pci.c +@@ -1255,7 +1255,7 @@ static int pci_dev_wait(struct pci_dev * + return -ENOTTY; + } + +- if (delay > 1000) ++ if (delay > PCI_RESET_WAIT) + pci_info(dev, "not ready %dms after %s; waiting\n", + delay - 1, reset_type); + +@@ -1264,7 +1264,7 @@ static int pci_dev_wait(struct pci_dev * + pci_read_config_dword(dev, PCI_COMMAND, &id); + } + +- if (delay > 1000) ++ if (delay > PCI_RESET_WAIT) + pci_info(dev, "ready %dms after %s\n", delay - 1, + reset_type); + +@@ -4886,24 +4886,31 @@ static int pci_bus_max_d3cold_delay(cons + /** + * pci_bridge_wait_for_secondary_bus - Wait for secondary bus to be accessible + * @dev: PCI bridge ++ * @reset_type: reset type in human-readable form ++ * @timeout: maximum time to wait for devices on secondary bus (milliseconds) + * + * Handle necessary delays before access to the devices on the secondary +- * side of the bridge are permitted after D3cold to D0 transition. ++ * side of the bridge are permitted after D3cold to D0 transition ++ * or Conventional Reset. + * + * For PCIe this means the delays in PCIe 5.0 section 6.6.1. For + * conventional PCI it means Tpvrh + Trhfa specified in PCI 3.0 section + * 4.3.2. ++ * ++ * Return 0 on success or -ENOTTY if the first device on the secondary bus ++ * failed to become accessible. + */ +-void pci_bridge_wait_for_secondary_bus(struct pci_dev *dev) ++int pci_bridge_wait_for_secondary_bus(struct pci_dev *dev, char *reset_type, ++ int timeout) + { + struct pci_dev *child; + int delay; + + if (pci_dev_is_disconnected(dev)) +- return; ++ return 0; + + if (!pci_is_bridge(dev)) +- return; ++ return 0; + + down_read(&pci_bus_sem); + +@@ -4915,14 +4922,14 @@ void pci_bridge_wait_for_secondary_bus(s + */ + if (!dev->subordinate || list_empty(&dev->subordinate->devices)) { + up_read(&pci_bus_sem); +- return; ++ return 0; + } + + /* Take d3cold_delay requirements into account */ + delay = pci_bus_max_d3cold_delay(dev->subordinate); + if (!delay) { + up_read(&pci_bus_sem); +- return; ++ return 0; + } + + child = list_first_entry(&dev->subordinate->devices, struct pci_dev, +@@ -4931,14 +4938,12 @@ void pci_bridge_wait_for_secondary_bus(s + + /* + * Conventional PCI and PCI-X we need to wait Tpvrh + Trhfa before +- * accessing the device after reset (that is 1000 ms + 100 ms). In +- * practice this should not be needed because we don't do power +- * management for them (see pci_bridge_d3_possible()). ++ * accessing the device after reset (that is 1000 ms + 100 ms). + */ + if (!pci_is_pcie(dev)) { + pci_dbg(dev, "waiting %d ms for secondary bus\n", 1000 + delay); + msleep(1000 + delay); +- return; ++ return 0; + } + + /* +@@ -4955,11 +4960,11 @@ void pci_bridge_wait_for_secondary_bus(s + * configuration requests if we only wait for 100 ms (see + * https://bugzilla.kernel.org/show_bug.cgi?id=203885). + * +- * Therefore we wait for 100 ms and check for the device presence. +- * If it is still not present give it an additional 100 ms. ++ * Therefore we wait for 100 ms and check for the device presence ++ * until the timeout expires. + */ + if (!pcie_downstream_port(dev)) +- return; ++ return 0; + + if (pcie_get_speed_cap(dev) <= PCIE_SPEED_5_0GT) { + pci_dbg(dev, "waiting %d ms for downstream link\n", delay); +@@ -4970,14 +4975,11 @@ void pci_bridge_wait_for_secondary_bus(s + if (!pcie_wait_for_link_delay(dev, true, delay)) { + /* Did not train, no need to wait any further */ + pci_info(dev, "Data Link Layer Link Active not set in 1000 msec\n"); +- return; ++ return -ENOTTY; + } + } + +- if (!pci_device_is_present(child)) { +- pci_dbg(child, "waiting additional %d ms to become accessible\n", delay); +- msleep(delay); +- } ++ return pci_dev_wait(child, reset_type, timeout - delay); + } + + void pci_reset_secondary_bus(struct pci_dev *dev) +@@ -4996,15 +4998,6 @@ void pci_reset_secondary_bus(struct pci_ + + ctrl &= ~PCI_BRIDGE_CTL_BUS_RESET; + pci_write_config_word(dev, PCI_BRIDGE_CONTROL, ctrl); +- +- /* +- * Trhfa for conventional PCI is 2^25 clock cycles. +- * Assuming a minimum 33MHz clock this results in a 1s +- * delay before we can consider subordinate devices to +- * be re-initialized. PCIe has some ways to shorten this, +- * but we don't make use of them yet. +- */ +- ssleep(1); + } + + void __weak pcibios_reset_secondary_bus(struct pci_dev *dev) +@@ -5023,7 +5016,8 @@ int pci_bridge_secondary_bus_reset(struc + { + pcibios_reset_secondary_bus(dev); + +- return pci_dev_wait(dev, "bus reset", PCIE_RESET_READY_POLL_MS); ++ return pci_bridge_wait_for_secondary_bus(dev, "bus reset", ++ PCIE_RESET_READY_POLL_MS); + } + EXPORT_SYMBOL_GPL(pci_bridge_secondary_bus_reset); + +--- a/drivers/pci/pci.h ++++ b/drivers/pci/pci.h +@@ -63,6 +63,13 @@ struct pci_cap_saved_state *pci_find_sav + #define PCI_PM_D3HOT_WAIT 10 /* msec */ + #define PCI_PM_D3COLD_WAIT 100 /* msec */ + ++/* ++ * Following exit from Conventional Reset, devices must be ready within 1 sec ++ * (PCIe r6.0 sec 6.6.1). A D3cold to D0 transition implies a Conventional ++ * Reset (PCIe r6.0 sec 5.8). ++ */ ++#define PCI_RESET_WAIT 1000 /* msec */ ++ + /** + * struct pci_platform_pm_ops - Firmware PM callbacks + * +@@ -124,7 +131,8 @@ void pci_msi_init(struct pci_dev *dev); + void pci_msix_init(struct pci_dev *dev); + bool pci_bridge_d3_possible(struct pci_dev *dev); + void pci_bridge_d3_update(struct pci_dev *dev); +-void pci_bridge_wait_for_secondary_bus(struct pci_dev *dev); ++int pci_bridge_wait_for_secondary_bus(struct pci_dev *dev, char *reset_type, ++ int timeout); + + static inline void pci_wakeup_event(struct pci_dev *dev) + { diff --git a/queue-5.15/series b/queue-5.15/series index 8e1427f988c..2465567694d 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -106,3 +106,8 @@ cpuidle-psci-iterate-backwards-over-list-in-psci_pd_remove.patch x86-mce-make-sure-logged-mces-are-processed-after-sysfs-update.patch x86-mm-fix-use-of-uninitialized-buffer-in-sme_enable.patch x86-resctrl-clear-staged_config-before-and-after-it-is-used.patch +drm-i915-don-t-use-stolen-memory-for-ring-buffers-with-llc.patch +drm-i915-active-fix-misuse-of-non-idle-barriers-as-fence-trackers.patch +io_uring-avoid-null-ptr-deref-in-io_arm_poll_handler.patch +pci-unify-delay-handling-for-reset-and-resume.patch +pci-dpc-await-readiness-of-secondary-bus-after-reset.patch