From: Bjorn Helgaas <helgaas@kernel.org>
To: Vidya Sagar <vidyas@nvidia.com>
Cc: bhelgaas@google.com, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, treding@nvidia.com,
jonathanh@nvidia.com, kthota@nvidia.com, mmaddireddy@nvidia.com,
sagar.tv@gmail.com
Subject: Re: [PATCH V2] PCI: Clear errors logged in Secondary Status Register
Date: Tue, 23 Apr 2024 16:09:54 -0500 [thread overview]
Message-ID: <20240423210954.GA467443@bhelgaas> (raw)
In-Reply-To: <20240116143258.483235-1-vidyas@nvidia.com>
On Tue, Jan 16, 2024 at 08:02:58PM +0530, Vidya Sagar wrote:
> The enumeration process leaves the 'Received Master Abort' bit set in
> the Secondary Status Register of the downstream port in the following
> scenarios.
>
> (1) The device connected to the downstream port has ARI capability
> and that makes the kernel set the 'ARI Forwarding Enable' bit in
> the Device Control 2 Register of the downstream port. This
> effectively makes the downstream port forward the configuration
> requests targeting the devices downstream of it, even though they
> don't exist in reality. It causes the downstream devices return
> completions with UR set in the status in turn causing 'Received
> Master Abort' bit set.
>
> In contrast, if the downstream device doesn't have ARI capability,
> the 'ARI Forwarding Enable' bit in the downstream port is not set
> and any configuration requests targeting the downstream devices
> that don't exist are terminated (section 6.13 of PCI Express Base
> 6.0 spec) in the downstream port itself resulting in no change of
> the 'Received Master Abort' bit.
>
> (2) A PCIe switch is connected to the downstream port and when the
> enumeration flow tries to explore the presence of devices that
> don't really exist downstream of the switch, the downstream
> port receives the completions with UR set causing the 'Received
> Master Abort' bit set.
>
> Clear 'Received Master Abort' bit to keep the bridge device in a clean
> state post enumeration.
>
> Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Applied to pci/enumeration for v6.10, thanks!
I shortened the commit log because I think this happens all the time,
not just in the specific cases you mentioned above:
PCI: Clear Secondary Status errors after enumeration
We enumerate devices by attempting config reads to the Vendor ID of each
possible device. On conventional PCI, if no device responds, the read
terminates with a Master Abort (PCI r3.0, sec 6.1). On PCIe, the config
read is terminated as an Unsupported Request (PCIe r6.0, sec 2.3.2,
7.5.1.3.7). In either case, if the read addressed a device below a bridge,
it is logged by setting "Received Master Abort" in the bridge Secondary
Status register.
Clear any errors logged in the Secondary Status register after enumeration.
> ---
> V2:
> * Changed commit message based on Bjorn's feedback
>
> drivers/pci/probe.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 795534589b98..640d2871b061 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1470,6 +1470,9 @@ static int pci_scan_bridge_extend(struct pci_bus *bus, struct pci_dev *dev,
> }
>
> out:
> + /* Clear errors in the Secondary Status Register */
> + pci_write_config_word(dev, PCI_SEC_STATUS, 0xffff);
> +
> pci_write_config_word(dev, PCI_BRIDGE_CONTROL, bctl);
>
> pm_runtime_put(&dev->dev);
> --
> 2.25.1
>
prev parent reply other threads:[~2024-04-23 21:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-04 1:32 [PATCH V1] PCI: Clear errors logged in Secondary Status Register Vidya Sagar
2024-01-12 13:57 ` Vidya Sagar
2024-01-12 17:06 ` Bjorn Helgaas
2024-01-16 13:54 ` Vidya Sagar
2024-01-16 14:32 ` [PATCH V2] " Vidya Sagar
2024-01-22 23:00 ` Bjorn Helgaas
2024-03-14 0:39 ` Vidya Sagar
2024-04-01 7:59 ` Vidya Sagar
2024-04-18 10:52 ` Vidya Sagar
2024-04-23 21:09 ` Bjorn Helgaas [this message]
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=20240423210954.GA467443@bhelgaas \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=jonathanh@nvidia.com \
--cc=kthota@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mmaddireddy@nvidia.com \
--cc=sagar.tv@gmail.com \
--cc=treding@nvidia.com \
--cc=vidyas@nvidia.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).