All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Lukas Wunner <lukas@wunner.de>
Cc: Bjorn Helgaas <helgaas@kernel.org>, <linux-pci@vger.kernel.org>,
	"Gregory Price" <gregory.price@memverge.com>,
	Ira Weiny <ira.weiny@intel.com>,
	"Dan Williams" <dan.j.williams@intel.com>,
	Alison Schofield <alison.schofield@intel.com>,
	Vishal Verma <vishal.l.verma@intel.com>,
	Dave Jiang <dave.jiang@intel.com>,
	"Li, Ming" <ming4.li@intel.com>,
	"Hillf Danton" <hdanton@sina.com>,
	Ben Widawsky <bwidawsk@kernel.org>, <linuxarm@huawei.com>,
	<linux-cxl@vger.kernel.org>
Subject: Re: [PATCH v2 04/10] cxl/pci: Use synchronous API for DOE
Date: Tue, 24 Jan 2023 11:01:27 +0000	[thread overview]
Message-ID: <20230124110127.00001de0@Huawei.com> (raw)
In-Reply-To: <b5469cbb8a3e138a1c709ed3eaab02d7ca8e84b2.1674468099.git.lukas@wunner.de>

On Mon, 23 Jan 2023 11:14:00 +0100
Lukas Wunner <lukas@wunner.de> wrote:

> A synchronous API for DOE has just been introduced.  Convert CXL CDAT
> retrieval over to it.
> 
> Tested-by: Ira Weiny <ira.weiny@intel.com>
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>

The clean up here gives opportunities for 'right sizing' at least
the response to reading the header. The others are harder was we
don't know what each one is going to be.

May make more sense as a follow on patch though. 

Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>


