kernel/linux.git/drivers/acpi/scan.c, branch v7.0-rc7

ACPI: video: Switch over to auxiliary bus type

2026-03-10T14:08:21+00:00

Commit 02c057ddefef ("ACPI: video: Convert the driver to a platform one") switched over the ACPI video bus driver from an ACPI driver to a platform driver, but that change introduced an unwanted and unexpected side effect. Namely, on some systems, the ACPI device object of the ACPI video bus device is an ACPI companion of multiple platform devices and, after adding video_device_ids[] as an acpi_match_table to the acpi_video_bus platform driver, all of those devices started to match that driver and its probe callback is invoked for all of them (it fails, but it leaves a confusing message in the log). Moreover, the MODULE_DEVICE_TABLE() of the ACPI video driver module matches all of the devices sharing the ACPI companion with the ACPI video bus device. To address this, make the core ACPI device enumeration code create an auxiliary device for the ACPI video bus device object instead of a platform device and switch over the ACPI video bus driver (once more) to an auxiliary driver. Auxiliary driver generally is a better match for ACPI video bus than platform driver, among other things because the ACPI video bus device does not require any resources to be allocated for it during enumeration. It also allows the ACPI video bus driver to stop abusing device matching based on ACPI device IDs and it allows a special case to be dropped from acpi_create_platform_device() because that function need not worry about the ACPI video bus device any more. Fixes: 02c057ddefef ("ACPI: video: Convert the driver to a platform one") Reported-by: Pratap Nirujogi Closes: https://lore.kernel.org/linux-acpi/007e3390-6b2b-457e-83c7-c794c5952018@amd.com/ Tested-by: Pratap Nirujogi Signed-off-by: Rafael J. Wysocki Reviewed-by: Mario Limonciello (AMD) [ rjw: Added AUXILIARY_BUS selection to CONFIG_ACPI to fix build issue ] [ rjw: Fixed error path in acpi_create_video_bus_device() ] Link: https://patch.msgid.link/5986516.DvuYhMxLoT@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki

Convert more 'alloc_obj' cases to default GFP_KERNEL arguments

2026-02-22T04:03:00+00:00

This converts some of the visually simpler cases that have been split over multiple lines. I only did the ones that are easy to verify the resulting diff by having just that final GFP_KERNEL argument on the next line. Somebody should probably do a proper coccinelle script for this, but for me the trivial script actually resulted in an assertion failure in the middle of the script. I probably had made it a bit _too_ trivial. So after fighting that far a while I decided to just do some of the syntactically simpler cases with variations of the previous 'sed' scripts. The more syntactically complex multi-line cases would mostly really want whitespace cleanup anyway. Signed-off-by: Linus Torvalds

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

Merge branch 'acpi-driver'

2026-02-05T13:47:50+00:00

Merge updates of drivers handling devices defined in the ACPI specification and other generic devices with ACPI interfaces for 6.20-rc1/7.0-rc1: - Add a piece of documentation explaining why binding drivers directly to ACPI device objects is not a good idea in general and why it is desirable to convert drivers doing so into proper platform drivers that use struct platform_driver for device binding (Rafael Wysocki) - Convert multiple "core ACPI" drivers, including the NFIT ACPI device driver, the generic ACPI button drivers, the generic ACPI thermal zone driver, the ACPI hardware event device (HED) driver, the ACPI EC driver, the ACPI SMBUS HC driver, the ACPI Smart Battery Subsystem (SBS) driver, and the ACPI backlight (video) driver to proper platform drivers that use struct platform_driver for device binding (Rafael Wysocki) - Use acpi_get_local_u64_address() in the ACPI backlight (video) driver to evaluate _ADR instead of evaluating that object directly (Andy Shevchenko) * acpi-driver: (25 commits) ACPI: video: simplify code with acpi_get_local_u64_address() ACPI: scan: Clean up after recent changes ACPI: scan: Use acpi_setup_gpe_for_wake() for buttons ACPI: PM: Let acpi_dev_pm_attach() skip devices without ACPI PM ACPI: Documentation: driver-api: Disapprove of using ACPI drivers ACPI: video: Convert the driver to a platform one ACPI: video: Adjust event notification routine ACPI: scan: Register platform devices for backlight device objects ACPI: SBS: Convert the driver to a platform one ACPI: SMBUS HC: Convert the driver to a platform one ACPI: EC: Convert the driver to a platform one ACPI: EC: Register a platform device for ECDT EC ACPI: HED: Convert the driver to a platform one ACPI: thermal: Rework system suspend and resume handling ACPI: thermal: Convert the driver to a platform one ACPI: thermal: Adjust event notification routine ACPI: scan: Register platform devices for thermal zones ACPI: scan: Do not mark button ACPI devices as wakeup-capable ACPI: scan: Do not bind ACPI drivers to fixed event buttons ACPI: tiny-power-button: Convert the driver to a platform one ...

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

