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
>
> .
>
prev 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).