Smita Koralahalli wrote: > From: Dan Williams <[email protected]> > > Ensure cxl_acpi has published CXL Window resources before HMEM walks Soft > Reserved ranges. > > Replace MODULE_SOFTDEP("pre: cxl_acpi") with an explicit, synchronous > request_module("cxl_acpi"). MODULE_SOFTDEP() only guarantees eventual > loading, it does not enforce that the dependency has finished init > before the current module runs. This can cause HMEM to start before > cxl_acpi has populated the resource tree, breaking detection of overlaps > between Soft Reserved and CXL Windows. > > Also, request cxl_pci before HMEM walks Soft Reserved ranges. Unlike > cxl_acpi, cxl_pci attach is asynchronous and creates dependent devices > that trigger further module loads. Asynchronous probe flushing > (wait_for_device_probe()) is added later in the series in a deferred > context before HMEM makes ownership decisions for Soft Reserved ranges. > > Add an additional explicit Kconfig ordering so that CXL_ACPI and CXL_PCI > must be initialized before DEV_DAX_HMEM. This prevents HMEM from consuming > Soft Reserved ranges before CXL drivers have had a chance to claim them. > > Signed-off-by: Dan Williams <[email protected]> > Signed-off-by: Smita Koralahalli <[email protected]> > Reviewed-by: Dave Jiang <[email protected]> > Reviewed-by: Jonathan Cameron <[email protected]> > Reviewed-by: Alison Schofield <[email protected]> > --- > drivers/dax/Kconfig | 2 ++ > drivers/dax/hmem/hmem.c | 17 ++++++++++------- > 2 files changed, 12 insertions(+), 7 deletions(-) > > diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig > index d656e4c0eb84..3683bb3f2311 100644 > --- a/drivers/dax/Kconfig > +++ b/drivers/dax/Kconfig > @@ -48,6 +48,8 @@ config DEV_DAX_CXL > tristate "CXL DAX: direct access to CXL RAM regions" > depends on CXL_BUS && CXL_REGION && DEV_DAX > default CXL_REGION && DEV_DAX > + depends on CXL_ACPI >= DEV_DAX_HMEM > + depends on CXL_PCI >= DEV_DAX_HMEM
As I learned from Keith's recent CXL_PMEM dependency fix for CXL_ACPI [1], this wants to be: depends on DEV_DAX_HMEM || !DEV_DAX_HMEM depends on CXL_ACPI || !CXL_ACPI depends on CXL_PCI || !CXL_PCI ...to make sure that DEV_DAX_CXL can never be built-in unless all of its dependencies are built-in. [1]: http://lore.kernel.org/[email protected] At this point I am wondering if all of the feedback I have for this series should just be incremental fixes. I also want to have a canned unit test that verifies the base expectations. That can also be something I reply incrementally.
