On Tue, May 19, 2026, at 3:18 AM, Tomasz Wolski wrote:
> The dax_region resource conflict in alloc_dax_region() indicates a
> serious configuration problem — two subsystems (e.g. dax_hmem and
> dax_cxl) are attempting to register overlapping address ranges. This is
> not a transient or debug-level condition; it represents a genuine
> resource conflict that an administrator needs to be aware of.
>
> Switch from request_resource() + dev_dbg() to
> request_resource_conflict() + dev_err() so that the conflict is visible
> by default and the colliding resource is identified in the message.
>
> Suggested-by: Dan Williams <[email protected]>
> Link:
> https://lore.kernel.org/linux-cxl/[email protected]/
> Signed-off-by: Tomasz Wolski <[email protected]>
> ---
> drivers/dax/bus.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
> index 68437c05e21d..66413c6c2ba0 100644
> --- a/drivers/dax/bus.c
> +++ b/drivers/dax/bus.c
> @@ -637,7 +637,7 @@ struct dax_region *alloc_dax_region(struct device
> *parent, int region_id,
> unsigned long flags)
> {
> struct dax_region *dax_region;
> - int rc;
> + struct resource *conflict;
>
> /*
> * The DAX core assumes that it can store its private data in
> @@ -670,10 +670,11 @@ struct dax_region *alloc_dax_region(struct device
> *parent, int region_id,
> .flags = IORESOURCE_MEM | flags,
> };
>
> - rc = request_resource(&dax_regions, &dax_region->res);
> - if (rc) {
> - dev_dbg(parent, "dax_region resource conflict for %pR\n",
> - &dax_region->res);
> + conflict = request_resource_conflict(&dax_regions, &dax_region->res);
Just report the request_resource() failure. This case does not warrant
exporting request_resource _conflict(). Historically one driver can not mess
with another driver's resource beyond conflict detection.
