From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sg-1-39.ptr.blmpb.com (sg-1-39.ptr.blmpb.com [118.26.132.39]) (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 F0FDA397ADB for ; Wed, 14 Jan 2026 11:48:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=118.26.132.39 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768391321; cv=none; b=d26ZzAI0+saNRv2+umA5RBy9/McHFZkPxtzLH4wa2KKH6Stg4HWCheTKqIN/r0bci/dlT98vkRld4maLr5wF4n+VhtIHmZGwmtYJyv591pyDoCZA9d4pMicZJj7efmD19QaIfIZ6TTJc3dpVEYPuZny7Y4KWVChI4/GH+7AV07k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768391321; c=relaxed/simple; bh=cTbX8Ct8rvPV8ZJgvQTiBDTNdYkgOfvXfcH9vGVhgXY=; h=Content-Type:In-Reply-To:From:Date:References:To:Cc:Subject: Message-Id:Mime-Version; b=ZrHl8CF3P3Vi8XHfiI3URxE2J+Z6mLmnL+loYCyH0KCHZcHZU934riTwSdDHn2HkZag96hh1jNoPAQBDyfYMOBfPPR262kdbDps9l86keqo7d7DebHi1x43I3VrzE8SvQkZAt6fMvtSkrMAxmqAlVdtQcJMMYAdFmlIyRbZXWbM= 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=AYS8CPDO; arc=none smtp.client-ip=118.26.132.39 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="AYS8CPDO" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=s1; d=picoheart-com.20200927.dkim.feishu.cn; t=1768391302; h=from:subject:mime-version:from:date:message-id:subject:to:cc: reply-to:content-type:mime-version:in-reply-to:message-id; bh=IdxEcpSQD+qfC2pBDgk9Vmnia3KRjpxXLUHXWcS5vOs=; b=AYS8CPDOWtiPg6Xy2e8HOW8I9motUNWGzrNHLF8JeOcqiXW26bvJV4R6eWLEnk0iSF7/SE btq6Bodh6G9IIfwJCMbyeFx8Xuy45fYSb9AyH/9JWm5NNMOo7VgsFYgGGET5z4okzWV61J okyL8xHAeoK9zd6IeSPBSnlYABbO7dfyI3T3qXIJO4Dwv0EDezUqMs4sJ9wvXEg3dMcDul Zth8B0dyUwlqkVyySLu2p8lbYHtPLaFUGSiXiyws4BaFk0uxzNvp3hrKUtYbVdrfJ/H9F0 PWkGujwdeA+kXAxfWWBxWYgg3YU/b1u36urtG7CAsFRlKKYgcDHdrsg6FMiQvQ== Content-Type: text/plain; charset=UTF-8 Received: from [172.16.153.176] ([58.250.122.114]) by smtp.feishu.cn with ESMTPS; Wed, 14 Jan 2026 19:48:19 +0800 In-Reply-To: From: "Yicong Yang" Date: Wed, 14 Jan 2026 19:48:16 +0800 X-Original-From: Yicong Yang Content-Transfer-Encoding: quoted-printable User-Agent: Mozilla Thunderbird References: <20260114063730.78009-1-yang.yicong@picoheart.com> To: "Anup Patel" Cc: , , , , , , , , , , Subject: Re: [PATCH] irqchip/riscv-aplic: Register the driver prior to device creation Content-Language: en-US X-Lms-Return-Path: Message-Id: <7b859dd5-9262-4d68-9a8e-e0be0c24ac4a@picoheart.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Hi Anup, On 1/14/26 4:57 PM, Anup Patel wrote: > On Wed, Jan 14, 2026 at 12:08=E2=80=AFPM Yicong Yang wrote: >> >> 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. >=20 > Changing the driver registration priority is not going to help. For DT, > we should rely on fw_devlink to ensure APLIC is probed before > drivers consuming APLIC interrupts. For ACPI in the RISC-V world, > the APLIC probe ordering using GSI mappings and _DEP objects. >=20 > There was a recent discussion on this so refer: > https://www.spinics.net/lists/kernel/msg5938816.html >=20 Thanks for the reference, the problem is different (though their problems should also blame to the asynchronous device creation). Our problem is the devices that depends on the APLIC is created lately, *parallel* with th= e init task so sometimes they're not even created (e.g. PCIe host bridge, tty) whe= n the init task running to the stage to check for these devices (as described in the commit). As for ACPI, this patch isn't going to change the probe ordering, the dependency's still described by the GSI mappings, _DEP or _PRT method and honored. But to make the related devices created earlier and in a synchronous manner. Currently the devices creation that depend on APLIC (take PCIe host bridge as example) is like below: [init thread] [workqueue N] // subsys_initcall acpi_init() acpi_arch_init() // create GSI mappings riscv_acpi_init_gsi_mapping() acpi_bus_scan() [...] acpi_walk_namespace(acpi_bus_check_add_1) // devices depend on APLIC, add to // acpi_dep_list for deferred creation acpi_scan_check_dep() acpi_scan_add_dep() // create acpi_device for APLIC or // other independent device acpi_add_single_object() acpi_bus_attach() // APLIC or other independent device acpi_create_platform_device() acpi_scan_postponed() // create acpi_device for APLIC depended // devices, e.g. PCI host bridge acpi_add_single_object() [...] // device_initcall platform_driver_register(&aplic_driver) driver_attach() // probe and init APLIC aplic_probe() [...] acpi_dev_clear_dependencies() // create work for each device=20 queue_work() acpi_scan_clear_dep_fn [...] acpi_scan_lock_acquire() // wi= ll compete with other // de= vice creation // later initcall than enter init task. // e.= g. for PCIe host brigdes acpi_pci_root_add() // create = PCIe Root which // is *par= allel* with init acpi_scan_lock_release() But if we register the driver earlier, the APLIC will be probed and initialized early in the 1st time DSDT scan. since the dependency is met, other devices depends on the APLIC will be created in the 2nd time DSDT scan in a synchronous way: [init thread] // core_initcall platform_driver_register(&aplic_driver) // subsys_initcall acpi_init() acpi_arch_init() // create GSI mappings riscv_acpi_init_gsi_mapping() acpi_bus_scan() [...] acpi_walk_namespace(acpi_bus_check_add_1) // devices depend on APLIC, add to // acpi_dep_list for deferred creation acpi_scan_check_dep() acpi_scan_add_dep() // create acpi_device for APLIC or // other independent device acpi_add_single_object() acpi_bus_attach() // APLIC or other independent device acpi_create_platform_device() aplic_probe() // driver's registered, probe directly [...] acpi_dev_clear_dependencies() acpi_scan_clear_dep() // acpi_device for e.g. PCI is not created // so won't queue the clear_dep work. only // mark the dependency met here if (acpi_device) acpi_scan_clear_dep_queue() acpi_scan_postponed() acpi_walk_namespace(acpi_bus_check_add_2) // create acpi_device for APLIC depended // devices, e.g. PCI host bridge acpi_add_single_object() acpi_bus_attach() acpi_pci_root_add() // e.g. PCIe host bridge created // acpi_create_platform_device() for // other platform devices // later initcalls then enter init task with above, since the initcalls and init task execution is serialized, at least the basic devices like tty platform devices and PCIe host bridges is created. Thanks.