summaryrefslogtreecommitdiffstats
path: root/include/uapi
diff options
context:
space:
mode:
authorRajat Jain <rajatxjain@gmail.com>2014-09-08 14:19:49 -0700
committerBjorn Helgaas <bhelgaas@google.com>2014-09-08 23:05:00 -0600
commit89665a6a71408796565bfd29cfa6a7877b17a667 (patch)
tree95fa4fcde378e302264775083c3234866956f0c9 /include/uapi
parent52addcf9d6669fa439387610bc65c92fa0980cef (diff)
downloadlinux-89665a6a71408796565bfd29cfa6a7877b17a667.tar.gz
linux-89665a6a71408796565bfd29cfa6a7877b17a667.tar.bz2
linux-89665a6a71408796565bfd29cfa6a7877b17a667.zip
PCI: Check only the Vendor ID to identify Configuration Request Retry
Per PCIe r3.0, sec 2.3.2, if a Root Complex - has Configuration Request Retry Status Software Visibility enabled, - issues a Configuration Read of both bytes of the Vendor ID, and - receives a Completion with Configuration Request Retry Status (CRS), it must complete the request to the host by fabricating data of 0x0001 for the Vendor ID and 0xff for any additional bytes in the request. Linux issues a single config read for the four bytes containing the Vendor ID and the Device ID. Previously we checked all four bytes for 0xffff0001 to identify CRS. However, it is only the Vendor ID that really indicates CRS, because it's sufficient to read only those two bytes. Checking the Device ID verifies spec compliance but doesn't add any information. Some Root Complexes appear to indicate CRS by returning 0x0001 for the Vendor ID along with the actual the Device ID. Previously we interpreted that as a valid Vendor/Device ID pair, although 0x0001 is reserved and cannot be a valid Vendor ID. [bhelgaas: changelog] Link: http://lkml.kernel.org/r/4729FC36.3040000@gmail.com Signed-off-by: Rajat Jain <rajatxjain@gmail.com> Signed-off-by: Rajat Jain <rajatjain@juniper.net> Signed-off-by: Guenter Roeck <groeck@juniper.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Diffstat (limited to 'include/uapi')
0 files changed, 0 insertions, 0 deletions