From: Niklas Cassel <cassel@kernel.org>
To: Laszlo Fiat <laszlo.fiat@proton.me>
Cc: "Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Heiko Stuebner" <heiko@sntech.de>,
"Krishna chaitanya chundru" <quic_krichai@quicinc.com>,
"Wilfred Mallawa" <wilfred.mallawa@wdc.com>,
"Damien Le Moal" <dlemoal@kernel.org>,
"Hans Zhang" <18255117159@163.com>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org,
linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH v2 0/4] PCI: dwc: Link Up IRQ fixes
Date: Fri, 16 May 2025 12:00:14 +0200 [thread overview]
Message-ID: <aCcMrtTus-QTNNiu@ryzen> (raw)
In-Reply-To: <fCMPjWu_crgW5GkH4DJd17WBjnCAsb363N9N_h6ld1i8NqNNGR9PTpQWAO9-kwv4DUL6um48dwP0GJ8GmdL4uQf-WniBepwuxTEhjmbBnug=@proton.me>
On Thu, May 15, 2025 at 05:33:41PM +0000, Laszlo Fiat wrote:
> I am the one experiencing the issue with my Orange PI 3B (RK3566, 8 GB RAM) and a PLEXTOR PX-256M8PeGN NVMe SSD.
>
> I first detected the problem while upgrading from 6.13.8 to 6.14.3, that my system cannot find the NVME SSD which contains the rootfs. After reverting the two patches:
>
> - ec9fd499b9c6 ("PCI: dw-rockchip: Don't wait for link since we can detect Link Up")
> - 0e0b45ab5d77 ("PCI: dw-rockchip: Enumerate endpoints based on dll_link_up IRQ")
>
> my system booted fine again.
> After that I tested the patches sent by Niklas in this thread, which fixed the issue, so I sent Tested-by.
>
> I did another test Today with 6.15.0-rc6, which in itself does not find my SSD. Niklas asked me to test with these
>
> - revert ec9fd499b9c6 ("PCI: dw-rockchip: Don't wait for link since we can detect Link Up")
> - revert 0e0b45ab5d77 ("PCI: dw-rockchip: Enumerate endpoints based on dll_link_up IRQ")
> - apply the following patch:
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c
> index b3615d125942..5dee689ecd95 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.c
> +++ b/drivers/pci/controller/dwc/pcie-designware.c
> @@ -692,7 +692,7 @@ int dw_pcie_wait_for_link(struct dw_pcie *pci)
> if (dw_pcie_link_up(pci))
> break;
>
> - msleep(LINK_WAIT_SLEEP_MS);
> + usleep_range(100, 200);
> }
>
> if (retries >= LINK_WAIT_MAX_RETRIES) {
>
>
> which restores the original behaviour to wait for link-up, then shorten the time. This resulted again a non booting system, this time with "Phy link never came up" error message.
That message was unexpected.
What I expected to happen was that the link would come up, but by reducing
delay between "link is up" and device is accessed (from 90 ms -> 100 us),
I was that you would see the same problem on "older" kernels as you do with
the "link up IRQ" patches (which originally had no delay, but this series
basically re-added the same delay (PCIE_T_RRS_READY_MS, 100 ms) as we had
before (LINK_WAIT_SLEEP_MS, 90 ms).
But I see the problem with the test code that I asked you to test to verify
that this problem also existed before (if you had a shorter delay).
(By reducing the delay, the LINK_WAIT_MAX_RETRIES also need to be bumped.)
Could you please test:
diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c
index b3615d125942..5dee689ecd95 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -692,7 +692,7 @@ int dw_pcie_wait_for_link(struct dw_pcie *pci)
if (dw_pcie_link_up(pci))
break;
- msleep(LINK_WAIT_SLEEP_MS);
+ usleep_range(100, 200);
}
if (retries >= LINK_WAIT_MAX_RETRIES) {
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index 4dd16aa4b39e..8422661b79d5 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -61,7 +61,7 @@
set_bit(DW_PCIE_CAP_ ## _cap, &(_pci)->caps)
/* Parameters for the waiting for link up routine */
-#define LINK_WAIT_MAX_RETRIES 10
+#define LINK_WAIT_MAX_RETRIES 10000
#define LINK_WAIT_SLEEP_MS 90
/* Parameters for the waiting for iATU enabled routine */
On top of an old kernel instead?
We expect the link to come up, but that you will not be able to mount rootfs.
If that is the case, we are certain that the this patch series is 100% needed
for your device to have the same functional behavior as before.
Kind regards,
Niklas
next prev parent reply other threads:[~2025-05-16 10:03 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-06 7:39 [PATCH v2 0/4] PCI: dwc: Link Up IRQ fixes Niklas Cassel
2025-05-06 7:39 ` [PATCH v2 1/4] PCI: dw-rockchip: Do not enumerate bus before endpoint devices are ready Niklas Cassel
2025-05-06 11:32 ` Laszlo Fiat
2025-05-06 22:23 ` Wilfred Mallawa
2025-05-28 22:42 ` Bjorn Helgaas
2025-05-30 13:57 ` Niklas Cassel
2025-05-30 15:21 ` Bjorn Helgaas
2025-05-30 15:59 ` Manivannan Sadhasivam
2025-05-30 17:19 ` Bjorn Helgaas
2025-05-30 17:24 ` Niklas Cassel
2025-05-30 19:43 ` Bjorn Helgaas
2025-05-31 6:47 ` Manivannan Sadhasivam
2025-06-03 14:08 ` Niklas Cassel
2025-06-03 18:12 ` Bjorn Helgaas
2025-06-04 11:40 ` Niklas Cassel
2025-06-04 17:10 ` Manivannan Sadhasivam
2025-06-04 18:44 ` Bjorn Helgaas
2025-06-05 12:28 ` Niklas Cassel
2025-06-05 13:22 ` Manivannan Sadhasivam
2025-06-05 19:27 ` Bjorn Helgaas
2025-05-06 7:39 ` [PATCH v2 3/4] PCI: dw-rockchip: Replace PERST sleep time with proper macro Niklas Cassel
2025-05-06 9:07 ` Hans Zhang
2025-05-06 11:36 ` Laszlo Fiat
2025-05-06 22:24 ` Wilfred Mallawa
2025-05-06 14:33 ` [PATCH v2 0/4] PCI: dwc: Link Up IRQ fixes Niklas Cassel
2025-05-06 14:51 ` Laszlo Fiat
2025-05-13 10:53 ` Manivannan Sadhasivam
2025-05-13 14:07 ` Niklas Cassel
2025-05-15 17:33 ` Laszlo Fiat
2025-05-16 10:00 ` Niklas Cassel [this message]
2025-05-16 18:48 ` Laszlo Fiat
2025-05-19 9:44 ` Niklas Cassel
2025-05-19 12:10 ` Manivannan Sadhasivam
2025-05-19 12:37 ` Manivannan Sadhasivam
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=aCcMrtTus-QTNNiu@ryzen \
--to=cassel@kernel.org \
--cc=18255117159@163.com \
--cc=bhelgaas@google.com \
--cc=dlemoal@kernel.org \
--cc=heiko@sntech.de \
--cc=kw@linux.com \
--cc=kwilczynski@kernel.org \
--cc=laszlo.fiat@proton.me \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=lpieralisi@kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=quic_krichai@quicinc.com \
--cc=robh@kernel.org \
--cc=wilfred.mallawa@wdc.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox