PCI_DEVICE(9)

📦 version 7.3.1, in nixpkgs unstable

💅 PCI_DEVICE(9) — the kernel API manual, bestie edition 🎀

Okay so we're cracking open PCI_DEVICE from the kernel API manual (that's the 9 in PCI_DEVICE(9), iykyk — section 9 is kernel routines) and honestly? It's a little guy with a big job. Let's get into it ✨

🌸 NAME 🌸

PCI_DEVICE — it's a macro, and its whole personality is describing one very specific PCI device. That's it. That's the job. Slay 🫶

✨ SYNOPSIS ✨

PCI_DEVICE (vend , dev );

That's the whole vibe check. Two args, parentheses, semicolon, done 💅

🦋 ARGUMENTS 🦋

  • vend — the 16 bit PCI Vendor ID 🏷️ (yes, 16 bit, keep it cute and keep it small)
  • dev — the 16 bit PCI Device ID 🎀 (also 16 bit, matching energy)

💖 DESCRIPTION 💖

So here's the tea, bestie: this macro builds you a struct pci_device_id that matches one specific device. Like, one. Not a family, not a class, not "whatever shows up" — that exact device and nobody else. Main character energy fr fr 👑

The way it works: the subvendor and subdevice fields get set to PCI_ANY_ID. So it's picky about vendor + device, and completely unbothered about subvendor + subdevice. Iconic behaviour honestly 🌈

Heads up: the 16 bit-ness of both vend and dev is the whole point — these are ID fields, not full addresses. Don't come at them with 32 bits 💀

🔥 SEE ALSO 🔥

Everything below lives in the kernel file ./include/linux/pci.h — one big PCI friend group and you should absolutely go meet all of them 🫶

Okay that's the whole page, you ate that 🍓 This one came from ./include/linux, dated October 2026, and it's PCI_DEVICE(9) signing off — mwah 💋✨

📦 where this page comes from