Re: [PATCH] cxl/acpi: fix CXL_ACPI=y + CXL_PMEM=m link failure

[Gregory Price <gourry@gourry.net>]

On Tue, Mar 03, 2026 at 10:13:30AM +0000, Jonathan Cameron wrote:
> On Mon,  2 Mar 2026 15:04:29 -0500
> Gregory Price <gourry@gourry.net> wrote:
> 
> > Commit e7e222ad73d9 ("cxl: Move devm_cxl_add_nvdimm_bridge() to
> > cxl_pmem.ko") moved devm_cxl_add_nvdimm_bridge() from cxl_core into
> > cxl_pmem, creating a symbol dependency from cxl_acpi to cxl_pmem.
> > 
> > When CXL_ACPI=y and CXL_PMEM=m, the built-in cxl_acpi attempts to
> > link against a non-built-in cxl_pmem, which the linker cannot resolve.
> > 
> > CXL_PMEM depends on LIBNVDIMM, so LIBNVDIMM=m constrains CXL_PMEM to
> > at most =m.
> > 
> > Change IS_ENABLED() to IS_REACHABLE(), which returns false when a
> > built-in caller references a modular target, preventing the link error.
> > 
> > The result is if the pmem/nvdimm symbols are not reachable at build
> > time, then at runtime it will always return -ENODEV.
> > 
> > Fixes: e7e222ad73d9 ("cxl: Move devm_cxl_add_nvdimm_bridge() to cxl_pmem.ko")
> > Signed-off-by: Gregory Price <gourry@gourry.net>
> 
> What's the impact of this build combination wrt to whether the result is
> actually useful?   Is there any point in building CXL_PMEM as a module
> without this call being made?  I can't remember and normally don't care
> much about PMEM :) 
> 

Basically no, it's not useful, but it's some definition of the default
depending on your olddefconfig, so rather than fight with this further
this basically terminates the same way DAX_CXL=m terminates.

tl;dr: You don't create the dax device / nbdimm and you're sad... but it
does build!

~Gregory