Jonathan Cameron wrote: > On Tue, 2 Apr 2024 10:46:08 -0700 > Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > > > Bjorn Helgaas wrote: > > [..] > > > FWIW, I pinged administration@xxxxxxxxxx and got the response that > > > "1E98h is not a VID in our system, but 1E98 has already been reserved > > > by CXL." > > > > > > I wish there were a clearer public statement of this reservation, but > > > I interpret the response to mean that CXL is not a "Vendor", maybe due > > > to some strict definition of "Vendor," but that PCI-SIG will not > > > assign 0x1e98 to any other vendor. > > > > > > So IMO we should add "#define PCI_VENDOR_ID_CXL 0x1e98" so that if we > > > ever *do* see such an assignment, we'll be more likely to flag it as > > > an issue. > > > > Agree. > > Sorry for late entry on this discussion and I'll be careful what I say > on the history. > > As you've guessed it was "entertaining" and for FWIW that text occurs > in other consortium specs (some predate CXL). > > It's reserved with agreement from the PCI SIG for a strictly defined set > of purposes that does not correspond to those allowed for a normal ID > granted to a vendor member. As you say CXL isn't a vendor (don't ask > how DMTF got a vendor ID - 0x1AB4). > > Hence the naming gymnastics and vague answers to avoid any chance of > lawyers getting involved :( Linux has practical reasons for renaming PCI_DVSEC_VENDOR_ID_CXL to PCI_VENDOR_ID_CXL. By this change Linux is asserting that not only does it expect to find 0x1e98 exclusively used for CXL DVSECs, but it expects to never read "0x1e98" from offset 0 in config space. If someone has reason to believe that assertion is invalid they can speak up here, but otherwise the naming solely reflects Linux's expectation of where it will be used.
