[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 at 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 at 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