On Thu, 4 Apr 2024 11:02:10 +0200 Lukas Wunner <lukas@xxxxxxxxx> wrote: > On Wed, Apr 03, 2024 at 03:44:41PM +0100, Jonathan Cameron 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. > > > > 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 :( > > Hm, I'm wondering if avoiding the term "vendor" with something like > > #define PCI_CONSORTIUM_ID_CXL 0x1e98 > > would assuage the angst of a legal misstep? ;) Works for me, but I really hope we don't have to care :( Jonathan
