Message-Id: <20260114063730.78009-1-yang.yicong@picoheart.com>
Date: Wed, 14 Jan 2026 14:37:30 +0800
From: "Yicong Yang" <yang.yicong@...oheart.com>
To: <anup@...infault.org>, <tglx@...nel.org>, <pjw@...nel.org>, 
	<palmer@...belt.com>, <aou@...s.berkeley.edu>, <alex@...ti.fr>
Cc: <linux-riscv@...ts.infradead.org>, <linux-kernel@...r.kernel.org>, 
	<yang.yicong@...oheart.com>, <geshijian@...oheart.com>, 
	<weidong.wd@...oheart.com>
Subject: [PATCH] irqchip/riscv-aplic: Register the driver prior to device creation

On RISC-V the APLIC serves part of the GSI interrupts, but unlike
other arthitecture it's initialized a bit late on ACPI based
system:
- the spec only mandates the report in DSDT (riscv-brs rule AML_100)
  so the APLIC is created as platform_device when scanning DSDT
- the driver is registered and initialize the device in device_initcall
  stage

The creation of devices depends on APLIC is deferred after the APLIC
is initialized (when the driver calls acpi_dev_clear_dependencies),
not like most other devices which is created when scanning the DSDT.
The affected devices include those declare the dependency explicitly
by ACPI _DEP method and _PRT for PCIe host bridge and those require
their interrupts as GSI. Furhtermore, the deferred creation is
performed in an async way (queued in the system_dfl_wq workqueue)
but all contend on the acpi_scan_lock.

Since the deferred devcie creation is asynchronous and will contend
for the same lock, the order and timing is not certain. And the time
is late enough for the device creation running parallel with the init
task. This will lead to below issues (also observed on our platforms):
- the console/tty device is created lately and sometimes it's not ready
  when init task check for its presence. the system will crash in the
  latter case since the init task always requires a valid console.
- the root device will by probed and registered lately (e.g. NVME,
  after the init task executed) and may run into the rescue shell if
  root device is not found.

We'll run into the issues more often in linuxboot since the init tasks
is more simpler (usually u-root) and will check for the console/root
devices more earlier.

Solve this by promote the APLIC driver register stage to core_initcall
which is prior to the APLIC device creation. So the dependency for
the GSI is met earlier. The key system devices like tty/PCI will be
created earlier when scanning ACPI namespace in a synchronous manner
and won't be parallel with the init task. So it's certain to have
a console/root device when the init task running.

Signed-off-by: Yicong Yang <yang.yicong@...oheart.com>
---
 drivers/irqchip/irq-riscv-aplic-main.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-riscv-aplic-main.c b/drivers/irqchip/irq-riscv-aplic-main.c
index 93e7c51f944a..86a3d19b6b24 100644
--- a/drivers/irqchip/irq-riscv-aplic-main.c
+++ b/drivers/irqchip/irq-riscv-aplic-main.c
@@ -231,4 +231,16 @@ static struct platform_driver aplic_driver = {
 	},
 	.probe = aplic_probe,
 };
-builtin_platform_driver(aplic_driver);
+
+static int __init aplic_driver_init(void)
+{
+	return platform_driver_register(&aplic_driver);
+}
+
+/*
+ * APLIC serves part of GSI interrupts and some key system devices like
+ * TTY/PCI depends on its initialization. Register the driver prior to
+ * APLIC device (on ACPI it's created in subsys_initcall when scanning
+ * the namespace devices) to make the GSI service ready early.
+ */
+core_initcall(aplic_driver_init);
-- 
2.34.1

Powered by blists - more mailing lists