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
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.0On 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
>
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
> >
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.
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
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
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.
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
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.0On 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© 2016 - 2026 Red Hat, Inc.