> ---
>  drivers/cxl/core/pci.c | 62 ++++++++++++++----------------------------
>  1 file changed, 20 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/cxl/core/pci.c b/drivers/cxl/core/pci.c
> index 57764e9cd19d..a02a2b005e6a 100644
> --- a/drivers/cxl/core/pci.c
> +++ b/drivers/cxl/core/pci.c
> @@ -487,51 +487,26 @@ static struct pci_doe_mb *find_cdat_doe(struct device *uport)
>  		    CXL_DOE_TABLE_ACCESS_TABLE_TYPE_CDATA) |		\
>  	 FIELD_PREP(CXL_DOE_TABLE_ACCESS_ENTRY_HANDLE, (entry_handle)))
>  
> -static void cxl_doe_task_complete(struct pci_doe_task *task)
> -{
> -	complete(task->private);
> -}
> -
> -struct cdat_doe_task {
> -	u32 request_pl;
> -	u32 response_pl[32];
> -	struct completion c;
> -	struct pci_doe_task task;
> -};
> -
> -#define DECLARE_CDAT_DOE_TASK(req, cdt)                       \
> -struct cdat_doe_task cdt = {                                  \
> -	.c = COMPLETION_INITIALIZER_ONSTACK(cdt.c),           \
> -	.request_pl = req,				      \
> -	.task = {                                             \
> -		.prot.vid = PCI_DVSEC_VENDOR_ID_CXL,        \
> -		.prot.type = CXL_DOE_PROTOCOL_TABLE_ACCESS, \
> -		.request_pl = &cdt.request_pl,                \
> -		.request_pl_sz = sizeof(cdt.request_pl),      \
> -		.response_pl = cdt.response_pl,               \
> -		.response_pl_sz = sizeof(cdt.response_pl),    \
> -		.complete = cxl_doe_task_complete,            \
> -		.private = &cdt.c,                            \
> -	}                                                     \
> -}
> -
>  static int cxl_cdat_get_length(struct device *dev,
>  			       struct pci_doe_mb *cdat_doe,
>  			       size_t *length)
>  {
> -	DECLARE_CDAT_DOE_TASK(CDAT_DOE_REQ(0), t);
> +	u32 request = CDAT_DOE_REQ(0);
> +	u32 response[32];

As we aren't now using a single structure for multiple purposes
we should take the opportunity to cleanup the magic sizes (32 dword
is just intended to be 'big enough' for anything we expect to read.
Perhaps even declare a structure for the header case.

struct cdat_header_resp {
	u8 resp_code;
	u8 table_type; /* 0 - CDAT */
	u16 entry_handle; /* 0 - Header */
	u32 cdat_length;
	u8 rev;
	u8 checksum;
	u8 resvd[6];
	u32 sequence;
};

A lot less than 32 dword.



>  	int rc;
>  
> -	rc = pci_doe_submit_task(cdat_doe, &t.task);
> +	rc = pci_doe(cdat_doe, PCI_DVSEC_VENDOR_ID_CXL,
> +		     CXL_DOE_PROTOCOL_TABLE_ACCESS,
> +		     &request, sizeof(request),
> +		     &response, sizeof(response));
>  	if (rc < 0) {
> -		dev_err(dev, "DOE submit failed: %d", rc);
> +		dev_err(dev, "DOE failed: %d", rc);
>  		return rc;
>  	}
> -	wait_for_completion(&t.c);
> -	if (t.task.rv < sizeof(u32))
> +	if (rc < sizeof(u32))
>  		return -EIO;
>  
> -	*length = t.response_pl[1];
> +	*length = response[1];
>  	dev_dbg(dev, "CDAT length %zu\n", *length);
>  
>  	return 0;
> @@ -546,26 +521,29 @@ static int cxl_cdat_read_table(struct device *dev,
>  	int entry_handle = 0;
>  
>  	do {
> -		DECLARE_CDAT_DOE_TASK(CDAT_DOE_REQ(entry_handle), t);
> +		u32 request = CDAT_DOE_REQ(entry_handle);
> +		u32 response[32];
As above, this is still a bit random.
Things we might be reading.
DSMAS: 6 dword
DSLBIS: 6 dword
DSIS: 2 dword
DSEMTS: 6 dword
SSLBIS: 4 dword + 2 * entires dwords.  This can get huge - as
can include p2p as well as the smaller usp / dsp set.

Right now we aren't reading from switches though so we can fix
that later (I posted an RFC for switches ages ago, but haven't
gotten back to it since then)

So for now probably leave this one at the 32 dwords.



>  		size_t entry_dw;
>  		u32 *entry;
>  		int rc;
>  
> -		rc = pci_doe_submit_task(cdat_doe, &t.task);
> +		rc = pci_doe(cdat_doe, PCI_DVSEC_VENDOR_ID_CXL,
> +			     CXL_DOE_PROTOCOL_TABLE_ACCESS,
> +			     &request, sizeof(request),
> +			     &response, sizeof(response));
>  		if (rc < 0) {
> -			dev_err(dev, "DOE submit failed: %d", rc);
> +			dev_err(dev, "DOE failed: %d", rc);
>  			return rc;
>  		}
> -		wait_for_completion(&t.c);
>  		/* 1 DW header + 1 DW data min */
> -		if (t.task.rv < (2 * sizeof(u32)))
> +		if (rc < (2 * sizeof(u32)))
>  			return -EIO;
>  
>  		/* Get the CXL table access header entry handle */
>  		entry_handle = FIELD_GET(CXL_DOE_TABLE_ACCESS_ENTRY_HANDLE,
> -					 t.response_pl[0]);
> -		entry = t.response_pl + 1;
> -		entry_dw = t.task.rv / sizeof(u32);
> +					 response[0]);
> +		entry = response + 1;
> +		entry_dw = rc / sizeof(u32);
>  		/* Skip Header */
>  		entry_dw -= 1;
>  		entry_dw = min(length / sizeof(u32), entry_dw);


  parent reply	other threads:[~2023-01-24 11:01 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-23 10:10 [PATCH v2 00/10] Collection of DOE material Lukas Wunner
2023-01-23 10:11 ` [PATCH v2 01/10] PCI/DOE: Silence WARN splat with CONFIG_DEBUG_OBJECTS=y Lukas Wunner
2023-01-24  0:33   ` Ira Weiny
2023-01-24 10:32     ` Jonathan Cameron
2023-01-25 21:05       ` Lukas Wunner
2023-01-24 16:18   ` Gregory Price
2023-02-10 23:50   ` Dan Williams
2023-01-23 10:12 ` [PATCH v2 02/10] PCI/DOE: Fix memory leak " Lukas Wunner
2023-01-24  0:35   ` Ira Weiny
2023-01-24 10:33     ` Jonathan Cameron
2023-02-10 23:52   ` Dan Williams
2023-01-23 10:13 ` [PATCH v2 03/10] PCI/DOE: Provide synchronous API and use it internally Lukas Wunner
2023-01-24  0:48   ` Ira Weiny
2023-01-24 10:40   ` Jonathan Cameron
2023-01-24 20:07     ` Ira Weiny
2023-02-10 23:57   ` Dan Williams
2023-01-23 10:14 ` [PATCH v2 04/10] cxl/pci: Use synchronous API for DOE Lukas Wunner
2023-01-24  0:52   ` Ira Weiny
2023-02-03  8:53     ` Li, Ming
2023-02-03  8:56       ` Li, Ming
2023-02-03  9:54       ` Lukas Wunner
2023-01-24 11:01   ` Jonathan Cameron [this message]
2023-02-10 22:17     ` Lukas Wunner
2023-01-23 10:15 ` [PATCH v2 05/10] PCI/DOE: Make asynchronous API private Lukas Wunner
2023-01-24  0:55   ` Ira Weiny
2023-01-24 11:03   ` Jonathan Cameron
2023-01-23 10:16 ` [PATCH v2 06/10] PCI/DOE: Allow mailbox creation without devres management Lukas Wunner
2023-01-24 12:15   ` Jonathan Cameron
2023-01-24 12:18     ` Jonathan Cameron
2023-02-03  9:06     ` Li, Ming
2023-02-03  9:09       ` Li, Ming
2023-02-03 10:08       ` Lukas Wunner
2023-02-10 22:03     ` Lukas Wunner
2023-01-23 10:17 ` [PATCH v2 07/10] PCI/DOE: Create mailboxes on device enumeration Lukas Wunner
2023-01-24  1:14   ` Ira Weiny
2023-01-24 12:21   ` Jonathan Cameron
2023-01-23 10:18 ` [PATCH v2 08/10] cxl/pci: Use CDAT DOE mailbox created by PCI core Lukas Wunner
2023-01-24  1:18   ` Ira Weiny
2023-01-24 12:25   ` Jonathan Cameron
2023-01-23 10:19 ` [PATCH v2 09/10] PCI/DOE: Make mailbox creation API private Lukas Wunner
2023-01-24  1:25   ` Ira Weiny
2023-01-24 12:26   ` Jonathan Cameron
2023-01-23 10:20 ` [PATCH v2 10/10] PCI/DOE: Relax restrictions on request and response size Lukas Wunner
2023-01-23 22:29   ` Bjorn Helgaas
2023-01-24  1:43   ` Ira Weiny
2023-02-10 21:47     ` Lukas Wunner
2023-01-24 12:43   ` Jonathan Cameron
2023-01-24 23:51     ` Bjorn Helgaas
2023-01-25  9:47       ` Jonathan Cameron
2023-02-10 22:10       ` Lukas Wunner
2023-01-23 22:30 ` [PATCH v2 00/10] Collection of DOE material Bjorn Helgaas
2023-02-10 21:39   ` Lukas Wunner
2023-02-11  0:04     ` 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=20230124110127.00001de0@Huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=alison.schofield@intel.com \
    --cc=bwidawsk@kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=gregory.price@memverge.com \
    --cc=hdanton@sina.com \
    --cc=helgaas@kernel.org \
    --cc=ira.weiny@intel.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=lukas@wunner.de \
    --cc=ming4.li@intel.com \
    --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.