ata_acpi_handle_hotplug(9)

📦 version 7.3.1, in nixpkgs unstable

💅 ata_acpi_handle_hotplug 💅

okay so you're in the Kernel API Manual, section 9, and today's main character is ata_acpi_handle_hotplug ✨ bestie this is the ACPI event handler backend and it's lowkey the place where every bay/device drama gets resolved 🎀

🌸 NAME 🌸

ata_acpi_handle_hotplug — the ACPI event handler backend, fr fr 💖

✨ SYNOPSIS ✨

void ata_acpi_handle_hotplug (struct ata_port *ap , struct ata_device
*dev , u32 event );

like yes that's the whole signature, no cap 🫶

🦋 ARGUMENTS 🦋

  • ap — the ATA port where the ACPI event went down 👀
  • dev — the ATA device the ACPI event happened to (and yes, it can be NULL, we'll get to that 😌)
  • event — the actual ACPI event that occurred, the whole reason we're here 💫

💜 DESCRIPTION 💜

So basically all the ACPI bay / device related events end up in this function. Like, every single one. It's giving main character energy for hotplug handling 👑

Here's the vibe check on dev:

  • if the event is port-wide, then dev is NULL 🙈
  • if the event is specific to a device, then dev points to it 👉💅

And the behaviour split, because this part matters:

  • Hotplug notification (as opposed to unplug) is always handled as port-wide 🌈
  • Unplug only kills the target device on a device-wide event 💀
LOCKING: ACPI notify handler context. May sleep. 😴 so like, don't be weird about it.

🔥 SEE ALSO 🔥

Kernel file ./drivers/ata/libata-acpi.c — go read it, iykyk 📖✨

okay that's the whole thing, you ate that 🍓 this lil page lives under ./drivers/ata, dated October 2026, and it's literally ata_acpi_handle_hotplug(9) — go slay your ACPI events bestie 💖🧚‍♀️⭐

📦 where this page comes from