Re: [PATCH v2 1/3] PCI: Add check for CXL Secondary Bus Reset

Jonathan Cameron
2024-04-04T13:52:46Z

On Thu, 4 Apr 2024 11:02:10 +0200
Lukas Wunner <lukas@wunner.de> wrote:

> On Wed, Apr 03, 2024 at 03:44:41PM +0100, Jonathan Cameron wrote:
> > > Bjorn Helgaas wrote:
> > > > FWIW, I pinged administration@pcisig.com 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