[PATCH 0/2] ACPI/PCI/CXL: Enforce _DEP ordering between ACPI0016 and ACPI0017

[PATCH 0/2] ACPI/PCI/CXL: Enforce _DEP ordering between ACPI0016 and ACPI0017

[Chen Pei]

On platforms whose ACPI namespace exposes a CXL host bridge (ACPI0016)
with an ACPI0017 CXL root device declaring _DEP on the host bridge,
cxl_acpi can probe before acpi_pci_root has attached the PCI root.
acpi_pci_find_root() then returns NULL, decoder targets read as 0,
and no port/endpoint device shows up under /sys/bus/cxl/devices/.

The root cause is twofold:

  1. acpi_pci_root_add() never calls acpi_dev_clear_dependencies(),
     so _DEP suppliers downstream of a PCI root are never released.

  2. ACPI0016 is not on acpi_honor_dep_ids[], so even when ACPI0017
     declares _DEP on it, acpi_dev_ready_for_enumeration() bypasses
     the dep_unmet check and lets cxl_acpi probe early.

On x86 the bug is usually masked by link order (acpi_pci_root is
built in and probed before cxl_acpi). On architectures like RISC-V
that ordering is not guaranteed, so the standard ACPI _DEP mechanism
must actually work.

This series fixes both sides and the two patches must be applied
together; applying only patch 2 would prevent cxl_acpi from ever
probing on ACPI0016 systems, because the supplier would never clear
the dependency.

  Patch 1 makes acpi_pci_root_add() clear _DEP on the supplier once
          the PCI root bus has been added.
  Patch 2 adds ACPI0016 to acpi_honor_dep_ids[] so the dependency
          declared by ACPI0017 is enforced.

The approach in this series follows the discussion of an earlier
posting:
https://lore.kernel.org/linux-cxl/20260514023238.49984-1-cp0613@linux.alibaba.com/

Chen Pei (2):
  ACPI: PCI: clear _DEP dependencies after PCI root bridge attach
  ACPI: scan: honor _DEP for ACPI0016 PCI/CXL host bridge

 drivers/acpi/pci_root.c | 4 ++++
 drivers/acpi/scan.c     | 1 +
 2 files changed, 5 insertions(+)

-- 
2.50.1

[PATCH 1/2] ACPI: PCI: Clear _DEP dependencies after PCI root bridge attach

[Chen Pei]

PCI root bridges enumerated by acpi_pci_root_add() can be the _DEP
supplier for other ACPI consumers, most notably ACPI0017 CXL root
devices whose probe path depends on acpi_pci_find_root() succeeding.
Once the root bus has been added, those consumers can safely be
enumerated, so notify them by clearing the dependency.

Call acpi_dev_clear_dependencies() at the end of acpi_pci_root_add(),
after pci_bus_add_devices(), following the same pattern used by other
ACPI suppliers such as the EC (drivers/acpi/ec.c) and the ACPI PCI
Link device (drivers/acpi/pci_link.c). The clear is intentionally
done only on the success path; on the error paths the supplier did
not attach and consumers must keep dep_unmet set.

This is a prerequisite for honoring _DEP on ACPI0016 host bridges,
which matters on architectures where the probe order of acpi_pci_root
relative to cxl_acpi is not guaranteed (e.g. RISC-V).

Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
Suggested-by: Dan Williams (nvidia) <djbw@kernel.org>
---
 drivers/acpi/pci_root.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index a0ba64e45e8a..4c06c3ffd0cb 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -755,6 +755,10 @@ static int acpi_pci_root_add(struct acpi_device *device,
 	pci_lock_rescan_remove();
 	pci_bus_add_devices(root->bus);
 	pci_unlock_rescan_remove();
+
+	/* Clear _DEP dependencies to allow consumers to enumerate */
+	acpi_dev_clear_dependencies(device);
+
 	return 1;
 
 remove_dmar:
-- 
2.50.1

Re: [PATCH 1/2] ACPI: PCI: Clear _DEP dependencies after PCI root bridge attach

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] acpi_pci_root_add() leaves a dangling pointer in device->driver_data on the dmar_device_add() error path.
--

commit c50bc9cc7a48e4b92d2f6107b97e5bdf5d2b47a4
Author: Chen Pei <cp0613@linux.alibaba.com>

ACPI: PCI: Clear _DEP dependencies after PCI root bridge attach

This commit clears _DEP dependencies at the end of acpi_pci_root_add(),
allowing consumers like ACPI0017 CXL root devices to safely enumerate
once the PCI root bridge has been attached.

> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index a0ba64e45e8ab..4c06c3ffd0cbb 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -755,6 +755,10 @@ static int acpi_pci_root_add(struct acpi_device *device,
>  	pci_lock_rescan_remove();
>  	pci_bus_add_devices(root->bus);
>  	pci_unlock_rescan_remove();
> +
> +	/* Clear _DEP dependencies to allow consumers to enumerate */
> +	acpi_dev_clear_dependencies(device);
> +
>  	return 1;
>  
>  remove_dmar:
>  	if (hotadd)
>  		dmar_device_remove(handle);
>  end:
>  	kfree(root);

[Severity: High]
This is a pre-existing issue, but does the dmar_device_add() error path
leave a dangling pointer in device->driver_data?

Earlier in acpi_pci_root_add(), the allocated root object is assigned to
device->driver_data:

	root->device = device;
	root->segment = segment & 0xFFFF;
	device->driver_data = root;

If dmar_device_add() fails during a hot-add, the code jumps to the end
label and frees the root pointer via kfree().

However, it doesn't explicitly reset device->driver_data to NULL, unlike
the later pci_acpi_scan_root() error path. Since the ACPI core does not
automatically clear driver_data on an attach failure, could subsequent calls
to acpi_pci_find_root() by other subsystems fetch and dereference this freed
pointer?

>  	return result;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260526025118.38935-1-cp0613@linux.alibaba.com?part=1

Re: [PATCH] cxl/acpi: Defer probe when ACPI0016 PCI root bridge is not ready

[Chen Pei]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 2420 bytes --]

On Tue, 26 May 2026 03:12:00 +0000, sashiko-bot@kernel.org wrote:

> > +
> > +	/* Clear _DEP dependencies to allow consumers to enumerate */
> > +	acpi_dev_clear_dependencies(device);
> > +
> >  	return 1;
> >  
> >  remove_dmar:
> >  	if (hotadd)
> >  		dmar_device_remove(handle);
> >  end:
> >  	kfree(root);
> 
> [Severity: High]
> This is a pre-existing issue, but does the dmar_device_add() error path
> leave a dangling pointer in device->driver_data?
> 
> Earlier in acpi_pci_root_add(), the allocated root object is assigned to
> device->driver_data:
> 
> 	root->device = device;
> 	root->segment = segment & 0xFFFF;
> 	device->driver_data = root;
> 
> If dmar_device_add() fails during a hot-add, the code jumps to the end
> label and frees the root pointer via kfree().
> 
> However, it doesn't explicitly reset device->driver_data to NULL, unlike
> the later pci_acpi_scan_root() error path. Since the ACPI core does not
> automatically clear driver_data on an attach failure, could subsequent calls
> to acpi_pci_find_root() by other subsystems fetch and dereference this freed
> pointer?

Good catch — you're right. On the dmar_device_add() failure path, the
code jumps to end: and frees root via kfree(), but
device->driver_data is left pointing at the freed memory. The later
pci_acpi_scan_root() failure path explicitly clears it to NULL, which
makes the omission on the dmar path look like an oversight rather than
intentional.

Since this is unrelated to the _DEP clearing change in this patch, I'd
prefer to keep it out of this patch and send a separate fix on top. Both
failure paths converge at end: and need the same cleanup, so I plan to
consolidate the NULL assignment there:

