From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Lukas Wunner <lukas@wunner.de>
Cc: Dan Williams <dan.j.williams@intel.com>,
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>
Subject: Re: [PATCH v2 1/3] PCI: Add check for CXL Secondary Bus Reset
Date: Thu, 4 Apr 2024 14:52:42 +0100 [thread overview]
Message-ID: <20240404145242.00002dd8@Huawei.com> (raw)
In-Reply-To: <Zg5skrUCyx17fRjq@wunner.de>
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
next prev parent reply other threads:[~2024-04-04 13:52 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-25 23:58 [PATCH 0/3 v2] PCI: Add Secondary Bus Reset (SBR) support for CXL Dave Jiang
2024-03-25 23:58 ` [PATCH v2 1/3] PCI: Add check for CXL Secondary Bus Reset Dave Jiang
2024-03-27 21:26 ` Bjorn Helgaas
2024-03-27 23:57 ` Dave Jiang
2024-03-28 17:38 ` Bjorn Helgaas
2024-03-28 19:03 ` Dan Williams
2024-03-28 19:14 ` Bjorn Helgaas
2024-04-02 17:23 ` Bjorn Helgaas
2024-04-02 17:46 ` Dan Williams
2024-04-03 14:44 ` Jonathan Cameron
2024-04-03 20:36 ` Dan Williams
2024-04-04 9:02 ` Lukas Wunner
2024-04-04 13:52 ` Jonathan Cameron [this message]
2024-03-28 1:43 ` Dan Williams
2024-03-25 23:58 ` [PATCH v2 2/3] PCI: Create new reset method to force SBR for CXL Dave Jiang
2024-03-28 1:53 ` Dan Williams
2024-03-25 23:58 ` [PATCH v2 3/3] cxl: Add post reset warning if reset is detected as Secondary Bus Reset (SBR) Dave Jiang
2024-03-28 2:03 ` Dan Williams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240404145242.00002dd8@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=alison.schofield@intel.com \
--cc=bhelgaas@google.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=helgaas@kernel.org \
--cc=ira.weiny@intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=vishal.l.verma@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).