All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: <alejandro.lucero-palau@amd.com>
Cc: <linux-cxl@vger.kernel.org>, <netdev@vger.kernel.org>,
	<dan.j.williams@intel.com>, <edward.cree@amd.com>,
	<davem@davemloft.net>, <kuba@kernel.org>, <pabeni@redhat.com>,
	<edumazet@google.com>, <dave.jiang@intel.com>,
	Alejandro Lucero <alucerop@amd.com>
Subject: Re: [PATCH v17 18/22] cxl: Allow region creation by type2 drivers
Date: Fri, 27 Jun 2025 10:32:23 +0100	[thread overview]
Message-ID: <20250627103223.00007e43@huawei.com> (raw)
In-Reply-To: <20250624141355.269056-19-alejandro.lucero-palau@amd.com>

On Tue, 24 Jun 2025 15:13:51 +0100
<alejandro.lucero-palau@amd.com> wrote:

> From: Alejandro Lucero <alucerop@amd.com>
> 
> Creating a CXL region requires userspace intervention through the cxl
> sysfs files. Type2 support should allow accelerator drivers to create
> such cxl region from kernel code.
> 
> Adding that functionality and integrating it with current support for
> memory expanders.
> 
> Support an action by the type2 driver to be linked to the created region
> for unwinding the resources allocated properly.
> 
> Based on https://lore.kernel.org/linux-cxl/168592159835.1948938.1647215579839222774.stgit@dwillia2-xfh.jf.intel.com/
> 
> Signed-off-by: Alejandro Lucero <alucerop@amd.com>
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
One question in here for others (probably Dan). When does it makes sense to
manually request devm region cleanup and when should we let if flow out
as we are failing the CXL creation anyway and it's one of many things to
clean up if that happens.

> ---
>  drivers/cxl/core/region.c | 152 ++++++++++++++++++++++++++++++++++++--
>  drivers/cxl/port.c        |   5 +-
>  include/cxl/cxl.h         |   5 ++
>  3 files changed, 153 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c
> index 21cf8c11efe3..4ca5ade54ad9 100644
> --- a/drivers/cxl/core/region.c
> +++ b/drivers/cxl/core/region.c
> @@ -2319,6 +2319,12 @@ static int cxl_region_detach(struct cxl_endpoint_decoder *cxled)
>  	return rc;
>  }
>  
> +/**
> + * cxl_decoder_kill_region - detach a region from device
> + *
> + * @cxled: endpoint decoder to detach the region from.
> + *

Stray blank line.

> + */
>  void cxl_decoder_kill_region(struct cxl_endpoint_decoder *cxled)
>  {
>  	down_write(&cxl_region_rwsem);
> @@ -2326,6 +2332,7 @@ void cxl_decoder_kill_region(struct cxl_endpoint_decoder *cxled)
>  	cxl_region_detach(cxled);
>  	up_write(&cxl_region_rwsem);
>  }
> +EXPORT_SYMBOL_NS_GPL(cxl_decoder_kill_region, "CXL");

