STRUCT USB_DEVICE_ID(9)

💅 struct usb_device_id — Kernel API Manual, but make it cute

okay so bestie, this is literally the glow-up guide for struct usb_device_id — the little struct that goes "hiii this is my device" when the kernel is probing stuff and hotplugging stuff. it's giving ✨matchmaker✨ energy, no cap.

---

🌸 NAME

struct usb_device_id — identifies USB devices for probing and hotplugging. that's it, that's the whole vibe. it's the little ID card your device waves around so the kernel knows who to hand it to 🫶

---

✨ SYNOPSIS

struct usb_device_id {
    __u16 match_flags;
    __u16 idVendor;
    __u16 idProduct;
    __u16 bcdDevice_lo;
    __u16 bcdDevice_hi;
    __u8 bDeviceClass;
    __u8 bDeviceSubClass;
    __u8 bDeviceProtocol;
    __u8 bInterfaceClass;
    __u8 bInterfaceSubClass;
    __u8 bInterfaceProtocol;
    __u8 bInterfaceNumber;
    kernel_ulong_t driver_info;
 };

look at her. fourteen fields. main character energy fr fr 👑

---

🎀 Members (the whole cast, no one gets cut)

• match_flags — the bit mask that decides which of the other fields actually get used when matching against new devices. any field except driver_info can be used, but ngl some of them only make sense when they're paired up with other fields. this one is usually set by a USB_DEVICE_*() macro, and that macro sets all the other fields in this struct too — except driver_info, which is on its own little journey 🙈
• idVendor — the USB vendor ID for a device. these numbers get assigned by the USB forum to its members. it's the family name, basically 💖
• idProduct — the product ID, and this one is assigned by the vendor themselves. very "my house, my rules."
• bcdDevice_lo — the low end of the range of vendor-assigned product version numbers. also used to identify individual product versions, for a range that consists of a single device. so like, a range of one. iconic 💅
• bcdDevice_hi — the high end of the version number range. and heads up, the range of product versions is inclusive — both ends count, no sneaky exclusions 🎯
• bDeviceClass — the class of the device; numbers assigned by the USB forum. products can choose to implement classes or just be vendor-specific, whichever. device classes specify the behavior of all the interfaces on a device — so it's the whole-device mood, not a per-interface one 🌈
• bDeviceSubClass — subclass of the device. it's associated with bDeviceClass, they're a package deal 🫶
• bDeviceProtocol — protocol of the device. also associated with bDeviceClass. the trio is complete.
• bInterfaceClass — class of an interface; numbers assigned by the USB forum. products may implement classes or be vendor-specific. and this one's different from bDeviceClass, okurrr: interface classes specify behavior only of a given interface — other interfaces on that same device may support other classes. so it's giving per-interface personality 🌸
• bInterfaceSubClass — subclass of the interface. associated with bInterfaceClass. matching set 🎀
• bInterfaceProtocol — protocol of the interface. also associated with bInterfaceClass.
• bInterfaceNumber — number of the interface. composite devices may use fixed interface numbers to differentiate between vendor-specific interfaces. lowkey the bouncer at the club checking which door you go through 💀
• driver_info — holds information used by the driver. usually it holds a pointer to a descriptor that the driver understands, or maybe device flags. the one field the macros don't touch, remember 👑

---

🔥 Description

in most cases, drivers will create a table of device IDs by using USB_DEVICE, or similar macros designed for exactly that purpose. then they export it to userspace using MODULE_DEVICE_TABLE, and hand it over to the USB core through their usb_driver structure. whole pipeline. slay ✨

if you wanna know how the matching actually happens, go see the usb_match_id function — that's the one doing the work. but briefly (because we're being efficient here 💅): you'll normally use one of several macros to help construct these entries. each entry you provide will either identify one or more specific products, or identify a class of products that have agreed to behave the same.

and here's the tip that actually matters: put the more specific matches towards the beginning of your table, so that driver_info can record quirks of specific products. order matters bestie, don't come crying to me when the generic entry eats your special one 😭

---

👑 SEE ALSO

• Kernel file ./include/linux/device-id/usb.h

---

ok so real talk before you go: everything above is exactly what the page says — nothing added, nothing dropped. go forth and match some devices 🦋

---

that's the whole page, mwah 💜 — this was struct usb_device_id(9) from the Kernel API Manual, sourced from ./include/linux/device-id, dated October 2026. ok bye bestie, drink some water 🍓