STRUCT DEVICE_DRIVER(9)

📦 version 7.3.1, in nixpkgs unstable

✨ struct device_driver(9) ✨

okay bestie, so we're diving into struct device_driver(9) from the Kernel API Manual — this is literally THE blueprint for how device drivers introduce themselves to the kernel. think of it as the driver's main character application form, and honestly? it's giving "hire me" energy. 💅

🌸 SYNOPSIS 🌸

struct device_driver {
    const char              *name;
    const struct bus_type   *bus;
    struct module           *owner;
    const char              *mod_name;
    bool suppress_bind_attrs;
    enum probe_type probe_type;
    const struct of_device_id       *of_match_table;
    const struct acpi_device_id     *acpi_match_table;
    int (*probe) (struct device *dev);
    void (*sync_state)(struct device *dev);
    int (*remove) (struct device *dev);
    void (*shutdown) (struct device *dev);
    int (*suspend) (struct device *dev, pm_message_t state);
    int (*resume) (struct device *dev);
    const struct attribute_group *const *groups;
    const struct attribute_group *const *dev_groups;
    const struct dev_pm_ops *pm;
    void (*coredump) (struct device *dev);
    struct driver_private *p;
    struct {
      void (*post_unbind_rust)(struct device *dev);
    } p_cb;
 };

🎀 Members 🎀

bestie, let me introduce you to every single field in this struct, no cap:

  • name — the driver's name. it's literally what it says on the tin. iconic branding moment.
  • bus — the bus that this driver's devices belong to. like, which friend group this driver runs with.
  • owner — the module owner. the one holding the leash, so to speak.
  • mod_name — used for built-in modules. lowkey just a lil alias situation.
  • suppress_bind_attrs — disables bind/unbind via sysfs. if this is true, the sysfs bind/unbind files are a no-show. 🚫
  • probe_type — the type of probe (synchronous or asynchronous) to use. whether you wanna slide in sync or async, your call.
  • of_match_table — the open firmware table. for the device tree girlies. 🌳
  • acpi_match_table — the ACPI match table. for the ACPI besties out there.
  • probe — called to query the existence of a specific device, whether this driver can work with it, and bind the driver to a specific device. this is THE moment. the "do you vibe with me" check. if it returns success, the driver gets bound to the device. main character callback fr.
  • sync_state — called to sync device state to software state after all the state tracking consumers linked to this device (present at the time of late_initcall) have successfully bound to a driver. if the device has no consumers, this function gets called at late_initcall_sync level. if the device has consumers that are never bound to a driver, this function will never get called until they do. so like, it's patient but also not. 💀
  • remove — called when the device is removed from the system to unbind a device from this driver. the breakup callback. 😭
  • shutdown — called at shut-down time to quiesce the device. making sure everything's chill before the lights go out.
  • suspend — called to put the device to sleep mode. usually to a low power state. nap time bestie. 😴
  • resume — called to bring a device from sleep mode. wakey wakey. ☀️
  • groups — default attributes that get created by the driver core automatically. the freebies that come with the driver.
  • dev_groups — additional attributes attached to device instance once it is bound to the driver. extra accessories for when the device and driver are officially linked. 🫶
  • pm — power management operations of the device which matched this driver. the whole sleep/wake situation, packaged up.
  • coredump — called when sysfs entry is written to. the device driver is expected to call the dev_coredump API resulting in a uevent. like, dump the core, but make it official. 🔥
  • p — driver core's private data. no one other than the driver core can touch this. literally hands off. 🚫 do not perceive.
  • p_cb — callbacks private to the driver core; no one other than the driver core is allowed to touch this. also off-limits, bestie. don't even look at it.

💖 Description 💖

okay so here's the tea: the device driver-model tracks all of the drivers known to the system. why? the main reason for this tracking is to enable the driver core to match up drivers with new devices. it's basically a matchmaking service but for hardware. 💘

once drivers are known objects within the system, however, a number of other things become possible. like, the glow-up is real. device drivers can export information and configuration variables that are independent of any specific device. so they're not just tied to one device — they're versatile, they're independent, they're slaying on their own terms. periodt.

🔗 SEE ALSO 🔗

go check these out if you wanna go deeper, bestie. iykyk:

this page lives in ./include/linux/device — last updated with love in October 2026, from the kernel homies themselves. stay slay, kernel bestie. 💜🌸✨
📦 where this page comes from