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

From: Dan Williams <dan.j.williams@intel.com>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	Dan Williams <dan.j.williams@intel.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
	Dave Jiang <dave.jiang@intel.com>, <linux-cxl@vger.kernel.org>,
	<linux-pci@vger.kernel.org>, <ira.weiny@intel.com>,
	<vishal.l.verma@intel.com>, <alison.schofield@intel.com>,
	<dave@stgolabs.net>, <bhelgaas@google.com>, <lukas@wunner.de>
Subject: Re: [PATCH v2 1/3] PCI: Add check for CXL Secondary Bus Reset
Date: Wed, 3 Apr 2024 13:36:03 -0700	[thread overview]
Message-ID: <660dbdb36159_15786294a8@dwillia2-mobl3.amr.corp.intel.com.notmuch> (raw)
In-Reply-To: <20240403154441.00002e30@Huawei.com>

Jonathan Cameron wrote:
> On Tue, 2 Apr 2024 10:46:08 -0700
> Dan Williams <dan.j.williams@intel.com> 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.  
> > 
> > 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.