From: "Vincenzo Palazzo" <vincenzopalazzodev@gmail.com>
To: "Peter Geis" <pgwipeout@gmail.com>, "Bjorn Helgaas" <helgaas@kernel.org>
Cc: <kw@linux.com>, <heiko@sntech.de>, <robh@kernel.org>,
<linux-pci@vger.kernel.org>, <shawn.lin@rock-chips.com>,
<linux-kernel@vger.kernel.org>, <lgirdwood@gmail.com>,
<linux-rockchip@lists.infradead.org>, <broonie@kernel.org>,
<bhelgaas@google.com>,
<linux-kernel-mentees@lists.linuxfoundation.org>,
<lpieralisi@kernel.org>, <linux-arm-kernel@lists.infradead.org>,
"Dan Johansen" <strit@manjaro.org>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Will Deacon" <will@kernel.org>,
"Robin Murphy" <robin.murphy@arm.com>
Subject: Re: [PATCH v1] drivers: pci: introduce configurable delay for Rockchip PCIe bus scan
Date: Mon, 15 May 2023 13:04:34 +0200 [thread overview]
Message-ID: <CSMSVO8Z73NV.3MX3FRNO026T9@vincent-arch> (raw)
In-Reply-To: <CAMdYzYqV72=pQa-U3a2N7MZ2ChBNL74QrxHQLbMZJxiftTK9sA@mail.gmail.com>
> >
> > There *is* a way for a PCIe device to say "I need more time". It does
> > this by responding to that Vendor ID config read with Request Retry
> > Status (RRS, aka CRS in older specs), which means "I'm not ready yet,
> > but I will be ready in the future." Adding a delay would definitely
> > make a difference here, so my guess is this is what's happening.
> >
> > Most root complexes return ~0 data to the CPU when a config read
> > terminates with UR or RRS. It sounds like rockchip does this for UR
> > but possibly not for RRS.
> >
> > There is a "RRS Software Visibility" feature, which is supposed to
> > turn the RRS into a special value (Vendor ID == 0x0001), but per [1],
> > rockchip doesn't support it (lspci calls it "CRSVisible").
> >
> > But the CPU load instruction corresponding to the config read has to
> > complete by reading *something* or else be aborted. It sounds like
> > it's aborted in this case. I don't know the arm64 details, but if we
> > could catch that abort and determine that it was an RRS and not a UR,
> > maybe we could fabricate the magic RRS 0x0001 value.
> >
> > imx6q_pcie_abort_handler() does something like that, although I think
> > it's for arm32, not arm64. But obviously we already catch the abort
> > enough to dump the register state and panic, so maybe there's a way to
> > extend that?
>
> Perhaps a hook mechanism that allows drivers to register with the
> serror handler and offer to handle specific errors before the generic
> code causes the system panic?
This sounds to me a good general solution that also help to handle
future HW like this one.
So this is a Concept Ack for me.
Cheers!
Vincent.
WARNING: multiple messages have this Message-ID (diff)
From: "Vincenzo Palazzo" <vincenzopalazzodev@gmail.com>
To: "Peter Geis" <pgwipeout@gmail.com>, "Bjorn Helgaas" <helgaas@kernel.org>
Cc: <kw@linux.com>, <heiko@sntech.de>, <robh@kernel.org>,
<linux-pci@vger.kernel.org>, <shawn.lin@rock-chips.com>,
<linux-kernel@vger.kernel.org>, <lgirdwood@gmail.com>,
<linux-rockchip@lists.infradead.org>, <broonie@kernel.org>,
<bhelgaas@google.com>,
<linux-kernel-mentees@lists.linuxfoundation.org>,
<lpieralisi@kernel.org>, <linux-arm-kernel@lists.infradead.org>,
"Dan Johansen" <strit@manjaro.org>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Will Deacon" <will@kernel.org>,
"Robin Murphy" <robin.murphy@arm.com>
Subject: Re: [PATCH v1] drivers: pci: introduce configurable delay for Rockchip PCIe bus scan
Date: Mon, 15 May 2023 13:04:34 +0200 [thread overview]
Message-ID: <CSMSVO8Z73NV.3MX3FRNO026T9@vincent-arch> (raw)
In-Reply-To: <CAMdYzYqV72=pQa-U3a2N7MZ2ChBNL74QrxHQLbMZJxiftTK9sA@mail.gmail.com>
> >
> > There *is* a way for a PCIe device to say "I need more time". It does
> > this by responding to that Vendor ID config read with Request Retry
> > Status (RRS, aka CRS in older specs), which means "I'm not ready yet,
> > but I will be ready in the future." Adding a delay would definitely
> > make a difference here, so my guess is this is what's happening.
> >
> > Most root complexes return ~0 data to the CPU when a config read
> > terminates with UR or RRS. It sounds like rockchip does this for UR
> > but possibly not for RRS.
> >
> > There is a "RRS Software Visibility" feature, which is supposed to
> > turn the RRS into a special value (Vendor ID == 0x0001), but per [1],
> > rockchip doesn't support it (lspci calls it "CRSVisible").
> >
> > But the CPU load instruction corresponding to the config read has to
> > complete by reading *something* or else be aborted. It sounds like
> > it's aborted in this case. I don't know the arm64 details, but if we
> > could catch that abort and determine that it was an RRS and not a UR,
> > maybe we could fabricate the magic RRS 0x0001 value.
> >
> > imx6q_pcie_abort_handler() does something like that, although I think
> > it's for arm32, not arm64. But obviously we already catch the abort
> > enough to dump the register state and panic, so maybe there's a way to
> > extend that?
>
> Perhaps a hook mechanism that allows drivers to register with the
> serror handler and offer to handle specific errors before the generic
> code causes the system panic?
This sounds to me a good general solution that also help to handle
future HW like this one.
So this is a Concept Ack for me.
Cheers!
Vincent.
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
WARNING: multiple messages have this Message-ID (diff)
From: "Vincenzo Palazzo" <vincenzopalazzodev@gmail.com>
To: "Peter Geis" <pgwipeout@gmail.com>, "Bjorn Helgaas" <helgaas@kernel.org>
Cc: kw@linux.com, heiko@sntech.de, Will Deacon <will@kernel.org>,
robh@kernel.org, linux-pci@vger.kernel.org,
shawn.lin@rock-chips.com, linux-kernel@vger.kernel.org,
lgirdwood@gmail.com, linux-rockchip@lists.infradead.org,
broonie@kernel.org, Catalin Marinas <catalin.marinas@arm.com>,
bhelgaas@google.com, Robin Murphy <robin.murphy@arm.com>,
linux-kernel-mentees@lists.linuxfoundation.org,
lpieralisi@kernel.org, linux-arm-kernel@lists.infradead.org,
Dan Johansen <strit@manjaro.org>
Subject: Re: [PATCH v1] drivers: pci: introduce configurable delay for Rockchip PCIe bus scan
Date: Mon, 15 May 2023 13:04:34 +0200 [thread overview]
Message-ID: <CSMSVO8Z73NV.3MX3FRNO026T9@vincent-arch> (raw)
In-Reply-To: <CAMdYzYqV72=pQa-U3a2N7MZ2ChBNL74QrxHQLbMZJxiftTK9sA@mail.gmail.com>
> >
> > There *is* a way for a PCIe device to say "I need more time". It does
> > this by responding to that Vendor ID config read with Request Retry
> > Status (RRS, aka CRS in older specs), which means "I'm not ready yet,
> > but I will be ready in the future." Adding a delay would definitely
> > make a difference here, so my guess is this is what's happening.
> >
> > Most root complexes return ~0 data to the CPU when a config read
> > terminates with UR or RRS. It sounds like rockchip does this for UR
> > but possibly not for RRS.
> >
> > There is a "RRS Software Visibility" feature, which is supposed to
> > turn the RRS into a special value (Vendor ID == 0x0001), but per [1],
> > rockchip doesn't support it (lspci calls it "CRSVisible").
> >
> > But the CPU load instruction corresponding to the config read has to
> > complete by reading *something* or else be aborted. It sounds like
> > it's aborted in this case. I don't know the arm64 details, but if we
> > could catch that abort and determine that it was an RRS and not a UR,
> > maybe we could fabricate the magic RRS 0x0001 value.
> >
> > imx6q_pcie_abort_handler() does something like that, although I think
> > it's for arm32, not arm64. But obviously we already catch the abort
> > enough to dump the register state and panic, so maybe there's a way to
> > extend that?
>
> Perhaps a hook mechanism that allows drivers to register with the
> serror handler and offer to handle specific errors before the generic
> code causes the system panic?
This sounds to me a good general solution that also help to handle
future HW like this one.
So this is a Concept Ack for me.
Cheers!
Vincent.
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
WARNING: multiple messages have this Message-ID (diff)
From: "Vincenzo Palazzo" <vincenzopalazzodev@gmail.com>
To: "Peter Geis" <pgwipeout@gmail.com>, "Bjorn Helgaas" <helgaas@kernel.org>
Cc: <kw@linux.com>, <heiko@sntech.de>, <robh@kernel.org>,
<linux-pci@vger.kernel.org>, <shawn.lin@rock-chips.com>,
<linux-kernel@vger.kernel.org>, <lgirdwood@gmail.com>,
<linux-rockchip@lists.infradead.org>, <broonie@kernel.org>,
<bhelgaas@google.com>,
<linux-kernel-mentees@lists.linuxfoundation.org>,
<lpieralisi@kernel.org>, <linux-arm-kernel@lists.infradead.org>,
"Dan Johansen" <strit@manjaro.org>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Will Deacon" <will@kernel.org>,
"Robin Murphy" <robin.murphy@arm.com>
Subject: Re: [PATCH v1] drivers: pci: introduce configurable delay for Rockchip PCIe bus scan
Date: Mon, 15 May 2023 13:04:34 +0200 [thread overview]
Message-ID: <CSMSVO8Z73NV.3MX3FRNO026T9@vincent-arch> (raw)
In-Reply-To: <CAMdYzYqV72=pQa-U3a2N7MZ2ChBNL74QrxHQLbMZJxiftTK9sA@mail.gmail.com>
> >
> > There *is* a way for a PCIe device to say "I need more time". It does
> > this by responding to that Vendor ID config read with Request Retry
> > Status (RRS, aka CRS in older specs), which means "I'm not ready yet,
> > but I will be ready in the future." Adding a delay would definitely
> > make a difference here, so my guess is this is what's happening.
> >
> > Most root complexes return ~0 data to the CPU when a config read
> > terminates with UR or RRS. It sounds like rockchip does this for UR
> > but possibly not for RRS.
> >
> > There is a "RRS Software Visibility" feature, which is supposed to
> > turn the RRS into a special value (Vendor ID == 0x0001), but per [1],
> > rockchip doesn't support it (lspci calls it "CRSVisible").
> >
> > But the CPU load instruction corresponding to the config read has to
> > complete by reading *something* or else be aborted. It sounds like
> > it's aborted in this case. I don't know the arm64 details, but if we
> > could catch that abort and determine that it was an RRS and not a UR,
> > maybe we could fabricate the magic RRS 0x0001 value.
> >
> > imx6q_pcie_abort_handler() does something like that, although I think
> > it's for arm32, not arm64. But obviously we already catch the abort
> > enough to dump the register state and panic, so maybe there's a way to
> > extend that?
>
> Perhaps a hook mechanism that allows drivers to register with the
> serror handler and offer to handle specific errors before the generic
> code causes the system panic?
This sounds to me a good general solution that also help to handle
future HW like this one.
So this is a Concept Ack for me.
Cheers!
Vincent.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-05-15 11:04 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-09 15:39 [PATCH v1] drivers: pci: introduce configurable delay for Rockchip PCIe bus scan Vincenzo Palazzo
2023-05-09 15:39 ` Vincenzo Palazzo
2023-05-09 15:39 ` Vincenzo Palazzo
2023-05-09 21:19 ` Bjorn Helgaas
2023-05-09 21:19 ` Bjorn Helgaas
2023-05-09 21:19 ` Bjorn Helgaas
2023-05-10 0:11 ` Peter Geis
2023-05-10 0:11 ` Peter Geis
2023-05-10 0:11 ` Peter Geis
2023-05-10 11:16 ` Vincenzo Palazzo
2023-05-10 11:16 ` Vincenzo Palazzo
2023-05-10 11:16 ` Vincenzo Palazzo
2023-05-10 19:46 ` Peter Geis
2023-05-10 19:46 ` Peter Geis
2023-05-10 19:46 ` Peter Geis
2023-05-10 20:47 ` Bjorn Helgaas
2023-05-10 20:47 ` Bjorn Helgaas
2023-05-10 20:47 ` Bjorn Helgaas
2023-05-11 1:07 ` Peter Geis
2023-05-11 1:07 ` Peter Geis
2023-05-11 1:07 ` Peter Geis
2023-05-12 10:46 ` Vincenzo Palazzo
2023-05-12 10:46 ` Vincenzo Palazzo
2023-05-12 10:46 ` Vincenzo Palazzo
2023-05-13 1:24 ` Bjorn Helgaas
2023-05-13 1:24 ` Bjorn Helgaas
2023-05-13 1:24 ` Bjorn Helgaas
2023-05-13 11:40 ` Peter Geis
2023-05-13 11:40 ` Peter Geis
2023-05-13 11:40 ` Peter Geis
2023-05-15 11:04 ` Vincenzo Palazzo [this message]
2023-05-15 11:04 ` Vincenzo Palazzo
2023-05-15 11:04 ` Vincenzo Palazzo
2023-05-15 11:04 ` Vincenzo Palazzo
2023-05-15 16:51 ` Bjorn Helgaas
2023-05-15 16:51 ` Bjorn Helgaas
2023-05-15 16:51 ` Bjorn Helgaas
2023-05-15 16:51 ` Bjorn Helgaas
2023-05-15 20:52 ` Peter Geis
2023-05-15 20:52 ` Peter Geis
2023-05-15 20:52 ` Peter Geis
2023-05-15 20:52 ` Peter Geis
2023-07-12 15:42 ` Vincenzo Palazzo
2023-07-12 15:42 ` Vincenzo Palazzo
2023-07-12 15:42 ` Vincenzo Palazzo
2023-07-12 15:42 ` Vincenzo Palazzo
2023-05-10 11:35 ` Vincenzo Palazzo
2023-05-10 11:35 ` Vincenzo Palazzo
2023-05-10 11:35 ` Vincenzo Palazzo
2023-05-12 16:40 ` Vincenzo Palazzo
2023-05-12 16:40 ` Vincenzo Palazzo
2023-05-12 16:40 ` Vincenzo Palazzo
2023-05-10 7:57 ` Greg KH
2023-05-10 7:57 ` Greg KH
2023-05-10 7:57 ` Greg KH
2023-05-10 10:49 ` Vincenzo Palazzo
2023-05-10 10:49 ` Vincenzo Palazzo
2023-05-10 10:49 ` Vincenzo Palazzo
2023-11-20 4:15 ` Tom Fitzhenry
2023-11-20 4:15 ` Tom Fitzhenry
2023-11-20 4:15 ` Tom Fitzhenry
2023-11-20 4:15 ` Tom Fitzhenry
-- strict thread matches above, loose matches on Subject: below --
2023-05-01 20:14 Vincenzo Palazzo
2023-05-01 20:14 ` Vincenzo Palazzo
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=CSMSVO8Z73NV.3MX3FRNO026T9@vincent-arch \
--to=vincenzopalazzodev@gmail.com \
--cc=bhelgaas@google.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=heiko@sntech.de \
--cc=helgaas@kernel.org \
--cc=kw@linux.com \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel-mentees@lists.linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=lpieralisi@kernel.org \
--cc=pgwipeout@gmail.com \
--cc=robh@kernel.org \
--cc=robin.murphy@arm.com \
--cc=shawn.lin@rock-chips.com \
--cc=strit@manjaro.org \
--cc=will@kernel.org \
/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.