kernel/linux.git/drivers/acpi/scan.c, branch v6.12.98

ACPI: scan: Use async schedule function in acpi_scan_clear_dep_fn()

2026-07-04T11:43:25+00:00

[ Upstream commit 7cf28b3797a81b616bb7eb3e90cf131afc452919 ] The device object rescan in acpi_scan_clear_dep_fn() is scheduled on a system workqueue which is not guaranteed to be finished before entering userspace. This may cause some key devices to be missing when userspace init task tries to find them. Two issues observed on RISCV platforms: - Kernel panic due to userspace init cannot have an opened console. The console device scanning is queued by acpi_scan_clear_dep_queue() and not finished by the time userspace init process running, thus by the time userspace init runs, no console is present. - Entering rescue shell due to the lack of root devices (PCIe nvme in our case). Same reason as above, the PCIe host bridge scanning is queued on a system workqueue and finished after init process runs. The reason is because both devices (console, PCIe host bridge) depend on riscv-aplic irqchip to serve their interrupts (console's wired interrupt and PCI's INTx interrupts). In order to keep the dependency, these devices are scanned and created after initializing riscv-aplic. The riscv-aplic is initialized in device_initcall() and a device scan work is queued via acpi_scan_clear_dep_queue(), which is close to the time userspace init process is run. Since system_dfl_wq is used in acpi_scan_clear_dep_queue() with no synchronization, the issues will happen if userspace init runs before these devices are ready. The solution is to wait for the queued work to complete before entering userspace init. One possible way would be to use a dedicated workqueue instead of system_dfl_wq, and explicitly flush it somewhere in the initcall stage before entering userspace. Another way is to use async_schedule_dev_nocall() for scanning these devices. It's designed for asynchronous initialization and will work in the same way as before because it's using a dedicated unbound workqueue as well, but the kernel init code calls async_synchronize_full() right before entering userspace init which will wait for the work to complete. Compared to a dedicated workqueue, the second approach is simpler because the async schedule framework takes care of all of the details. The ACPI code only needs to focus on its job. A dedicated workqueue for this could also be redundant because some platforms don't need acpi_scan_clear_dep_queue() for their device scanning. Signed-off-by: Yicong Yang [ rjw: Subject adjustment, changelog edits ] Link: https://patch.msgid.link/20260128132848.93638-1-yang.yicong@picoheart.com Signed-off-by: Rafael J. Wysocki [ Vivian: Adjust system_dfl_wq -> system_unbound_wq in removed lines ] Signed-off-by: Vivian Wang Signed-off-by: Sasha Levin

ACPI: scan: Use acpi_dev_put() in object add error paths

2026-05-14T13:29:17+00:00

commit 9c0acc169ac71535477caedea8315f7041c5f07c upstream. After acpi_init_device_object(), the lifetime of struct acpi_device is managed by the driver core through reference counting. Both acpi_add_power_resource() and acpi_add_single_object() call acpi_init_device_object() and then invoke acpi_device_add(). If that fails, their error paths call the release callback directly instead of dropping the device reference through acpi_dev_put(). This bypasses the normal device lifetime rules and frees the object without releasing the reference acquired by device_initialize(), which may lead to a refcount leak. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fix both error paths by using acpi_dev_put() and let the release callback handle the final cleanup. Fixes: 781d737c7466 ("ACPI: Drop power resources driver") Fixes: 718fb0de8ff88 ("ACPI: fix NULL bug for HID/UID string") Cc: All applicable Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260413135343.2884481-1-lgs201920130244@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI: scan: Update honor list for RPMI System MSI

2025-11-13T20:34:30+00:00

[ Upstream commit 4215d1cf59e4b272755f4277a05cd5967935a704 ] The RPMI System MSI interrupt controller (just like PLIC and APLIC) needs to probed prior to devices like GED which use interrupts provided by it. Also, it has dependency on the SBI MPXY mailbox device. Add HIDs of RPMI System MSI and SBI MPXY mailbox devices to the honor list so that those dependencies are handled. Reviewed-by: Atish Patra Reviewed-by: Andy Shevchenko Acked-by: Rafael J. Wysocki Signed-off-by: Sunil V L Signed-off-by: Anup Patel Acked-by: Jassi Brar Link: https://lore.kernel.org/r/20250818040920.272664-17-apatel@ventanamicro.com Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin

ACPI: scan: Add Intel CVS ACPI HIDs to acpi_ignore_dep_ids[]

2025-11-13T20:34:04+00:00

[ Upstream commit 4405a214df146775338a1e6232701a29024b82e1 ] Some x86/ACPI laptops with MIPI cameras have a INTC10DE or INTC10E0 ACPI device in the _DEP dependency list of the ACPI devices for the camera- sensors (which have flags.honor_deps set). These devices are for an Intel Vision CVS chip for which an out of tree driver is available [1]. The camera sensor works fine without a driver being loaded for this ACPI device on the 2 laptops this was tested on: ThinkPad X1 Carbon Gen 12 (Meteor Lake) ThinkPad X1 2-in-1 Gen 10 (Arrow Lake) For now add these HIDs to acpi_ignore_dep_ids[] so that acpi_dev_ready_for_enumeration() will return true once the other _DEP dependencies are met and an i2c_client for the camera sensor will get instantiated. Link: https://github.com/intel/vision-drivers/ [1] Signed-off-by: Hans de Goede Link: https://patch.msgid.link/20250829142748.21089-1-hansg@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

