lspci(8)

from lspci(8), brought to you by The PCI Utilities 💅 welcome bestie, pull up a chair, we're about to read ur hardware's whole aura ✨

👑 NAME 👑

lspci — list all PCI devices 🦋

---

✨ SYNOPSIS ✨

lspci [options]

---

🌸 DESCRIPTION 🌸

okay so lspci is literally the utility that shows u info about all the PCI buses in ur system and every device plugged into them. it's giving inventory energy 💖

by default it shows a brief list of devices. want more? the options below let u request either a more verbose output, or output that's designed to be parsed by other programs (iykyk).

if ur about to report bugs in PCI device drivers, or in lspci itself, pls pls pls include the output of lspci -vvx or — even better — lspci -vvxxx 🫶 (but also, check below for possible caveats, bestie, don't come for me).

ngl some parts of the output — especially in the super verbose modes — are probably only intelligible to experienced PCI hackers 💀. for the exact definitions of the fields, go consult either the PCI specifications or the header.h and /usr/include/linux/pci.h include files.

also important: on many operating systems, access to some parts of the PCI configuration space is restricted to root, so the features of lspci available to normal users are limited. but lspci tries its best to show as much as it can and marks everything else with the text <access denied> 😭. not her fault, she's doing her best.

---

🎀 OPTIONS 🎀

💅 Basic display modes

• -m — dump PCI device data in a backward-compatible machine readable form. see below for the deets.
• -mm — dump PCI device data in a machine readable form that's easy for scripts to parse. also see below.
• -t — show a tree-like diagram with all the buses, bridges, devices and the connections between them 🌳. iconic.

🌈 Display options

• -v — be verbose and show detailed info about all devices.
• -vv — be very verbose and show more details. this level includes everything deemed useful.
• -vvv — be even more verbose and show everything we're able to parse, even if it doesn't look interesting at all (e.g., undefined memory regions). no filter, no shame 💀
• -k — show the kernel drivers handling each device, and also the kernel modules capable of handling it. this is turned on by default when -v is given in the normal mode of output. (currently works only on Linux with kernel 2.6 or newer.)
• -x — show a hexadecimal dump of the standard part of the configuration space (the first 64 bytes, or 128 bytes for CardBus bridges).
• -xxx — show a hexadecimal dump of the whole PCI configuration space. it's available only to root, because several PCI devices crash when u try to read some parts of the config space (this behavior probably doesn't violate the PCI standard, but it's at least very stupid 💀). however, such devices are rare, so u needn't worry much.
• -xxxx — show a hexadecimal dump of the extended (4096-byte) PCI configuration space, available on PCI-X 2.0 and PCI Express buses.
• -b — bus-centric view. show all IRQ numbers and addresses as seen by the cards on the PCI bus instead of as seen by the kernel.
• -D — always show PCI domain numbers. by default, lspci suppresses them on machines that only have domain 0.
• -P — identify PCI devices by their path through each bridge, instead of by bus number.
• -PP — identify PCI devices by their path through each bridge, showing the bus number as well as the device number.

🦋 Options to control resolving IDs to names

• -n — show PCI vendor and device codes as numbers instead of looking them up in the PCI ID list.
• -nn — show PCI vendor and device codes as both numbers and names.
• -q — use DNS to query the central PCI ID database if a device isn't found in the local pci.ids file. if the DNS query succeeds, the result is cached in $XDG_CACHE_HOME/pci-ids and it's recognized in subsequent runs even if -q isn't given any more. please use this switch inside automated scripts only with caution, to avoid overloading the database servers 🫶.
• -qq — same as -q, but the local cache is reset.
• -Q — query the central database even for entries that are recognized locally. use this if u suspect that the displayed entry is wrong.

💜 Options for selection of devices

• -s [[[[<domain>]:]<bus>]:][<device>][.[<func>]] — show only devices in the specified domain (in case ur machine has several host bridges, they can either share a common bus number space or each of them can address a PCI domain of its own; domains are numbered from 0 to ffff), bus (0 to ff), device (0 to 1f) and function (0 to 7). each component of the device address can be omitted or set to "*" — both mean "any value". all numbers are hexadecimal. e.g., "0:" means all devices on bus 0, "0" means all functions of device 0 on any bus, "0.3" selects the third function of device 0 on all buses, and ".4" shows only the fourth function of each device.
• -d [<vendor>]:[<device>][:<class>[:<prog-if>]] — show only devices with the specified vendor, device, class ID, and programming interface. the IDs are given in hexadecimal and may be omitted or given as "*" — both mean "any value". the class ID can contain "x" characters which stand for "any digit".

when -s and -d are combined, only devices that match both criteria are selected. when the same option is used multiple times, the rightmost one overrides the others and a warning is produced.

🍓 Other options

• -i <file> — use <file> as the PCI ID list instead of /usr/share/hwdata/pci.ids.
• -p <file> — use <file> as the map of PCI IDs handled by kernel modules. by default, lspci uses /lib/modules/kernel_version/modules.pcimap. applies only to Linux systems with recent enough module tools.
• -M — invoke bus mapping mode, which performs a thorough scan of all PCI devices, including those behind misconfigured bridges, etc. this option gives meaningful results only with a direct hardware access mode, which usually requires root privileges. by default, the bus mapper scans domain. u can use the -s option to select a different domain.
• --version — shows lspci version. this option should be used stand-alone.

🧚 PCI access options

the PCI utilities use the PCI library to talk to PCI devices (see pcilib(7) for details). u can use the following options to influence its behavior:

• -A <method> — the library supports a variety of methods to access the PCI hardware. by default, it uses the first access method available, but u can use this option to override that decision. see -A help for a list of available methods and their descriptions.
• -O <param>=<value> — the behavior of the library is controlled by several named parameters. this option lets u set the value of any of the parameters. use -O help for a list of known parameters and their default values.
• -H1 — use direct hardware access via Intel configuration mechanism 1. (this is a shorthand for -A intel-conf1.)
• -H2 — use direct hardware access via Intel configuration mechanism 2. (this is a shorthand for -A intel-conf2.)
• -F <file> — instead of accessing real hardware, read the list of devices and the values of their configuration registers from the given file, produced by an earlier run of lspci -x. if file is a single dash (-), read the contents from stdin.

this is very useful for analysis of user-supplied bug reports, because u can display the hardware configuration in any way u want without disturbing the user with requests for more dumps 🫶.

• -G — increase debug level of the library.

---

🌟 MACHINE READABLE OUTPUT 🌟

if ur planning to process the output of lspci automatically, pls pls use one of the machine-readable output formats (-m, -vm, -vmm) described in this section. all other formats are likely to change between versions of lspci 💀.

all numbers are always printed in hexadecimal. if u want to process numeric IDs instead of names, pls add the -n switch.

✨ Simple format (-m)

in the simple format, each device is described on a single line, formatted as parameters suitable for passing to a shell script — i.e., values separated by whitespaces, quoted and escaped if necessary. some of the arguments are positional: slot, class, vendor name, device name, subsystem vendor name and subsystem name (the last two are empty if the device has no subsystem); the remaining arguments are option-like:

• -rrev — revision number.
• -pprogif — programming interface.

the relative order of positional arguments and options is undefined. new options can be added in future versions, but they will always have a single argument not separated from the option by any spaces, so they can be easily ignored if not recognized.

🌈 Verbose format (-vmm)

the verbose output is a sequence of records separated by blank lines. each record describes a single device by a sequence of lines, each line containing a single tag: value pair. the tag and the value are separated by a single tab character. neither the records nor the lines within a record are in any particular order. tags are case-sensitive.

the following tags are defined:

• Slot — the name of the slot where the device resides ([domain:]bus:device.function). this tag is always the first</> in a record.
• Class — name of the class.
• Vendor — name of the vendor.
• Device — name of the device.
• SVendor — name of the subsystem vendor (optional).
• SDevice — name of the subsystem (optional).
• PhySlot — the physical slot where the device resides (optional, Linux only).
• Rev — revision number (optional).
• ProgIf — programming interface (optional).
• Driver — kernel driver currently handling the device (optional, Linux only).
• Module — kernel module reporting that it is capable of handling the device (optional, Linux only). multiple lines with this tag can occur.
• NUMANode — NUMA node this device is connected to (optional, Linux only).
• IOMMUGroup — IOMMU group that this device is part of (optional, Linux only).

new tags can be added in future versions, so u should silently ignore any tags u don't recognize.

💖 Backward-compatible verbose format (-vm)

in this mode, lspci tries to be perfectly compatible with its old versions. it's almost the same as the regular verbose format, but the Device tag is used for both the slot and the device name, so it occurs twice in a single record. pls avoid using this format in any new code 🙈.

📁 FILES 📁

• /usr/share/hwdata/pci.ids — bestie this is THE master list, the holy text, the canon. It's every single known PCI ID: vendors, devices, classes and subclasses, all of it. It's maintained over at https://pci-ids.ucw.cz/, and if you want the freshest version you go grab it with the update-pciids utility. Keep her fed, she deserves it. 🍓
• /usr/share/hwdata/pci.ids.gz — the compressed glow-up version of the same file. If lspci is compiled with support for compression, it gets tried before pci.ids does. Compression girlies stay winning. ✨
• $XDG_CACHE_HOME/pci-ids — every ID that turns up during DNS query mode gets cached in here. It's the little memory jar of your lookups. 🫙

---

💀 BUGS 💀

Okay so, real talk, sometimes lspci just can't decode the configuration registers all the way. Fully not her fault!! 😭 This usually happens when not enough documentation was available to the authors — like, they did their best, the docs just weren't there.

In those cases she at least prints the <?> mark, which is her way of saying "there is potentially something more to say here, i'm not being mysterious on purpose." So if you see <?>, that's the signal. 👀

And if you happen to know the details? Patches are of course welcome. The authors would literally be so grateful. 🫶

Also, heads up: access to the extended configuration space is currently supported only by the linux_sysfs back-end. Nobody else is doing it. Not yet. Periodt.

---

👀 SEE ALSO 👀

Go read your sisters, they ate:

• setpci(8)
• pci.ids(5)
• update-pciids(8)
• pcilib(7)

---

👑 AUTHOR 👑

The PCI Utilities are maintained by Martin Mares <mj@ucw.cz>. Living legend behaviour, no cap. 💅

---

And that's the whole page, bestie!! This was pciutils-3.15.0, dated 05 April 2026, and it's lspci(8) in all her glory. Go run lspci and feel something. 🌸🦋