__device_li...e_sync_state(9)

📦 version 7.3.1, in nixpkgs unstable

💅 __device_li...e_sync_state(9) 💅

okay so bestie, welcome to the Kernel API Manual 🎀 — yes the title is lowkey truncated with dots and yes that's just how it is, we don't ask questions, we just vibe. This one's about __device_links_queue_sync_state, which honestly is giving "long name, big job" energy. Let's get into it 💖

✨ NAME ✨

__device_links_queue_sync_state — Queue a device for sync_state() callback 🦋

🌸 SYNOPSIS 🌸

void __device_links_queue_sync_state (struct device *dev , struct list_head *list );

💜 ARGUMENTS 💜

  • dev — the Device you want to call sync_state on 🫶
  • list — the List head you're queueing the dev on ⭐

🔥 DESCRIPTION 🔥

So here's the tea ☕: this function queues a device up for a sync_state callback, but specifically when the device links write lock isn't held. That's the whole point, iykyk — it lets the sync_state execution flow use device links APIs without things getting messy 💅

girl, listen 🙈 — the caller must ensure this function is called with device_links_write_lock held. That's not a suggestion, that's the rule, periodt.

This function does a get_device to make sure the device is not freed while it's sitting on this list. Very protective, very main character energy 👑

So the caller must also ensure that device_links_flush_sync_list is called as soon as the caller releases device_links_write_lock. Why? Because that's necessary to make sure the sync_state is called in a timely fashion ⏰ and the put_device is called on this device. Both of those things need to happen, no cap 💯

🌈 SEE ALSO 🌈

Kernel file ./drivers/base/core.c — and now the friend group, because there's a lot of them 🧚✨

and that's the whole page, bestie, you ate that 🍓✨

tiny sign-off moment 🎀 — this one lives in ./drivers/base, stamped October 2026, and it's still __device_li...e_sync_state(9) because the title said so 💀💖

📦 where this page comes from