Merge branches 'acpi-ec', 'acpi-sysfs', 'acpi-utils' and 'acpi-soc'

2024-09-11T19:45:36+00:00

Merge an ACPI EC driver update, ACPI sysfs interface updates, an ACPI library function update, and an ACPI APD driver update for 6.12-rc1: - Do not release locks during operation region accesses in the ACPI EC driver (Rafael Wysocki). - Fix up the _STR handling in the ACPI device object sysfs interface, make it represent the device object attributes as an attribute group and make it rely on driver core functionality for sysfs attrubute management (Thomas Weißschuh). - Extend error messages printed to the kernel log when acpi_evaluate_dsm() fails to include revision and function number (David Wang). - Add a new AMDI0015 platform device ID to the ACPi APD driver for AMD SoCs (Shyam Sundar S K). * acpi-ec: ACPI: EC: Do not release locks during operation region accesses * acpi-sysfs: ACPI: sysfs: remove return value of acpi_device_setup_files() ACPI: sysfs: manage sysfs attributes through device core ACPI: sysfs: manage attributes as attribute_group ACPI: sysfs: evaluate _STR on each sysfs access ACPI: sysfs: validate return type of _STR method * acpi-utils: ACPI: utils: Add rev/func to message when acpi_evaluate_dsm() fails * acpi-soc: ACPI: APD: Add AMDI0015 as platform device

ACPI: pci_link: Clear the dependencies after probe

2024-08-27T13:48:35+00:00

RISC-V platforms need to use dependencies between PCI host bridge, Link devices and the interrupt controllers to ensure probe order. The dependency is like below. Interrupt controller <-- Link Device <-- PCI Host bridge. If there is no dependency between Link device and PCI Host Bridge, then PCI devices may be probed prior to Link devices. If a PCI device is probed before its Link device, we won't be able to find its INTx mapping. So, add the link device's HID to dependency honor list and clear the dependency after probe is done so that the dependent devices are unblocked to probe. Signed-off-by: Sunil V L Tested-by: Björn Töpel Link: https://patch.msgid.link/20240812005929.113499-9-sunilvl@ventanamicro.com Signed-off-by: Rafael J. Wysocki

ACPI: scan: Define weak function to populate dependencies

2024-08-27T13:48:35+00:00

Some architectures like RISC-V need to add dependencies without explicit _DEP. Define a weak function which can be implemented by the architecture. Signed-off-by: Sunil V L Tested-by: Björn Töpel Link: https://patch.msgid.link/20240812005929.113499-7-sunilvl@ventanamicro.com Signed-off-by: Rafael J. Wysocki

ACPI: scan: Add RISC-V interrupt controllers to honor list

2024-08-27T13:48:35+00:00

RISC-V PLIC and APLIC will have dependency from devices using GSI. So, add these devices to the honor list. Signed-off-by: Sunil V L Tested-by: Björn Töpel Link: https://patch.msgid.link/20240812005929.113499-6-sunilvl@ventanamicro.com Signed-off-by: Rafael J. Wysocki

ACPI: scan: Refactor dependency creation

2024-08-27T13:48:35+00:00

Some architectures like RISC-V will use implicit dependencies like GSI map to create dependencies between interrupt controller and devices. To support doing that, the function which creates the dependency, is refactored bit and made public so that dependency can be added from outside of scan.c as well. Signed-off-by: Sunil V L Tested-by: Björn Töpel Link: https://patch.msgid.link/20240812005929.113499-5-sunilvl@ventanamicro.com Signed-off-by: Rafael J. Wysocki

ACPI: scan: Add a weak arch_sort_irqchip_probe() to order the IRQCHIP probe

2024-08-27T13:48:35+00:00

Unlike OF framework, the irqchip probe using IRQCHIP_ACPI_DECLARE has no order defined. Depending on the Makefile is not a good idea. So, usually it is worked around by mandating only root interrupt controller probed using IRQCHIP_ACPI_DECLARE and other interrupt controllers are probed via cascade mechanism. However, this is also not a clean solution because if there are multiple root controllers (ex: RINTC in RISC-V which is per CPU) which need to be probed first, then the cascade will happen for every root controller. So, introduce an architecture specific weak function arch_sort_irqchip_probe() to order the probing of the interrupt controllers which can be implemented by different architectures as per their interrupt controller hierarchy. Signed-off-by: Sunil V L Tested-by: Björn Töpel Link: https://patch.msgid.link/20240812005929.113499-3-sunilvl@ventanamicro.com Signed-off-by: Rafael J. Wysocki