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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAJZ5v0iv8q_Yq9sttsNm2GHTemYVqmnxaQ3xy-cw9wwJFOAeVA@mail.gmail.com>
Date: Thu, 8 Jan 2026 15:04:19 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: huyuye <huyuye812@....com>
Cc: Bjorn Helgaas <bhelgaas@...gle.com>, "Rafael J . Wysocki" <rafael@...nel.org>, Len Brown <lenb@...nel.org>, 
	linux-pci@...r.kernel.org, linux-acpi@...r.kernel.org, 
	linux-kernel@...r.kernel.org, dai.hualiang@....com.cn, 
	deng.weixian@....com.cn, guo.chang2@....com.cn, liu.qingtao2@....com.cn, 
	wu.jiabao@....com.cn, lin.yongchun@....com.cn, hu.yuye@....com.cn, 
	zhang.longxiang@....com.cn, zuo.jiang@....com.cn, li.kunpeng@....com.cn
Subject: Re: [PATCH] ACPI: pci_root: Clear the acpi dependencies after PCI
 root bridge initialization on RISC-V

On Wed, Dec 3, 2025 at 3:07 PM huyuye <huyuye812@....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@....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:
> --