lspci on Mac: SPPCIDataType Is Empty, 8 Devices Exist

I built pciutils 3.15.0 from source on the M4 Mac mini that runs this business, and the build was clean: make exited 0 and produced an lspci binary. Running it printed two lines and quit:

$ ./lspci
pcilib: Cannot open AppleACPIPlatformExpert (add boot arg debug=0x144 & run as root)
lspci: Cannot find any working access method.
$ echo $?
1

The advice in that message doesn't apply to this machine. Root and the boot argument can't help, because the IOKit class the Darwin backend needs is not present on Apple Silicon. The built-in replacement most answers suggest, system_profiler SPPCIDataType, printed zero bytes. Yet the I/O Registry holds eight PCIe devices. This post covers why both fail, what each popular answer returns on macOS 26, and an 18-line shell function that prints an lspci-style list.

lspci on Mac: what the obvious routes return

Everything below ran on 2026-10-04 on a Mac16,10 (Mac mini M4) with macOS 26.4.1 build 25E253, SIP enabled, no sudo, and nothing plugged into the Thunderbolt ports:

$ which lspci
lspci not found
$ system_profiler -listDataTypes | grep -i pci
SPPCIDataType
$ system_profiler SPPCIDataType | wc -c
       0
$ system_profiler SPPCIDataType -json
{
  "SPPCIDataType" : [

  ]
}
$ HOMEBREW_NO_AUTO_UPDATE=1 brew install pciutils
Error: pciutils: no bottle available!
If no compatible bottle is available, you can try to install from source with:
  brew install --build-from-source pciutils

Two things here are misleading. First, the empty SPPCIDataType result is a real answer, not a renamed type like the USB one I tripped over in lsusb on Mac; the name is still in the list. It is empty because of what the reporter chooses to show (more below). Second, Homebrew's error points you toward building from source. The pciutils formula actually says depends_on :linux with the comment "arm64 macOS is not supported", and its only bottles are Linux ones. brew info pciutils didn't mention the Linux requirement either.

Why a source build of pciutils can't read anything

pciutils does have a macOS backend. Its lib/darwin.c carries a 2013 Apple copyright and opens a user client on the IOKit class AppleACPIPlatformExpert, then reads PCI config space through an ACPI address-space call. That class exists on Intel Macs, which boot through ACPI. Apple Silicon Macs boot from a device tree instead, and the platform expert on this machine is a class called J773gAP:

$ ioreg -r -c AppleACPIPlatformExpert | wc -l
       0
$ ./lspci -A darwin -n
lspci: darwin_read: kACPIMethodAddressSpaceRead failed: (ipc/send) invalid destination port

So "add boot arg debug=0x144 & run as root" is Intel-era advice. Setting a boot argument on Apple Silicon also means lowering security in recovery and rebooting, which on a FileVault server I run headless means a trip to the keyboard. I didn't try it, and the upstream thread gives no reason to. pciutils issue #111 has been open since October 2022 with 16 comments. The last one, from April 2023, says the darwin method "requires AppleACPIPlatformExpert which doesn't exist on Apple Silicon", and that the alternative bridge class has no user client there. Nobody in the thread reports a working Apple Silicon build.

What the I/O Registry has instead

IOKit still models every PCIe function as an IOPCIDevice, with the vendor ID, device ID, class code and negotiated link state attached as properties. It just won't let user space read raw config space. Reading those properties is enough for what most people want from lspci. On this Mac there are eight:

ioreg node	vendor:device	Class	Link	pci.ids name
pci-bridge0	106b:100c	0604 bridge	Gen2 x1	Apple Silicon PCI Express Root Port
wlan	14e4:4434	0280 network	Gen2 x1	BCM4388 802.11ax Wireless LAN
bluetooth-pcie	14e4:5f72	0280 network	Gen2 x1	BCM4388 Bluetooth Controller
pci-bridge2	106b:100c	0604 bridge	Gen1 x1	Apple Silicon PCI Express Root Port
lan-1gb	14e4:1682	0200 Ethernet	Gen1 x1	NetXtreme BCM57762 Gigabit Ethernet
pcic0, pcic1, pcic3	106b:1017	0604 bridge	no link	not in pci.ids

