Re: [PATCH v2] cxl/core: Create einj_types when EINJ becomes available

["Cheatham, Benjamin" <benjamin.cheatham@amd.com>]

On 10/28/2026 3:49 AM, Yongxin Yang wrote:
> From: Yang Yongxin <yangyongxin@kylinos.cn>
> 
> The einj_types file under the CXL debugfs directory is never created.
> 
> cxl_core_init() runs at subsys_initcall level, while EINJ registers itself
> from einj_init() at module_init level. When cxl_core_init() evaluates
> einj_cxl_is_initialized() the built-in EINJ driver has not been initialized
> yet, so the value is always false and the debugfs_create_file("einj_types")
> call below it is never reached. Users have no way to discover which CXL
> error types the platform supports from debugfs.
> 
> Create the file from both places that can know EINJ is up: cxl_core_init(),
> which covers the case where cxl_core is a module and einj has already been
> initialized by the time the module is loaded, and the dport probe path,
> which covers the built-in case. The dport probe path can run concurrently
> for different parent ports, each holding only its own device lock, so
> serialize the check and the create to avoid a duplicate
> debugfs_create_file() attempt that would only fail with -EEXIST.
> 
> Note that this is still a partial fix: an RCH platform returns early from
> devm_cxl_enumerate_ports() before any dport is added, so einj_types does
> not appear there. Fixing that requires moving cxl_core_init() after EINJ
> is probed, or creating the file from cxl_acpi_probe(), both of which are
> out of scope here.

I'm not a fan of having to write a value to einj_inject to see what values are
possible to write to einj_inject. Maybe if it was changed to reading einj_inject
creating einj_types it would be better, but I think I'd rather see the file created
in cxl_acpi_probe() as a fix.

I was able to make a quick mock up using your fix here and it wasn't that bad:

diff --git a/drivers/cxl/acpi.c b/drivers/cxl/acpi.c
index 0c21dc03a6..4017500ef4 100644
--- a/drivers/cxl/acpi.c
+++ b/drivers/cxl/acpi.c
@@ -974,6 +974,8 @@
 	if (rc < 0)
 		return rc;
 
+	cxl_debugfs_einj_add_types();
+
 	/* In case PCI is scanned before ACPI re-trigger memdev attach */
 	cxl_bus_rescan();
 	return 0;
diff --git a/drivers/cxl/core/port.c b/drivers/cxl/core/port.c
index f3705ea44d..0b75792a9a 100644
--- a/drivers/cxl/core/port.c
+++ b/drivers/cxl/core/port.c
@@ -811,6 +811,20 @@
 
 DEFINE_SHOW_ATTRIBUTE(einj_cxl_available_error_type);
 
+static struct dentry *cxl_debugfs;
+static struct dentry *einj_types_dentry;
+
+static DEFINE_MUTEX(einj_types_lock);
+void cxl_debugfs_einj_add_types(void)
+{
+	guard(mutex)(&einj_types_lock);
+	if (!einj_types_dentry && einj_cxl_is_initialized())
+		einj_types_dentry = debugfs_create_file("einj_types", 0400,
+							cxl_debugfs, NULL,
+							&einj_cxl_available_error_type_fops);
+}
+EXPORT_SYMBOL_FOR_MODULES(cxl_debugfs_einj_add_types, "cxl_acpi");
+
 static int cxl_einj_inject(void *data, u64 type)
 {
 	struct cxl_dport *dport = data;
@@ -2589,8 +2603,6 @@
 };
 EXPORT_SYMBOL_NS_GPL(cxl_bus_type, "CXL");
 
-static struct dentry *cxl_debugfs;
-
 struct dentry *cxl_debugfs_create_dir(const char *dir)
 {
 	return debugfs_create_dir(dir, cxl_debugfs);
@@ -2603,10 +2615,6 @@
 
 	cxl_debugfs = debugfs_create_dir("cxl", NULL);
 
-	if (einj_cxl_is_initialized())
-		debugfs_create_file("einj_types", 0400, cxl_debugfs, NULL,
-				    &einj_cxl_available_error_type_fops);
+	cxl_debugfs_einj_add_types();

 	cxl_mbox_init();
 
 	rc = cxl_memdev_init();
diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
index baa6df2d36..40be8ea938 100644
--- a/drivers/cxl/cxl.h
+++ b/drivers/cxl/cxl.h
@@ -956,4 +956,5 @@
 
 u16 cxl_gpf_get_dvsec(struct device *dev);
 
+void cxl_debugfs_einj_add_types(void);
 #endif /* __CXL_H__ */

---

I only did some quick compile testing with a few common configs and didn't see any errors,
so take it with a grain of salt. The only issue I see with it at the moment is the debugfs
init is now partially decoupled from the cxl_core module, but I think that's just a
maintainability issue instead of a technical one.

You may also be able to get away with removing the locking in cxl_debugfs_einj_add_types()
since cxl_acpi doesn't force async probe, but I left it there just in case.

Thanks,
Ben