> +/**
> + * cxl_create_region - Establish a region given an endpoint decoder
> + * @cxlrd: root decoder to allocate HPA
> + * @cxled: endpoint decoder with reserved DPA capacity
> + * @ways: interleave ways required
> + *
> + * Returns a fully formed region in the commit state and attached to the
> + * cxl_region driver.
> + */
> +struct cxl_region *cxl_create_region(struct cxl_root_decoder *cxlrd,
> +				     struct cxl_endpoint_decoder **cxled,
> +				     int ways, void (*action)(void *),
> +				     void *data)
> +{
> +	struct cxl_region *cxlr;
> +
> +	scoped_guard(mutex, &cxlrd->range_lock) {
> +		cxlr = __construct_new_region(cxlrd, cxled, ways);
> +		if (IS_ERR(cxlr))
> +			return cxlr;
> +	}
> +
> +	if (device_attach(&cxlr->dev) <= 0) {
> +		dev_err(&cxlr->dev, "failed to create region\n");
> +		drop_region(cxlr);

I'm in two minds about this.  If we were to have wrapped the whole thing
up in a devres group and on failure (so carrying  on without cxl support)
we tidy that group up, then we'd not need to clean this up here.
However we do some local devm cleanup in construct_region today so maybe
keeping this local makes sense...  Dan, maybe you have a better view of
whether cleaning up here is sensible or not?

> +		return ERR_PTR(-ENODEV);
> +	}
> +
> +	if (action)
> +		devm_add_action_or_reset(&cxlr->dev, action, data);

This is a little odd looking (and can fail so should be error checkeD)
I'd push the devm registration to the caller.


> +
> +	return cxlr;
> +}
> +EXPORT_SYMBOL_NS_GPL(cxl_create_region, "CXL");
> +
>  int cxl_add_to_region(struct cxl_port *root, struct cxl_endpoint_decoder *cxled)
>  {
>  	struct cxl_memdev *cxlmd = cxled_to_memdev(cxled);


  reply	other threads:[~2025-06-27  9:32 UTC|newest]

Thread overview: 115+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-24 14:13 [PATCH v17 00/22] Type2 device basic support alejandro.lucero-palau
2025-06-24 14:13 ` [PATCH v17 01/22] cxl: Add type2 " alejandro.lucero-palau
2025-06-25 14:06   ` Jonathan Cameron
2025-06-30 14:38     ` Alejandro Lucero Palau
2025-07-25 21:46   ` dan.j.williams
2025-08-05 10:45     ` Alejandro Lucero Palau
2025-08-05 15:14       ` Dave Jiang
2025-06-24 14:13 ` [PATCH v17 02/22] sfc: add cxl support alejandro.lucero-palau
2025-06-25 16:37   ` Jonathan Cameron
2025-06-30 14:52     ` Alejandro Lucero Palau
2025-06-30 14:55       ` Alejandro Lucero Palau
2025-06-30 16:07         ` Jonathan Cameron
2025-07-25 22:16   ` dan.j.williams
2025-08-06  8:37     ` Alejandro Lucero Palau
2025-06-24 14:13 ` [PATCH v17 03/22] cxl: Move pci generic code alejandro.lucero-palau
2025-07-25 22:41   ` dan.j.williams
2025-08-06  8:46     ` Alejandro Lucero Palau
2025-08-06  9:31       ` Alejandro Lucero Palau
2025-06-24 14:13 ` [PATCH v17 04/22] cxl: allow Type2 drivers to map cxl component regs alejandro.lucero-palau
2025-06-27  8:27   ` Jonathan Cameron
2025-07-25 22:55   ` dan.j.williams
2025-07-28 16:23     ` Dave Jiang
2025-08-06  9:43       ` Alejandro Lucero Palau
2025-08-06  9:41     ` Alejandro Lucero Palau
2025-06-24 14:13 ` [PATCH v17 05/22] sfc: setup cxl component regs and set media ready alejandro.lucero-palau
2025-06-27  8:39   ` Jonathan Cameron
2025-06-30 15:57     ` Alejandro Lucero Palau
2025-08-08 13:11       ` Alejandro Lucero Palau
2025-06-27  8:45   ` Jonathan Cameron
2025-08-08 13:14     ` Alejandro Lucero Palau
2025-07-25 23:04   ` dan.j.williams
2025-06-24 14:13 ` [PATCH v17 06/22] cxl: Support dpa initialization without a mailbox alejandro.lucero-palau
2025-06-27  8:42   ` Jonathan Cameron
2025-06-27 16:43     ` Dave Jiang
2025-07-01 15:23     ` Alejandro Lucero Palau
2025-06-27  8:43   ` Jonathan Cameron
2025-07-01 15:25     ` Alejandro Lucero Palau
2025-07-26  0:54   ` dan.j.williams
2025-06-24 14:13 ` [PATCH v17 07/22] sfc: initialize dpa alejandro.lucero-palau
2025-07-26  0:55   ` dan.j.williams
2025-08-08 16:59     ` Alejandro Lucero Palau
2025-06-24 14:13 ` [PATCH v17 08/22] cxl: Prepare memdev creation for type2 alejandro.lucero-palau
2025-07-26  1:05   ` dan.j.williams
2025-08-08 17:01     ` Alejandro Lucero Palau
2025-06-24 14:13 ` [PATCH v17 09/22] sfc: create type2 cxl memdev alejandro.lucero-palau
2025-06-27  8:51   ` Jonathan Cameron
2025-07-01 15:30     ` Alejandro Lucero Palau
2025-06-24 14:13 ` [PATCH v17 10/22] cx/memdev: Indicate probe deferral alejandro.lucero-palau
2025-06-27  8:59   ` Jonathan Cameron
2025-06-27  9:42   ` Jonathan Cameron
2025-07-01 15:30     ` Alejandro Lucero Palau
2025-06-27 18:17   ` Dave Jiang
2025-06-30 16:20     ` Jonathan Cameron
2025-07-01 16:07       ` Alejandro Lucero Palau
2025-07-01 16:25         ` Dave Jiang
2025-07-01 16:44           ` Jonathan Cameron
2025-07-01 16:02     ` Alejandro Lucero Palau
2025-07-28 17:45       ` dan.j.williams
2025-07-30  3:46         ` dan.j.williams
2025-08-09 11:24         ` Alejandro Lucero Palau
2025-07-16 22:52   ` Dave Jiang
2025-06-24 14:13 ` [PATCH v17 11/22] cxl: Define a driver interface for HPA free space enumeration alejandro.lucero-palau
2025-06-27 22:42   ` Dave Jiang
2025-07-04 14:45     ` Alejandro Lucero Palau
2025-08-05 16:14   ` dan.j.williams
2025-08-11 12:04     ` Alejandro Lucero Palau
2025-06-24 14:13 ` [PATCH v17 12/22] sfc: get endpoint decoder alejandro.lucero-palau
2025-06-27  9:10   ` Jonathan Cameron
2025-07-04 14:51     ` Alejandro Lucero Palau
2025-07-28 16:30   ` dan.j.williams
2025-08-11 14:24     ` Alejandro Lucero Palau
2025-09-02  7:11       ` Alejandro Lucero Palau
2025-06-24 14:13 ` [PATCH v17 13/22] cxl: Define a driver interface for DPA allocation alejandro.lucero-palau
2025-06-27  9:06   ` Jonathan Cameron
2025-07-04 15:18     ` Alejandro Lucero Palau
2025-06-27 20:46   ` Dave Jiang
2025-07-04 15:21     ` Alejandro Lucero Palau
2025-06-24 14:13 ` [PATCH v17 14/22] sfc: get endpoint decoder alejandro.lucero-palau
2025-06-27  9:11   ` Jonathan Cameron
2025-07-07 11:24     ` Alejandro Lucero Palau
2025-07-16 23:48   ` Dave Jiang
2025-06-24 14:13 ` [PATCH v17 15/22] cxl: Make region type based on endpoint type alejandro.lucero-palau
2025-09-03 17:20   ` Davidlohr Bueso
2025-06-24 14:13 ` [PATCH v17 16/22] cxl/region: Factor out interleave ways setup alejandro.lucero-palau
2025-06-27  9:13   ` Jonathan Cameron
2025-06-27 23:05     ` Dave Jiang
2025-06-30 16:20       ` Jonathan Cameron
2025-06-30 16:34         ` Dave Jiang
2025-06-24 14:13 ` [PATCH v17 17/22] cxl/region: Factor out interleave granularity setup alejandro.lucero-palau
2025-06-24 14:13 ` [PATCH v17 18/22] cxl: Allow region creation by type2 drivers alejandro.lucero-palau
2025-06-27  9:32   ` Jonathan Cameron [this message]
2025-07-07 11:31     ` Alejandro Lucero Palau
2025-08-05 16:33   ` dan.j.williams
2025-08-11 14:45     ` Alejandro Lucero Palau
2025-06-24 14:13 ` [PATCH v17 19/22] cxl: Avoid dax creation for accelerators alejandro.lucero-palau
2025-06-27  9:33   ` Jonathan Cameron
2025-09-03 17:24   ` Davidlohr Bueso
2025-06-24 14:13 ` [PATCH v17 20/22] sfc: create cxl region alejandro.lucero-palau
2025-06-27  9:38   ` Jonathan Cameron
2025-07-07 11:37     ` Alejandro Lucero Palau
2025-07-28 16:20   ` dan.j.williams
2025-08-11 14:38     ` Alejandro Lucero Palau
2025-06-24 14:13 ` [PATCH v17 21/22] cxl: Add function for obtaining region range alejandro.lucero-palau
2025-06-24 14:13 ` [PATCH v17 22/22] sfc: support pio mapping based on cxl alejandro.lucero-palau
2025-06-27  9:46   ` Jonathan Cameron
2025-07-07 12:06     ` Alejandro Lucero Palau
2025-08-27 17:26   ` ALOK TIWARI
2025-07-25 20:51 ` [PATCH v17 00/22] Type2 device basic support dan.j.williams
2025-07-25 21:11   ` dan.j.williams
2025-08-27 16:48 ` PJ Waskiewicz
2025-08-28  8:02   ` Alejandro Lucero Palau
2025-09-04 17:48     ` PJ Waskiewicz
2025-09-08 11:48       ` Alejandro Lucero Palau
2025-09-05 23:23     ` PJ Waskiewicz
2025-09-08 12:03       ` Alejandro Lucero Palau

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=20250627103223.00007e43@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=alejandro.lucero-palau@amd.com \
    --cc=alucerop@amd.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=edward.cree@amd.com \
    --cc=kuba@kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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.