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>,
	Alison Schofield <alison.schofield@intel.com>,
	Vishal Verma <vishal.l.verma@intel.com>,
	Ben Widawsky <ben.widawsky@intel.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	linux-cxl@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH 4/5] cxl/mem: Add CDAT table reading from DOE
Date: Mon, 8 Nov 2021 14:25:16 -0800	[thread overview]
Message-ID: <20211108222516.GE3538886@iweiny-DESK2.sc.intel.com> (raw)
In-Reply-To: <20211108150236.00003a6c@Huawei.com>

On Mon, Nov 08, 2021 at 03:02:36PM +0000, Jonathan Cameron wrote:
> On Fri, 5 Nov 2021 16:50:55 -0700
> <ira.weiny@intel.com> wrote:
> 
> > From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > 

[snip]

> 
> A few more things came to mind whilst reading the rest of the series. In particular
> lifetime management for the doe structures.

Thanks for the review I'm just working through all the comments and so I'm
somewhat working backwards.

> 
> >   * DOC: cxl pci
> > @@ -575,17 +576,106 @@ static int cxl_setup_doe_devices(struct cxl_dev_state *cxlds)
> >  		if (rc)
> >  			return rc;
> >  
> > -		if (device_attach(&adev->dev) != 1)
> > +		if (device_attach(&adev->dev) != 1) {
> >  			dev_err(&adev->dev,
> >  				"Failed to attach a driver to DOE device %d\n",
> >  				adev->id);
> > +			goto next;
> > +		}
> > +
> > +		if (pci_doe_supports_prot(new_dev, PCI_DVSEC_VENDOR_ID_CXL,
> > +					  CXL_DOE_PROTOCOL_TABLE_ACCESS))
> > +			cxlds->cdat_doe = new_dev;
> 
> I'm probably missing something, but what prevents new_dev from going away after
> this assignment?
> Perhaps a force unbind or driver removal.  Should we get a
> reference?

I had a get_device() here at one point but took it out...  Because I was
thinking that new_dev's lifetime was equal to cxlds because cxlds 'owned' the
DOE devices.  However this is totally not true.  And there is a race between
the device going away and cxlds going away which could be a problem.

> 
> Also it's possible we'll have multiple CDAT supporting DOEs so
> I'd suggest checking if cxlds->cdata_doe is already set before setting it.

Sure.

> 
> We could break out of the loop early, but I want to bolt the CMA doe detection
> in there so I'd rather we didn't.  This is all subject to whether we attempt
> to generalize this support and move it over to the PCI side of things.

I'm not 100% sure about moving it to the PCI side but it does make some sense
because really the auxiliary devices are only bounded by the PCI device being
available.  None of the CXL stuff needs to exist for the DOE driver to talk to
the device but the pdev does need to be there...  :-/

This is all part of what drove the cxl_mem rename because that structure was
really confusing me.  Dan got me straightened out but I did not revisit this
series after that.  Now off the top of my head I'm not sure that cxlds needs to
be involved in the auxiliary device creation.  OTOH I was making it a central
place for in kernel users to know where/how to get information from DOE
mailboxes.  Hence caching which of these devices had CDAT capability.[1]

Since you seem to have arrived at this conclusion before me where in the PCI
code do you think is appropriate for this?

Ira

[1] I'm not really sure what is going to happen if multiple DOE boxes have CDAT
capability.  This seems like a recipe for confusion.

> 
> >  
> > +next:
> >  		pos = pci_find_next_ext_capability(pdev, pos, PCI_EXT_CAP_ID_DOE);
> >  	}
> >  
> >  	return 0;
> >  }
> >  

  reply	other threads:[~2021-11-08 22:25 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-05 23:50 [PATCH 0/5] CXL: Read CDAT and DSMAS data from the device ira.weiny
2021-11-05 23:50 ` [PATCH 1/5] PCI: Add vendor ID for the PCI SIG ira.weiny
2021-11-17 21:50   ` Bjorn Helgaas
2021-11-05 23:50 ` [PATCH 2/5] PCI/DOE: Add Data Object Exchange Aux Driver ira.weiny
2021-11-08 12:15   ` Jonathan Cameron
2021-11-10  5:45     ` Ira Weiny
2021-11-18 18:48       ` Jonathan Cameron
2021-11-16 23:48   ` Bjorn Helgaas
2021-12-03 20:48     ` Dan Williams
2021-12-03 23:56       ` Bjorn Helgaas
2021-12-04 15:47         ` Dan Williams
2021-12-06 12:27           ` Jonathan Cameron
2021-11-05 23:50 ` [PATCH 3/5] cxl/pci: Add DOE Auxiliary Devices ira.weiny
2021-11-08 13:09   ` Jonathan Cameron
2021-11-11  1:31     ` Ira Weiny
2021-11-11 11:53       ` Jonathan Cameron
2021-11-16 23:48   ` Bjorn Helgaas
2021-11-17 12:23     ` Jonathan Cameron
2021-11-17 22:15       ` Bjorn Helgaas
2021-11-18 10:51         ` Jonathan Cameron
2021-11-19  6:48         ` Christoph Hellwig
2021-11-29 23:37           ` Dan Williams
2021-11-29 23:59             ` Dan Williams
2021-11-30  6:42               ` Christoph Hellwig
2021-11-05 23:50 ` [PATCH 4/5] cxl/mem: Add CDAT table reading from DOE ira.weiny
2021-11-08 13:21   ` Jonathan Cameron
2021-11-08 23:19     ` Ira Weiny
2021-11-08 15:02   ` Jonathan Cameron
2021-11-08 22:25     ` Ira Weiny [this message]
2021-11-09 11:09       ` Jonathan Cameron
2021-11-19 14:40   ` Jonathan Cameron
2021-11-05 23:50 ` [PATCH 5/5] cxl/cdat: Parse out DSMAS data from CDAT table ira.weiny
2021-11-08 14:52   ` Jonathan Cameron
2021-11-11  3:58     ` Ira Weiny
2021-11-11 11:58       ` Jonathan Cameron
2021-11-18 17:02   ` Jonathan Cameron
2021-11-19 14:55   ` 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=20211108222516.GE3538886@iweiny-DESK2.sc.intel.com \
    --to=ira.weiny@intel.com \
    --cc=Jonathan.Cameron@Huawei.com \
    --cc=alison.schofield@intel.com \
    --cc=ben.widawsky@intel.com \
    --cc=bhelgaas@google.com \
    --cc=dan.j.williams@intel.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --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).