Message-Id: <7b859dd5-9262-4d68-9a8e-e0be0c24ac4a@picoheart.com>
Date: Wed, 14 Jan 2026 19:48:16 +0800
From: "Yicong Yang" <yang.yicong@...oheart.com>
To: "Anup Patel" <apatel@...tanamicro.com>
Cc: <yang.yicong@...oheart.com>, <anup@...infault.org>, <tglx@...nel.org>, 
	<pjw@...nel.org>, <palmer@...belt.com>, <aou@...s.berkeley.edu>, 
	<alex@...ti.fr>, <linux-riscv@...ts.infradead.org>, 
	<linux-kernel@...r.kernel.org>, <geshijian@...oheart.com>, 
	<weidong.wd@...oheart.com>
Subject: Re: [PATCH] irqchip/riscv-aplic: Register the driver prior to device creation

Hi Anup,

On 1/14/26 4:57 PM, Anup Patel wrote:
> On Wed, Jan 14, 2026 at 12:08 PM Yicong Yang <yang.yicong@...oheart.com> 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.
> 
> 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.
> 
> There was a recent discussion on this so refer:
> https://www.spinics.net/lists/kernel/msg5938816.html
> 

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 the init
task so sometimes they're not even created (e.g. PCIe host bridge, tty) when 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 
        queue_work()                       acpi_scan_clear_dep_fn
[...]                                        acpi_scan_lock_acquire() // will compete with other
                                                                      // device creation
// later initcall than enter init task.                               // e.g. for PCIe host brigdes
                                             acpi_pci_root_add() // create PCIe Root which
                                                                 // is *parallel* 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.

Powered by blists - more mailing lists