acpi_scan_drop_device(9)

💅 NAME 💅

Okay so bestie, welcome to acpi_scan_drop_device(9) from the Kernel API Manual — we're dropping an ACPI device object, and it's giving very specific kernel cleanup energy ✨

acpi_scan_drop_device — drop an ACPI device object.

✨ SYNOPSIS ✨

void acpi_scan_drop_device (acpi_handle handle , void *context );

🎀 ARGUMENTS 🎀

• handle — handle of an ACPI namespace node, and bestie, it is literally not used here 🙈
• context — address of the ACPI device object to drop 💖

🌸 DESCRIPTION 🌸

So this function gets invoked by acpi_ns_delete_node during the removal of the ACPI namespace node that the device object pointed to by context is attached to. Very “right place, right time” of it 👑

The unregistration is carried out asynchronously — yes, async slay — specifically to avoid running acpi_device_del under ACPICA's namespace mutex. And the list is used to make sure the ordering stays correct: the device objects must be unregistered in the same order in which the corresponding namespace nodes are deleted. Order matters, periodt 🫶

🌈 SEE ALSO 🌈

Kernel file: ./drivers/acpi/scan.c — that's the spot 💅

Also on the SEE ALSO list, in all their referenced glory:

• acpi_fetch_acpi_dev(9)
• acpi_get_acpi_dev(9)
• acpi_dma_supported(9)
• acpi_get_dma_attr(9)
• acpi_dma_get_range(9)
• acpi_dma_configure_id(9)
• acpi_walk_dep_device_list(9)
• acpi_dev_clear_dependencies(9)
• acpi_dev_ready_for_enumeration(9)
• acpi_dev_get_next_consumer_dev(9)
• acpi_bus_scan(9)
• acpi_bus_trim(9)

That's the whole page, bestie! Source/version: ./drivers/acpi; date: October 2026; title energy: acpi_scan_drop_device(9). Stay slay, stay ordered, and may your namespace nodes delete cleanly 💖✨🎀