2026-01-28T21:03:24+00:00

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

ACPI: scan: Clean up after recent changes

2026-01-15T13:27:38+00:00

Use LIST_HEAD() for initializing an on-stack list head in two places and remove an empty code line added by mistake. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/12825056.O9o76ZdvQC@rafael.j.wysocki

ACPI: scan: Use acpi_setup_gpe_for_wake() for buttons

2026-01-15T13:27:38+00:00

After starting to use platform devices for representing buttons enumerated via ACPI, acpi_mark_gpe_for_wake() is insufficient for preparing their GPEs to wake up the system from sleep because it does not change the "dispatch type" of the given GPE to ACPI_GPE_DISPATCH_NOTIFY. Subsequently, this causes acpi_enable_gpe() in __acpi_device_wakeup_enable() to fail and system suspend transitions to be aborted. Address this by updating acpi_wakeup_gpe_init() to use acpi_setup_gpe_for_wake() for buttons like for any other devices. This allows acpi_setup_gpe_for_wake() to be simplified further because buttons are not a special case in it any more, so do that as well. Fixes: 52d864019636 ("ACPI: button: Convert the driver to a platform one") Signed-off-by: Rafael J. Wysocki Tested-by: Xi Pardee Link: https://patch.msgid.link/2259694.irdbgypaU6@rafael.j.wysocki

ACPI: scan: Register platform devices for backlight device objects

2026-01-15T13:26:34+00:00

ACPI device objects associated with backlight interfaces are special because they are ACPI companions of PCI devices (GPUs), but the interfaces exposed by them resemble platform device one. Currently, the ACPI video driver binds to them with the help of a special "synthetic" device ID regardless of the pairing with the PCI devices, but since it is generally better to use platform drivers for handling such interfaces, the plan is to convert that drviver into a platform one. However, for this purpose, platform devices corresponding to the ACPI backlight device objects need to be registered, so update acpi_bus_attach() to apply the default ACPI enumeration to them and modify acpi_create_platform_device() to avoid bailing out early if a "physical" device is already attached to a backlight ACPI device object. In addition, update acpi_companion_match() to return a valid struct acpi_device pointer if the ACPI companion of the given device is a backlight ACPI device object, which will facilitate driver matching for platform devices corresponding to those objects. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Reviewed-by: Armin Wolf Link: https://patch.msgid.link/5081593.31r3eYUQgx@rafael.j.wysocki

ACPI: scan: Drop outdated comment regarding removed function

2026-01-02T12:11:00+00:00

The function acpi_video_get_capabilities() was removed from drivers/acpi/video_detect.c by commit 87521e16a7ab ("acpi-video-detect: Rewrite backlight interface selection logic") in 2015. At the time, comments about this function were just removed, and no replacement seemed to be proposed. Drop the reference to acpi_video_get_capabilities() here as well. Signed-off-by: Julia Lawall [ rjw: Subject adjustment, changelog edits ] Link: https://patch.msgid.link/20251230160644.100439-1-Julia.Lawall@inria.fr Signed-off-by: Rafael J. Wysocki