I apologize for completely dropping the ball on this one. I don't
remember why, but I *do* remember one issue that we should clear up:
On Sat, Mar 07, 2020 at 06:20:44PM +0100, Stanislav Spassov wrote:
> From: Stanislav Spassov <stanspas@xxxxxxxxx>
>
> The PCI Express specification dictates minimal amounts of time that the
> host needs to wait after triggering different kinds of resets before it
> is allowed to attempt accessing the device. After this waiting period,
> devices are required to be responsive to Configuration Space reads.
> However, if a device needs more time to actually complete the reset
> operation internally, it may respond to the read with a Completion
> Request Retry Status (CRS), and keep doing so on subsequent reads
> for as long as necessary. If the device is broken, it may even keep
> responding with CRS indefinitely.
>
> The specification also mandates that any Root Port that supports CRS
> and has CRS Software Visibility (CRS SV) enabled will synthesize the
> special value 0x0001 for the Vendor ID and set any other bits to 1
> upon receiving a CRS Completion for a Configuration Read Request that
> includes both bytes of the Vendor ID (offset 0).
>
> If CRS SV is disabled or a different register (not Vendor ID) is being
> read, the request is retried autonomously by the Root Port.
> Platform-specific configuration registers may exist to limit the number
> of or time taken by such retries.
I think the Root Complex may eventually complete the transaction as
failed *regardless* of whether CRS SV is enabled. This is unclear in
PCIe r5.0, sec 2.3.2, because the text formatting was broken between
r4.0 and r5.0. The r4.0 text is formatted like this:
Root Complex handling of a Completion with Configuration Request
Retry Status for a Configuration Request is implementation specific,
except for the period following system reset (see Section 6.6). For
Root Complexes that support CRS Software Visibility, the following
rules apply:
* If CRS Software Visibility is not enabled, the Root Complex must
re-issue the Configuration Request as a new Request.
* If CRS Software Visibility is enabled (see below):
- For a Configuration Read Request that includes both bytes of
the Vendor ID field of a device Function’s Configuration Space
Header, the Root Complex must complete the Request to the host
by returning a read-data value of 0001h for the Vendor ID
field and all ‘1’s for any additional bytes included in the
request. This read-data value has been reserved specifically
for this use by the PCI-SIG and does not correspond to any
assigned Vendor ID.
- For a Configuration Write Request or for any other
Configuration Read Request, the Root Complex must re-issue the
Configuration Request as a new Request.
A Root Complex implementation may choose to limit the number of
Configuration Request/CRS Completion Status loops before determining
that something is wrong with the target of the Request and taking
appropriate action, e.g., complete the Request to the host as a
failed transaction.
I reported this to the PCI-SIG, and I think the formatting did get
fixed for the upcoming PCIe r6 spec, so the meaning will be the same
as r4.0
Probably doesn't affect this patch, but we can clarify some of the
commentary.
Bjorn
