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: <aSAn8DdQVBBzenlJ@sunil-laptop>
Date: Fri, 21 Nov 2025 14:20:56 +0530
From: Sunil V L <sunilvl@...tanamicro.com>
To: niliqiang <ni_liqiang@....com>
Cc: apatel@...tanamicro.com, ajones@...tanamicro.com, anup@...infault.org,
	atishp@...shpatra.org, bjorn@...nel.org, conor+dt@...nel.org,
	devicetree@...r.kernel.org, frowand.list@...il.com,
	krzysztof.kozlowski+dt@...aro.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-riscv@...ts.infradead.org, maz@...nel.org, palmer@...belt.com,
	paul.walmsley@...ive.com, robh+dt@...nel.org, saravanak@...gle.com,
	tglx@...utronix.de, hu.yuye@....com.cn, deng.weixian@....com.cn,
	ni.liqiang@....com.cn
Subject: Re: [PATCH v16 6/9] irqchip: Add RISC-V advanced PLIC driver for
 direct-mode

Hi Liqiang,

On Thu, Nov 20, 2025 at 10:43:11PM +0800, niliqiang wrote:
> > diff --git a/drivers/irqchip/irq-riscv-aplic-main.c b/drivers/irqchip/irq-riscv-aplic-main.c
> > +static const struct of_device_id aplic_match[] = {
> > + { .compatible = "riscv,aplic" },
> > + {}
> > +};
> > +
> > +static struct platform_driver aplic_driver = {
> > + .driver = {
> > +  .name  = "riscv-aplic",
> > +  .of_match_table = aplic_match,
> > + },
> > + .probe = aplic_probe,
> > +};
> > +builtin_platform_driver(aplic_driver);
> 
> Dear Anup Patel and all concerned,
> 
> I am writing to inquire about the historical rationale behind defining the APLIC driver's
> initialization priority using builtin_platform_driver in the current implementation.
> 
> In our environment, we are encountering an issue where this priority level causes ACPI-based PCIe
> enumeration to be executed in the system_unbound_wq work queue. This parallel execution model
> results in PCIe devices being enumerated in an arbitrary order rather than strictly following the
> sequence defined in the ACPI DSDT table.
> 
> The random enumeration order is adversely affecting customer experience, particularly in scenarios
> where device ordering is critical for proper system operation or application compatibility.
> 
> We are considering modifying the APLIC driver's initialization priority to ensure PCIe enumeration
> occurs sequentially according to the DSDT specification. However, before proceeding with such
> changes, we wanted to consult with you regarding:
> 
> 1. Were there specific technical considerations that led to the current priority selection?
> 2. Are there any potential side effects or broader impacts that we might have overlooked?
> 3. Would you support such a priority adjustment, or do you have alternative suggestions to 
> address the enumeration order issue?
> 
> We greatly appreciate your insights and expertise on this matter, as it will help us make an
> informed decision while maintaining system stability and compatibility.
> 
> Thank you for your time and consideration.
> 

IRQ subsystem maintainers rejected the idea of relying on initcalls to
enforce probe order because initcalls do not guarantee ordering. The
Linux driver model instead ensures probe order through device
dependencies. Since PCI INTx depends on the APLIC being probed first,
the PCI host bridge probe cannot occur until after the APLIC probe
completes. This requirement and behavior are the same for both DT and
ACPI. In DT, the driver model uses fw_devlink to establish probe
ordering, while in ACPI this is handled through either an explicit _DEP
or, on RISC-V, the GSI mapping.

Typically, this dependency appears in the DSDT only for the PCI host
bridge. Individual PCIe devices are enumerated through the standard PCI
scan once the host bridge has been probed. Therefore, I’m not sure what
you meant by a probe sequence defined in the DSDT for PCIe devices.

Regards,
Sunil