Re: [PATCH v4 1/3] cxl/core/region: move pmem region driver logic into region_pmem.c

From: Dan Williams

Date: Sat Apr 11 2026 - 16:36:28 EST


Jonathan Cameron wrote:
> On Sun, 22 Mar 2026 09:16:36 -0400
> Gregory Price <gourry@xxxxxxxxxx> wrote:
>
> > core/region.c is overloaded with per-region control logic (pmem, dax,
> > sysram, etc). Move the pmem region driver logic from region.c into
> > region_pmem.c make it clear that this code only applies to pmem regions.
> >
> > No functional changes.
> >
> > Signed-off-by: Gregory Price <gourry@xxxxxxxxxx>
[..]
> > +static struct lock_class_key cxl_pmem_region_key;
> > +
>
> > +
> > +/**
> > + * devm_cxl_add_pmem_region() - add a cxl_region-to-nd_region bridge
> > + * @cxlr: parent CXL region for this pmem region bridge device
> > + *
> > + * Return: 0 on success negative error code on failure.
>
> FWIW the lifetime management in here feels way to complex to me. Not
> a problem for this patch and I'm not immediately sure what we can do about it.
>
[..]
> > + scoped_guard(device, &cxl_nvb->dev) {
> > + if (cxl_nvb->dev.driver)
> > + rc = devm_add_action_or_reset(&cxl_nvb->dev,
> > + cxlr_pmem_unregister,
> > + cxlr_pmem);
> > + else
> > + rc = -ENXIO;
> As an example. If we happen to take this path... Where is the device_add() undone?

Yes, but thankfully this a leftover from "cb9cfff82f6a cxl/acpi:
Simplify cxl_nvdimm_bridge probing" where the "!cxl_nvb->dev.driver"
case was obviated. It should not be the case that this can end up with a
disabled "nvdimm-bridge".

Still more complicated than I would like. I believe that this should be
able to rely on the same base unwind logic as other regions and memdevs.
I.e. region comes down on either CXL-root removal or any member memdev
removal. Just not clear that this reduces complexity vs just refactors
it out of devm_cxl_add_pmem_region().