From: Sathyanarayanan Kuppuswamy <sathyanarayanan.kuppuswamy@linux.intel.com>
To: Lukas Wunner <lukas@wunner.de>,
Bjorn Helgaas <helgaas@kernel.org>,
linux-pci@vger.kernel.org
Cc: Keith Busch <kbusch@kernel.org>, Ashok Raj <ashok.raj@intel.com>,
Ravi Kishore Koppuravuri <ravi.kishore.koppuravuri@intel.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Sheng Bi <windy.bi.enflame@gmail.com>,
Stanislav Spassov <stanspas@amazon.de>,
Yang Su <yang.su@linux.alibaba.com>
Subject: Re: [PATCH 3/3] PCI/DPC: Await readiness of secondary bus after reset
Date: Tue, 3 Jan 2023 11:49:56 -0800 [thread overview]
Message-ID: <430c314c-50ed-d0ed-e15e-1b3278286c83@linux.intel.com> (raw)
In-Reply-To: <a2ff8481c3f08458dcd2b4028a838730e965c72f.1672511017.git.lukas@wunner.de>
HI,
On 12/31/22 10:33 AM, Lukas Wunner wrote:
> We're calling pci_bridge_wait_for_secondary_bus() after performing a
> Secondary Bus Reset, but neglect to do the same after coming out of a
> DPC-induced Hot Reset. As a result, we're not observing the delays
> prescribed by PCIe r6.0 sec 6.6.1 and may access devices on the
> secondary bus before they're ready. Fix it.
Please remove "we" usage. Otherwise, looks good.
>
> Tested-by: Ravi Kishore Koppuravuri <ravi.kishore.koppuravuri@intel.com>
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
> Cc: stable@vger.kernel.org
> ---
> drivers/pci/pci.c | 3 ---
> drivers/pci/pci.h | 3 +++
> drivers/pci/pcie/dpc.c | 4 ++--
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index b0b49243a908..19fe0ef0e583 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -167,9 +167,6 @@ static int __init pcie_port_pm_setup(char *str)
> }
> __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
> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> index 40758248dd80..b72fd888379b 100644
> --- a/drivers/pci/pci.h
> +++ b/drivers/pci/pci.h
> @@ -7,6 +7,9 @@
> /* Number of possible devfns: 0.0 to 1f.7 inclusive */
> #define MAX_NR_DEVFNS 256
>
> +/* Time to wait after a reset for device to become responsive */
> +#define PCIE_RESET_READY_POLL_MS 60000
> +
> #define PCI_FIND_CAP_TTL 48
>
> #define PCI_VSEC_ID_INTEL_TBT 0x1234 /* Thunderbolt */
> diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
> index f5ffea17c7f8..a5d7c69b764e 100644
> --- a/drivers/pci/pcie/dpc.c
> +++ b/drivers/pci/pcie/dpc.c
> @@ -170,8 +170,8 @@ pci_ers_result_t dpc_reset_link(struct pci_dev *pdev)
> 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 {
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
next prev parent reply other threads:[~2023-01-03 19:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-31 18:33 [PATCH 0/3] PCI reset delay fixes Lukas Wunner
2022-12-31 18:33 ` [PATCH 1/3] PCI/PM: Observe reset delay irrespective of bridge_d3 Lukas Wunner
2023-01-03 19:50 ` Sathyanarayanan Kuppuswamy
2022-12-31 18:33 ` [PATCH 2/3] PCI: Unify delay handling for reset and resume Lukas Wunner
2023-01-03 19:50 ` Sathyanarayanan Kuppuswamy
2023-01-12 22:31 ` Bjorn Helgaas
2022-12-31 18:33 ` [PATCH 3/3] PCI/DPC: Await readiness of secondary bus after reset Lukas Wunner
2023-01-03 19:49 ` Sathyanarayanan Kuppuswamy [this message]
2023-01-12 22:35 ` Bjorn Helgaas
[not found] ` <15135d89-0515-d965-567b-79b3eca236e6@linux.alibaba.com>
2023-01-13 3:06 ` Bjorn Helgaas
2023-01-13 10:18 ` Lukas Wunner
2023-01-13 9:10 ` Lukas Wunner
2023-01-03 11:09 ` [PATCH 0/3] PCI reset delay fixes Mika Westerberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=430c314c-50ed-d0ed-e15e-1b3278286c83@linux.intel.com \
--to=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=ashok.raj@intel.com \
--cc=helgaas@kernel.org \
--cc=kbusch@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mika.westerberg@linux.intel.com \
--cc=ravi.kishore.koppuravuri@intel.com \
--cc=stanspas@amazon.de \
--cc=windy.bi.enflame@gmail.com \
--cc=yang.su@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.