linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jay Fang <f.fangjian@huawei.com>
To: Bjorn Helgaas <helgaas@kernel.org>,
	Sean V Kelley <sean.v.kelley@linux.intel.com>
Cc: <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, 27 Apr 2020 11:22:28 +0800	[thread overview]
Message-ID: <6bb98f80-2c8d-cfd5-7ebf-c1365485c9c8@huawei.com> (raw)
In-Reply-To: <20200420174747.GA48539@google.com>

Got it.
Bjorn, thanks.

Jay

On 2020/4/21 1:47, Bjorn Helgaas wrote:
> 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
> 
> .
> 


      parent reply	other threads:[~2020-04-27  3:22 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
2020-04-20 17:54         ` Sean V Kelley
2020-04-27  3:22         ` Jay Fang [this message]

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=6bb98f80-2c8d-cfd5-7ebf-c1365485c9c8@huawei.com \
    --to=f.fangjian@huawei.com \
    --cc=helgaas@kernel.org \
    --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).