@@ -724,7 +724,6 @@ static int acpi_pci_root_add(struct acpi_device *device,
		if (!root->bus) {
				dev_err(&device->dev,
						"Bus %04x:%02x not present in PCI namespace\n",
						root->segment, (unsigned int)root->secondary.start);
-				device->driver_data = NULL;
				result = -ENODEV;
				goto remove_dmar;
		}
@@ -764,6 +763,7 @@ static int acpi_pci_root_add(struct acpi_device *device,
remove_dmar:
		if (hotadd)
				dmar_device_remove(handle);
end:
+		device->driver_data = NULL;
		kfree(root);
		return result;
}

This way every path reaching end: clears driver_data before freeing
root, and any future error path that does goto end; is automatically
correct. Does that split sound OK to you?

Thanks,
Pei

[PATCH 2/2] ACPI: scan: Honor _DEP for ACPI0016 PCI/CXL host bridge

[Chen Pei]

CXL root devices (ACPI0017) declare _DEP on their parent ACPI0016
PCI/CXL host bridge so that cxl_acpi probes only after acpi_pci_root
has attached the PCI root and registered it for acpi_pci_find_root().
However, acpi_dev_ready_for_enumeration() only consults dep_unmet
when the supplier's HID is on acpi_honor_dep_ids[]; otherwise the
dependency is silently ignored.

Without honoring the dependency, cxl_acpi can probe before the PCI
root is ready. The resulting CXL topology is broken: decoder targets
read as 0 and no port/endpoint devices appear under
/sys/bus/cxl/devices/.

Add ACPI0016 to acpi_honor_dep_ids[] so the _DEP declared by ACPI0017
is enforced. This relies on the preceding patch ("ACPI: PCI: clear
_DEP dependencies after PCI root bridge attach"), which releases the
dependency once the PCI root is fully enumerated; the two patches
must be applied together.

Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
---
 drivers/acpi/scan.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 530547cda8b2..5f20e7748f36 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -866,6 +866,7 @@ static const char * const acpi_honor_dep_ids[] = {
 	"RSCV0005", /* RISC-V SBI MPXY MBOX */
 	"RSCV0006", /* RISC-V RPMI SYSMSI */
 	"PNP0C0F",  /* PCI Link Device */
+	"ACPI0016", /* CXL/PCIe host bridge: CXL root (ACPI0017) depends on PCI root attach */
 	NULL
 };
 
-- 
2.50.1

Re: [PATCH 2/2] ACPI: scan: Honor _DEP for ACPI0016 PCI/CXL host bridge

[Rafael J. Wysocki]

On Tue, May 26, 2026 at 4:51 AM Chen Pei <cp0613@linux.alibaba.com> wrote:
>
> CXL root devices (ACPI0017) declare _DEP on their parent ACPI0016
> PCI/CXL host bridge so that cxl_acpi probes only after acpi_pci_root
> has attached the PCI root and registered it for acpi_pci_find_root().
> However, acpi_dev_ready_for_enumeration() only consults dep_unmet
> when the supplier's HID is on acpi_honor_dep_ids[]; otherwise the
> dependency is silently ignored.
>
> Without honoring the dependency, cxl_acpi can probe before the PCI
> root is ready. The resulting CXL topology is broken: decoder targets
> read as 0 and no port/endpoint devices appear under
> /sys/bus/cxl/devices/.
>
> Add ACPI0016 to acpi_honor_dep_ids[] so the _DEP declared by ACPI0017
> is enforced. This relies on the preceding patch ("ACPI: PCI: clear
> _DEP dependencies after PCI root bridge attach"), which releases the
> dependency once the PCI root is fully enumerated; the two patches
> must be applied together.
>
> Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
> ---
>  drivers/acpi/scan.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 530547cda8b2..5f20e7748f36 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -866,6 +866,7 @@ static const char * const acpi_honor_dep_ids[] = {
>         "RSCV0005", /* RISC-V SBI MPXY MBOX */
>         "RSCV0006", /* RISC-V RPMI SYSMSI */
>         "PNP0C0F",  /* PCI Link Device */
> +       "ACPI0016", /* CXL/PCIe host bridge: CXL root (ACPI0017) depends on PCI root attach */
>         NULL
>  };
>
> --

If anyone has any objections or comments on this one, please let me
know.  In the absence of any, it will be queued up (as 7.2 material)
next week.

Thanks!

Re: [PATCH 0/2] ACPI/PCI/CXL: Enforce _DEP ordering between ACPI0016 and ACPI0017

[Dave Jiang]

On 5/25/26 7:51 PM, Chen Pei wrote:
> On platforms whose ACPI namespace exposes a CXL host bridge (ACPI0016)
> with an ACPI0017 CXL root device declaring _DEP on the host bridge,
> cxl_acpi can probe before acpi_pci_root has attached the PCI root.
> acpi_pci_find_root() then returns NULL, decoder targets read as 0,
> and no port/endpoint device shows up under /sys/bus/cxl/devices/.
> 
> The root cause is twofold:
> 
>   1. acpi_pci_root_add() never calls acpi_dev_clear_dependencies(),
>      so _DEP suppliers downstream of a PCI root are never released.
> 
>   2. ACPI0016 is not on acpi_honor_dep_ids[], so even when ACPI0017
>      declares _DEP on it, acpi_dev_ready_for_enumeration() bypasses
>      the dep_unmet check and lets cxl_acpi probe early.
> 
> On x86 the bug is usually masked by link order (acpi_pci_root is
> built in and probed before cxl_acpi). On architectures like RISC-V
> that ordering is not guaranteed, so the standard ACPI _DEP mechanism
> must actually work.
> 
> This series fixes both sides and the two patches must be applied
> together; applying only patch 2 would prevent cxl_acpi from ever
> probing on ACPI0016 systems, because the supplier would never clear
> the dependency.
> 
>   Patch 1 makes acpi_pci_root_add() clear _DEP on the supplier once
>           the PCI root bus has been added.
>   Patch 2 adds ACPI0016 to acpi_honor_dep_ids[] so the dependency
>           declared by ACPI0017 is enforced.
> 
> The approach in this series follows the discussion of an earlier
> posting:
> https://lore.kernel.org/linux-cxl/20260514023238.49984-1-cp0613@linux.alibaba.com/
> 
> Chen Pei (2):
>   ACPI: PCI: clear _DEP dependencies after PCI root bridge attach
>   ACPI: scan: honor _DEP for ACPI0016 PCI/CXL host bridge
> 
>  drivers/acpi/pci_root.c | 4 ++++
>  drivers/acpi/scan.c     | 1 +
>  2 files changed, 5 insertions(+)
> 

For the series

Reviewed-by: Dave Jiang <dave.jiang@intel.com>

Are Fixes tags needed?

Re: [PATCH 0/2] ACPI/PCI/CXL: Enforce _DEP ordering between ACPI0016 and ACPI0017

[Alison Schofield]

On Tue, May 26, 2026 at 10:51:16AM +0800, Chen Pei wrote:
> On platforms whose ACPI namespace exposes a CXL host bridge (ACPI0016)
> with an ACPI0017 CXL root device declaring _DEP on the host bridge,
> cxl_acpi can probe before acpi_pci_root has attached the PCI root.
> acpi_pci_find_root() then returns NULL, decoder targets read as 0,
> and no port/endpoint device shows up under /sys/bus/cxl/devices/.
> 
> The root cause is twofold:
> 
>   1. acpi_pci_root_add() never calls acpi_dev_clear_dependencies(),
>      so _DEP suppliers downstream of a PCI root are never released.
> 
>   2. ACPI0016 is not on acpi_honor_dep_ids[], so even when ACPI0017
>      declares _DEP on it, acpi_dev_ready_for_enumeration() bypasses
>      the dep_unmet check and lets cxl_acpi probe early.
> 
> On x86 the bug is usually masked by link order (acpi_pci_root is
> built in and probed before cxl_acpi). On architectures like RISC-V
> that ordering is not guaranteed, so the standard ACPI _DEP mechanism
> must actually work.
> 
> This series fixes both sides and the two patches must be applied
> together; applying only patch 2 would prevent cxl_acpi from ever
> probing on ACPI0016 systems, because the supplier would never clear
> the dependency.
> 
>   Patch 1 makes acpi_pci_root_add() clear _DEP on the supplier once
>           the PCI root bus has been added.
>   Patch 2 adds ACPI0016 to acpi_honor_dep_ids[] so the dependency
>           declared by ACPI0017 is enforced.
> 
> The approach in this series follows the discussion of an earlier
> posting:
> https://lore.kernel.org/linux-cxl/20260514023238.49984-1-cp0613@linux.alibaba.com/
> 
> Chen Pei (2):
>   ACPI: PCI: clear _DEP dependencies after PCI root bridge attach
>   ACPI: scan: honor _DEP for ACPI0016 PCI/CXL host bridge

For the set:
	Tested-by: Alison Schofield <alison.schofield@intel.com>
	Reviewed-by: Alison Schofield <alison.schofield@intel.com>

Re: [PATCH 0/2] ACPI/PCI/CXL: Enforce _DEP ordering between ACPI0016 and ACPI0017

[Rafael J. Wysocki]

On Wed, May 27, 2026 at 3:15 AM Alison Schofield
<alison.schofield@intel.com> wrote:
>
> On Tue, May 26, 2026 at 10:51:16AM +0800, Chen Pei wrote:
> > On platforms whose ACPI namespace exposes a CXL host bridge (ACPI0016)
> > with an ACPI0017 CXL root device declaring _DEP on the host bridge,
> > cxl_acpi can probe before acpi_pci_root has attached the PCI root.
> > acpi_pci_find_root() then returns NULL, decoder targets read as 0,
> > and no port/endpoint device shows up under /sys/bus/cxl/devices/.
> >
> > The root cause is twofold:
> >
> >   1. acpi_pci_root_add() never calls acpi_dev_clear_dependencies(),
> >      so _DEP suppliers downstream of a PCI root are never released.
> >
> >   2. ACPI0016 is not on acpi_honor_dep_ids[], so even when ACPI0017
> >      declares _DEP on it, acpi_dev_ready_for_enumeration() bypasses
> >      the dep_unmet check and lets cxl_acpi probe early.
> >
> > On x86 the bug is usually masked by link order (acpi_pci_root is
> > built in and probed before cxl_acpi). On architectures like RISC-V
> > that ordering is not guaranteed, so the standard ACPI _DEP mechanism
> > must actually work.
> >
> > This series fixes both sides and the two patches must be applied
> > together; applying only patch 2 would prevent cxl_acpi from ever
> > probing on ACPI0016 systems, because the supplier would never clear
> > the dependency.
> >
> >   Patch 1 makes acpi_pci_root_add() clear _DEP on the supplier once
> >           the PCI root bus has been added.
> >   Patch 2 adds ACPI0016 to acpi_honor_dep_ids[] so the dependency
> >           declared by ACPI0017 is enforced.
> >
> > The approach in this series follows the discussion of an earlier
> > posting:
> > https://lore.kernel.org/linux-cxl/20260514023238.49984-1-cp0613@linux.alibaba.com/
> >
> > Chen Pei (2):
> >   ACPI: PCI: clear _DEP dependencies after PCI root bridge attach
> >   ACPI: scan: honor _DEP for ACPI0016 PCI/CXL host bridge
>
> For the set:
>         Tested-by: Alison Schofield <alison.schofield@intel.com>
>         Reviewed-by: Alison Schofield <alison.schofield@intel.com>

And so applied as 7.2 material, thanks!

[PATCH] cxl/acpi: Defer probe when ACPI0016 PCI root bridge is not ready

[Chen Pei]

On some platforms (e.g., RISC-V and ARM64) that use the generic
pci_acpi_scan_root() implementation, cxl_acpi_probe may run before
acpi_pci_root driver has bound to ACPI0016 (CXL host bridge) devices.
In this case, acpi_pci_find_root() returns NULL, causing
to_cxl_host_bridge() to skip the device silently. This results in
incomplete CXL port enumeration on first boot.

Fix this by detecting the case where an ACPI0016 device exists but its
PCI root bridge is not yet ready, and returning -EPROBE_DEFER to trigger
a deferred probe retry.

Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
---
 drivers/cxl/acpi.c | 26 ++++++++++++++++++++++++--
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/cxl/acpi.c b/drivers/cxl/acpi.c
index 127537628817..9952d0cff903 100644
--- a/drivers/cxl/acpi.c
+++ b/drivers/cxl/acpi.c
@@ -631,8 +631,21 @@ static int add_host_bridge_dport(struct device *match, void *arg)
 	struct acpi_pci_root *pci_root;
 	struct cxl_port *root_port = arg;
 	struct device *host = root_port->dev.parent;
-	struct acpi_device *hb = to_cxl_host_bridge(host, match);
+	struct acpi_device *adev = to_acpi_device(match);
+	struct acpi_device *hb;
 
+	/*
+	 * If this is an ACPI0016 device but acpi_pci_find_root() hasn't
+	 * found the PCI root yet (driver not probed), defer the probe
+	 * to allow acpi_pci_root to bind first.
+	 */
+	if (strcmp(acpi_device_hid(adev), "ACPI0016") == 0 &&
+	    !acpi_pci_find_root(adev->handle)) {
+		dev_dbg(host, "deferring probe, ACPI0016 PCI root not ready\n");
+		return -EPROBE_DEFER;
+	}
+
+	hb = to_cxl_host_bridge(host, match);
 	if (!hb)
 		return 0;
 
@@ -688,7 +701,8 @@ static int add_host_bridge_uport(struct device *match, void *arg)
 {
 	struct cxl_port *root_port = arg;
 	struct device *host = root_port->dev.parent;
-	struct acpi_device *hb = to_cxl_host_bridge(host, match);
+	struct acpi_device *adev = to_acpi_device(match);
+	struct acpi_device *hb;
 	struct acpi_pci_root *pci_root;
 	struct cxl_dport *dport;
 	struct cxl_port *port;
@@ -697,6 +711,14 @@ static int add_host_bridge_uport(struct device *match, void *arg)
 	resource_size_t component_reg_phys;
 	int rc;
 
+	/* Same deferral check as in add_host_bridge_dport() */
+	if (strcmp(acpi_device_hid(adev), "ACPI0016") == 0 &&
+	    !acpi_pci_find_root(adev->handle)) {
+		dev_dbg(host, "deferring probe, ACPI0016 PCI root not ready\n");
+		return -EPROBE_DEFER;
+	}
+
+	hb = to_cxl_host_bridge(host, match);
 	if (!hb)
 		return 0;
 
-- 
2.50.1

Re: [PATCH] cxl/acpi: Defer probe when ACPI0016 PCI root bridge is not ready

[Richard Cheng]

On Thu, May 14, 2026 at 10:32:38AM +0800, Chen Pei wrote:
> On some platforms (e.g., RISC-V and ARM64) that use the generic
> pci_acpi_scan_root() implementation, cxl_acpi_probe may run before
> acpi_pci_root driver has bound to ACPI0016 (CXL host bridge) devices.
> In this case, acpi_pci_find_root() returns NULL, causing
> to_cxl_host_bridge() to skip the device silently. This results in
> incomplete CXL port enumeration on first boot.
> 
> Fix this by detecting the case where an ACPI0016 device exists but its
> PCI root bridge is not yet ready, and returning -EPROBE_DEFER to trigger
> a deferred probe retry.
> 
> Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
> ---
>  drivers/cxl/acpi.c | 26 ++++++++++++++++++++++++--
>  1 file changed, 24 insertions(+), 2 deletions(-)
>

Hi Chen Pei,

Thanks for the patch.
I have a few questions and suggestions regarding to your changes.

First of all I would like in which scenario did you encounter the bug?
Any specific CONFIG options and the devices ? what's the error log ?

It would be nice if you can attach it for us. 

> diff --git a/drivers/cxl/acpi.c b/drivers/cxl/acpi.c
> index 127537628817..9952d0cff903 100644
> --- a/drivers/cxl/acpi.c
> +++ b/drivers/cxl/acpi.c
> @@ -631,8 +631,21 @@ static int add_host_bridge_dport(struct device *match, void *arg)
>  	struct acpi_pci_root *pci_root;
>  	struct cxl_port *root_port = arg;
>  	struct device *host = root_port->dev.parent;
> -	struct acpi_device *hb = to_cxl_host_bridge(host, match);
> +	struct acpi_device *adev = to_acpi_device(match);
> +	struct acpi_device *hb;
>  
> +	/*
> +	 * If this is an ACPI0016 device but acpi_pci_find_root() hasn't
> +	 * found the PCI root yet (driver not probed), defer the probe
> +	 * to allow acpi_pci_root to bind first.
> +	 */
> +	if (strcmp(acpi_device_hid(adev), "ACPI0016") == 0 &&
> +	    !acpi_pci_find_root(adev->handle)) {
> +		dev_dbg(host, "deferring probe, ACPI0016 PCI root not ready\n");
> +		return -EPROBE_DEFER;
> +	}

What about strncpy() here since we already know we're comparing against "ACPI0016" ?
At the same time, why not just use "acpi_dev_hid_match()" ? it's widely used across
numerous files.

> +
> +	hb = to_cxl_host_bridge(host, match);
>  	if (!hb)
>  		return 0;
>  
> @@ -688,7 +701,8 @@ static int add_host_bridge_uport(struct device *match, void *arg)
>  {
>  	struct cxl_port *root_port = arg;
>  	struct device *host = root_port->dev.parent;
> -	struct acpi_device *hb = to_cxl_host_bridge(host, match);
> +	struct acpi_device *adev = to_acpi_device(match);
> +	struct acpi_device *hb;
>  	struct acpi_pci_root *pci_root;
>  	struct cxl_dport *dport;
>  	struct cxl_port *port;
> @@ -697,6 +711,14 @@ static int add_host_bridge_uport(struct device *match, void *arg)
>  	resource_size_t component_reg_phys;
>  	int rc;
>  
> +	/* Same deferral check as in add_host_bridge_dport() */
> +	if (strcmp(acpi_device_hid(adev), "ACPI0016") == 0 &&
> +	    !acpi_pci_find_root(adev->handle)) {
> +		dev_dbg(host, "deferring probe, ACPI0016 PCI root not ready\n");
> +		return -EPROBE_DEFER;
> +	}
> +
> +	hb = to_cxl_host_bridge(host, match);
>  	if (!hb)
>  		return 0;
>  
> -- 
> 2.50.1
> 
> 

These 2 checks are basically the same, can we put it in a static inline helper or
a macro if possible? something like the following might be better

```
static int cxl_acpi_defer_host_bridge(struct device *host,
				      struct acpi_device *adev)
{
	if (acpi_dev_hid_match(adev, "ACPI0016") &&
	    !acpi_pci_find_root(adev->handle)) {
		dev_dbg(host, "deferring probe, ACPI0016 PCI root not ready\n");
		return -EPROBE_DEFER;
	}
	return 0;
}
```
and use it in your code like

```
int rc = cxl_acpi_defer_host_bridge(host, adev);
if (rc)
	return rc;
```


Last but not least, have you run the kselftests of CXL ? some mock bridges
are platform devices, not ACPI devices, you are using "to_acpi_device(match)", this
is not a safe runtime check when "match" is a platform_device, the code will read the memory
layout wrongly.


Best regards,
Richard Cheng.

Re: [PATCH] cxl/acpi: Defer probe when ACPI0016 PCI root bridge is not ready

[Chen Pei]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 6567 bytes --]

On Thu, 14 May 2026 15:31:11 +0800, Richard Cheng wrote:

> > On some platforms (e.g., RISC-V and ARM64) that use the generic
> > pci_acpi_scan_root() implementation, cxl_acpi_probe may run before
> > acpi_pci_root driver has bound to ACPI0016 (CXL host bridge) devices.
> > In this case, acpi_pci_find_root() returns NULL, causing
> > to_cxl_host_bridge() to skip the device silently. This results in
> > incomplete CXL port enumeration on first boot.
> > 
> > Fix this by detecting the case where an ACPI0016 device exists but its
> > PCI root bridge is not yet ready, and returning -EPROBE_DEFER to trigger
> > a deferred probe retry.
> > 
> > Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
> > ---
> >  drivers/cxl/acpi.c | 26 ++++++++++++++++++++++++--
> >  1 file changed, 24 insertions(+), 2 deletions(-)
> >
> 
> Hi Chen Pei,
> 
> Thanks for the patch.
> I have a few questions and suggestions regarding to your changes.
> 
> First of all I would like in which scenario did you encounter the bug?
> Any specific CONFIG options and the devices ? what's the error log ?
> 
> It would be nice if you can attach it for us.

Hi Richard,

Thanks for the review.

I'm currently working on bringing up CXL support on the RISC-V QEMU
virt platform with ACPI (EDK2 UEFI firmware). This is still in the
early debugging/enabling stage.

During testing, I found that cxl_acpi (ACPI0017) probes before
acpi_pci_root has bound to the ACPI0016 (CXL host bridge) device.
RISC-V uses the generic pci_acpi_scan_root() implementation, where
the probe ordering of acpi_pci_root relative to cxl_acpi is not
guaranteed.

On x86, acpi_pci_root uses subsys_initcall and binds very early,
so this race does not manifest there.

This is a silent failure (no explicit error log), which makes it
particularly hard to diagnose. When cxl_acpi probes before
acpi_pci_root has bound the ACPI0016 device:
1. acpi_pci_find_root() returns NULL in to_cxl_host_bridge()
2. to_cxl_host_bridge() returns NULL
2. Both add_host_bridge_dport() and add_host_bridge_uport() return 0
   (not an error), silently skipping the host bridge
3. cxl_acpi_probe() returns success, but the CXL port topology is
   incomplete — no dports or uports are registered

The observable result after boot:
    # memdev is visible but decoder hierarchy is missing
    $ cxl list -M
    [
      {
        "memdev":"mem0",
        ...
      }
    ]

    # No decoders or ports registered for the host bridge
    $ cxl list -BDP
    []

    # Workaround: manually unbind/bind triggers re-probe after
    # acpi_pci_root is ready, and CXL topology enumerates correctly
    $ echo ACPI0017:00 > /sys/bus/platform/drivers/cxl_acpi/unbind
    $ echo ACPI0017:00 > /sys/bus/platform/drivers/cxl_acpi/bind

    # After re-probe, full topology is available and CXL memory
    # can be enabled/onlined successfully
    $ cxl enable-memdev mem0
    $ cxl create-region -m -t ram -d decoder0.0 -w 1 mem0 -s 4G
    $ daxctl online-memory dax0.0

> > diff --git a/drivers/cxl/acpi.c b/drivers/cxl/acpi.c
> > index 127537628817..9952d0cff903 100644
> > --- a/drivers/cxl/acpi.c
> > +++ b/drivers/cxl/acpi.c
> > @@ -631,8 +631,21 @@ static int add_host_bridge_dport(struct device *match, void *arg)
> >   struct acpi_pci_root *pci_root;
> >   struct cxl_port *root_port = arg;
> >   struct device *host = root_port->dev.parent;
> > - struct acpi_device *hb = to_cxl_host_bridge(host, match);
> > + struct acpi_device *adev = to_acpi_device(match);
> > + struct acpi_device *hb;
> >  
> > + /*
> > +  * If this is an ACPI0016 device but acpi_pci_find_root() hasn't
> > +  * found the PCI root yet (driver not probed), defer the probe
> > +  * to allow acpi_pci_root to bind first.
> > +  */
> > + if (strcmp(acpi_device_hid(adev), "ACPI0016") == 0 &&
> > +     !acpi_pci_find_root(adev->handle)) {
> > +  dev_dbg(host, "deferring probe, ACPI0016 PCI root not ready\n");
> > +  return -EPROBE_DEFER;
> > + }
> 
> What about strncpy() here since we already know we're comparing against "ACPI0016" ?
> At the same time, why not just use "acpi_dev_hid_match()" ? it's widely used across
> numerous files.

Good point, thanks. I will switch to the acpi_dev_hid_match() in v2.

> > +
> > + hb = to_cxl_host_bridge(host, match);
> >   if (!hb)
> >    return 0;
> >  
> > @@ -688,7 +701,8 @@ static int add_host_bridge_uport(struct device *match, void *arg)
> >  {
> >   struct cxl_port *root_port = arg;
> >   struct device *host = root_port->dev.parent;
> > - struct acpi_device *hb = to_cxl_host_bridge(host, match);
> > + struct acpi_device *adev = to_acpi_device(match);
> > + struct acpi_device *hb;
> >   struct acpi_pci_root *pci_root;
> >   struct cxl_dport *dport;
> >   struct cxl_port *port;
> > @@ -697,6 +711,14 @@ static int add_host_bridge_uport(struct device *match, void *arg)
> >   resource_size_t component_reg_phys;
> >   int rc;
> >  
> > + /* Same deferral check as in add_host_bridge_dport() */
> > + if (strcmp(acpi_device_hid(adev), "ACPI0016") == 0 &&
> > +     !acpi_pci_find_root(adev->handle)) {
> > +  dev_dbg(host, "deferring probe, ACPI0016 PCI root not ready\n");
> > +  return -EPROBE_DEFER;
> > + }
> > +
> > + hb = to_cxl_host_bridge(host, match);
> >   if (!hb)
> >    return 0;
> >  
> > -- 
> > 2.50.1
> > 
> > 
> 
> These 2 checks are basically the same, can we put it in a static inline helper or
> a macro if possible? something like the following might be better
> 
> ```
> static int cxl_acpi_defer_host_bridge(struct device *host,
          > struct acpi_device *adev)
> {
 > if (acpi_dev_hid_match(adev, "ACPI0016") &&
     > !acpi_pci_find_root(adev->handle)) {
  > dev_dbg(host, "deferring probe, ACPI0016 PCI root not ready\n");
  > return -EPROBE_DEFER;
 > }
 > return 0;
> }
> ```
> and use it in your code like
> 
> ```
> int rc = cxl_acpi_defer_host_bridge(host, adev);
> if (rc)
 > return rc;
> ```

Agreed, will extract it into a helper in v2.

> Last but not least, have you run the kselftests of CXL ? some mock bridges
> are platform devices, not ACPI devices, you are using "to_acpi_device(match)", this
> is not a safe runtime check when "match" is a platform_device, the code will read the memory
> layout wrongly.

Good catch, I haven't run the CXL kselftests. You're right that the
mock bridges are platform devices and unconditionally calling
to_acpi_device(match) would be unsafe there.

I'll fix this in v2 by adding a dev_is_platform() guard in the
helper, so it only applies to real ACPI devices. I'll also run
the CXL kselftests to validate before sending v2.

Thanks,
Pei

Re: [PATCH] cxl/acpi: Defer probe when ACPI0016 PCI root bridge is not ready

[Dan Williams (nvidia)]

Chen Pei wrote:
> On Thu, 14 May 2026 15:31:11 +0800, Richard Cheng wrote:
> 
> > > On some platforms (e.g., RISC-V and ARM64) that use the generic
> > > pci_acpi_scan_root() implementation, cxl_acpi_probe may run before
> > > acpi_pci_root driver has bound to ACPI0016 (CXL host bridge) devices.
> > > In this case, acpi_pci_find_root() returns NULL, causing
> > > to_cxl_host_bridge() to skip the device silently. This results in
> > > incomplete CXL port enumeration on first boot.
> > > 
> > > Fix this by detecting the case where an ACPI0016 device exists but its
> > > PCI root bridge is not yet ready, and returning -EPROBE_DEFER to trigger
> > > a deferred probe retry.
> > > 
> > > Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
> > > ---
> > >  drivers/cxl/acpi.c | 26 ++++++++++++++++++++++++--
> > >  1 file changed, 24 insertions(+), 2 deletions(-)
> > >
> > 
> > Hi Chen Pei,
> > 
> > Thanks for the patch.
> > I have a few questions and suggestions regarding to your changes.
> > 
> > First of all I would like in which scenario did you encounter the bug?
> > Any specific CONFIG options and the devices ? what's the error log ?
> > 
> > It would be nice if you can attach it for us.
> 
> Hi Richard,
> 
> Thanks for the review.
> 
> I'm currently working on bringing up CXL support on the RISC-V QEMU
> virt platform with ACPI (EDK2 UEFI firmware). This is still in the
> early debugging/enabling stage.
>
> During testing, I found that cxl_acpi (ACPI0017) probes before
> acpi_pci_root has bound to the ACPI0016 (CXL host bridge) device.
> RISC-V uses the generic pci_acpi_scan_root() implementation, where
> the probe ordering of acpi_pci_root relative to cxl_acpi is not
> guaranteed.
> 
> On x86, acpi_pci_root uses subsys_initcall and binds very early,
> so this race does not manifest there.

If the platform is defined to defer PCI root scans then this dependency
must be declared. Specifically firmware needs to tell Linux about the
dependency given it does not order PCI enumeration before ACPI0017
enumeration by default. Something like: 

  Device (CXLM) { // ACPI0017
      Name (_HID, "ACPI0017")
      Name (_DEP, Package () {
          \_SB.CXL0, // ACPI0016 host bridge
          \_SB.CXL1,
      })
  }

...in the firmware, and then:

acpi_dev_clear_dependencies()

...for each acpi_pci_root_add().

Then ACPI0017 will naturally await all of the ACPI0016 devices that the
firmware knows about.

Otherwise EPROBE_DEFER and scanning for ACPI0016 attachment is
introducing a mess that _DEP was meant to solve.

Re: [PATCH] cxl/acpi: Defer probe when ACPI0016 PCI root bridge is not ready

[Chen Pei]

On Fri, 15 May 2026 12:24:50 -0700, Dan Williams wrote:

> If the platform is defined to defer PCI root scans then this dependency
> must be declared. Specifically firmware needs to tell Linux about the
> dependency given it does not order PCI enumeration before ACPI0017
> enumeration by default. Something like: 
> 
>   Device (CXLM) { // ACPI0017
>       Name (_HID, "ACPI0017")
>       Name (_DEP, Package () {
>           \_SB.CXL0, // ACPI0016 host bridge
>           \_SB.CXL1,
>       })
>   }
> 
> ...in the firmware, and then:
> 
> acpi_dev_clear_dependencies()
> 
> ...for each acpi_pci_root_add().
> 
> Then ACPI0017 will naturally await all of the ACPI0016 devices that the
> firmware knows about.

Hi Dan,

Thanks for the guidance. The _DEP approach is clearly the right way
to handle this - it's the proper ACPI standard mechanism for declaring
device dependencies and avoids the permanent defer risk that Dave and
others raised with the EPROBE_DEFER approach.

I plan to abandon this patch and implement the _DEP solution instead.
Let me confirm my understanding of the two changes needed:

1. Firmware (QEMU DSDT): Add a _DEP package to the ACPI0017 device
   that references all ACPI0016 CXL host bridge devices in the system.

2. Kernel (drivers/acpi/pci_root.c): Add acpi_dev_clear_dependencies()
   at the end of acpi_pci_root_add() so that once an ACPI0016 device
   is bound, its consumers (ACPI0017) are notified and can proceed
   with probing.

Is my understanding correct? Any other changes or considerations
I might be missing?

Thanks,
Pei

Re: [PATCH] cxl/acpi: Defer probe when ACPI0016 PCI root bridge is not ready

[Dave Jiang]

On 5/18/26 6:55 PM, Chen Pei wrote:
> On Fri, 15 May 2026 12:24:50 -0700, Dan Williams wrote:
> 
>> If the platform is defined to defer PCI root scans then this dependency
>> must be declared. Specifically firmware needs to tell Linux about the
>> dependency given it does not order PCI enumeration before ACPI0017
>> enumeration by default. Something like: 
>>
>>   Device (CXLM) { // ACPI0017
>>       Name (_HID, "ACPI0017")
>>       Name (_DEP, Package () {
>>           \_SB.CXL0, // ACPI0016 host bridge
>>           \_SB.CXL1,
>>       })
>>   }
>>
>> ...in the firmware, and then:
>>
>> acpi_dev_clear_dependencies()
>>
>> ...for each acpi_pci_root_add().
>>
>> Then ACPI0017 will naturally await all of the ACPI0016 devices that the
>> firmware knows about.
> 
> Hi Dan,
> 
> Thanks for the guidance. The _DEP approach is clearly the right way
> to handle this - it's the proper ACPI standard mechanism for declaring
> device dependencies and avoids the permanent defer risk that Dave and
> others raised with the EPROBE_DEFER approach.
> 
> I plan to abandon this patch and implement the _DEP solution instead.
> Let me confirm my understanding of the two changes needed:
> 
> 1. Firmware (QEMU DSDT): Add a _DEP package to the ACPI0017 device
>    that references all ACPI0016 CXL host bridge devices in the system.
> 
> 2. Kernel (drivers/acpi/pci_root.c): Add acpi_dev_clear_dependencies()
>    at the end of acpi_pci_root_add() so that once an ACPI0016 device
>    is bound, its consumers (ACPI0017) are notified and can proceed
>    with probing.

Please submit a patch upstream for this. Thanks!

> 
> Is my understanding correct? Any other changes or considerations
> I might be missing?
> 
> Thanks,
> Pei

Re: [PATCH] cxl/acpi: Defer probe when ACPI0016 PCI root bridge is not ready

[Dave Jiang]

On 5/13/26 7:32 PM, Chen Pei wrote:
> On some platforms (e.g., RISC-V and ARM64) that use the generic
> pci_acpi_scan_root() implementation, cxl_acpi_probe may run before
> acpi_pci_root driver has bound to ACPI0016 (CXL host bridge) devices.
> In this case, acpi_pci_find_root() returns NULL, causing
> to_cxl_host_bridge() to skip the device silently. This results in
> incomplete CXL port enumeration on first boot.
> 
> Fix this by detecting the case where an ACPI0016 device exists but its
> PCI root bridge is not yet ready, and returning -EPROBE_DEFER to trigger
> a deferred probe retry.
> 
> Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
> ---
>  drivers/cxl/acpi.c | 26 ++++++++++++++++++++++++--
>  1 file changed, 24 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/cxl/acpi.c b/drivers/cxl/acpi.c
> index 127537628817..9952d0cff903 100644
> --- a/drivers/cxl/acpi.c
> +++ b/drivers/cxl/acpi.c
> @@ -631,8 +631,21 @@ static int add_host_bridge_dport(struct device *match, void *arg)
>  	struct acpi_pci_root *pci_root;
>  	struct cxl_port *root_port = arg;
>  	struct device *host = root_port->dev.parent;
> -	struct acpi_device *hb = to_cxl_host_bridge(host, match);
> +	struct acpi_device *adev = to_acpi_device(match);
> +	struct acpi_device *hb;
>  
> +	/*
> +	 * If this is an ACPI0016 device but acpi_pci_find_root() hasn't
> +	 * found the PCI root yet (driver not probed), defer the probe
> +	 * to allow acpi_pci_root to bind first.
> +	 */
> +	if (strcmp(acpi_device_hid(adev), "ACPI0016") == 0 &&
> +	    !acpi_pci_find_root(adev->handle)) {
> +		dev_dbg(host, "deferring probe, ACPI0016 PCI root not ready\n");
> +		return -EPROBE_DEFER;
> +	}
> +
> +	hb = to_cxl_host_bridge(host, match);
>  	if (!hb)
>  		return 0;
>  
> @@ -688,7 +701,8 @@ static int add_host_bridge_uport(struct device *match, void *arg)
>  {
>  	struct cxl_port *root_port = arg;
>  	struct device *host = root_port->dev.parent;
> -	struct acpi_device *hb = to_cxl_host_bridge(host, match);
> +	struct acpi_device *adev = to_acpi_device(match);
> +	struct acpi_device *hb;
>  	struct acpi_pci_root *pci_root;
>  	struct cxl_dport *dport;
>  	struct cxl_port *port;
> @@ -697,6 +711,14 @@ static int add_host_bridge_uport(struct device *match, void *arg)
>  	resource_size_t component_reg_phys;
>  	int rc;
>  
> +	/* Same deferral check as in add_host_bridge_dport() */
> +	if (strcmp(acpi_device_hid(adev), "ACPI0016") == 0 &&
> +	    !acpi_pci_find_root(adev->handle)) {
> +		dev_dbg(host, "deferring probe, ACPI0016 PCI root not ready\n");
> +		return -EPROBE_DEFER;
> +	}

I don't believe this check in add_host_bridge_uport() is necessary. add_host_bridge_dport() happens first and the check should've been done there. There is no reason to do it again and you'll never reach here if it's not ready. 

DJ

> +
> +	hb = to_cxl_host_bridge(host, match);
>  	if (!hb)
>  		return 0;
>  

Re: [PATCH] cxl/acpi: Defer probe when ACPI0016 PCI root bridge is not ready

[Chen Pei]

On Thu, 14 May 2026 10:10:50 -0700, Dave Jiang wrote:

> > On some platforms (e.g., RISC-V and ARM64) that use the generic
> > pci_acpi_scan_root() implementation, cxl_acpi_probe may run before
> > acpi_pci_root driver has bound to ACPI0016 (CXL host bridge) devices.
> > In this case, acpi_pci_find_root() returns NULL, causing
> > to_cxl_host_bridge() to skip the device silently. This results in
> > incomplete CXL port enumeration on first boot.
> > 
> > Fix this by detecting the case where an ACPI0016 device exists but its
> > PCI root bridge is not yet ready, and returning -EPROBE_DEFER to trigger
> > a deferred probe retry.
> > 
> > Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
> > ---
> >  drivers/cxl/acpi.c | 26 ++++++++++++++++++++++++--
> >  1 file changed, 24 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/cxl/acpi.c b/drivers/cxl/acpi.c
> > index 127537628817..9952d0cff903 100644
> > --- a/drivers/cxl/acpi.c
> > +++ b/drivers/cxl/acpi.c
> > @@ -631,8 +631,21 @@ static int add_host_bridge_dport(struct device *match, void *arg)
> >   struct acpi_pci_root *pci_root;
> >   struct cxl_port *root_port = arg;
> >   struct device *host = root_port->dev.parent;
> > - struct acpi_device *hb = to_cxl_host_bridge(host, match);
> > + struct acpi_device *adev = to_acpi_device(match);
> > + struct acpi_device *hb;
> >  
> > + /*
> > +  * If this is an ACPI0016 device but acpi_pci_find_root() hasn't
> > +  * found the PCI root yet (driver not probed), defer the probe
> > +  * to allow acpi_pci_root to bind first.
> > +  */
> > + if (strcmp(acpi_device_hid(adev), "ACPI0016") == 0 &&
> > +     !acpi_pci_find_root(adev->handle)) {
> > +  dev_dbg(host, "deferring probe, ACPI0016 PCI root not ready\n");
> > +  return -EPROBE_DEFER;
> > + }
> > +
> > + hb = to_cxl_host_bridge(host, match);
> >   if (!hb)
> >    return 0;
> >  
> > @@ -688,7 +701,8 @@ static int add_host_bridge_uport(struct device *match, void *arg)
> >  {
> >   struct cxl_port *root_port = arg;
> >   struct device *host = root_port->dev.parent;
> > - struct acpi_device *hb = to_cxl_host_bridge(host, match);
> > + struct acpi_device *adev = to_acpi_device(match);
> > + struct acpi_device *hb;
> >   struct acpi_pci_root *pci_root;
> >   struct cxl_dport *dport;
> >   struct cxl_port *port;
> > @@ -697,6 +711,14 @@ static int add_host_bridge_uport(struct device *match, void *arg)
> >   resource_size_t component_reg_phys;
> >   int rc;
> >  
> > + /* Same deferral check as in add_host_bridge_dport() */
> > + if (strcmp(acpi_device_hid(adev), "ACPI0016") == 0 &&
> > +     !acpi_pci_find_root(adev->handle)) {
> > +  dev_dbg(host, "deferring probe, ACPI0016 PCI root not ready\n");
> > +  return -EPROBE_DEFER;
> > + }
> 
> I don't believe this check in add_host_bridge_uport() is necessary. add_host_bridge_dport() happens first and the check should've been done there. There is no reason to do it again and you'll never reach here if it's not ready. 
> 
> DJ

Hi Dave,

You're right. Since add_host_bridge_dport() is called first and
cxl_acpi_probe() returns early on error, add_host_bridge_uport()
will never be reached if the PCI root is not ready. I'll drop the
duplicate check in v2.

Thanks,
Pei

> > +
> > + hb = to_cxl_host_bridge(host, match);
> >   if (!hb)
> >    return 0;

Re: [PATCH] cxl/acpi: Defer probe when ACPI0016 PCI root bridge is not ready

[Alison Schofield]

On Thu, May 14, 2026 at 10:32:38AM +0800, Chen Pei wrote:
> On some platforms (e.g., RISC-V and ARM64) that use the generic
> pci_acpi_scan_root() implementation, cxl_acpi_probe may run before
> acpi_pci_root driver has bound to ACPI0016 (CXL host bridge) devices.
> In this case, acpi_pci_find_root() returns NULL, causing
> to_cxl_host_bridge() to skip the device silently. This results in
> incomplete CXL port enumeration on first boot.
> 
> Fix this by detecting the case where an ACPI0016 device exists but its
> PCI root bridge is not yet ready, and returning -EPROBE_DEFER to trigger
> a deferred probe retry.
> 
> Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>

Hi Chen Pei,

As Richard suggested, this fails for the mock platform in cxl-test.
(stack trace appended at end)

With this diff applied on top of your patch, it works for cxl-test
AND I think it works for your case too. With real hardware,
ACPI_COMPANION returns the device, and with the mock platform,
ACPI_COMPANION returns NULL and the defer check is skipped.

Try it out, and note that I didn't consider if any of the comments
need updating.


diff --git a/drivers/cxl/acpi.c b/drivers/cxl/acpi.c
index 9952d0cff903..ec037668afba 100644
--- a/drivers/cxl/acpi.c
+++ b/drivers/cxl/acpi.c
@@ -631,7 +631,7 @@ static int add_host_bridge_dport(struct device *match, void *arg)
 	struct acpi_pci_root *pci_root;
 	struct cxl_port *root_port = arg;
 	struct device *host = root_port->dev.parent;
-	struct acpi_device *adev = to_acpi_device(match);
+	struct acpi_device *adev = ACPI_COMPANION(match);
 	struct acpi_device *hb;
 
 	/*
@@ -639,7 +639,7 @@ static int add_host_bridge_dport(struct device *match, void *arg)
 	 * found the PCI root yet (driver not probed), defer the probe
 	 * to allow acpi_pci_root to bind first.
 	 */
-	if (strcmp(acpi_device_hid(adev), "ACPI0016") == 0 &&
+	if (adev && strcmp(acpi_device_hid(adev), "ACPI0016") == 0 &&
 	    !acpi_pci_find_root(adev->handle)) {
 		dev_dbg(host, "deferring probe, ACPI0016 PCI root not ready\n");
 		return -EPROBE_DEFER;
@@ -701,7 +701,7 @@ static int add_host_bridge_uport(struct device *match, void *arg)
 {
 	struct cxl_port *root_port = arg;
 	struct device *host = root_port->dev.parent;
-	struct acpi_device *adev = to_acpi_device(match);
+	struct acpi_device *adev = ACPI_COMPANION(match);
 	struct acpi_device *hb;
 	struct acpi_pci_root *pci_root;
 	struct cxl_dport *dport;
@@ -711,8 +711,7 @@ static int add_host_bridge_uport(struct device *match, void *arg)
 	resource_size_t component_reg_phys;
 	int rc;
 
-	/* Same deferral check as in add_host_bridge_dport() */
-	if (strcmp(acpi_device_hid(adev), "ACPI0016") == 0 &&
+	if (adev && strcmp(acpi_device_hid(adev), "ACPI0016") == 0 &&
 	    !acpi_pci_find_root(adev->handle)) {
 		dev_dbg(host, "deferring probe, ACPI0016 PCI root not ready\n");
 		return -EPROBE_DEFER;

==========

Failure loading cxl-test module:

[    6.523556] calling  cxl_test_init+0x0/0xff0 [cxl_test] @ 622
[    6.524952] BUG: kernel NULL pointer dereference, address: 0000000000000091
[    6.526022] #PF: supervisor read access in kernel mode
[    6.526988] #PF: error_code(0x0000) - not-present page
[    6.527855] PGD 0 P4D 0 
[    6.528331] Oops: Oops: 0000 [#1] SMP NOPTI
[    6.529268] CPU: 3 UID: 0 PID: 622 Comm: systemd-modules Tainted: G           O        7.1.0-rc1+ #212 PREEMPT(lazy) 
[    6.530655] Tainted: [O]=OOT_MODULE
[    6.531238] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
[    6.532321] RIP: 0010:acpi_device_hid+0x18/0x30
[    6.533008] Code: cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 48 8b 87 98 00 00 00 48 81 c7 98 00 00 00 48 39 f8 74 0e 48 85 c0 74 09 <48> 8b 40 10 c3 cc cc cc cc 48 c7 c0 ad c9 a7 82 c3 cc cc cc cc 0f
[    6.535011] RSP: 0018:ffffc90002077870 EFLAGS: 00010206
[    6.535729] RAX: 0000000000000081 RBX: ffff8882000eb010 RCX: ffffffffa00504f0
[    6.536514] RDX: ffff88800199acc8 RSI: ffff888006ca6000 RDI: ffff8882000eae48
[    6.537284] RBP: ffffc900020778c0 R08: ffffffffa0e67491 R09: 0000000000000040
[    6.538122] R10: ffff888203667c00 R11: ffffffff835ccf70 R12: ffff888006ba3010
[    6.538961] R13: ffff888006ca6000 R14: 0000000000000000 R15: ffff888006ca6000
[    6.539777] FS:  00007f9001205480(0000) GS:ffff8880fa501000(0000) knlGS:0000000000000000
[    6.540639] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    6.541313] CR2: 0000000000000091 CR3: 0000000007037003 CR4: 0000000000370ef0
[    6.542125] Call Trace:
[    6.542540]  <TASK>
[    6.542903]  ? add_host_bridge_dport+0x23/0x200 [cxl_acpi]
[    6.543538]  ? klist_next+0xb0/0x170
[    6.544019]  ? __pfx_add_host_bridge_dport+0x10/0x10 [cxl_acpi]
[    6.544716]  bus_for_each_dev+0x65/0xa0
[    6.545204]  cxl_acpi_probe+0xe5/0x2d0 [cxl_acpi]
[    6.545758]  ? acpi_dev_pm_attach+0x20/0xf0
[    6.546300]  platform_probe+0x3a/0x70
[    6.546834]  really_probe+0xda/0x3e0
[    6.547302]  ? __pfx___device_attach_driver+0x10/0x10
[    6.547913]  __driver_probe_device+0x10b/0x1a0
[    6.548422]  driver_probe_device+0x1f/0x90
[    6.548949]  __device_attach_driver+0x8f/0x130
[    6.549448]  bus_for_each_drv+0x73/0xb0
[    6.549947]  __device_attach+0xb1/0x1c0
[    6.550371]  device_initial_probe+0x43/0x50
[    6.550882]  bus_probe_device+0x29/0x90
[    6.551340]  device_add+0x682/0x860
[    6.551836]  ? dev_set_name+0x3e/0x50
[    6.552282]  platform_device_add+0x176/0x260
[    6.552820]  cxl_test_init+0x80c/0xff0 [cxl_test]
[    6.553348]  ? __pfx_cxl_test_init+0x10/0x10 [cxl_test]
[    6.553954]  do_one_initcall+0x46/0x220
[    6.554411]  do_init_module+0x63/0x240
[    6.554926]  load_module+0x2826/0x2b40
[    6.555410]  ? kernel_read+0x3f/0x50
[    6.555931]  ? kernel_read_file+0x27b/0x2f0
[    6.556414]  init_module_from_file+0xbc/0xf0
[    6.556964]  __x64_sys_finit_module+0x267/0x380
[    6.557473]  x64_sys_call+0x1d68/0x2010
[    6.557958]  do_syscall_64+0x5a/0x470
[    6.558399]  entry_SYSCALL_64_after_hwframe+0x71/0x79
[    6.558981] RIP: 0033:0x7f900110b27d
[    6.559405] Code: 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 cb 0e 00 f7 d8 64 89 01 48
[    6.561245] RSP: 002b:00007fff4b386268 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[    6.562035] RAX: ffffffffffffffda RBX: 000055b7253f34b0 RCX: 00007f900110b27d
[    6.562779] RDX: 0000000000000000 RSI: 00007f900178f43c RDI: 000000000000000c
[    6.563473] RBP: 00007f900178f43c R08: 0000000000000000 R09: 000055b7253f8f80
[    6.564187] R10: 000000000000000c R11: 0000000000000246 R12: 0000000000020000
[    6.564918] R13: 000055b7253f4cc0 R14: 0000000000000000 R15: 000055b7253f97c0
[    6.565601]  </TASK>
[    6.565895] Modules linked in: cxl_test(O+) cxl_acpi(O) cxl_pmem(O) cxl_mem(O) cxl_port(O) cxl_mock(O) cxl_core(O) fwctl libnvdimm
[    6.566999] CR2: 0000000000000091
[    6.567417] ---[ end trace 0000000000000000 ]---
[    6.567990] RIP: 0010:acpi_device_hid+0x18/0x30
[    6.568661] Code: cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 48 8b 87 98 00 00 00 48 81 c7 98 00 00 00 48 39 f8 74 0e 48 85 c0 74 09 <48> 8b 40 10 c3 cc cc cc cc 48 c7 c0 ad c9 a7 82 c3 cc cc cc cc 0f
[    6.573628] RSP: 0018:ffffc90002077870 EFLAGS: 00010206
[    6.575230] RAX: 0000000000000081 RBX: ffff8882000eb010 RCX: ffffffffa00504f0
[    6.577279] RDX: ffff88800199acc8 RSI: ffff888006ca6000 RDI: ffff8882000eae48
[    6.579343] RBP: ffffc900020778c0 R08: ffffffffa0e67491 R09: 0000000000000040
[    6.581407] R10: ffff888203667c00 R11: ffffffff835ccf70 R12: ffff888006ba3010
[    6.583237] R13: ffff888006ca6000 R14: 0000000000000000 R15: ffff888006ca6000
[    6.584595] FS:  00007f9001205480(0000) GS:ffff8880fa501000(0000) knlGS:0000000000000000
[    6.586087] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    6.587256] CR2: 0000000000000091 CR3: 0000000007037003 CR4: 0000000000370ef0
[    6.588634] note: systemd-modules[622] exited with irqs disabled

Re: [PATCH] cxl/acpi: Defer probe when ACPI0016 PCI root bridge is not ready

[Chen Pei]

On Thu, 14 May 2026 10:19:43 -0700, Alison Schofield wrote:

> > On some platforms (e.g., RISC-V and ARM64) that use the generic
> > pci_acpi_scan_root() implementation, cxl_acpi_probe may run before
> > acpi_pci_root driver has bound to ACPI0016 (CXL host bridge) devices.
> > In this case, acpi_pci_find_root() returns NULL, causing
> > to_cxl_host_bridge() to skip the device silently. This results in
> > incomplete CXL port enumeration on first boot.
> > 
> > Fix this by detecting the case where an ACPI0016 device exists but its
> > PCI root bridge is not yet ready, and returning -EPROBE_DEFER to trigger
> > a deferred probe retry.
> > 
> > Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
> 
> Hi Chen Pei,
> 
> As Richard suggested, this fails for the mock platform in cxl-test.
> (stack trace appended at end)
> 
> With this diff applied on top of your patch, it works for cxl-test
> AND I think it works for your case too. With real hardware,
> ACPI_COMPANION returns the device, and with the mock platform,
> ACPI_COMPANION returns NULL and the defer check is skipped.
> 
> Try it out, and note that I didn't consider if any of the comments
> need updating.

Hi Alison,

Thanks for the fix! 

I'll test it on my RISC-V QEMU setup and fold it into v2 along with
the other review feedback (switching to acpi_dev_hid_match(),
dropping the redundant check in add_host_bridge_uport(), etc.).

Will also run the CXL kselftests to make sure the mock platform path
works correctly.

Thanks,
Pei

Re: [PATCH] cxl/acpi: Defer probe when ACPI0016 PCI root bridge is not ready

[Dave Jiang]

On 5/13/26 7:32 PM, Chen Pei wrote:
> On some platforms (e.g., RISC-V and ARM64) that use the generic
> pci_acpi_scan_root() implementation, cxl_acpi_probe may run before
> acpi_pci_root driver has bound to ACPI0016 (CXL host bridge) devices.
> In this case, acpi_pci_find_root() returns NULL, causing
> to_cxl_host_bridge() to skip the device silently. This results in
> incomplete CXL port enumeration on first boot.
> 
> Fix this by detecting the case where an ACPI0016 device exists but its
> PCI root bridge is not yet ready, and returning -EPROBE_DEFER to trigger
> a deferred probe retry.
> 
> Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
> ---
>  drivers/cxl/acpi.c | 26 ++++++++++++++++++++++++--
>  1 file changed, 24 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/cxl/acpi.c b/drivers/cxl/acpi.c
> index 127537628817..9952d0cff903 100644
> --- a/drivers/cxl/acpi.c
> +++ b/drivers/cxl/acpi.c
> @@ -631,8 +631,21 @@ static int add_host_bridge_dport(struct device *match, void *arg)
>  	struct acpi_pci_root *pci_root;
>  	struct cxl_port *root_port = arg;
>  	struct device *host = root_port->dev.parent;
> -	struct acpi_device *hb = to_cxl_host_bridge(host, match);
> +	struct acpi_device *adev = to_acpi_device(match);
> +	struct acpi_device *hb;
>  
> +	/*
> +	 * If this is an ACPI0016 device but acpi_pci_find_root() hasn't
> +	 * found the PCI root yet (driver not probed), defer the probe
> +	 * to allow acpi_pci_root to bind first.
> +	 */
> +	if (strcmp(acpi_device_hid(adev), "ACPI0016") == 0 &&
> +	    !acpi_pci_find_root(adev->handle)) {

I would leave the assignment of 'hb' as is above and just what's below after looking at to_cxl_host_bridge() function.

if (!hb) {
	if (!acpi_pci_find_root(adev->handle)) {
		...
		return -EPROBE_DEFER;
	}
	return 0;
}

I am concerned of other failure cases that causes acpi_pci_find_root() to fail beyond the driver not being attached. Will cxl_acpi probe() be stuck permanently in the defer probe queue when that happens? This is also something that Sashiko raised. Is there no way to adjust the RISCV ACPI setup to go around subsys_initcall()? That would be preferred solution.

DJ

> +		dev_dbg(host, "deferring probe, ACPI0016 PCI root not ready\n");
> +		return -EPROBE_DEFER;
> +	}
> +
> +	hb = to_cxl_host_bridge(host, match);
>  	if (!hb)
>  		return 0;
>  
> @@ -688,7 +701,8 @@ static int add_host_bridge_uport(struct device *match, void *arg)
>  {
>  	struct cxl_port *root_port = arg;
>  	struct device *host = root_port->dev.parent;
> -	struct acpi_device *hb = to_cxl_host_bridge(host, match);
> +	struct acpi_device *adev = to_acpi_device(match);
> +	struct acpi_device *hb;
>  	struct acpi_pci_root *pci_root;
>  	struct cxl_dport *dport;
>  	struct cxl_port *port;
> @@ -697,6 +711,14 @@ static int add_host_bridge_uport(struct device *match, void *arg)
>  	resource_size_t component_reg_phys;
>  	int rc;
>  
> +	/* Same deferral check as in add_host_bridge_dport() */
> +	if (strcmp(acpi_device_hid(adev), "ACPI0016") == 0 &&
> +	    !acpi_pci_find_root(adev->handle)) {
> +		dev_dbg(host, "deferring probe, ACPI0016 PCI root not ready\n");
> +		return -EPROBE_DEFER;
> +	}
> +
> +	hb = to_cxl_host_bridge(host, match);
>  	if (!hb)
>  		return 0;
>  

Re: [PATCH] cxl/acpi: Defer probe when ACPI0016 PCI root bridge is not ready

[Chen Pei]

On Fri, 15 May 2026 08:38:01 -0700, Dave Jiang wrote:

> I would leave the assignment of 'hb' as is above and just what's below
> after looking at to_cxl_host_bridge() function.
> 
> if (!hb) {
> 	if (!acpi_pci_find_root(adev->handle)) {
> 		...
> 		return -EPROBE_DEFER;
> 	}
> 	return 0;
> }

Hi Dave,

Thanks for the review and the code structure suggestion. I agree that
nesting the check under `if (!hb)` is cleaner.

> I am concerned of other failure cases that causes acpi_pci_find_root()
> to fail beyond the driver not being attached. Will cxl_acpi probe() be
> stuck permanently in the defer probe queue when that happens? This is
> also something that Sashiko raised. Is there no way to adjust the
> RISCV ACPI setup to go around subsys_initcall()? That would be
> preferred solution.

You raise a valid concern. The EPROBE_DEFER approach indeed risks
infinite deferral if acpi_pci_find_root() fails for reasons other
than the driver not being attached yet. This is a fundamental
limitation of this approach.

After considering the feedback from you, Sashiko, and Dan Williams,
I plan to abandon the EPROBE_DEFER approach and instead use the
ACPI _DEP mechanism as Dan suggested. This is the proper ACPI
standard way to declare device dependencies:

1. Firmware side (DSDT): Add a _DEP package to the ACPI0017 device
   pointing to all ACPI0016 host bridges it depends on.

2. Kernel side: Add acpi_dev_clear_dependencies() in acpi_pci_root_add()
   so that ACPI0017 will naturally wait for all ACPI0016 devices to
   be ready before probing.

This eliminates the permanent defer risk since the dependency is
explicitly declared by firmware and resolved by the ACPI core,
rather than relying on runtime probing heuristics.

I'll send a new patch series for this approach.

Thanks,
Pei