From: Bjorn Helgaas <helgaas@kernel.org>
To: Sean V Kelley <sean.v.kelley@linux.intel.com>
Cc: Jay Fang <f.fangjian@huawei.com>,
mj@ucw.cz, linux-pci@vger.kernel.org,
huangdaode <huangdaode@hisilicon.com>
Subject: Re: [PATCH v5 2/2] pciutils: Decode Compute eXpress Link DVSEC
Date: Mon, 20 Apr 2020 12:47:47 -0500 [thread overview]
Message-ID: <20200420174747.GA48539@google.com> (raw)
In-Reply-To: <B647B03B-9476-4D31-9662-4D68E7204459@linux.intel.com>
Hi Jay, thanks for taking a look at this!
On Mon, Apr 20, 2020 at 09:21:27AM -0700, Sean V Kelley wrote:
> On 18 Apr 2020, at 1:36, Jay Fang wrote:
> > On 2020/4/15 8:47, Sean V Kelley wrote:
> > >
> > > [1] https://www.computeexpresslink.org/
> > >
> > > Signed-off-by: Sean V Kelley <sean.v.kelley@linux.intel.com>
> > > ---
> > > lib/header.h | 20 +++
> >
> > > +
> > > +static int
> > > +is_cxl_cap(struct device *d, int where)
> > > +{
> > > + u32 hdr;
> > > + u16 w;
> > > +
> > > + if (!config_fetch(d, where + PCI_DVSEC_HEADER1, 8))
> > > + return 0;
> > > +
> > > + /* Check for supported Vendor */
> > > + hdr = get_conf_long(d, where + PCI_DVSEC_HEADER1);
> > > + w = BITS(hdr, 0, 16);
> > > + if (w != PCI_VENDOR_ID_INTEL)
> >
> > I don't think here checking is quite right. Does only Intel support CXL?
> > Other Vendors should also be considered.
>
> In the absence of currently available hardware, I was attempting to limit
> false positive noise. I’m happy to avoid the check on the vendor if there
> were to exist a definitive supported list. Bjorn suggested that I check for
> vendor ID with DVSEC ID for now. As hardware enters the market, I can
> surely revise this with an update when the CXL group publishes a list.
The Vendor ID check cannot be avoided. Vendor IDs are allocated by
the PCI-SIG, but the DVSEC ID is vendor-defined so there cannot be a
global "CXL capability" DVSEC ID.
CXL *could* work through the PCI-SIG and define a new CXL Extended
Capability that could make this generic. But apparently they've
chosen to use the DVSEC mechanism instead.
> > > + /* Check for Designated Vendor-Specific ID */
> > > + hdr = get_conf_long(d, where + PCI_DVSEC_HEADER2);
> > > + w = BITS(hdr, 0, 16);
> > > + if (w == PCI_DVSEC_ID)
However, this is slightly wrong. The name "PCI_DVSEC_ID" implies that
there can only be one DVSEC ID and it is vendor-independent, but
neither is true.
This value is allocated by Intel, so we must check for the Intel
Vendor ID first. And Intel may define several DVSEC capabilities for
different purposes, so the name should also mention CXL.
So this should be "PCI_DVSEC_INTEL_CXL" or something similar.
But that doesn't mean other vendors need to define their own DVSEC
IDs for CXL. The spec (PCIe r5.0, sec 7.9.6) says:
[The DVSEC Capability] allows PCI Express component vendors to use
the Extended Capability mechanism to expose vendor-specific
registers that can be present in components by a variety of
vendors.
Any vendor that implements this CXL DVSEC the same way Intel does can
tag it with PCI_VENDOR_ID_INTEL and PCI_DVSEC_INTEL_CXL.
Note that there are two types of vendor-specific capabilities:
1) Vendor-Specific Extended Capability (VSEC). The structure and
definition are defined by the *Function* Vendor ID (from offset 0 in
config space) and the VSEC ID in the capability.
2) Designated Vendor-Specific Extended Capability (DVSEC). The
structure and definition are defined by the *DVSEC* Vendor ID (from
the DVSEC capability, *not* the vendor of the Function) and the
DVSEC ID in the capability.
This CXL capability is the latter, of course.
Bjorn
next prev parent reply other threads:[~2020-04-20 17:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-15 0:47 [PATCH v5 0/2] pciutils: Add basic decode support for CXL DVSEC Sean V Kelley
2020-04-15 0:47 ` [PATCH v5 1/2] pciutils: Decode available DVSEC details Sean V Kelley
2020-04-15 0:47 ` [PATCH v5 2/2] pciutils: Decode Compute eXpress Link DVSEC Sean V Kelley
2020-04-18 8:36 ` Jay Fang
2020-04-20 16:21 ` Sean V Kelley
2020-04-20 17:47 ` Bjorn Helgaas [this message]
2020-04-20 17:54 ` Sean V Kelley
2020-04-27 3:22 ` Jay Fang
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=20200420174747.GA48539@google.com \
--to=helgaas@kernel.org \
--cc=f.fangjian@huawei.com \
--cc=huangdaode@hisilicon.com \
--cc=linux-pci@vger.kernel.org \
--cc=mj@ucw.cz \
--cc=sean.v.kelley@linux.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 NNTP newsgroup(s).