STRUCT DEVICE(9)

📦 version 7.3.1, in nixpkgs unstable

💖 struct device(9) 💖

okay bestie, buckle up — this is struct device(9) from the Kernel API Manual, and it's literally the blueprint for every single device your kernel has ever met. main character energy, fr.

✨ NAME ✨

struct device — the basic device structure 🫶

🦋 SYNOPSIS 🦋

struct device {
    struct kobject kobj;
    struct device           *parent;
    struct device_private   *p;
    const char              *init_name;
    const struct device_type *type;
    const struct bus_type   *bus;
    struct device_driver *driver;
    void *platform_data;
    void *driver_data;
    struct {
      const char      *name;
      spinlock_t lock;
    } driver_override;
    struct mutex            mutex;
    struct dev_links_info   links;
    struct dev_pm_info      power;
    struct dev_pm_domain    *pm_domain;
  #ifdef CONFIG_ENERGY_MODEL;
    struct em_perf_domain   *em_pd;
  #endif;
  #ifdef CONFIG_PINCTRL;
    struct dev_pin_info     *pins;
  #endif;
    struct dev_msi_info     msi;
  #ifdef CONFIG_ARCH_HAS_DMA_OPS;
    const struct dma_map_ops *dma_ops;
  #endif;
    u64 *dma_mask;
    u64 coherent_dma_mask;
    u64 bus_dma_limit;
    const struct bus_dma_region *dma_range_map;
    struct device_dma_parameters *dma_parms;
    struct list_head        dma_pools;
  #ifdef CONFIG_DMA_DECLARE_COHERENT;
    struct dma_coherent_mem *dma_mem;
  #endif;
  #ifdef CONFIG_DMA_CMA;
    struct cma *cma_area;
  #endif;
  #ifdef CONFIG_SWIOTLB;
    struct io_tlb_mem *dma_io_tlb_mem;
  #endif;
  #ifdef CONFIG_SWIOTLB_DYNAMIC;
    struct list_head dma_io_tlb_pools;
    spinlock_t dma_io_tlb_lock;
    bool dma_uses_io_tlb;
  #endif;
    struct dev_archdata     archdata;
    struct device_node      *of_node;
    struct fwnode_handle    *fwnode;
  #ifdef CONFIG_NUMA;
    int numa_node;
  #endif;
    dev_t devt;
    u32 id;
    spinlock_t devres_lock;
    struct list_head        devres_head;
    const struct class      *class;
    const struct attribute_group **groups;
    void (*release)(struct device *dev);
    struct iommu_group      *iommu_group;
    struct dev_iommu        *iommu;
    struct device_physical_location *physical_location;
    enum device_removable   removable;
    unsigned long flags[BITS_TO_LONGS( DEV_FLAG_COUNT)];
 };

bestie it's a big struct, but every field is iconic in its own way. let's go 👑

🌸 Members 🌸

  • kobj — a top-level, abstract class that other classes are derived from. the origin story, basically.
  • parent — the device's "parent" device, i.e. the device it's attached to. in most cases a parent device is some sort of bus or host controller. if parent is NULL, the device is a top-level device — which is not usually what you want 💀
  • p — holds the private data of the driver core portions of the device. see the comment of the struct device_private for detail.
  • init_name — the initial name of the device.
  • type — the type of device. it identifies the device type and carries type-specific information.
  • bus — the type of bus the device is on.
  • driver — which driver has allocated this.
  • platform_data — platform data specific to the device.
  • driver_data — private pointer for driver specific info.
  • driver_override — driver name to force a match. do not touch directly; use device_set_driver_override instead 🙈
  • mutex — mutex to synchronize calls to its driver.
  • links — links to suppliers and consumers of this device.
  • power — for device power management. see Documentation/driver-api/pm/devices.rst for details.
  • pm_domain — provides callbacks executed during system suspend, hibernation, system resume and during runtime PM transitions, along with subsystem-level and driver-level callbacks.
  • em_pd — the device's energy model performance domain. (lives behind CONFIG_ENERGY_MODEL ✨)
  • pins — for device pin management. see Documentation/driver-api/pin-control.rst for details. (behind CONFIG_PINCTRL)
  • msi — MSI related data.
  • dma_ops — DMA mapping operations for this device. (behind CONFIG_ARCH_HAS_DMA_OPS)
  • dma_mask — DMA mask (if it's a dma'ble device).
  • coherent_dma_mask — like dma_mask, but for alloc_coherent mapping, since not all hardware supports 64-bit addresses for consistent allocations of such descriptors.
  • bus_dma_limit — limit of an upstream bridge or bus which imposes a smaller DMA limit than the device itself supports.
  • dma_range_map — map for DMA memory ranges relative to that of RAM.
  • dma_parms — a low level driver may set these to teach IOMMU code about segment limitations.
  • dma_pools — DMA pools (if it's a dma'ble device).
  • dma_mem — internal for coherent mem override. (behind CONFIG_DMA_DECLARE_COHERENT)
  • cma_area — contiguous memory area for DMA allocations. (behind CONFIG_DMA_CMA)
  • dma_io_tlb_mem — software IO TLB allocator. not for driver use, bestie, hands off. (behind CONFIG_SWIOTLB)
  • dma_io_tlb_pools — list of transient swiotlb memory pools. (behind CONFIG_SWIOTLB_DYNAMIC)
  • dma_io_tlb_lock — protects changes to the list of active pools. (behind CONFIG_SWIOTLB_DYNAMIC)
  • dma_uses_io_tlb — true if the device has used the software IO TLB. (behind CONFIG_SWIOTLB_DYNAMIC)
  • archdata — for arch-specific additions.
  • of_node — associated device tree node.
  • fwnode — associated device node supplied by platform firmware.
  • numa_node — the NUMA node this device is close to. (behind CONFIG_NUMA)
  • devt — for creating the sysfs "dev".
  • id — device instance.
  • devres_lock — spinlock to protect the resource of the device.
  • devres_head — the resources list of the device.
  • class — the class of the device.
  • groups — optional attribute groups.
  • release — callback to free the device after all references have gone away. this should be set by the allocator of the device (i.e. the bus driver that discovered the device).
  • iommu_group — the IOMMU group the device belongs to.
  • iommu — per device generic IOMMU runtime data.
  • physical_location — describes the physical location of the device connection point in the system housing.
  • removable — whether the device can be removed from the system. this should be set by the subsystem / bus driver that discovered the device.
  • flags — DEV_FLAG_XXX flags. use atomic bitfield operations to modify them, no cap 🫡

🎀 Example 🎀

for devices on custom boards — the typical embedded and SOC based hardware situation — Linux often uses platform_data to point to board-specific structures describing devices and how they're wired. that can include which ports are available, chip variants, which GPIO pins act in what additional roles, and so on. it shrinks the "Board Support Packages" (BSPs) and minimizes board-specific #ifdefs in drivers. absolutely slaying the bloat 💅

🧚 Description 🧚

at the lowest level, every device in a Linux system is represented by an instance of struct device. the device structure holds the information the device model core needs to model the system. most subsystems, however, track additional information about the devices they host. so yeah — it's rare for devices to be represented by bare device structures; instead that structure, like kobject structures, is usually embedded within a higher-level representation of the device. it's giving nesting dolls. it's giving "everything is a device inside a device" 🌈

👑 SEE ALSO 👑

kernel file ./include/linux/device.h, plus all these besties:

ngl bestie, if you made it this far you're officially a kernel dev now. go read device.h and hydrate 💜

this lil page came from ./include/linux, dated October 2026 — mwah, love u, bye 🍓✨🎀

📦 where this page comes from