ibm_handle_events(9)

bestie, this is ibm_handle_events(9) from the Kernel API Manual — welcome to the ACPI callback page, it's giving kernel-hotplug realness 💅

🎀 NAME 🎀

ibm_handle_events — listens for ACPI events for the IBM37D0 device. no cap.

✨ SYNOPSIS ✨

void ibm_handle_events (acpi_handle handle , u32 event , void *context );

🫶 ARGUMENTS 🫶

• handle — an ACPI handle to the device that caused the event. like, which device woke us up 💖
• event — the event info (device specific). the details are device-coded, iykyk.
• context — passed context (our notification struct). this is our little carry-on bag 🎀

🌸 DESCRIPTION 🌸

okay so this method is registered as a callback with the ACPI subsystem, and it gets called when this device has an event to notify the OS of. very main character callback energy.

the events actually come from the device as two events that get synthesized into one event with data by this function. the event ID comes first, and then the slot number that caused it. we report this as one event to the OS. slay, one clean notification ✨

from section 5.6.2.2 of the ACPI 2.0 spec, I understand that the OSPM will only re-enable the interrupt that causes this event AFTER this method has returned — thereby enforcing serial access for the notification struct. periodt, that's the whole safety vibe 💅

bestie this serial-access detail is not decorative: the return-before-re-enable order is what keeps the notification struct from getting chaotic.

💜 SEE ALSO 💜

• Kernel file ./drivers/pci/hotplug/acpiphp_ibm.c
• ibm_slot_from_id(9)
• ibm_set_attention_status(9)
• ibm_get_attention_status(9)
• ibm_get_table_from_acpi(9)
• ibm_read_apci_table(9)
• ibm_find_acpi_device(9)

source/version: ./drivers/pci/hotplug · date: October 2026 · page: ibm_handle_events(9) — bye bestie, hydrate and check your interrupts 🫶💖