The names come from the pci.ids file bundled with pciutils 3.15.0 (dated 2026-04-05). Four of the five distinct IDs resolve. 106b:1017 isn't in that file or in the 2026-10-01 edition I downloaded from the PCI ID project, which only knows the older 1010 "USB4/Thunderbolt PCI Express Root Port". I think the three 1017 bridges are this Mac's Thunderbolt root ports: their slot names are Slot-0, Slot-1 and Slot-3, and system_profiler SPThunderboltDataType lists exactly Bus 0, 1 and 3, each "No device connected". That's an inference from matching numbers, not something Apple documents.

To check that I was decoding the link fields correctly, I compared them with a second source. IOPCIExpressLinkStatus on the Ethernet controller is 4113, or 0x1011: speed code 1 (2.5 GT/s), width 1. system_profiler SPEthernetDataType independently reports the same chip as 0x14e4/0x1682 at "2.5 GT/s" and "x1". The empty Thunderbolt bridges report 0xFFFF, which is what an absent link reads as.

Why SPPCIDataType is empty

System Information's PCI section is for expansion hardware. The strings inside /System/Library/SystemProfiler/SPPCIReporter.spreporter include PCI-Thunderbolt, Thunderbolt@%d,%d,%d, AAPL,slot-name and IOPCITunnelCompatible, which fit a reporter that lists devices in slots or behind Thunderbolt and skips soldered-down ones. A tinygrad issue from April 2026 shows the populated case on an Apple Silicon host: an AMD eGPU appears under SPPCIDataType with vendor 0x1002, device 0x7341 and "Slot: Thunderbolt@...". With no Thunderbolt device attached, the list is empty. I couldn't test the populated case myself because I have no Thunderbolt PCIe device. The empty result is still a fair answer to "what's in my expansion slots". It just isn't lspci, which shows every function on the bus.

The five answers people find, run on macOS 26

The main thread is Ask Different's "Does macOS have equivalent command line tools like lshw or lspci": 26 votes, 63,902 views, five answers, none accepted. I pulled all five through the Stack Exchange API and checked each one on this Mac:

• ioreg -l | grep PCI (17 votes, 2016). This one works, but it printed 350 lines for 8 devices, mostly power-management and interrupt properties. The data is all there; the grep just isn't selective enough.
• system_profiler SPPCIDataType and friends (2 votes, 2023). This printed 0 bytes here, for the reason above. The same answer recommends SPUSBDataType, which macOS 26 renamed, so that one prints nothing too.
• Run lshw inside an Ubuntu Docker container (1 vote, 2019). Docker on a Mac runs Linux in a virtual machine, so lshw would describe the VM's virtual hardware rather than the Mac's. Docker isn't installed here, so I didn't run it.
• dspci from DPCIManager (0 votes, 2017). The last release is 2.0 from April 2019 and the binary is x86_64 only. Its strings show it reads IOPCIDevice properties and pci.ids, the same approach as the function below. Without Rosetta installed, it fails with "Bad CPU type". I didn't install Rosetta to test further.
• "system_profiler" (-1 vote, 2022), with no data type given.

The one answer that works has the fewest specifics. Title searches for lspci on Stack Overflow, Super User and Unix & Linux returned 97 questions, and none of them answers the Mac question.

A shell function that prints lspci-style output

This reads the eight entries directly, decodes the little-endian IDs and the link status, and prints one line per function:

