From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Chris Browy <cbrowy@avery-design.com>
Cc: <mst@redhat.com>, <armbru@redhat.com>, <ben.widawsky@intel.com>,
<dan.j.williams@intel.com>, <david@redhat.com>, <f4bug@amsat.org>,
<hchkuo@avery-design.com.tw>, <imammedo@redhat.com>,
<ira.weiny@intel.com>, <jgroves@micron.com>,
<linux-cxl@vger.kernel.org>, <qemu-devel@nongnu.org>,
<tyshao@avery-design.com.tw>, <vishal.l.verma@intel.com>
Subject: Re: [PATCH v5 cxl2.0-v3-doe 2/6] include/hw/pci: headers for PCIe DOE
Date: Wed, 28 Apr 2021 11:59:44 +0100 [thread overview]
Message-ID: <20210428115944.00004ead@Huawei.com> (raw)
In-Reply-To: <1619457403-12901-1-git-send-email-cbrowy@avery-design.com>
On Mon, 26 Apr 2021 13:16:43 -0400
Chris Browy <cbrowy@avery-design.com> wrote:
> From: hchkuo <hchkuo@avery-design.com.tw>
>
> Macros for the vender ID of PCI-SIG and the size of PCIe Data Object
> Exchange.
The PCI SIG vendor ID is a little tricky to track down as it's only
called out indirectly in PCI specs.
In a similar fashion to what Bjorn asked for in the kernel code, perhaps
a reference to where it is in the DOE ECN would at least reassure people
that 0x0001 definitely is the PCI-SIG?
>
> Signed-off-by: Chris Browy <cbrowy@avery-design.com>
One comment inline.
Jonathan
> ---
> include/hw/pci/pci_ids.h | 2 ++
> include/hw/pci/pcie_regs.h | 3 +++
> 2 files changed, 5 insertions(+)
>
> diff --git a/include/hw/pci/pci_ids.h b/include/hw/pci/pci_ids.h
> index 95f92d98e9..471c915395 100644
> --- a/include/hw/pci/pci_ids.h
> +++ b/include/hw/pci/pci_ids.h
> @@ -157,6 +157,8 @@
>
> /* Vendors and devices. Sort key: vendor first, device next. */
>
> +#define PCI_VENDOR_ID_PCI_SIG 0x0001
> +
> #define PCI_VENDOR_ID_LSI_LOGIC 0x1000
> #define PCI_DEVICE_ID_LSI_53C810 0x0001
> #define PCI_DEVICE_ID_LSI_53C895A 0x0012
> diff --git a/include/hw/pci/pcie_regs.h b/include/hw/pci/pcie_regs.h
> index 1db86b0ec4..5ec7014211 100644
> --- a/include/hw/pci/pcie_regs.h
> +++ b/include/hw/pci/pcie_regs.h
> @@ -179,4 +179,7 @@ typedef enum PCIExpLinkWidth {
> #define PCI_ACS_VER 0x1
> #define PCI_ACS_SIZEOF 8
>
> +/* DOE Capability Register Fields */
> +#define PCI_DOE_SIZEOF 24
I wonder if we should do the same thing as for other cases above and also
have the PCI_DOE_VER defined here?
In theory the SIZEOF only refers to the current version of DOE - it might get
bigger in future...
Jonathan
> +
> #endif /* QEMU_PCIE_REGS_H */
WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Chris Browy <cbrowy@avery-design.com>
Cc: ben.widawsky@intel.com, jgroves@micron.com, david@redhat.com,
qemu-devel@nongnu.org, vishal.l.verma@intel.com, mst@redhat.com,
armbru@redhat.com, linux-cxl@vger.kernel.org, f4bug@amsat.org,
hchkuo@avery-design.com.tw, tyshao@avery-design.com.tw,
imammedo@redhat.com, dan.j.williams@intel.com,
ira.weiny@intel.com
Subject: Re: [PATCH v5 cxl2.0-v3-doe 2/6] include/hw/pci: headers for PCIe DOE
Date: Wed, 28 Apr 2021 11:59:44 +0100 [thread overview]
Message-ID: <20210428115944.00004ead@Huawei.com> (raw)
In-Reply-To: <1619457403-12901-1-git-send-email-cbrowy@avery-design.com>
On Mon, 26 Apr 2021 13:16:43 -0400
Chris Browy <cbrowy@avery-design.com> wrote:
> From: hchkuo <hchkuo@avery-design.com.tw>
>
> Macros for the vender ID of PCI-SIG and the size of PCIe Data Object
> Exchange.
The PCI SIG vendor ID is a little tricky to track down as it's only
called out indirectly in PCI specs.
In a similar fashion to what Bjorn asked for in the kernel code, perhaps
a reference to where it is in the DOE ECN would at least reassure people
that 0x0001 definitely is the PCI-SIG?
>
> Signed-off-by: Chris Browy <cbrowy@avery-design.com>
One comment inline.
Jonathan
> ---
> include/hw/pci/pci_ids.h | 2 ++
> include/hw/pci/pcie_regs.h | 3 +++
> 2 files changed, 5 insertions(+)
>
> diff --git a/include/hw/pci/pci_ids.h b/include/hw/pci/pci_ids.h
> index 95f92d98e9..471c915395 100644
> --- a/include/hw/pci/pci_ids.h
> +++ b/include/hw/pci/pci_ids.h
> @@ -157,6 +157,8 @@
>
> /* Vendors and devices. Sort key: vendor first, device next. */
>
> +#define PCI_VENDOR_ID_PCI_SIG 0x0001
> +
> #define PCI_VENDOR_ID_LSI_LOGIC 0x1000
> #define PCI_DEVICE_ID_LSI_53C810 0x0001
> #define PCI_DEVICE_ID_LSI_53C895A 0x0012
> diff --git a/include/hw/pci/pcie_regs.h b/include/hw/pci/pcie_regs.h
> index 1db86b0ec4..5ec7014211 100644
> --- a/include/hw/pci/pcie_regs.h
> +++ b/include/hw/pci/pcie_regs.h
> @@ -179,4 +179,7 @@ typedef enum PCIExpLinkWidth {
> #define PCI_ACS_VER 0x1
> #define PCI_ACS_SIZEOF 8
>
> +/* DOE Capability Register Fields */
> +#define PCI_DOE_SIZEOF 24
I wonder if we should do the same thing as for other cases above and also
have the PCI_DOE_VER defined here?
In theory the SIZEOF only refers to the current version of DOE - it might get
bigger in future...
Jonathan
> +
> #endif /* QEMU_PCIE_REGS_H */
next prev parent reply other threads:[~2021-04-28 11:01 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-26 16:36 [PATCH v5 cxl2.0-v3-doe 0/6] QEMU PCIe DOE for PCIe 4.0/5.0 and CXL 2.0 Chris Browy
2021-04-26 16:52 ` [PATCH v5 cxl2.0-v3-doe 1/6] standard-headers/linux/pci_regs: PCI header from Linux kernel Chris Browy
2021-04-26 17:16 ` [PATCH v5 cxl2.0-v3-doe 2/6] include/hw/pci: headers for PCIe DOE Chris Browy
2021-04-28 10:59 ` Jonathan Cameron [this message]
2021-04-28 10:59 ` Jonathan Cameron
2021-04-26 17:28 ` [PATCH v5 cxl2.0-v3-doe 3/6] hw/pci: PCIe Data Object Exchange implementation Chris Browy
2021-04-28 13:25 ` Jonathan Cameron
2021-04-28 13:25 ` Jonathan Cameron
2021-04-26 17:33 ` [PATCH v5 cxl2.0-v3-doe 4/6] cxl/compliance: CXL Compliance " Chris Browy
2021-04-28 13:29 ` Jonathan Cameron
2021-04-28 13:29 ` Jonathan Cameron
2021-04-26 17:36 ` [PATCH v5 cxl2.0-v3-doe 5/6] cxl/cdat: CXL CDAT " Chris Browy
2021-04-28 13:47 ` Jonathan Cameron
2021-04-28 13:47 ` Jonathan Cameron
2021-04-26 17:37 ` [PATCH v5 cxl2.0-v3-doe 6/6] test/cdat: CXL CDAT test data Chris Browy
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=20210428115944.00004ead@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=armbru@redhat.com \
--cc=ben.widawsky@intel.com \
--cc=cbrowy@avery-design.com \
--cc=dan.j.williams@intel.com \
--cc=david@redhat.com \
--cc=f4bug@amsat.org \
--cc=hchkuo@avery-design.com.tw \
--cc=imammedo@redhat.com \
--cc=ira.weiny@intel.com \
--cc=jgroves@micron.com \
--cc=linux-cxl@vger.kernel.org \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=tyshao@avery-design.com.tw \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.