devm_drm_dev_alloc(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

✨ devm_drm_dev_alloc ✨

okay bestie, so this is a page from the Kernel API Manual, and it's about devm_drm_dev_alloc β€” the resource-managed way to spin up a &drm_device instance πŸ’… specifically, it's a resource managed allocation of a &drm_device instance, and it's lowkey iconic for the lazy-in-a-good-way driver dev.


πŸŽ€ SYNOPSIS πŸŽ€

devm_drm_dev_alloc (parent , driver , type , member );

🌸 ARGUMENTS 🌸

  • parent β€” the parent device object 🫢
  • driver β€” the DRM driver
  • type β€” the type of the struct which contains struct drm_device
  • member β€” the name of the drm_device within type

πŸ¦‹ DESCRIPTION πŸ¦‹

So what this does: it allocates and initializes a new DRM device πŸ’– but heads up β€” no device registration is done. none. zero. nope πŸ™ˆ

For that you gotta call drm_dev_register to advertise the device to user space and register it with the other core subsystems. And the way to do it right? Do it last in the device initialization sequence, so userspace can't get its hands on an inconsistent state. that's the vibe check πŸ”₯

The initial ref-count of the object is 1. Use drm_dev_get and drm_dev_put to take and drop further ref-counts, bestie ✨

It is recommended that drivers embed struct drm_device into their own device structure. do it. it's giving good design πŸ‘‘

πŸ’œ Note bestie: this manages the lifetime of the resulting drm_device automatically using devres. The DRM device initialized with this function is automatically put on driver detach using drm_dev_put. so you literally don't have to worry about it β€” no cap 😭🫢

⭐ RETURN ⭐

Pointer to new DRM device, or ERR_PTR on failure. that's it, that's the return πŸ’€

🌈 SEE ALSO 🌈


✨ and that's the whole page! ✨ this lil beauty lives in ./include/drm, it's dated October 2026, and it's brought to you by the Kernel API Manual β€” go forth and allocate responsibly, bestie πŸ’–πŸŽ€πŸ¦‹πŸŒΈπŸ’…πŸ«ΆπŸ‘‘πŸŒˆβ­πŸ§šπŸ’œ

πŸ“¦ where this page comes from