From: Lukas Wunner <lukas@wunner.de>
To: Alexander Gruhlke <gruhlke@mailbox.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Alex Williamson <alex@shazbot.org>,
Hui Wang <hui.wang@canonical.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
regressions@lists.linux.dev
Subject: Re: [PATCH 1/2] PCI: Don't treat ~0 as ready in pci_dev_wait() with RRS SV
Date: Sat, 10 Oct 2026 20:36:38 +0200 [thread overview]
Message-ID: <asqFthqcsDkUU6Sg@wunner.de> (raw)
In-Reply-To: <20261010160529.27974-2-gruhlke@mailbox.org>
On Sat, Oct 10, 2026 at 06:05:28PM +0200, Alexander Gruhlke wrote:
> With RRS Software Visibility, pci_dev_wait() considers a device ready as
> soon as reading the Vendor ID doesn't return the RRS value. Some devices
> don't respond with RRS while they aren't ready, so the read returns ~0
> and pci_dev_wait() stops waiting too early. This was seen with Intel
> [8086:0a54] and Samsung [144d:a80c] NVMe SSDs.
If I understand the spec correctly (PCIe r7.1 sec 2.3.2), enabling
RRS Software Visibility at the Root Port doesn't mean that every
failed device access has to return 0x0001.
Rather, that value is only returned if the device sent an RRS Completion
to the Root Complex.
It seems support for RRS Completions in Endpoints is optional because the
"Implementation Note: Request Retry Status for Configuration Requests"
at the end of PCIe r7.1 sec 2.3.1 says devices are "permitted" to send
RRS Completions. That's a spec term used if something is optional.
The device may send such Completions, but it doesn't have to.
Also, the device may not be accessible at all, in which case it's sending
no Completion to the Root Complex.
> @@ -1215,7 +1215,8 @@ static int pci_dev_wait(struct pci_dev *dev, char *reset_type, int timeout)
> * If the device is below a Root Port with Configuration RRS
> * Software Visibility enabled, reading the Vendor ID returns a
> * special data value if the device responded with RRS. Read the
> - * Vendor ID until we get non-RRS status.
> + * Vendor ID until we get non-RRS status, then the Command register
> + * as below.
> *
The code comment should be rephrased such that "returns" is replaced
with "may return" because of the optionality of RRS Completions.
> @@ -1235,8 +1236,11 @@ static int pci_dev_wait(struct pci_dev *dev, char *reset_type, int timeout)
>
> if (root && root->config_rrs_sv) {
> pci_read_config_dword(dev, PCI_VENDOR_ID, &id);
> - if (!pci_bus_rrs_vendor_id(id))
> - break;
> + if (!pci_bus_rrs_vendor_id(id)) {
> + pci_read_config_dword(dev, PCI_COMMAND, &id);
> + if (!PCI_POSSIBLE_ERROR(id))
> + break;
> + }
I think it's sufficient if you just change the if-condition like this:
- if (!pci_bus_rrs_vendor_id(id))
+ if (!pci_bus_rrs_vendor_id(id) &&
+ !PCI_POSSIBLE_ERROR(id)) {
I don't see the need for the extra read of the Command register
you're performing.
Thanks,
Lukas
next prev parent reply other threads:[~2026-10-10 18:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-10 16:05 [PATCH 0/2] PCI: Wait after FLR for devices that don't honor Immediate Readiness Alexander Gruhlke
2026-10-10 16:05 ` [PATCH 1/2] PCI: Don't treat ~0 as ready in pci_dev_wait() with RRS SV Alexander Gruhlke
2026-10-10 18:36 ` Lukas Wunner [this message]
2026-10-11 8:24 ` Alexander Gruhlke
2026-10-10 16:05 ` [PATCH 2/2] PCI: Wait for readiness after FLR even with Immediate Readiness Alexander Gruhlke
2026-10-10 17:51 ` Lukas Wunner
2026-10-11 8:25 ` Alexander Gruhlke
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=asqFthqcsDkUU6Sg@wunner.de \
--to=lukas@wunner.de \
--cc=alex@shazbot.org \
--cc=bhelgaas@google.com \
--cc=gruhlke@mailbox.org \
--cc=hui.wang@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=regressions@lists.linux.dev \
/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
all inboxes | Powered by JetHome®