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

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: <20251126161540.6460-1-ni_liqiang@126.com>
Date: Thu, 27 Nov 2025 00:15:40 +0800
From: niliqiang <ni_liqiang@....com>
To: tglx@...utronix.de
Cc: ajones@...tanamicro.com,
	anup@...infault.org,
	apatel@...tanamicro.com,
	atishp@...shpatra.org,
	bjorn@...nel.org,
	conor+dt@...nel.org,
	dai.hualiang@....com.cn,
	deng.weixian@....com.cn,
	devicetree@...r.kernel.org,
	frowand.list@...il.com,
	guo.chang2@....com.cn,
	hu.yuye@....com.cn,
	krzysztof.kozlowski+dt@...aro.org,
	linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	linux-riscv@...ts.infradead.org,
	liu.qingtao2@....com.cn,
	liu.wenhong35@....com.cn,
	maz@...nel.org,
	ni.liqiang@....com.cn,
	ni_liqiang@....com,
	palmer@...belt.com,
	paul.walmsley@...ive.com,
	robh+dt@...nel.org,
	saravanak@...gle.com,
	sunilvl@...tanamicro.com,
	wu.jiabao@....com.cn
Subject: Re: [PATCH v16 6/9] irqchip: Add RISC-V advanced PLIC driver for direct-mode

Hi, tglx

> > 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.
> 
> > 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