STRUCT DEVICE_PRIVATE(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

✨ struct device_private(9) β€” the kernel API manual, but make it make sense ✨

Okay bestie, so we're looking at struct device_private(9) from the Kernel API Manual and honestly? It's giving "the driver core's little secret" energy. This page is literally all about the structure that holds all the private-to-the-driver-core portions of the device structure. So like, the stuff regular device code doesn't get to peek at πŸ‘€πŸ’…


πŸ“› NAME

struct device_private β€” a structure that literally holds the private-to-the-driver-core portions of the device structure. That's it. That's the whole vibe. It's the VIP backstage area of struct device 🎟️✨


🧬 SYNOPSIS

struct device_private {
    struct klist klist_children;
    struct klist_node knode_parent;
    struct klist_node knode_driver;
    struct klist_node knode_bus;
    struct klist_node knode_class;
    struct list_head deferred_probe;
    const struct device_driver *async_driver;
    char *deferred_probe_reason;
    struct device *device;
    u8 dead:1;
 };

πŸ’– Members

  • klist_children β€” the klist that's holding literally all the children of this device. Like, every single child device? It's in there. No cap πŸ‘‘
  • knode_parent β€” this is the node in the sibling list. Lowkey just a link in the family group chat of devices 🫢
  • knode_driver β€” node in the driver list. It's giving "which driver am I linked to" energy πŸ”—
  • knode_bus β€” node in the bus list. Bestie's got a seat on the bus and this is the ticket 🎫
  • knode_class β€” node in the class list. Classy behavior only, fr fr πŸŽ€
  • deferred_probe β€” okay so this one is an entry in deferred_probe_list and it's literally used to retry binding drivers that couldn't get all the resources they needed for the device. Like, usually because it depends on another driver getting probed first. It's the "hey bestie, wait your turn" list πŸ˜­πŸ’€
  • async_driver β€” pointer to the device driver that's awaiting probe via async_probe. It's the main character driver waiting backstage for its moment πŸ”₯
  • deferred_probe_reason β€” this one captures the -EPROBE_DEFER message that's emitted with dev_err_probe so it can be retrieved later via debugfs. It's giving "receipts for later" energy 🧾✨
  • device β€” pointer back to the struct device that this structure is associated with. It's literally the "home again" link 🏠
  • dead β€” this device is currently either in the process of being removed or has already been removed from the system. And any asynchronous events scheduled for this device should exit without taking any action. Like, if you see dead, just leave. Don't do anything. It's not worth it πŸ’€πŸšͺ

⚠️ Description

Nothing outside of the driver core should ever touch these fields.

That's it. That's the whole warning. This is NOT for you unless you are the driver core. It's giving "don't touch my stuff" energy, and honestly? Respect the boundaries πŸ«ΆπŸ™ˆ


πŸ¦‹ SEE ALSO

  • Kernel file ./drivers/base/base.h
  • struct subsys_private(9)

Okay that's the whole page, bestie. You're now officially caught up on struct device_private(9). This page was brought to you by the fine folks at ./drivers/base, dated October 2026, and it's literally serving struct device_private(9) excellence. That's the tea! πŸ΅βœ¨πŸ’…

πŸ“¦ where this page comes from