linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ira Weiny <ira.weiny@intel.com>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Lukas Wunner <lukas@wunner.de>,
	Alison Schofield <alison.schofield@intel.com>,
	Vishal Verma <vishal.l.verma@intel.com>,
	"Dave Jiang" <dave.jiang@intel.com>,
	Ben Widawsky <bwidawsk@kernel.org>,
	<linux-kernel@vger.kernel.org>, <linux-cxl@vger.kernel.org>,
	<linux-pci@vger.kernel.org>
Subject: Re: [PATCH V12 6/9] cxl/port: Read CDAT table
Date: Wed, 29 Jun 2022 20:35:34 -0700	[thread overview]
Message-ID: <Yr0aBnTJtFXrCUSM@iweiny-desk3> (raw)
In-Reply-To: <20220628154727.0000021c@Huawei.com>

On Tue, Jun 28, 2022 at 03:47:27PM +0100, Jonathan Cameron wrote:
> On Mon, 27 Jun 2022 21:15:24 -0700
> ira.weiny@intel.com wrote:
> 
> > From: Ira Weiny <ira.weiny@intel.com>
> > 
> > The OS will need CDAT data from CXL devices to properly set up
> > interleave sets.  Currently this is supported through a DOE mailbox
> > which supports CDAT.
> > 
> > Search the DOE mailboxes available, query CDAT data, and cache the data
> > for later parsing.
> > 
> > Provide a sysfs binary attribute to allow dumping of the CDAT.
> > 
> > Binary dumping is modeled on /sys/firmware/ACPI/tables/
> > 
> > The ability to dump this table will be very useful for emulation of real
> > devices once they become available as QEMU CXL type 3 device emulation will
> > be able to load this file in.
> > 
> > This does not support table updates at runtime. It will always provide
> > whatever was there when first cached. Handling of table updates can be
> > implemented later.
> > 
> > Finally create a complete list of CDAT defines within cdat.h for code
> > wishing to decode the CDAT table.
> > 
> > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > Co-developed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > Signed-off-by: Ira Weiny <ira.weiny@intel.com>
> 
> One query inline, though I'm fine with it either way, just want to
> understand your logic in keeping completion when Dan suggested using
> flush_work() to achieve the same thing.
> 
> > 
> > ---
> > Changes from V11:
> > 	Adjust for the use of DOE mailbox xarray
> > 	Dan Williams:
> > 		Remove unnecessary get/put device
> > 		Use new BIN_ATTR_ADMIN_RO macro
> > 		Flag that CDAT was supported
> > 			If there is a read error then the CDAT sysfs
> > 			will return a 0 length entry
> > 
> ...
> > diff --git a/drivers/cxl/core/pci.c b/drivers/cxl/core/pci.c
> > index c4c99ff7b55e..4bd479ec0253 100644
> > --- a/drivers/cxl/core/pci.c
> > +++ b/drivers/cxl/core/pci.c
> > @@ -4,10 +4,12 @@
> 
> > +static int cxl_cdat_get_length(struct device *dev,
> > +			       struct pci_doe_mb *cdat_mb,
> > +			       size_t *length)
> > +{
> > +	u32 cdat_request_pl = CDAT_DOE_REQ(0);
> > +	u32 cdat_response_pl[32];
> > +	DECLARE_COMPLETION_ONSTACK(c);
> > +	struct pci_doe_task task = {
> > +		.prot.vid = PCI_DVSEC_VENDOR_ID_CXL,
> > +		.prot.type = CXL_DOE_PROTOCOL_TABLE_ACCESS,
> > +		.request_pl = &cdat_request_pl,
> > +		.request_pl_sz = sizeof(cdat_request_pl),
> > +		.response_pl = cdat_response_pl,
> > +		.response_pl_sz = sizeof(cdat_response_pl),
> > +		.complete = cxl_doe_task_complete,
> > +		.private = &c,
> > +	};
> > +	int rc = 0;
> > +
> > +	rc = pci_doe_submit_task(cdat_mb, &task);
> > +	if (rc < 0) {
> > +		dev_err(dev, "DOE submit failed: %d", rc);
> > +		return rc;
> > +	}
> > +	wait_for_completion(&c);
> 
> Dan mentioned in his review that we could just use
> flush_work() and drop the completion logic and callback.
> Why didn't you go that way?  Would want to wrap it up
> in pci_doe_wait_task() or something like that.

In early reviews of the Aux Bus work Dan also specified the above design
pattern.

	"I would expect that the caller of this routine [pci_doe_exchange_sync]
	would want to specify the task and end_task() callback and use that as
	the completion signal.  It may also want "no wait" behavior where it is
	prepared for the DOE result to come back sometime later. With that
	change the exchange fields can move into the task directly."

	-- https://lore.kernel.org/linux-cxl/CAPcyv4hYAgyf-WcArGvbWHAJgc5+p=OO_6ah_dXJhNM5cXcVTw@mail.gmail.com/

I've renamed pci_doe_exchange_sync() pci_doe_submit_task() because of other
feedback.  Here the callback is set to cxl_doe_task_complete() and we have to
wait because this particular query needs the length prior to the next task
being issued.

I use flush_workqueue() within the shutdown handling (or if someone destroys
the mailbox or abort fails) to first block new work from being submitted
(PCI_DOE_FLAG_DEAD), cancel the running work if needed (PCI_DOE_FLAG_CANCEL
[was ABORT]), and then flush the queue causing all the pending work to error
when seeing PCI_DOE_FLAG_DEAD.

Ira

> 
> > +
> > +	if (task.rv < 1)
> > +		return -EIO;
> > +
> > +	*length = cdat_response_pl[1];
> > +	dev_dbg(dev, "CDAT length %zu\n", *length);
> > +
> > +	return rc;
> > +}
> > +

  reply	other threads:[~2022-06-30  3:36 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-28  4:15 [PATCH V12 0/9] CXL: Read CDAT and DSMAS data ira.weiny
2022-06-28  4:15 ` [PATCH V12 1/9] PCI: Add vendor ID for the PCI SIG ira.weiny
2022-06-28  4:15 ` [PATCH V12 2/9] PCI: Replace magic constant for PCI Sig Vendor ID ira.weiny
2022-06-28  4:15 ` [PATCH V12 3/9] PCI: Create PCIe library functions in support of DOE mailboxes ira.weiny
2022-06-28 14:16   ` Jonathan Cameron
2022-06-28 14:56     ` Bjorn Helgaas
2022-06-28 18:20     ` Ira Weiny
2022-06-29 14:09       ` Jonathan Cameron
2022-06-30  4:34         ` Ira Weiny
2022-06-30 15:25           ` Jonathan Cameron
2022-07-01 22:22             ` Ira Weiny
2022-07-04  6:45               ` Jonathan Cameron
2022-06-29 16:53       ` Ira Weiny
2022-06-28 14:38   ` Jonathan Cameron
2022-06-28 16:58     ` Ira Weiny
2022-06-28  4:15 ` [PATCH V12 4/9] cxl/pci: Create PCI DOE mailbox's for memory devices ira.weiny
2022-06-28 14:33   ` Jonathan Cameron
2022-06-30  5:32     ` Ira Weiny
2022-06-30 15:32       ` Jonathan Cameron
2022-06-30 16:14         ` Davidlohr Bueso
2022-07-01 19:52           ` Ira Weiny
2022-06-28  4:15 ` [PATCH V12 5/9] driver-core: Introduce BIN_ATTR_ADMIN_{RO,RW} ira.weiny
2022-06-28  6:06   ` Greg Kroah-Hartman
2022-06-28 16:42   ` Ira Weiny
2022-06-29  1:10   ` Bjorn Helgaas
2022-06-28  4:15 ` [PATCH V12 6/9] cxl/port: Read CDAT table ira.weiny
2022-06-28 14:47   ` Jonathan Cameron
2022-06-30  3:35     ` Ira Weiny [this message]
2022-06-30 15:45       ` Jonathan Cameron
2022-06-28  4:15 ` [PATCH V12 7/9] cxl/port: Introduce cxl_cdat_valid() ira.weiny
2022-06-28 14:49   ` Jonathan Cameron
2022-06-30  4:42     ` Ira Weiny
2022-06-28  4:15 ` [PATCH V12 8/9] cxl/port: Retry reading CDAT on failure ira.weiny
2022-06-28 14:57   ` Jonathan Cameron
2022-06-30  3:40     ` Ira Weiny
2022-06-28  4:15 ` [PATCH V12 9/9] cxl/port: Parse out DSMAS data from CDAT table ira.weiny
2022-06-28 15:00   ` Jonathan Cameron

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=Yr0aBnTJtFXrCUSM@iweiny-desk3 \
    --to=ira.weiny@intel.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=alison.schofield@intel.com \
    --cc=bhelgaas@google.com \
    --cc=bwidawsk@kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    --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 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).