drmm_alloc_o...ed_workqueue(9)

📦 version 7.3.1, in nixpkgs unstable

💅 drmm_alloc_ordered_workqueue (9)

okay so bestie, welcome to the kernel API manual — this one lives in the Kernel API Manual, and the whole vibe is: you want a workqueue, but you want your drm_device to handle the cleanup for you. no cap, it's giving "managed responsibility" and we're obsessed. 🎀

✨ NAME ✨

drmm_alloc_ordered_workqueue — the &drm_device-managed version of alloc_ordered_workqueue(). literally the same energy, just with automatic cleanup built in 🫶

🌸 SYNOPSIS 🌸

drmm_alloc_ordered_workqueue (dev , fmt , flags , args... );

🦋 ARGUMENTS 🦋

  • dev — your DRM device. the main character, honestly 👑
  • fmt — a printf format for the name of the workqueue. yes, it gets a name. slay 💅
  • flags — the WQ_* flags. heads up though: only WQ_FREEZABLE and WQ_MEM_RECLAIM are actually meaningful here. the rest are just... there. not me pointing that out 🙈
  • args — args for fmt. the lil supporting cast for the name ✨

💖 DESCRIPTION 💖

so this is a drm_device-managed version of alloc_ordered_workqueue. and the way it works is chef's kiss — the allocated workqueue is automatically destroyed on the final drm_dev_put. no manual teardown, no "oops i forgot to free it" moment. iconic behavior fr fr 🔥

⭐ RETURN ⭐

on success you get the workqueue. on failure, you get a negative ERR_PTR. so check it, bestie — don't just assume it's fine 😭

🌈 SEE ALSO 🌈

kernel file ./include/drm/drm_managed.h, plus the whole managed-allocation friend group:

they all understood the assignment 💜

lowkey reminder: the only flags doing any work are WQ_FREEZABLE and WQ_MEM_RECLAIM — everything else is just along for the ride 🧚

and that's the page! brought to you from ./include/drm, dated October 2026, under the title drmm_alloc_o...ed_workqueue(9) — yes the page title itself got truncated and honestly? relatable. bye bestie, go manage some workqueues 💕🌸

📦 where this page comes from