From: Niklas Cassel <cassel@kernel.org>
To: Bjorn Helgaas <helgaas@kernel.org>
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>,
"Wilfred Mallawa" <wilfred.mallawa@wdc.com>,
"Damien Le Moal" <dlemoal@kernel.org>,
"Hans Zhang" <18255117159@163.com>,
"Laszlo Fiat" <laszlo.fiat@proton.me>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org
Subject: Re: [PATCH v2 1/4] PCI: dw-rockchip: Do not enumerate bus before endpoint devices are ready
Date: Thu, 5 Jun 2025 14:28:41 +0200 [thread overview]
Message-ID: <aEGNefEgf56P-mBM@ryzen> (raw)
In-Reply-To: <20250604184445.GA567382@bhelgaas>
On Wed, Jun 04, 2025 at 01:44:45PM -0500, Bjorn Helgaas wrote:
> On Wed, Jun 04, 2025 at 10:40:09PM +0530, Manivannan Sadhasivam wrote:
>
> > > If we add a 100 ms sleep after wait_for_link(), then I suggest that we
> > > also reduce LINK_WAIT_SLEEP_MS to something shorter.
> >
> > No. The 900ms sleep is to make sure that we wait 1s before erroring out
> > assuming that the device is not present. This is mandated by the spec. So
> > irrespective of the delay we add *after* link up, we should try to detect the
> > link up for ~1s.
>
> I think it would be sensible for dw_pcie_wait_for_link() to check for
> link up more frequently, i.e., reduce LINK_WAIT_SLEEP_MS and increase
> LINK_WAIT_MAX_RETRIES.
>
> If LINK_WAIT_SLEEP_MS * LINK_WAIT_MAX_RETRIES is for the 1.0s
> mentioned in sec 6.6.1, seems like maybe we should make a generic
> #define for it so we could include the spec reference and use it
> across all drivers. And resolve the question of 900ms vs 1000ms.
Like Bjorn mentioned, when I wrote reduce LINK_WAIT_SLEEP_MS,
I simply meant that we should poll for link up more frequently.
But yes, if we reduce LINK_WAIT_SLEEP_MS we should bump
LINK_WAIT_MAX_RETRIES to not change the current max wait time.
Bjorn, should I send something out after -rc1, or did you want
to work on this yourself?
Kind regards,
Niklas
WARNING: multiple messages have this Message-ID (diff)
From: Niklas Cassel <cassel@kernel.org>
To: Bjorn Helgaas <helgaas@kernel.org>
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>,
"Wilfred Mallawa" <wilfred.mallawa@wdc.com>,
"Damien Le Moal" <dlemoal@kernel.org>,
"Hans Zhang" <18255117159@163.com>,
"Laszlo Fiat" <laszlo.fiat@proton.me>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org
Subject: Re: [PATCH v2 1/4] PCI: dw-rockchip: Do not enumerate bus before endpoint devices are ready
Date: Thu, 5 Jun 2025 14:28:41 +0200 [thread overview]
Message-ID: <aEGNefEgf56P-mBM@ryzen> (raw)
In-Reply-To: <20250604184445.GA567382@bhelgaas>
On Wed, Jun 04, 2025 at 01:44:45PM -0500, Bjorn Helgaas wrote:
> On Wed, Jun 04, 2025 at 10:40:09PM +0530, Manivannan Sadhasivam wrote:
>
> > > If we add a 100 ms sleep after wait_for_link(), then I suggest that we
> > > also reduce LINK_WAIT_SLEEP_MS to something shorter.
> >
> > No. The 900ms sleep is to make sure that we wait 1s before erroring out
> > assuming that the device is not present. This is mandated by the spec. So
> > irrespective of the delay we add *after* link up, we should try to detect the
> > link up for ~1s.
>
> I think it would be sensible for dw_pcie_wait_for_link() to check for
> link up more frequently, i.e., reduce LINK_WAIT_SLEEP_MS and increase
> LINK_WAIT_MAX_RETRIES.
>
> If LINK_WAIT_SLEEP_MS * LINK_WAIT_MAX_RETRIES is for the 1.0s
> mentioned in sec 6.6.1, seems like maybe we should make a generic
> #define for it so we could include the spec reference and use it
> across all drivers. And resolve the question of 900ms vs 1000ms.
Like Bjorn mentioned, when I wrote reduce LINK_WAIT_SLEEP_MS,
I simply meant that we should poll for link up more frequently.
But yes, if we reduce LINK_WAIT_SLEEP_MS we should bump
LINK_WAIT_MAX_RETRIES to not change the current max wait time.
Bjorn, should I send something out after -rc1, or did you want
to work on this yourself?
Kind regards,
Niklas
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2025-06-05 12:40 UTC|newest]
Thread overview: 77+ 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 ` 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 7:39 ` Niklas Cassel
2025-05-06 11:32 ` Laszlo Fiat
2025-05-06 11:32 ` Laszlo Fiat
2025-05-06 22:23 ` Wilfred Mallawa
2025-05-06 22:23 ` Wilfred Mallawa
2025-05-28 22:42 ` Bjorn Helgaas
2025-05-28 22:42 ` Bjorn Helgaas
2025-05-30 13:57 ` Niklas Cassel
2025-05-30 13:57 ` Niklas Cassel
2025-05-30 15:21 ` Bjorn Helgaas
2025-05-30 15:21 ` Bjorn Helgaas
2025-05-30 15:59 ` Manivannan Sadhasivam
2025-05-30 15:59 ` Manivannan Sadhasivam
2025-05-30 17:19 ` Bjorn Helgaas
2025-05-30 17:19 ` Bjorn Helgaas
2025-05-30 17:24 ` Niklas Cassel
2025-05-30 17:24 ` Niklas Cassel
2025-05-30 19:43 ` Bjorn Helgaas
2025-05-30 19:43 ` Bjorn Helgaas
2025-05-31 6:47 ` Manivannan Sadhasivam
2025-05-31 6:47 ` Manivannan Sadhasivam
2025-06-03 14:08 ` Niklas Cassel
2025-06-03 14:08 ` Niklas Cassel
2025-06-03 18:12 ` Bjorn Helgaas
2025-06-03 18:12 ` Bjorn Helgaas
2025-06-04 11:40 ` Niklas Cassel
2025-06-04 11:40 ` Niklas Cassel
2025-06-04 17:10 ` Manivannan Sadhasivam
2025-06-04 17:10 ` Manivannan Sadhasivam
2025-06-04 18:44 ` Bjorn Helgaas
2025-06-04 18:44 ` Bjorn Helgaas
2025-06-05 12:28 ` Niklas Cassel [this message]
2025-06-05 12:28 ` Niklas Cassel
2025-06-05 13:22 ` Manivannan Sadhasivam
2025-06-05 13:22 ` Manivannan Sadhasivam
2025-06-05 19:27 ` Bjorn Helgaas
2025-06-05 19:27 ` Bjorn Helgaas
2025-05-06 7:39 ` [PATCH v2 2/4] PCI: qcom: " Niklas Cassel
2025-05-06 10:11 ` Krishna Chaitanya Chundru
2025-05-06 11:29 ` Laszlo Fiat
2025-05-06 22:24 ` Wilfred Mallawa
2025-05-06 7:39 ` [PATCH v2 3/4] PCI: dw-rockchip: Replace PERST sleep time with proper macro Niklas Cassel
2025-05-06 7:39 ` Niklas Cassel
2025-05-06 9:07 ` Hans Zhang
2025-05-06 9:07 ` Hans Zhang
2025-05-06 11:36 ` Laszlo Fiat
2025-05-06 11:36 ` Laszlo Fiat
2025-05-06 22:24 ` Wilfred Mallawa
2025-05-06 22:24 ` Wilfred Mallawa
2025-05-06 7:39 ` [PATCH v2 4/4] PCI: qcom: " Niklas Cassel
2025-05-06 9:07 ` Hans Zhang
2025-05-06 10:12 ` Krishna Chaitanya Chundru
2025-05-06 11:37 ` Laszlo Fiat
2025-05-06 22:25 ` Wilfred Mallawa
2025-05-06 14:33 ` [PATCH v2 0/4] PCI: dwc: Link Up IRQ fixes Niklas Cassel
2025-05-06 14:33 ` Niklas Cassel
2025-05-06 14:51 ` Laszlo Fiat
2025-05-06 14:51 ` Laszlo Fiat
2025-05-13 10:53 ` Manivannan Sadhasivam
2025-05-13 10:53 ` Manivannan Sadhasivam
2025-05-13 14:07 ` Niklas Cassel
2025-05-13 14:07 ` Niklas Cassel
2025-05-15 17:33 ` Laszlo Fiat
2025-05-15 17:33 ` Laszlo Fiat
2025-05-16 10:00 ` Niklas Cassel
2025-05-16 10:00 ` Niklas Cassel
2025-05-16 18:48 ` Laszlo Fiat
2025-05-16 18:48 ` Laszlo Fiat
2025-05-19 9:44 ` Niklas Cassel
2025-05-19 9:44 ` Niklas Cassel
2025-05-19 12:10 ` Manivannan Sadhasivam
2025-05-19 12:10 ` Manivannan Sadhasivam
2025-05-19 12:37 ` 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=aEGNefEgf56P-mBM@ryzen \
--to=cassel@kernel.org \
--cc=18255117159@163.com \
--cc=bhelgaas@google.com \
--cc=dlemoal@kernel.org \
--cc=heiko@sntech.de \
--cc=helgaas@kernel.org \
--cc=kw@linux.com \
--cc=kwilczynski@kernel.org \
--cc=laszlo.fiat@proton.me \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=lpieralisi@kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--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 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.