STRUCT USB_DRIVER(9)

📦 version 7.3.1, in nixpkgs unstable

💅 struct usb_driver(9)

okay so this is from the Kernel API Manual bestie — it's the whole entire glow-up guide to struct usb_driver, aka the thing that tells usbcore "hi yes this driver is here for a USB interface." iconic behavior only.

🌸 NAME

struct usb_driver — it literally identifies a USB interface driver to usbcore. that's the whole vibe. no notes.

✨ SYNOPSIS

struct usb_driver {
    const char *name;
    int (*probe) (struct usb_interface *intf, const struct usb_device_id *id);
    void (*disconnect) (struct usb_interface *intf);
    int (*unlocked_ioctl) (struct usb_interface *intf, unsigned int code, void *buf);
    int (*suspend) (struct usb_interface *intf, pm_message_t message);
    int (*resume) (struct usb_interface *intf);
    int (*reset_resume)(struct usb_interface *intf);
    int (*pre_reset)(struct usb_interface *intf);
    int (*post_reset)(struct usb_interface *intf);
    void (*shutdown)(struct usb_interface *intf);
    const struct usb_device_id *id_table;
    const struct attribute_group **dev_groups;
    struct usb_dynids dynids;
    struct device_driver driver;
    unsigned int no_dynamic_id:1;
    unsigned int supports_autosuspend:1;
    unsigned int disable_hub_initiated_lpm:1;
    unsigned int soft_unbind:1;
 };

🎀 Members

let's go through the whole cast, one by one, main character by main character:

  • name — the driver name, and it's gotta be unique among USB drivers. lowkey the rule is: it should normally be the same as the module name. keep them matching bestie 🫶
  • probe — called to see if the driver is even willing to manage a particular interface on a device. if it is: probe returns zero and uses usb_set_intfdata to associate driver-specific data with the interface. it may also use usb_set_interface to specify the appropriate altsetting. not willing? return -ENODEV. genuine IO errors happened?? return an appropriate negative errno value. nb: the usb_device_id parameter is only valid during probe — do NOT go keeping it around 👀
  • disconnect — called when the interface is no longer accessible. usually that's because its device has been (or is being) disconnected, or the driver module is being unloaded. it's giving "we're so done here" 💀
  • unlocked_ioctl — for drivers that wanna talk to userspace through the "usbfs" filesystem. this lets devices provide ways to expose info to user space regardless of where they do (or don't) show up otherwise in the filesystem. slay for the messy filesystem girlies.
  • suspend — called when the device is gonna get suspended by the system, either from system sleep context or runtime suspend context. ⚠️ the return value will be ignored in system sleep context, so do NOT try to keep using the device if suspend fails there. instead, let the resume or reset_resume routine recover from the failure. like, just let them handle it bestie 🙈
  • resume — called when the device is being resumed by the system. welcome back 🦋
  • reset_resume — called when the suspended device has been reset instead of being resumed. different thing!! don't mix them up!!
  • pre_reset — called by usb_reset_device when the device is about to be reset. 🚨 this routine must not return until the driver has no active URBs for the device, and no more URBs may be submitted until the post_reset method is called. no cap, this one's strict.
  • post_reset — called by usb_reset_device after the device has been reset. order matters, periodt.
  • shutdown — called at shut-down time to quiesce the device. nap time 😴
  • id_table — USB drivers use the ID table to support hotplugging. export it with MODULE_DEVICE_TABLE(usb,...). and this must be set or your driver's probe function will literally never get called. never ever. 😭
  • dev_groups — attributes attached to the device that will be created once it's bound to the driver.
  • dynids — used internally to hold the list of dynamically added device ids for this driver. that's internal business, don't touch 💅
  • driver — the driver-model core driver structure. the structural support beam of the whole fit.
  • no_dynamic_id — if set to 1, the USB core will not allow dynamic ids to be added to this driver, and it does that by preventing the sysfs file from being created.
  • supports_autosuspend — if set to 0, the USB core will not allow autosuspend for interfaces bound to this driver.
  • disable_hub_initiated_lpm — if set to 1, the USB core will not allow hubs to initiate lower power link state transitions when an idle timeout occurs. but device-initiated USB 3.0 link PM will still be allowed. so it's a partial block, not a full block, iykyk.
  • soft_unbind — if set to 1, the USB core will not kill URBs and disable endpoints before calling the driver's disconnect method. spicy 🌶️

🌈 Description

okay the actual rules of the assignment:

USB interface drivers must provide a name, probe and disconnect methods, and an id_table. everything else in the driver fields is optional. those four are the non-negotiables ✨

the id_table is used in hotplugging. it holds a set of descriptors, and specialized data may be associated with each entry. that table is used by both user mode and kernel mode hotplugging support. equal opportunity table.

the probe and disconnect methods are called in a context where they can sleep — but they should avoid abusing the privilege (we all know that girl who naps through everything). most of the work to connect to a device should be done when the device is opened, and undone at the last close. the disconnect code needs to address concurrency issues with respect to open and close methods, as well as forcing all pending I/O requests to complete — by unlinking them as necessary, and blocking until the unlinks complete. so like, actually deal with it, don't just ghost the pending I/O 🔥

💜 SEE ALSO

Kernel file ./include/linux/usb.h and honestly the whole friend group:

and that's the whole page bestie 🎀 this one lives at ./include/linux and it's dated October 2026, page struct usb_driver(9) — screenshot it, cite it, live by it. mwah 💋

📦 where this page comes from