Re: [PATCH 9/9] tools/testing/cxl: Test dax_hmem takeover of CXL regions

[Alison Schofield <alison.schofield@intel.com>]

On Thu, Mar 26, 2026 at 10:28:21PM -0700, Dan Williams wrote:
> When platform firmware is committed to publishing EFI_CONVENTIONAL_MEMORY
> in the memory map, but CXL fails to assemble the region, dax_hmem can
> attempt to attach a dax device to the memory range.
> 
> Take advantage of the new ability to support multiple "hmem_platform"
> devices, and to enable regression testing of several scenarios:
> 
> * CXL correctly assembles a region, check dax_hmem fails to attach dax
> * CXL fails to assemble a region, check dax_hmem successfully attaches dax
> * Check that loading the dax_cxl driver loads the dax_hmem driver
> * Attempt to race cxl_mock_mem async probe vs dax_hmem probe flushing.
>   Check that both positive and negative cases.
> 
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>

snip

> diff --git a/tools/testing/cxl/test/mem.c b/tools/testing/cxl/test/mem.c
> index cb87e8c0e63c..cc847e9aeceb 100644
> --- a/tools/testing/cxl/test/mem.c
> +++ b/tools/testing/cxl/test/mem.c
> @@ -1695,6 +1695,9 @@ static int cxl_mock_mem_probe(struct platform_device *pdev)
>  	struct cxl_dpa_info range_info = { 0 };
>  	int rc;
>  
> +	/* Increase async probe race window */
> +	usleep_range(500*1000, 1000*1000);
> +

I see your words in the commit log "Attempt to race..."
and this sleep looks like it is only widening the timing window,
not making the order deterministic. Given these tests are typically
single-pass tests, what ensure we actually hit the intended ordering?