Re: PCIe resets/restore and lack of CRS wait

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Thu, 2018-03-22 at 16:12 +1100, Benjamin Herrenschmidt wrote:
> 
> > > I'm keen on doing a rather "blanket" fix by adding a CRS wait inside
> > > pci_dev_restore(). Would you guys agree ?
> > > 
> > > Also why does pci_flr_wait() not use vendor/device ID but instead waits
> > > on the COMMAND register being all 1's ? It's not clear to me ...
> > > VID/DID will give a very specific signature for CRS which is ffff0001
> > > while COMMAND could return all 1's for other reasons (device unplugged
> > > for example).
> > > 
> > 
> > Because if you read vendor id of a virtual function, you get 0xffffffff
> 
> Ah indeed, I forgot about that... 

Actually, that makes me a bit nervous, I wonder if we should limit
that "trick" to VFs and otherwise do the right thing. As per PCIe
spec 3.1a (I haven't looked at 4.0 yet)

<<
stalled while the device completes its self-initialization. Software
that intends to take advantage of
this mechanism must ensure that the first access made to a device
following a valid reset condition is
a Configuration Read Request accessing both bytes of the Vendor ID
field in the device’s
Configuration Space header. For this case only, the Root Complex, if
enabled, will synthesize a
special read-data value for the Vendor ID field to indicate to software
that CRS Completion Status
has been returned by the device. For other Configuration Requests, or
when CRS Software
Visibility is not enabled, the Root Complex will generally re-issue the
Configuration Request until it
completes with a status other than CRS as described in Section 2.3.2.
>>

That tells me that there is no guarantee by spec that we'll get
ffff's, instead we might get HW stalls, or other really nasty
effects when probing a register other than 0 (VID/DID) for CRS.

Cheers,
Ben.