[PATCH] ACPI: pci_root: Clear the acpi dependencies after PCI root bridge initialization on RISC-V

[PATCH] ACPI: pci_root: Clear the acpi dependencies after PCI root bridge initialization on RISC-V

[huyuye]

On RISC-V platforms with multiple PCI root bridges, the enumeration
order varies randomly across reboots due to APLIC driver initialization
occurring after ACPI device scanning. This defers PCI probing to a
unbound workqueue, resulting in non-deterministic device discovery
sequences.

Such random enumeration leads to changes in device naming across each
boot, which disrupts storage configurations, network settings, and
severely impacts the stability of server maintenance.

By adding the acpi_dev_clear_dependencies() call in acpi_pci_root_add(),
this patch enables the firmware to actively control the enumeration order
of multiple PCI root bridges through the ACPI _DEP method, providing the
firmware with the opportunity to initialize devices in the intended order,
thereby ensuring consistent enumeration results across multiple boots.

Signed-off-by: huyuye <huyuye812@163.com>
---
 drivers/acpi/pci_root.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index 74ade4160314..f5b5aa7d5f93 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -760,6 +760,20 @@ static int acpi_pci_root_add(struct acpi_device *device,
 	pci_lock_rescan_remove();
 	pci_bus_add_devices(root->bus);
 	pci_unlock_rescan_remove();
+#ifdef CONFIG_RISCV
+    /*
+     * Clear dependencies to allow dependent devices to be enumerated.
+     * This is particularly important for RISC-V platforms where multiple
+     * PCIe host bridges may have initialization order dependencies defined
+     * via ACPI _DEP method in DSDT. If a host bridge B depends on host
+     * bridge A (via _DEP), this call allows bridge B to proceed with
+     * enumeration after bridge A is fully initialized.
+     */
+#ifdef CONFIG_ACPI
+	if (!acpi_disabled)
+		acpi_dev_clear_dependencies(device);
+#endif
+#endif
 	return 1;
 
 remove_dmar:
-- 
2.43.0

Re: [PATCH] ACPI: pci_root: Clear the acpi dependencies after PCI root bridge initialization on RISC-V

[Rafael J. Wysocki]

On Wed, Dec 3, 2025 at 3:07 PM huyuye <huyuye812@163.com> wrote:
>
> On RISC-V platforms with multiple PCI root bridges, the enumeration
> order varies randomly across reboots due to APLIC driver initialization
> occurring after ACPI device scanning. This defers PCI probing to a
> unbound workqueue, resulting in non-deterministic device discovery
> sequences.
>
> Such random enumeration leads to changes in device naming across each
> boot, which disrupts storage configurations, network settings, and
> severely impacts the stability of server maintenance.
>
> By adding the acpi_dev_clear_dependencies() call in acpi_pci_root_add(),
> this patch enables the firmware to actively control the enumeration order
> of multiple PCI root bridges through the ACPI _DEP method, providing the
> firmware with the opportunity to initialize devices in the intended order,
> thereby ensuring consistent enumeration results across multiple boots.
>
> Signed-off-by: huyuye <huyuye812@163.com>
> ---
>  drivers/acpi/pci_root.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
>
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index 74ade4160314..f5b5aa7d5f93 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -760,6 +760,20 @@ static int acpi_pci_root_add(struct acpi_device *device,
>         pci_lock_rescan_remove();
>         pci_bus_add_devices(root->bus);
>         pci_unlock_rescan_remove();
> +#ifdef CONFIG_RISCV
> +    /*
> +     * Clear dependencies to allow dependent devices to be enumerated.
> +     * This is particularly important for RISC-V platforms where multiple
> +     * PCIe host bridges may have initialization order dependencies defined
> +     * via ACPI _DEP method in DSDT. If a host bridge B depends on host
> +     * bridge A (via _DEP), this call allows bridge B to proceed with
> +     * enumeration after bridge A is fully initialized.
> +     */
> +#ifdef CONFIG_ACPI
> +       if (!acpi_disabled)
> +               acpi_dev_clear_dependencies(device);
> +#endif

All of this code depends on CONFIG_ACPI, so why is the #ifdef needed?
Also, is it actually reachable when acpi_disabled is set?

Moreover, could this be done in RISC-V specific code rather than here?

> +#endif
>         return 1;
>
>  remove_dmar:
> --

[PATCH v2] ACPI: pci_root: Clear the acpi dependencies after PCI root bridge initialization on RISC-V

[huyuye]

Hi Rafael,
Thank you for your thorough review and valuable comments on v1.
I've updated the patch as follows:
1. Removed the redundant #ifdef CONFIG_ACPI and if (!acpi_disabled) 
guard as you pointed out. The entire code block indeed already depends
on CONFIG_ACPI at a higher level, making the inner guard unnecessary.
2. Moved acpi_dev_clear_dependencies to RISC-V specific architecture 
code (driver/acpi/riscv/acpi_pci.c). This ensures that ACPI dependency
clearing is handled within the appropriate architectural context.

Best regards
Signed-off-by: huyuye <huyuye812@163.com> 
---
 drivers/acpi/pci_root.c       |  6 ++++++
 drivers/acpi/riscv/Makefile   |  2 +-
 drivers/acpi/riscv/acpi_pci.c | 11 +++++++++++
 include/acpi/acpi_bus.h       |  1 +
 4 files changed, 19 insertions(+), 1 deletion(-)
 create mode 100644 drivers/acpi/riscv/acpi_pci.c

diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index 9d7f85dadc48..a16eb9097cdc 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -30,6 +30,11 @@ static int acpi_pci_root_add(struct acpi_device *device,
 			     const struct acpi_device_id *not_used);
 static void acpi_pci_root_remove(struct acpi_device *device);
 
+
+void __weak arch_acpi_pci_root_add_clear_dep(struct acpi_device *device)
+{
+}
+
 static int acpi_pci_root_scan_dependent(struct acpi_device *adev)
 {
 	acpiphp_check_host_bridge(adev);
@@ -760,6 +765,7 @@ static int acpi_pci_root_add(struct acpi_device *device,
 	pci_lock_rescan_remove();
 	pci_bus_add_devices(root->bus);
 	pci_unlock_rescan_remove();
+	arch_acpi_pci_root_add_clear_dep(device);
 	return 1;
 
 remove_dmar:
diff --git a/drivers/acpi/riscv/Makefile b/drivers/acpi/riscv/Makefile
index 1284a076fa88..5b1bd0298fb9 100644
--- a/drivers/acpi/riscv/Makefile
+++ b/drivers/acpi/riscv/Makefile
@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0-only
-obj-y					+= rhct.o init.o irq.o
+obj-y					+= rhct.o init.o irq.o acpi_pci.o
 obj-$(CONFIG_ACPI_PROCESSOR_IDLE)	+= cpuidle.o
 obj-$(CONFIG_ACPI_CPPC_LIB)		+= cppc.o
 obj-$(CONFIG_ACPI_RIMT)			+= rimt.o
diff --git a/drivers/acpi/riscv/acpi_pci.c b/drivers/acpi/riscv/acpi_pci.c
new file mode 100644
index 000000000000..368ff113e5c6
--- /dev/null
+++ b/drivers/acpi/riscv/acpi_pci.c
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2026, ZTE Corporation
+ *  Author: Yu Ye Hu <hu.yuye@zte.com.cn>
+ */
+#include <linux/acpi.h>
+
+void arch_acpi_pci_root_add_clear_dep(struct acpi_device *device)
+{
+	acpi_dev_clear_dependencies(device);
+}
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index aad1a95e6863..c00b523a6ebd 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -996,6 +996,7 @@ int acpi_wait_for_acpi_ipmi(void);
 
 int acpi_scan_add_dep(acpi_handle handle, struct acpi_handle_list *dep_devices);
 u32 arch_acpi_add_auto_dep(acpi_handle handle);
+void arch_acpi_pci_root_add_clear_dep(struct acpi_device *device);
 #else	/* CONFIG_ACPI */
 
 static inline int register_acpi_bus_type(void *bus) { return 0; }
-- 
2.43.0

Re: [PATCH v2] ACPI: pci_root: Clear the acpi dependencies after PCI root bridge initialization on RISC-V

[Bjorn Helgaas]

On Mon, Jan 12, 2026 at 10:16:29PM +0800, huyuye wrote:
> Hi Rafael,
> Thank you for your thorough review and valuable comments on v1.
> I've updated the patch as follows:
> 1. Removed the redundant #ifdef CONFIG_ACPI and if (!acpi_disabled) 
> guard as you pointed out. The entire code block indeed already depends
> on CONFIG_ACPI at a higher level, making the inner guard unnecessary.
> 2. Moved acpi_dev_clear_dependencies to RISC-V specific architecture 
> code (driver/acpi/riscv/acpi_pci.c). This ensures that ACPI dependency
> clearing is handled within the appropriate architectural context.
> 
> Best regards

This really should have the commit log here, as it did in the original
post [1].

> Signed-off-by: huyuye <huyuye812@163.com> 
> ---

And the description of the changes from v1 to v2 can go here, after
the "---" since it doesn't need to be part of the permanent git
history; see [2].

[1] https://lore.kernel.org/r/20251203140716.3065-1-huyuye812@163.com
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=v6.18#n784

[PATCH v3] ACPI: pci_root: Clear the acpi dependencies after PCI root bridge initialization on RISC-V

[huyuye]

On RISC-V platforms with multiple PCI root bridges, the enumeration
order varies randomly across reboots due to APLIC driver initialization
occurring after ACPI device scanning. This defers PCI probing to a
unbound workqueue, resulting in non-deterministic device discovery
sequences.

Such random enumeration leads to changes in device naming across each
boot, which disrupts storage configurations, network settings, and
severely impacts the stability of server maintenance.

By adding the acpi_dev_clear_dependencies() call in acpi_pci_root_add(),
this patch enables the firmware to actively control the enumeration order
of multiple PCI root bridges through the ACPI _DEP method, providing the
firmware with the opportunity to initialize devices in the intended order,
thereby ensuring consistent enumeration results across multiple boots.

Signed-off-by: huyuye <huyuye812@163.com>
---
v2 -> v3:
- Added back the missing commit description from v1
- Moved v2 changelog to correct location after "---"

v1 -> v2:
- Removed the redundant #ifdef CONFIG_ACPI and if (!acpi_disabled) guard
- Moved acpi_dev_clear_dependencies to RISC-V specific architecture code 

 drivers/acpi/pci_root.c       |  6 ++++++
 drivers/acpi/riscv/Makefile   |  2 +-
 drivers/acpi/riscv/acpi_pci.c | 11 +++++++++++
 include/acpi/acpi_bus.h       |  1 +
 4 files changed, 19 insertions(+), 1 deletion(-)
 create mode 100644 drivers/acpi/riscv/acpi_pci.c

diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index 9d7f85dadc48..a16eb9097cdc 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -30,6 +30,11 @@ static int acpi_pci_root_add(struct acpi_device *device,
 			     const struct acpi_device_id *not_used);
 static void acpi_pci_root_remove(struct acpi_device *device);
 
+
+void __weak arch_acpi_pci_root_add_clear_dep(struct acpi_device *device)
+{
+}
+
 static int acpi_pci_root_scan_dependent(struct acpi_device *adev)
 {
 	acpiphp_check_host_bridge(adev);
@@ -760,6 +765,7 @@ static int acpi_pci_root_add(struct acpi_device *device,
 	pci_lock_rescan_remove();
 	pci_bus_add_devices(root->bus);
 	pci_unlock_rescan_remove();
+	arch_acpi_pci_root_add_clear_dep(device);
 	return 1;
 
 remove_dmar:
diff --git a/drivers/acpi/riscv/Makefile b/drivers/acpi/riscv/Makefile
index 1284a076fa88..5b1bd0298fb9 100644
--- a/drivers/acpi/riscv/Makefile
+++ b/drivers/acpi/riscv/Makefile
@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0-only
-obj-y					+= rhct.o init.o irq.o
+obj-y					+= rhct.o init.o irq.o acpi_pci.o
 obj-$(CONFIG_ACPI_PROCESSOR_IDLE)	+= cpuidle.o
 obj-$(CONFIG_ACPI_CPPC_LIB)		+= cppc.o
 obj-$(CONFIG_ACPI_RIMT)			+= rimt.o
diff --git a/drivers/acpi/riscv/acpi_pci.c b/drivers/acpi/riscv/acpi_pci.c
new file mode 100644
index 000000000000..368ff113e5c6
--- /dev/null
+++ b/drivers/acpi/riscv/acpi_pci.c
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2026, ZTE Corporation
+ *  Author: Yu Ye Hu <hu.yuye@zte.com.cn>
+ */
+#include <linux/acpi.h>
+
+void arch_acpi_pci_root_add_clear_dep(struct acpi_device *device)
+{
+	acpi_dev_clear_dependencies(device);
+}
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index aad1a95e6863..c00b523a6ebd 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -996,6 +996,7 @@ int acpi_wait_for_acpi_ipmi(void);
 
 int acpi_scan_add_dep(acpi_handle handle, struct acpi_handle_list *dep_devices);
 u32 arch_acpi_add_auto_dep(acpi_handle handle);
+void arch_acpi_pci_root_add_clear_dep(struct acpi_device *device);
 #else	/* CONFIG_ACPI */
 
 static inline int register_acpi_bus_type(void *bus) { return 0; }
-- 
2.43.0

[PATCH v4] ACPI: pci_root: Clear the acpi dependencies after PCI root bridge initialization on RISC-V

[huyuye]

On RISC-V platforms with multiple PCI root bridges, the enumeration
order varies randomly across reboots due to APLIC driver initialization
occurring after ACPI device scanning. This defers PCI probing to a
unbound workqueue, resulting in non-deterministic device discovery
sequences.

Such random enumeration leads to changes in device naming across each
boot, which disrupts storage configurations, network settings, and
severely impacts the stability of server maintenance.

By adding the acpi_dev_clear_dependencies() call in acpi_pci_root_add(),
this patch enables the firmware to actively control the enumeration order
of multiple PCI root bridges through the ACPI _DEP method, providing the
firmware with the opportunity to initialize devices in the intended order,
thereby ensuring consistent enumeration results across multiple boots.

Signed-off-by: huyuye <huyuye812@163.com>
---
v3 -> v4:
-Removed __weak function

v2 -> v3:
- Added back the missing commit description from v1
- Moved v2 changelog to correct location after "---"

v1 -> v2:
- Removed the redundant #ifdef CONFIG_ACPI and if (!acpi_disabled) guard
- Moved acpi_dev_clear_dependencies to RISC-V specific architecture code
 drivers/acpi/pci_root.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index 9d7f85dadc48..5169104b9d13 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -760,6 +760,18 @@ static int acpi_pci_root_add(struct acpi_device *device,
 	pci_lock_rescan_remove();
 	pci_bus_add_devices(root->bus);
 	pci_unlock_rescan_remove();
+	/*
+	 * On RISC-V platforms with ACPI, PCIe host bridge dependencies may be
+	 * explicitly defined via the _DEP method in the DSDT.
+	 *
+	 * The firmware uses _DEP to enforce initialization ordering: if host bridge B
+	 * depends on host bridge A, ACPI will delay B's enumeration until A is ready.
+	 *
+	 * Once this host bridge is fully initialized, we clear its _DEP entries to
+	 * release dependent bridges (like B) for enumeration.
+	 */
+	if (IS_ENABLED(CONFIG_RISCV))
+		acpi_dev_clear_dependencies(device);
 	return 1;
 
 remove_dmar:
-- 
2.43.0

Re: [PATCH v2] ACPI: pci_root: Clear the acpi dependencies after PCI root bridge initialization on RISC-V

[Rafael J. Wysocki]

On Mon, Jan 12, 2026 at 3:17 PM huyuye <huyuye812@163.com> wrote:
>
> Hi Rafael,
> Thank you for your thorough review and valuable comments on v1.
> I've updated the patch as follows:
> 1. Removed the redundant #ifdef CONFIG_ACPI and if (!acpi_disabled)
> guard as you pointed out. The entire code block indeed already depends
> on CONFIG_ACPI at a higher level, making the inner guard unnecessary.
> 2. Moved acpi_dev_clear_dependencies to RISC-V specific architecture
> code (driver/acpi/riscv/acpi_pci.c). This ensures that ACPI dependency
> clearing is handled within the appropriate architectural context.
>
> Best regards
> Signed-off-by: huyuye <huyuye812@163.com>
> ---
>  drivers/acpi/pci_root.c       |  6 ++++++
>  drivers/acpi/riscv/Makefile   |  2 +-
>  drivers/acpi/riscv/acpi_pci.c | 11 +++++++++++
>  include/acpi/acpi_bus.h       |  1 +
>  4 files changed, 19 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/acpi/riscv/acpi_pci.c
>
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index 9d7f85dadc48..a16eb9097cdc 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -30,6 +30,11 @@ static int acpi_pci_root_add(struct acpi_device *device,
>                              const struct acpi_device_id *not_used);
>  static void acpi_pci_root_remove(struct acpi_device *device);
>
> +
> +void __weak arch_acpi_pci_root_add_clear_dep(struct acpi_device *device)
> +{
> +}
> +
>  static int acpi_pci_root_scan_dependent(struct acpi_device *adev)
>  {
>         acpiphp_check_host_bridge(adev);
> @@ -760,6 +765,7 @@ static int acpi_pci_root_add(struct acpi_device *device,
>         pci_lock_rescan_remove();
>         pci_bus_add_devices(root->bus);
>         pci_unlock_rescan_remove();
> +       arch_acpi_pci_root_add_clear_dep(device);

Actually, this could be as simple as

       if (IS_ENABLED(CONFIG_RISCV))
              acpi_dev_clear_dependencies(device);

with a brief comment explaining why it is needed.

Bjorn, any thoughts?

>         return 1;
>
>  remove_dmar:
> diff --git a/drivers/acpi/riscv/Makefile b/drivers/acpi/riscv/Makefile
> index 1284a076fa88..5b1bd0298fb9 100644
> --- a/drivers/acpi/riscv/Makefile
> +++ b/drivers/acpi/riscv/Makefile
> @@ -1,5 +1,5 @@
>  # SPDX-License-Identifier: GPL-2.0-only
> -obj-y                                  += rhct.o init.o irq.o
> +obj-y                                  += rhct.o init.o irq.o acpi_pci.o
>  obj-$(CONFIG_ACPI_PROCESSOR_IDLE)      += cpuidle.o
>  obj-$(CONFIG_ACPI_CPPC_LIB)            += cppc.o
>  obj-$(CONFIG_ACPI_RIMT)                        += rimt.o
> diff --git a/drivers/acpi/riscv/acpi_pci.c b/drivers/acpi/riscv/acpi_pci.c
> new file mode 100644
> index 000000000000..368ff113e5c6
> --- /dev/null
> +++ b/drivers/acpi/riscv/acpi_pci.c
> @@ -0,0 +1,11 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2026, ZTE Corporation
> + *  Author: Yu Ye Hu <hu.yuye@zte.com.cn>
> + */
> +#include <linux/acpi.h>
> +
> +void arch_acpi_pci_root_add_clear_dep(struct acpi_device *device)
> +{
> +       acpi_dev_clear_dependencies(device);
> +}
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> index aad1a95e6863..c00b523a6ebd 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -996,6 +996,7 @@ int acpi_wait_for_acpi_ipmi(void);
>
>  int acpi_scan_add_dep(acpi_handle handle, struct acpi_handle_list *dep_devices);
>  u32 arch_acpi_add_auto_dep(acpi_handle handle);
> +void arch_acpi_pci_root_add_clear_dep(struct acpi_device *device);
>  #else  /* CONFIG_ACPI */
>
>  static inline int register_acpi_bus_type(void *bus) { return 0; }
> --
> 2.43.0
>

Re: [PATCH v2] ACPI: pci_root: Clear the acpi dependencies after PCI root bridge initialization on RISC-V

[Bjorn Helgaas]

On Tue, Jan 27, 2026 at 04:00:49PM +0100, Rafael J. Wysocki wrote:
> On Mon, Jan 12, 2026 at 3:17 PM huyuye <huyuye812@163.com> wrote:
> >
> > Hi Rafael,
> > Thank you for your thorough review and valuable comments on v1.
> > I've updated the patch as follows:
> > 1. Removed the redundant #ifdef CONFIG_ACPI and if (!acpi_disabled)
> > guard as you pointed out. The entire code block indeed already depends
> > on CONFIG_ACPI at a higher level, making the inner guard unnecessary.
> > 2. Moved acpi_dev_clear_dependencies to RISC-V specific architecture
> > code (driver/acpi/riscv/acpi_pci.c). This ensures that ACPI dependency
> > clearing is handled within the appropriate architectural context.
> >
> > Best regards
> > Signed-off-by: huyuye <huyuye812@163.com>
> > ---
> >  drivers/acpi/pci_root.c       |  6 ++++++
> >  drivers/acpi/riscv/Makefile   |  2 +-
> >  drivers/acpi/riscv/acpi_pci.c | 11 +++++++++++
> >  include/acpi/acpi_bus.h       |  1 +
> >  4 files changed, 19 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/acpi/riscv/acpi_pci.c
> >
> > diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> > index 9d7f85dadc48..a16eb9097cdc 100644
> > --- a/drivers/acpi/pci_root.c
> > +++ b/drivers/acpi/pci_root.c
> > @@ -30,6 +30,11 @@ static int acpi_pci_root_add(struct acpi_device *device,
> >                              const struct acpi_device_id *not_used);
> >  static void acpi_pci_root_remove(struct acpi_device *device);
> >
> > +
> > +void __weak arch_acpi_pci_root_add_clear_dep(struct acpi_device *device)
> > +{
> > +}
> > +
> >  static int acpi_pci_root_scan_dependent(struct acpi_device *adev)
> >  {
> >         acpiphp_check_host_bridge(adev);
> > @@ -760,6 +765,7 @@ static int acpi_pci_root_add(struct acpi_device *device,
> >         pci_lock_rescan_remove();
> >         pci_bus_add_devices(root->bus);
> >         pci_unlock_rescan_remove();
> > +       arch_acpi_pci_root_add_clear_dep(device);
> 
> Actually, this could be as simple as
> 
>        if (IS_ENABLED(CONFIG_RISCV))
>               acpi_dev_clear_dependencies(device);
> 
> with a brief comment explaining why it is needed.
> 
> Bjorn, any thoughts?

The justification ("If a host bridge B depends on host bridge A (via
_DEP), this call allows bridge B to proceed with enumeration after
bridge A is fully initialized") doesn't sound specific to RISC-V.

For that matter, it doesn't sound specific to host bridges either.

The _DEP spec language is a bit vague.  ACPI r6.6, sec 6.5.8, says:

  _DEP evaluates to a package and designates device objects that OSPM
  should assign a higher priority in start ordering due to
  dependencies between devices (for example, related to future
  operation region accesses).

I don't know what "device start" means.  It sounds like this alludes
to the order in which OSPM runs some device start method?  _INI?
Should acpi_dev_clear_dependencies() be done at the point where that
device start method is run?

> >         return 1;
> >
> >  remove_dmar:
> > diff --git a/drivers/acpi/riscv/Makefile b/drivers/acpi/riscv/Makefile
> > index 1284a076fa88..5b1bd0298fb9 100644
> > --- a/drivers/acpi/riscv/Makefile
> > +++ b/drivers/acpi/riscv/Makefile
> > @@ -1,5 +1,5 @@
> >  # SPDX-License-Identifier: GPL-2.0-only
> > -obj-y                                  += rhct.o init.o irq.o
> > +obj-y                                  += rhct.o init.o irq.o acpi_pci.o
> >  obj-$(CONFIG_ACPI_PROCESSOR_IDLE)      += cpuidle.o
> >  obj-$(CONFIG_ACPI_CPPC_LIB)            += cppc.o
> >  obj-$(CONFIG_ACPI_RIMT)                        += rimt.o
> > diff --git a/drivers/acpi/riscv/acpi_pci.c b/drivers/acpi/riscv/acpi_pci.c
> > new file mode 100644
> > index 000000000000..368ff113e5c6
> > --- /dev/null
> > +++ b/drivers/acpi/riscv/acpi_pci.c
> > @@ -0,0 +1,11 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2026, ZTE Corporation
> > + *  Author: Yu Ye Hu <hu.yuye@zte.com.cn>
> > + */
> > +#include <linux/acpi.h>
> > +
> > +void arch_acpi_pci_root_add_clear_dep(struct acpi_device *device)
> > +{
> > +       acpi_dev_clear_dependencies(device);
> > +}
> > diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> > index aad1a95e6863..c00b523a6ebd 100644
> > --- a/include/acpi/acpi_bus.h
> > +++ b/include/acpi/acpi_bus.h
> > @@ -996,6 +996,7 @@ int acpi_wait_for_acpi_ipmi(void);
> >
> >  int acpi_scan_add_dep(acpi_handle handle, struct acpi_handle_list *dep_devices);
> >  u32 arch_acpi_add_auto_dep(acpi_handle handle);
> > +void arch_acpi_pci_root_add_clear_dep(struct acpi_device *device);
> >  #else  /* CONFIG_ACPI */
> >
> >  static inline int register_acpi_bus_type(void *bus) { return 0; }
> > --
> > 2.43.0
> >

Re: [PATCH v2] ACPI: pci_root: Clear the acpi dependencies after PCI root bridge initialization on RISC-V

[Rafael J. Wysocki]

On Tue, Jan 27, 2026 at 6:26 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> On Tue, Jan 27, 2026 at 04:00:49PM +0100, Rafael J. Wysocki wrote:
> > On Mon, Jan 12, 2026 at 3:17 PM huyuye <huyuye812@163.com> wrote:
> > >
> > > Hi Rafael,
> > > Thank you for your thorough review and valuable comments on v1.
> > > I've updated the patch as follows:
> > > 1. Removed the redundant #ifdef CONFIG_ACPI and if (!acpi_disabled)
> > > guard as you pointed out. The entire code block indeed already depends
> > > on CONFIG_ACPI at a higher level, making the inner guard unnecessary.
> > > 2. Moved acpi_dev_clear_dependencies to RISC-V specific architecture
> > > code (driver/acpi/riscv/acpi_pci.c). This ensures that ACPI dependency
> > > clearing is handled within the appropriate architectural context.
> > >
> > > Best regards
> > > Signed-off-by: huyuye <huyuye812@163.com>
> > > ---
> > >  drivers/acpi/pci_root.c       |  6 ++++++
> > >  drivers/acpi/riscv/Makefile   |  2 +-
> > >  drivers/acpi/riscv/acpi_pci.c | 11 +++++++++++
> > >  include/acpi/acpi_bus.h       |  1 +
> > >  4 files changed, 19 insertions(+), 1 deletion(-)
> > >  create mode 100644 drivers/acpi/riscv/acpi_pci.c
> > >
> > > diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> > > index 9d7f85dadc48..a16eb9097cdc 100644
> > > --- a/drivers/acpi/pci_root.c
> > > +++ b/drivers/acpi/pci_root.c
> > > @@ -30,6 +30,11 @@ static int acpi_pci_root_add(struct acpi_device *device,
> > >                              const struct acpi_device_id *not_used);
> > >  static void acpi_pci_root_remove(struct acpi_device *device);
> > >
> > > +
> > > +void __weak arch_acpi_pci_root_add_clear_dep(struct acpi_device *device)
> > > +{
> > > +}
> > > +
> > >  static int acpi_pci_root_scan_dependent(struct acpi_device *adev)
> > >  {
> > >         acpiphp_check_host_bridge(adev);
> > > @@ -760,6 +765,7 @@ static int acpi_pci_root_add(struct acpi_device *device,
> > >         pci_lock_rescan_remove();
> > >         pci_bus_add_devices(root->bus);
> > >         pci_unlock_rescan_remove();
> > > +       arch_acpi_pci_root_add_clear_dep(device);
> >
> > Actually, this could be as simple as
> >
> >        if (IS_ENABLED(CONFIG_RISCV))
> >               acpi_dev_clear_dependencies(device);
> >
> > with a brief comment explaining why it is needed.
> >
> > Bjorn, any thoughts?
>
> The justification ("If a host bridge B depends on host bridge A (via
> _DEP), this call allows bridge B to proceed with enumeration after
> bridge A is fully initialized") doesn't sound specific to RISC-V.

But there are no _DEP dependencies between host bridgers on other
architectures in practice.

acpi_dev_clear_dependencies() could be called unconditionally here,
but it would be useless overhead if no such dependencies existed.

> For that matter, it doesn't sound specific to host bridges either.

No, it is not specific to host bridges.

> The _DEP spec language is a bit vague.  ACPI r6.6, sec 6.5.8, says:
>
>   _DEP evaluates to a package and designates device objects that OSPM
>   should assign a higher priority in start ordering due to
>   dependencies between devices (for example, related to future
>   operation region accesses).
>
> I don't know what "device start" means.  It sounds like this alludes
> to the order in which OSPM runs some device start method?  _INI?
> Should acpi_dev_clear_dependencies() be done at the point where that
> device start method is run?

Not really.

acpi_dev_clear_dependencies() is related to the way Linux uses _DEP
which is to defer the enumeration of dependent devices until the
devices they depend on are ready.

So by calling acpi_dev_clear_dependencies() the driver basically
allows other drivers to bind to devices.

Re: [PATCH v2] ACPI: pci_root: Clear the acpi dependencies after PCI root bridge initialization on RISC-V

[Bjorn Helgaas]

On Tue, Jan 27, 2026 at 06:50:24PM +0100, Rafael J. Wysocki wrote:
> On Tue, Jan 27, 2026 at 6:26 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Tue, Jan 27, 2026 at 04:00:49PM +0100, Rafael J. Wysocki wrote:
> > > On Mon, Jan 12, 2026 at 3:17 PM huyuye <huyuye812@163.com> wrote:
> > > >
> > > > Hi Rafael,
> > > > Thank you for your thorough review and valuable comments on v1.
> > > > I've updated the patch as follows:
> > > > 1. Removed the redundant #ifdef CONFIG_ACPI and if (!acpi_disabled)
> > > > guard as you pointed out. The entire code block indeed already depends
> > > > on CONFIG_ACPI at a higher level, making the inner guard unnecessary.
> > > > 2. Moved acpi_dev_clear_dependencies to RISC-V specific architecture
> > > > code (driver/acpi/riscv/acpi_pci.c). This ensures that ACPI dependency
> > > > clearing is handled within the appropriate architectural context.
> > > >
> > > > Best regards
> > > > Signed-off-by: huyuye <huyuye812@163.com>
> > > > ---
> > > >  drivers/acpi/pci_root.c       |  6 ++++++
> > > >  drivers/acpi/riscv/Makefile   |  2 +-
> > > >  drivers/acpi/riscv/acpi_pci.c | 11 +++++++++++
> > > >  include/acpi/acpi_bus.h       |  1 +
> > > >  4 files changed, 19 insertions(+), 1 deletion(-)
> > > >  create mode 100644 drivers/acpi/riscv/acpi_pci.c
> > > >
> > > > diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> > > > index 9d7f85dadc48..a16eb9097cdc 100644
> > > > --- a/drivers/acpi/pci_root.c
> > > > +++ b/drivers/acpi/pci_root.c
> > > > @@ -30,6 +30,11 @@ static int acpi_pci_root_add(struct acpi_device *device,
> > > >                              const struct acpi_device_id *not_used);
> > > >  static void acpi_pci_root_remove(struct acpi_device *device);
> > > >
> > > > +
> > > > +void __weak arch_acpi_pci_root_add_clear_dep(struct acpi_device *device)
> > > > +{
> > > > +}
> > > > +
> > > >  static int acpi_pci_root_scan_dependent(struct acpi_device *adev)
> > > >  {
> > > >         acpiphp_check_host_bridge(adev);
> > > > @@ -760,6 +765,7 @@ static int acpi_pci_root_add(struct acpi_device *device,
> > > >         pci_lock_rescan_remove();
> > > >         pci_bus_add_devices(root->bus);
> > > >         pci_unlock_rescan_remove();
> > > > +       arch_acpi_pci_root_add_clear_dep(device);
> > >
> > > Actually, this could be as simple as
> > >
> > >        if (IS_ENABLED(CONFIG_RISCV))
> > >               acpi_dev_clear_dependencies(device);
> > >
> > > with a brief comment explaining why it is needed.
> > >
> > > Bjorn, any thoughts?
> >
> > The justification ("If a host bridge B depends on host bridge A (via
> > _DEP), this call allows bridge B to proceed with enumeration after
> > bridge A is fully initialized") doesn't sound specific to RISC-V.
> 
> But there are no _DEP dependencies between host bridgers on other
> architectures in practice.
> 
> acpi_dev_clear_dependencies() could be called unconditionally here,
> but it would be useless overhead if no such dependencies existed.
> 
> > For that matter, it doesn't sound specific to host bridges either.
> 
> No, it is not specific to host bridges.
> 
> > The _DEP spec language is a bit vague.  ACPI r6.6, sec 6.5.8, says:
> >
> >   _DEP evaluates to a package and designates device objects that OSPM
> >   should assign a higher priority in start ordering due to
> >   dependencies between devices (for example, related to future
> >   operation region accesses).
> >
> > I don't know what "device start" means.  It sounds like this alludes
> > to the order in which OSPM runs some device start method?  _INI?
> > Should acpi_dev_clear_dependencies() be done at the point where that
> > device start method is run?
> 
> Not really.
> 
> acpi_dev_clear_dependencies() is related to the way Linux uses _DEP
> which is to defer the enumeration of dependent devices until the
> devices they depend on are ready.
> 
> So by calling acpi_dev_clear_dependencies() the driver basically
> allows other drivers to bind to devices.

I assumed the dependency expressed by _DEP would be satisfied by the
execution of some other ACPI method.  E.g., the dependency might be
satisfied when a _REG method makes an opregion available (although the
spec seems to suggest that's only one of the possible dependencies).

But in this case it sounds like RISC-V is using _DEP not because of
any ACPI-related ordering requirement, but simply to enforce the OS
enumeration order (and therefore naming).  I guess this refers to PCI
device naming, so I suppose that dependency is on
pci_acpi_scan_root().

I thought udev was supposed to be the real solution for consistent
naming.  Is this sort of a workaround to accomplish the same end?

In any case, your IS_ENABLED(CONFIG_RISCV) proposal seems fine to me.
I think it's nice if we can avoid adding another __weak function.

Bjorn

Re: [PATCH v2] ACPI: pci_root: Clear the acpi dependencies after PCI root bridge initialization on RISC-V

[Rafael J. Wysocki]

On Tue, Jan 27, 2026 at 8:46 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> On Tue, Jan 27, 2026 at 06:50:24PM +0100, Rafael J. Wysocki wrote:
> > On Tue, Jan 27, 2026 at 6:26 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > On Tue, Jan 27, 2026 at 04:00:49PM +0100, Rafael J. Wysocki wrote:
> > > > On Mon, Jan 12, 2026 at 3:17 PM huyuye <huyuye812@163.com> wrote:
> > > > >
> > > > > Hi Rafael,
> > > > > Thank you for your thorough review and valuable comments on v1.
> > > > > I've updated the patch as follows:
> > > > > 1. Removed the redundant #ifdef CONFIG_ACPI and if (!acpi_disabled)
> > > > > guard as you pointed out. The entire code block indeed already depends
> > > > > on CONFIG_ACPI at a higher level, making the inner guard unnecessary.
> > > > > 2. Moved acpi_dev_clear_dependencies to RISC-V specific architecture
> > > > > code (driver/acpi/riscv/acpi_pci.c). This ensures that ACPI dependency
> > > > > clearing is handled within the appropriate architectural context.
> > > > >
> > > > > Best regards
> > > > > Signed-off-by: huyuye <huyuye812@163.com>
> > > > > ---
> > > > >  drivers/acpi/pci_root.c       |  6 ++++++
> > > > >  drivers/acpi/riscv/Makefile   |  2 +-
> > > > >  drivers/acpi/riscv/acpi_pci.c | 11 +++++++++++
> > > > >  include/acpi/acpi_bus.h       |  1 +
> > > > >  4 files changed, 19 insertions(+), 1 deletion(-)
> > > > >  create mode 100644 drivers/acpi/riscv/acpi_pci.c
> > > > >
> > > > > diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> > > > > index 9d7f85dadc48..a16eb9097cdc 100644
> > > > > --- a/drivers/acpi/pci_root.c
> > > > > +++ b/drivers/acpi/pci_root.c
> > > > > @@ -30,6 +30,11 @@ static int acpi_pci_root_add(struct acpi_device *device,
> > > > >                              const struct acpi_device_id *not_used);
> > > > >  static void acpi_pci_root_remove(struct acpi_device *device);
> > > > >
> > > > > +
> > > > > +void __weak arch_acpi_pci_root_add_clear_dep(struct acpi_device *device)
> > > > > +{
> > > > > +}
> > > > > +
> > > > >  static int acpi_pci_root_scan_dependent(struct acpi_device *adev)
> > > > >  {
> > > > >         acpiphp_check_host_bridge(adev);
> > > > > @@ -760,6 +765,7 @@ static int acpi_pci_root_add(struct acpi_device *device,
> > > > >         pci_lock_rescan_remove();
> > > > >         pci_bus_add_devices(root->bus);
> > > > >         pci_unlock_rescan_remove();
> > > > > +       arch_acpi_pci_root_add_clear_dep(device);
> > > >
> > > > Actually, this could be as simple as
> > > >
> > > >        if (IS_ENABLED(CONFIG_RISCV))
> > > >               acpi_dev_clear_dependencies(device);
> > > >
> > > > with a brief comment explaining why it is needed.
> > > >
> > > > Bjorn, any thoughts?
> > >
> > > The justification ("If a host bridge B depends on host bridge A (via
> > > _DEP), this call allows bridge B to proceed with enumeration after
> > > bridge A is fully initialized") doesn't sound specific to RISC-V.
> >
> > But there are no _DEP dependencies between host bridgers on other
> > architectures in practice.
> >
> > acpi_dev_clear_dependencies() could be called unconditionally here,
> > but it would be useless overhead if no such dependencies existed.
> >
> > > For that matter, it doesn't sound specific to host bridges either.
> >
> > No, it is not specific to host bridges.
> >
> > > The _DEP spec language is a bit vague.  ACPI r6.6, sec 6.5.8, says:
> > >
> > >   _DEP evaluates to a package and designates device objects that OSPM
> > >   should assign a higher priority in start ordering due to
> > >   dependencies between devices (for example, related to future
> > >   operation region accesses).
> > >
> > > I don't know what "device start" means.  It sounds like this alludes
> > > to the order in which OSPM runs some device start method?  _INI?
> > > Should acpi_dev_clear_dependencies() be done at the point where that
> > > device start method is run?
> >
> > Not really.
> >
> > acpi_dev_clear_dependencies() is related to the way Linux uses _DEP
> > which is to defer the enumeration of dependent devices until the
> > devices they depend on are ready.
> >
> > So by calling acpi_dev_clear_dependencies() the driver basically
> > allows other drivers to bind to devices.
>
> I assumed the dependency expressed by _DEP would be satisfied by the
> execution of some other ACPI method.  E.g., the dependency might be
> satisfied when a _REG method makes an opregion available (although the
> spec seems to suggest that's only one of the possible dependencies).
>
> But in this case it sounds like RISC-V is using _DEP not because of
> any ACPI-related ordering requirement, but simply to enforce the OS
> enumeration order (and therefore naming).  I guess this refers to PCI
> device naming, so I suppose that dependency is on
> pci_acpi_scan_root().
>
> I thought udev was supposed to be the real solution for consistent
> naming.  Is this sort of a workaround to accomplish the same end?

IIUC, the enumeration ordering enforcement on RISC-V is related to a
functional dependency, but admittedly I'm unfamiliar with the details.

> In any case, your IS_ENABLED(CONFIG_RISCV) proposal seems fine to me.
> I think it's nice if we can avoid adding another __weak function.

OK, thanks!

I would also like to get some feedback on this from the RISC-V side.
Specifically on the reasons why the _DEP in question is used in the
firmware.

Re: [PATCH v2] ACPI: pci_root: Clear the acpi dependencies after PCI root bridge initialization on RISC-V

[Sunil V L]

On Tue, Jan 27, 2026 at 01:46:48PM -0600, Bjorn Helgaas wrote:
> On Tue, Jan 27, 2026 at 06:50:24PM +0100, Rafael J. Wysocki wrote:
> > On Tue, Jan 27, 2026 at 6:26 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > On Tue, Jan 27, 2026 at 04:00:49PM +0100, Rafael J. Wysocki wrote:
> > > > On Mon, Jan 12, 2026 at 3:17 PM huyuye <huyuye812@163.com> wrote:
> > > > >
[...]

> > Not really.
> > 
> > acpi_dev_clear_dependencies() is related to the way Linux uses _DEP
> > which is to defer the enumeration of dependent devices until the
> > devices they depend on are ready.
> > 
> > So by calling acpi_dev_clear_dependencies() the driver basically
> > allows other drivers to bind to devices.
> 
> I assumed the dependency expressed by _DEP would be satisfied by the
> execution of some other ACPI method.  E.g., the dependency might be
> satisfied when a _REG method makes an opregion available (although the
> spec seems to suggest that's only one of the possible dependencies).
> 
> But in this case it sounds like RISC-V is using _DEP not because of
> any ACPI-related ordering requirement, but simply to enforce the OS
> enumeration order (and therefore naming).  I guess this refers to PCI
> device naming, so I suppose that dependency is on
> pci_acpi_scan_root().
> 
Right. Devices that use wired interrupts (or GSIs) depend on the APLIC
interrupt controller being probed first. ACPI uses the _DEP mechanism to
enforce this probe order. However, when multiple dependent PCI bridges
are present in the system, there is no guarantee that they will be
probed in the same order on every reboot. This patch addresses the issue
by adding _DEP relationships between the PCI bridge nodes in the
platform, ensuring that they are always probed in a deterministic
order.

> I thought udev was supposed to be the real solution for consistent
> naming.  Is this sort of a workaround to accomplish the same end?
>
Yes, Marc had suggested this as well, but it looks like it’s not easy to
use in this environment [1].

> In any case, your IS_ENABLED(CONFIG_RISCV) proposal seems fine to me.
> I think it's nice if we can avoid adding another __weak function.
> 
I agree. But I am not sure if ARM also can get into this situation with
GICv5. Adding Lorenzo.

[1] - https://lore.kernel.org/linux-riscv/20251126161540.6460-1-ni_liqiang@126.com/

Thanks,
Sunil

Re: [PATCH v2] ACPI: pci_root: Clear the acpi dependencies after PCI root bridge initialization on RISC-V

[Lorenzo Pieralisi]

On Thu, Jan 29, 2026 at 07:19:43PM +0530, Sunil V L wrote:
> On Tue, Jan 27, 2026 at 01:46:48PM -0600, Bjorn Helgaas wrote:
> > On Tue, Jan 27, 2026 at 06:50:24PM +0100, Rafael J. Wysocki wrote:
> > > On Tue, Jan 27, 2026 at 6:26 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > > On Tue, Jan 27, 2026 at 04:00:49PM +0100, Rafael J. Wysocki wrote:
> > > > > On Mon, Jan 12, 2026 at 3:17 PM huyuye <huyuye812@163.com> wrote:
> > > > > >
> [...]
> 
> > > Not really.
> > > 
> > > acpi_dev_clear_dependencies() is related to the way Linux uses _DEP
> > > which is to defer the enumeration of dependent devices until the
> > > devices they depend on are ready.
> > > 
> > > So by calling acpi_dev_clear_dependencies() the driver basically
> > > allows other drivers to bind to devices.
> > 
> > I assumed the dependency expressed by _DEP would be satisfied by the
> > execution of some other ACPI method.  E.g., the dependency might be
> > satisfied when a _REG method makes an opregion available (although the
> > spec seems to suggest that's only one of the possible dependencies).
> > 
> > But in this case it sounds like RISC-V is using _DEP not because of
> > any ACPI-related ordering requirement, but simply to enforce the OS
> > enumeration order (and therefore naming).  I guess this refers to PCI
> > device naming, so I suppose that dependency is on
> > pci_acpi_scan_root().
> > 
> Right. Devices that use wired interrupts (or GSIs) depend on the APLIC
> interrupt controller being probed first. ACPI uses the _DEP mechanism to
> enforce this probe order. However, when multiple dependent PCI bridges
> are present in the system, there is no guarantee that they will be
> probed in the same order on every reboot. This patch addresses the issue
> by adding _DEP relationships between the PCI bridge nodes in the
> platform, ensuring that they are always probed in a deterministic
> order.
> 
> > I thought udev was supposed to be the real solution for consistent
> > naming.  Is this sort of a workaround to accomplish the same end?
> >
> Yes, Marc had suggested this as well, but it looks like it’s not easy to
> use in this environment [1].

FWIW I agree with Marc - I read [1] and still don't understand what the problem
is with implementing a udev set of rules to fix it.

> > In any case, your IS_ENABLED(CONFIG_RISCV) proposal seems fine to me.
> > I think it's nice if we can avoid adding another __weak function.
> > 
> I agree. But I am not sure if ARM also can get into this situation with
> GICv5. Adding Lorenzo.

It can happen with GICv5 but I don't think that's the point. It can happen
on any arch regardless of interrupt controller probe ordering and udev is
the de facto solution to this problem AFAIU, please correct me if I am wrong.

Lorenzo