From nobody Mon Feb 9 02:24:32 2026 Received: from va-2-51.ptr.blmpb.com (va-2-51.ptr.blmpb.com [209.127.231.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C9BFD34EEEF for ; Wed, 14 Jan 2026 06:38:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.127.231.51 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768372716; cv=none; b=maBESfwOk23MWz8b6M1rYcmYAe8h6URJMXiWkodUObKusSsjh0rcBIUf0WXwcphGXle+XpnnPLDLj3luBrupuWil9JMi/dOMlAREl2zbNQ2LIi7XYJcG9bBmkB9KXNc6pqN4VF7hW4Lpygnx4SBJ6wPuCzUIRQpyZlXjs+ooOfQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768372716; c=relaxed/simple; bh=FYgh3ggUKBv3cIu6c39CJTFUJthOU3Bw4LCS8fXm734=; h=Cc:Mime-Version:To:Subject:Date:Message-Id:From:Content-Type; b=YYnz9VvBH6cXwWKrtRhNS1eesDu/s86NuhcLZSySE5jDBl1O5C7mzpWbvErZf1zAB7UQFK22LQBvZKqkyjzq+SdTEkHw9i3fxQ6KNA+lV7xIO/d+c2lplBa0hCLUSLsMPg1cSjyID2TydUaLkfxXcU3UYjYVDTNSBWekz1GQu74= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=picoheart.com; spf=pass smtp.mailfrom=picoheart.com; dkim=pass (2048-bit key) header.d=picoheart-com.20200927.dkim.feishu.cn header.i=@picoheart-com.20200927.dkim.feishu.cn header.b=iAuDZH16; arc=none smtp.client-ip=209.127.231.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=picoheart.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=picoheart.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=picoheart-com.20200927.dkim.feishu.cn header.i=@picoheart-com.20200927.dkim.feishu.cn header.b="iAuDZH16" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=s1; d=picoheart-com.20200927.dkim.feishu.cn; t=1768372656; h=from:subject:mime-version:from:date:message-id:subject:to:cc: reply-to:content-type:mime-version:in-reply-to:message-id; bh=1KHXngXfRGvvMW06f+GfqzL0+p+XIjFjhJb/29MnMg4=; b=iAuDZH16fuUx8xq3B3gIRtG+2XIIxh7WcZ0yn0euTWQpCLBo7Vv0o2//imA0RlpH5Mu9ha +AMpCMNKYFxv+Cf/sE/7sqkP4p9ymTH/hzNdDnrw+b9QYpC8YlBW3oMcZkkYYaENntAOZX 74XRjxtGR0UpeAmQu7WLYaQ8sEncv1dOYZRglttzvPb7TdzA5jO9wjBnlkS6Q5o6HpX0me 8hYf97iYOYrzVuUrsT/nKs95pBJzpF+60Xk8vWAIQmD/zckJfNHaQWB5mG798CfWFjXaIk AqGvBt4XMJKv0vQgvxLrYaYXV6DYqKVDPymLN7Hlq6Xo1aGmsxqYF/vrKrNDSA== Cc: , , , , Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 To: , , , , , Subject: [PATCH] irqchip/riscv-aplic: Register the driver prior to device creation Date: Wed, 14 Jan 2026 14:37:30 +0800 Message-Id: <20260114063730.78009-1-yang.yicong@picoheart.com> X-Original-From: Yicong Yang Received: from G9WYR9K0VW ([58.250.122.114]) by smtp.feishu.cn with ESMTPS; Wed, 14 Jan 2026 14:37:33 +0800 Content-Transfer-Encoding: quoted-printable X-Lms-Return-Path: From: "Yicong Yang" X-Mailer: git-send-email 2.50.1 Content-Type: text/plain; charset="utf-8" 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 --- 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-r= iscv-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 =3D { }, .probe =3D 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); --=20 2.34.1