lspci() {
  ioreg -r -c IOPCIDevice -d 1 -l | awk '
    function le16(h) { return substr(h,3,2) substr(h,1,2) }
    function out() {
      if (node == "") return
      gt = "-"
      if (ls != "" && ls != 65535) gt = "Gen" (ls % 16) " x" int(ls / 16) % 64
      else if (ls == 65535) gt = "no link"
      printf "%-12s %s [%s:%s] %-22s %s\n", bdf, cls, ven, dev, node, gt
    }
    /^\+-o / { out(); node = $2; sub(/@.*/, "", node); bdf = ven = dev = cls = ls = "" }
    /"pcidebug" =/   { bdf = $3; gsub(/"/, "", bdf); sub(/\(.*/, "", bdf) }
    /"vendor-id" =/  { h = $3; gsub(/[<>]/, "", h); ven = le16(h) }
    /"device-id" =/  { h = $3; gsub(/[<>]/, "", h); dev = le16(h) }
    /"class-code" =/ { h = $3; gsub(/[<>]/, "", h); cls = substr(h,5,2) substr(h,3,2) }
    /"IOPCIExpressLinkStatus" =/ { ls = $3 }
    END { out() }'
}

$ lspci
0:0:0        0604 [106b:100c] pci-bridge0            Gen2 x1
2:0:0        0280 [14e4:4434] wlan                   Gen2 x1
2:0:1        0280 [14e4:5f72] bluetooth-pcie         Gen2 x1
0:2:0        0604 [106b:100c] pci-bridge2            Gen1 x1
1:0:0        0200 [14e4:1682] lan-1gb                Gen1 x1
0:0:0        0604 [106b:1017] pcic0-bridge           no link
0:0:0        0604 [106b:1017] pcic1-bridge           no link
0:0:0        0604 [106b:1017] pcic3-bridge           no link

It produced identical output in zsh -f, macOS's bash 3.2.57 and /bin/sh, in 0.02 seconds. Two caveats. The first column comes from Apple's pcidebug property, and several entries share 0:0:0 because each root complex numbers its own buses, so don't treat it as a unique address the way you would on Linux. And it can't show what lspci -vv shows from raw config space, such as capability lists or error registers, because user space can't read config space here.

The vendor:device pair is what you need to check whether macOS has a driver for a card, which is how I counted Aquantia IDs in the 10GbE adapter post and the SD reader's two PCI IDs in the SD card reader post. This is the same pattern as lscpu on Mac and lsblk on Mac: the data exists, but the Linux tool can't reach it and the usual replacement answers a narrower question. It's also similar to the dtrace SIP error, where a tool ships and runs but has no access.

FAQ

Is there an lspci command on Mac?

No. macOS doesn't include lspci, and Homebrew's pciutils formula is Linux-only. On Apple Silicon, a source build of pciutils 3.15.0 compiles but fails with "Cannot open AppleACPIPlatformExpert", because that IOKit class only exists on Intel Macs. Use ioreg -r -c IOPCIDevice -l to list PCIe devices instead.

Why does system_profiler SPPCIDataType show nothing?

SPPCIDataType reports expansion devices, meaning cards in slots and PCIe devices attached over Thunderbolt. Built-in Wi-Fi, Bluetooth and Ethernet controllers aren't listed, so on a Mac with no Thunderbolt PCIe device attached the output is empty. The internal devices are still in the I/O Registry under the IOPCIDevice class.

How do I find a PCIe device's vendor and device ID on Mac?

Run ioreg -r -c IOPCIDevice -d 1 -l and read the vendor-id and device-id properties. They're little-endian bytes, so <e4140000> means vendor 0x14e4 (Broadcom). For network chips, system_profiler SPEthernetDataType also shows Vendor ID and Device ID in normal hex.

Method: on 2026-10-04 between about 19:30 and 20:15 KST I ran every command above on a Mac mini M4 (Mac16,10, macOS 26.4.1 build 25E253, SIP enabled) as a normal user with nothing on the Thunderbolt ports. pciutils 3.15.0 was built from the release tarball in a temporary directory (checksum matching the Homebrew formula) and deleted afterwards. Device names come from pci.ids 2026.04.05 and 2026.10.01. The Ask Different answers, votes and views were read through the Stack Exchange API that day. I did not test with sudo, with a Thunderbolt PCIe device attached, with Docker or Rosetta, on Intel Macs, or on macOS 15 and earlier. The claim that the 1017 bridges are the Thunderbolt root ports is my inference from the matching slot and bus numbers.