kfd_topology...ate_io_links(9)

💖 NAME 💖

Okay bestie, this is the page for kfd_topology_update_io_links, from the Kernel API Manual — you might see it filed as kfd_topology...ate_io_links(9). It does exactly what it says on the tin: update IO links after device removal. Slay. ✨

🌸 SYNOPSIS 🌸

void kfd_topology_update_io_links (int proximity_domain );

🎀 ARGUMENTS 🎀

• proximity_domain — the proximity domain value of the dev being removed. Yes, “dev” like device — keep up 💅

🦋 DESCRIPTION 🦋

So right now, the topology list is arranged in increasing order of proximity domain. That's the setup.

When a device is removed, two things need to be done:

1. All the IO links to this device need to be removed. Bye links 👋
2. All nodes after the current device node need to move up once this device node is removed from the topology list. As a result, the proximity domain values for all nodes after the node being deleted reduce by 1. This would also cause the proximity domain values for io links to be updated based on new proximity domain values. The domino effect is real 😭

👑 CONTEXT 👑

The caller must hold write topology_lock. No cap — that's the rule. 🔥

🌈 SEE ALSO 🌈

Kernel file ./drivers/gpu/drm/amd/amdkfd/kfd_topology.c — that's the spot, iykyk.

Cute sign-off: this page's source/version is ./drivers/gpu/drm/amd/amdkfd, and it's dated October 2026, still under the Kernel API Manual umbrella. Bye bestie, go update those IO links 💅🫶