Re: [PATCH v16 6/9] irqchip: Add RISC-V advanced PLIC driver for direct-mode

Hi, tglx

quoted

We've noticed that PCIe enumeration order tends to vary across system reboots (for example: first
boot showed PC08->PC06->PC10->PC07->PC11->PC09, while second boot showed
PC09->PC06->PC08->PC11->PC07->PC10), even though the ACPI firmware consistently reports the root
bridge sequence as PC06->PC07->PC08->PC09->PC10->PC11.

quoted

In our testing, we found that adjusting the registration priority of the aplic driver seems to help
ensure the interrupt controller initializes before PCI enumeration, leading to more consistent
device ordering.

The ACPI table does not provide a sequence, it provides a collection and
it's nowhere written in stone that this collection has to be processed
in order.
If you want a sequence then put dependencies into the table and be done
with it, no?

Thank you for your suggestions. 

Through our validation, We have observed that the current kernel appears to lack an effective
dependency resolution mechanism between ACPI PCIe host bridge devices.

The specific manifestation is as follows: when establishing dependencies between host bridges via
the _DEP method (for example, PC07 depends on PC06), only PC06 is enumerated successfully, while
PC07 is skipped. Our investigation reveals that the root cause lies in the current limitation where
ACPI PCIe devices have only a single opportunity to resolve dependencies—specifically within the
acpi_dev_clear_dependencies function inside the APLIC driver. PC06, having its dependency resolved
earlier by the APLIC driver, is asynchronously processed in the system_unbound_wq queue. At this
point, PC07 still depends on PC06, which has not yet completed enumeration. As a result, PC07 cannot
proceed and subsequently misses its enumeration opportunity.

To address this issue, we have introduced the following dependency resolution mechanism at the end
of the acpi_pci_root_add function in the kernel's PCIe enumeration path to achieve the desired
fixed-order enumeration:

#ifdef CONFIG_ACPI
if (!acpi_disabled)
acpi_dev_clear_dependencies(device);
#endif

We have observed that other drivers in the kernel also utilize acpi_dev_clear_dependencies to handle
device dependencies. We seek confirmation on whether this approach is reasonable and welcome
feedback regarding alternative effective solutions.

Best regards,
Liqiang