Re: [PATCH v11 12/31] cxl/mem: Set up framework for handling DC Events

Anisa Su <[email protected]>
Newsgroups org.kernel.vger.linux-cxl,dev.linux.lists.nvdimm,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On Fri, Jun 26, 2026 at 02:54:43PM -0700, Dave Jiang wrote:
> 
> 
> On 6/25/26 4:04 AM, Anisa Su wrote:
> > From: Ira Weiny <[email protected]>
> > 
> > Adds the support for receiving DC event records but defers
> > the real add/release logic to subsequent commits. Simply refuse all
> > extents for DC_ADD and ack all DC_RELEASE events for now. Forced
> > release is currently unsupported.
> > 
> > In order, this commit adds the following:
> > 
> > 1. Learn about DC Event Records and how to respond to them
> > 
> > * cxl_mem_get_event_records() learns about the DC Event record.
> > Records of that type are routed to cxl_handle_dcd_event_records().
> > 
> > * cxl_handle_dcd_event_records() switches on event_type:
> > 	- DCD_ADD_CAPACITY     -> handle_add_event()
> > 	- DCD_RELEASE_CAPACITY -> cxl_rm_extent()
> > 	- DCD_FORCED_CAPACITY_RELEASE is logged and ignored (FM/device-only).
> > 
> > * cxl_send_dc_response() sends the reply mailbox commands
> > ADD_DC_RESPONSE / RELEASE_DC
> > 
> > 2. Add stubs for DC_ADD and DC_RELEASE logic
> > 
> > * handle_add_event() stages incoming extents onto
> > mds->add_ctx.pending_extents and, when More=0 closes the chain,
> > replies with an empty ADD_DC_RESPONSE — refusing all extents for now
> > 
> > * cxl_rm_extent() acks the release via memdev_release_extent() so the
> > device's view stays consistent; we can ack all releases because
> > we currently don't accept/use any extents offered.
> > 
> > 3. Structural setup for later commits:
> > 
> > * struct dc_extent, struct cxl_dc_tag_group, and pending_add_ctx
> > set up the stage for the real DC_ADD path, which will enforce
> > tag/grouping semantics
> > 
> > Based on an original patch by Navneet Singh.
> > 
> > Signed-off-by: Ira Weiny <[email protected]>
> > Signed-off-by: Anisa Su <[email protected]>
> 
> Just a minor comment below besides all the issues raised by sashiko
> 
Got it!

> 
> > 
> > +
[snip]

I also meant to ask in the last rev but I forgot: are these stub
comments useful or should I just get rid of them?

> > +/*
> > + * Stub: ack the release back to the device so it knows we are not
> > + * using the range.  A later commit replaces this with the real
> > + * teardown that walks the region's tag group and tears down the
> > + * member dc_extent devices.
> > + */
> > +static int cxl_rm_extent(struct cxl_memdev_state *mds,
> > +			 struct cxl_extent *extent)
> > +{
> > +	u64 start_dpa = le64_to_cpu(extent->start_dpa);
> > +	struct range dpa_range = {
> > +		.start = start_dpa,
> > +		.end = start_dpa + le64_to_cpu(extent->length) - 1,
> > +	};
> > +
> > +	memdev_release_extent(mds, &dpa_range);
> > +	return 0;
> > +}
> > +
> > +static char *cxl_dcd_evt_type_str(u8 type)
> 
> Should it return 'const char *' instead?
> 
Yes

> DJ
> 
Thanks,
Anisa

> > +{
> > +	switch (type) {
> > +	case DCD_ADD_CAPACITY:
> > +		return "add";
> > +	case DCD_RELEASE_CAPACITY:
> > +		return "release";
> > +	case DCD_FORCED_CAPACITY_RELEASE:
> > +		return "force release";
> > +	default:
> > +		break;
> > +	}
> > +
> > +	return "<unknown>";
> > +}
> > +
[snip]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.