On 22/08/2025 11:42, Smita Koralahalli wrote:
> Prevent cxl_region_probe() from unconditionally calling into
> devm_cxl_add_dax_region() when the DEV_DAX_CXL driver is not enabled.
> Wrap the call with IS_ENABLED(CONFIG_DEV_DAX_CXL) so region probe skips
> DAX setup cleanly if no consumer is present.
A question came to mind:
Why is the case of `CXL_REGION && !DEV_DAX_CXL` necessary? It appears to fall back to the hmem driver in that scenario.
If so, could we instead simplify it as follows?
--- a/drivers/cxl/Kconfig
+++ b/drivers/cxl/Kconfig
@@ -200,6 +200,7 @@ config CXL_REGION
depends on SPARSEMEM
select MEMREGION
select GET_FREE_REGION
+ select DEV_DAX_CXL
>
> In parallel, update DEV_DAX_HMEM’s Kconfig to depend on
> !CXL_BUS || (CXL_ACPI && CXL_PCI) || m. This ensures:
>
> Built-in (y) HMEM is allowed when CXL is disabled, or when the full
> CXL discovery stack is built-in. Module (m) HMEM remains always possible.
Hmm,IIUC, `dax_hmem` isn't exclusively designed for CXL. It could support other special memory types (e.g., HBM).
Thanks
Zhijian
>
> Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@xxxxxxx>
> ---
> I did not want to override Dan’s original approach, so I am posting this
> as an RFC.
>
> This patch addresses a corner case when applied on top of Patches 1–5.
>
> When DEV_DAX_HMEM=y and CXL=m, the DEV_DAX_CXL option ends up disabled.
> In that configuration, with Patches 1–5 applied, ownership of the Soft
> Reserved ranges falls back to dax_hmem. As a result, /proc/iomem looks
> like this:
>
> 850000000-284fffffff : CXL Window 0
> 850000000-284fffffff : region3
> 850000000-284fffffff : Soft Reserved
> 850000000-284fffffff : dax0.0
> 850000000-284fffffff : System RAM (kmem)
> 2850000000-484fffffff : CXL Window 1
> 2850000000-484fffffff : region4
> 2850000000-484fffffff : Soft Reserved
> 2850000000-484fffffff : dax1.0
> 2850000000-484fffffff : System RAM (kmem)
> 4850000000-684fffffff : CXL Window 2
> 4850000000-684fffffff : region5
> 4850000000-684fffffff : Soft Reserved
> 4850000000-684fffffff : dax2.0
> 4850000000-684fffffff : System RAM (kmem)
>
> In this case the dax devices are created by dax_hmem, not by dax_cxl.
> Consequently, a "cxl disable-region <regionx>" operation does not
> unregister these devices. In addition, the dmesg output can be misleading
> to users, since it looks like the CXL region driver created the devdax
> devices:
>
> devm_cxl_add_region: cxl_acpi ACPI0017:00: decoder0.2: created region5
> ..
> ..
>
> This patch addresses those situations. I am not entirely sure how clean
> the approach of using “|| m” is, so I am sending it as RFC for feedback.
> ---
> drivers/cxl/core/region.c | 4 +++-
> drivers/dax/Kconfig | 1 +
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c
> index 71cc42d05248..6a2c21e55dbc 100644
> --- a/drivers/cxl/core/region.c
> +++ b/drivers/cxl/core/region.c
> @@ -3617,7 +3617,9 @@ static int cxl_region_probe(struct device *dev)
> p->res->start, p->res->end, cxlr,
> is_system_ram) > 0)
> return 0;
> - return devm_cxl_add_dax_region(cxlr);
> + if (IS_ENABLED(CONFIG_DEV_DAX_CXL))
> + return devm_cxl_add_dax_region(cxlr);
> + return 0;
> default:
> dev_dbg(&cxlr->dev, "unsupported region mode: %d\n",
> cxlr->mode);
> diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig
> index 3683bb3f2311..fd12cca91c78 100644
> --- a/drivers/dax/Kconfig
> +++ b/drivers/dax/Kconfig
> @@ -30,6 +30,7 @@ config DEV_DAX_PMEM
> config DEV_DAX_HMEM
> tristate "HMEM DAX: direct access to 'specific purpose' memory"
> depends on EFI_SOFT_RESERVE
> + depends on !CXL_BUS || (CXL_ACPI && CXL_PCI) || m
> select NUMA_KEEP_MEMINFO if NUMA_MEMBLKS
> default DEV_DAX
> help
